System and method for digital authorization verification

Abstract

A digital authorization verification system comprises server(s) each having a secure internal server database storing a list of authorized users for a service, a secure distributed ledger shared by the server(s), and a platform communicatively coupled to the server(s) and having a secure internal platform database, the platform configured to encrypt a user identity of a user requesting access to the service for use in verifying, using the distributed ledger and the list of authorized users, an authorization of the user to access the service. A digital authorization verification method comprises, at the platform, receiving the user identity, verifying the authenticity of the user identity using a trusted third party, issuing an encryption key pair comprising a first public key and a first private key specific to the user, and storing a correspondence between the user identity and the first public key in the internal platform database.

Description

SYSTEM AND METHOD FOR DIGITAL AUTHORIZATION VERIFICATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of United States Provisional Patent Application No. 63 / 527,928 filed on July 20, 2023, the contents of which are hereby incorporated by reference.FIELD

[0002] The present disclosure generally relates to verification of user credentials, and in particular to a system and method for digital authorization verification.INTRODUCTION

[0003] Verifying the credentials of a user is a common requirement in today's day-to-day activities. Typically, a user proves her credential by providing a physical token (e.g., driver's license, passport) to a verifier. The verifier then verifies the authenticity and validity of the token and, provides access to the requested services. This way of verifying credentials unnecessarily exposes users’ sensitive information since physical credential tokens often contain much more information than is necessary for their intended tasks. A malicious verifier can aggregate users’ private information over time if the users provide a variety of credentials to access the services with the verifier.

[0004] The same problem persists with the use of digital tools. When a shared register (e.g., distributed ledger) is used to collect the verification request, for validation by the public authority, and finally for the presentation of this authorization, any personal information contained within the authorization is revealed to all the users of the register. The privacy issue when using a distributed ledger for verification is illustrated in FIG. 1.

[0005] Secure digital identities have been the topic of much interest recently. Sovrin is a blockchain-based global identity solution. However, the system's trust depends on a network of Stewards (consensus nodes) that is currently under development. uPort is an identity framework that uses Ethereum™ smart contracts to store uPort identities. However, an issuer of attestations can see how the attestation is being used and can thus build a profile of a user. ShoCard is a digital identity card whose cryptographic hashes are stored on a Bitcoin blockchain. Also, it uses a centralized ShoCard server to exchange records, which is a single point of failure and a target for several attacks on the system. EverlD is an identity management system developed on a private Ethereum™ using proprietary datagrams but it fails to meet data minimization as credential verification requires full disclosure of data.

[0006] The World Wide Web Consortium (W3C) suggests representing an entire credential as claims using specific entities such as distributed identifiers to develop verifiable credentials which enables properties such as selective disclosure, anonymity, etc. However, the representation of the credentials as claims is not practically implemented and is currently under development.

[0007] Decentralizing identity is another proposed solution having an integrative identity architecture that considers privacy by design concept. However, the architecture relies on external (trusted) authorities for the portability of digital credentials and attestation services.

[0008] Decentralized Trusted Identity (DTI) assumes a service that proves the user's identity and records his digital identity on the blockchain. Proving of the user's identity relies on a traditional trusted credential verification method and it requires the presence of an external trusted authority. Following the same line of reasoning, several studies assume that the existing identities such as driver's license, passport, etc., need to be transformed into a customized format to implement their works.

[0009] Therefore, there is a need for improvement.SUMMARY

[0010] A novel distributed framework is provided to issue and manage digital badges to users that minimizes the scope of the information shared. A digital badge is a statement made about a user. These badges are certified and issued on demand by a party in authority such as a governmental authority for the benefit of their users. The users control the release of their digital badges.

[0011] One embodiment is developed considering the architecture of a smart city platform. Integrating the proposed framework on smart city platforms allows the platform users to use digital badges to share only necessary data. The digital badges are publicly verifiable, tamper-evident and traceable. In addition, the digital badges may be used to create platform dependent tokens such as a smart resident card to extend their usability.

[0012] Smart contracts may be used to present, evaluate and enforce the conditions for issuing and managing the digital badges. In one implementation, Ethereum™ smart contracts may be used.

[0013] In accordance with an aspect, there is provided a digital authorization verification system comprising one or more servers, each server having a secure internal server database storing a list of authorized users for a service specific to the one or more servers, a secure distributed ledger shared by the one or more servers, and a platform communicatively coupled to the one or more servers and having a secure internal platform database, the platform configured to encrypt a useridentity of a user requesting access to the service for use in verifying, using the distributed ledger and the list of authorized users, an authorization of the user to access the service.

[0014] In at least one embodiment in accordance with any previous / other embodiment described herein, the platform comprises at least one platform processor, and a platform memory storing instructions which when executed by the at least one platform processor configure the at least one platform processor to perform a registration procedure comprising receiving the user identity from a user device, verifying an authenticity of the user identity using a trusted third party, issuing an encryption key pair comprising a first public key and a first private key specific to the user, and storing, in the secure internal platform database, a correspondence between the user identity and the first public key.

[0015] In at least one embodiment in accordance with any previous / other embodiment described herein, the at least one platform processor is configured to perform a badge request procedure comprising receiving from the user device a request for an authorization badge to access the service, the request including the first public key and an indication of the service, verifying the user identity of the user requesting access to the service, and upon successful validation of the user identity, transmitting the request to a given one of the one or more servers associated with the service for which the request for the authorization badge is received.

[0016] In at least one embodiment in accordance with any previous / other embodiment described herein, the given server has a second public key and a second private key associated therewith, further wherein the at least one platform processor is configured to perform the badge request procedure further comprising obtaining the user identity using the correspondence between the user identity and the first public key, encrypting the user identity with the second public key, thereby generating an encrypted user identity, and recording the request for the authorization badge to the distributed ledger.

[0017] In at least one embodiment in accordance with any previous / other embodiment described herein, the given server comprises at least one server processor, and a server memory storing instructions which when executed by the at least one server processor configure the at least one server processor to perform the badge request procedure further comprising decrypting the encrypted user identify using the second private key, verifying the authorization of the user to access the service based on the list of authorized users for the service, and in response to the authorization of the user being verified, generating the authorization badge, recording the authorization badge to the distributed ledger, and transmitting the authorization badge to the at least one platform processor.

[0018] In at least one embodiment in accordance with any previous / other embodiment described herein, subsequent to generating the authorization badge, the at least one server processor is configured to request at least one signing authority to digitally sign the authorization badge.

[0019] In at least one embodiment in accordance with any previous / other embodiment described herein, the distributed ledger has smart contracts residing thereon, and the at least one platform processor is configured to invoke the smart contracts to perform the badge request procedure.

[0020] In at least one embodiment in accordance with any previous / other embodiment described herein, the distributed ledger has smart contracts residing thereon, and the at least one server processor is configured to invoke the smart contracts to perform the badge request procedure.

[0021] In at least one embodiment in accordance with any previous / other embodiment described herein, the smart contracts comprise a request contract configured to coordinate production of the authorization badge by calling at least another one of the smart contracts, an access control contract configured to evaluate one or more access conditions associated with the authorization badge, a badge contract configured to create the authorization badge, and a signing contract configured to get the authorization badge digitally signed by at least one signing authority.

[0022] In at least one embodiment in accordance with any previous / other embodiment described herein, the at least one platform processor is configured to receive a plurality of requests for authorization badges for different services, and perform the badge request procedure for each request of the plurality of requests.

[0023] In at least one embodiment in accordance with any previous / other embodiment described herein, the distributed ledger is a public permissioned blockchain, and the one or more servers comprise a network of consensus nodes using a consensus protocol to achieve consensus of transactions on the distributed ledger.

[0024] In accordance with another aspect, there is provided a computer-implemented method for digital authorization verification, the method comprising receiving, by a platform in a digital authorization verification system, from a user device, a user identity of a user requesting access to a service, verifying, by the platform, an authenticity of the user identity using a trusted third party, issuing, by the platform, an encryption key pair comprising a first public key and a first private key specificto the user, and storing, by the platform in a secure internal platform database ofthe platform, a correspondence between the user identity and the first public key.

[0025] In at least one embodiment in accordance with any previous / other embodiment described herein, the method comprises performing a badge request procedure comprising receiving, by the platform, from the user device, a request for an authorization badge to access the service, the request including the first public key and an indication of the service, verifying the user identity of the user requesting access to the service, and upon successful validation of the user identity, transmitting the request to a given one of the one or more servers associated with the service for which the request for the authorization badge is received.

[0026] In at least one embodiment in accordance with any previous / other embodiment described herein, the given server has a second public key and a second private key associated therewith, wherein performing the badge request procedure further comprises obtaining, by the platform, the user identity using the correspondence between the user identity and the first public key, encrypting, by the platform, the user identity with the second public key, thereby generating an encrypted user identity, and recording, by the platform, the request forthe authorization badge to a secure distributed ledger shared by the one or more servers.

[0027] In at least one embodiment in accordance with any previous / other embodiment described herein, performing the badge request procedure further comprises decrypting, by the given server, the encrypted user identity using the second private key, verifying, by the given server, the authorization of the user to access the service based on a list of authorized users for the service stored in a secure internal server database of the one or more servers, and, in response to the authorization of the user being verified, generating, by the given server, the authorization badge, recording, by the given server, the authorization badge to the distributed ledger, and transmitting the authorization badge to the at least one platform processor.

[0028] In at least one embodiment in accordance with any previous / other embodiment described herein, the method comprises, subsequent to generating the authorization badge, requesting, by the given server, at least one signing authority to digitally sign the authorization badge.

[0029] In at least one embodiment in accordance with any previous / other embodiment described herein, the platform is configured to invoke smart contracts residing on the distributed ledger to perform the badge request procedure.

[0030] In at least one embodiment in accordance with any previous / other embodiment described herein, the server is configured to invoke smart contracts residing on the distributed ledgerto perform the badge request procedure.

[0031] In at least one embodiment in accordance with any previous / other embodiment described herein, the method comprises receiving, by the platform, a plurality of requests for authorization badges for different services, and performing, by the platform, the badge request procedure for each request of the plurality of requests.

[0032] In various further aspects, the disclosure provides corresponding systems and devices, and logic structures such as machine-executable coded instruction sets for implementing such systems, devices, and methods.

[0033] In this respect, before explaining at least one embodiment in detail, it is to be understood that the embodiments are not limited in application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. Also, it is to be understood that the phraseology and terminology employed herein are forthe purpose of description and should not be regarded as limiting.

[0034] Many further features and combinations thereof concerning embodiments described herein will appear to those skilled in the art following a reading of the instant disclosure.DESCRIPTION OF THE FIGURES

[0035] Embodiments will be described, by way of example only, with reference to the attached figures, wherein in the figures:

[0036] FIG. 1 illustrates an example of a verification of a digital badge in a distributed ledger;

[0037] FIG. 2 illustrates a platform that encrypts the identity of the user using a key specific to the public service performing the verification, in accordance with some embodiments;

[0038] FIG. 3 illustrates the process of registering a user in a system model of distributed and verifiable digital badges, in accordance with some embodiments;

[0039] FIG. 4 illustrates a system model of distributed and verifiable digital badges, in accordance with some embodiments;

[0040] FIG. 5 illustrates a variation of the system model of FIG. 4 for different levels of trust;

[0041] FIG. 6A illustrates, in a call flow diagram, an example of registration of distributed and verifiable digital badges, in accordance with some embodiments;

[0042] FIG. 6B illustrates, in a call flow diagram, an example of requesting a distributed and verifiable digital badge, in accordance with some embodiments;

[0043] FIG. 7 is a flowchart illustrating the operation of the Request Contract (RC);

[0044] FIG. 8 is a flowchart illustrating the operation of the Access Control Contract (ACC);

[0045] FIG. 9 is a flowchart illustrating the operation of the Badge Contract (BC);

[0046] FIG. 10 is a flowchart illustrating the operation of the Signing Contract (SC);

[0047] FIG. 11A illustrates an example of a smart resident card with a QR code and the subscription information view on a mobile device, in accordance with some embodiments;

[0048] FIG. 11 B illustrates an example smart resident card offered by a smart city, in accordance with some embodiments; and

[0049] FIG. 12 is a schematic diagram of a computing device such as a server or other computer in a device.

[0050] It is understood that throughout the description and figures, like features are identified by like reference numerals.DETAILED DESCRIPTION

[0051] Embodiments of methods, systems, and apparatus are described through reference to the drawings. Applicant notes that the described embodiments and examples are illustrative and nonlimiting. Practical implementation of the features may incorporate a combination of some or all of the aspects, and features described herein should not be taken as indications of future or existing product plans.

[0052] Personal information is commonly recorded in a physical token that is used as an identity by a user. Typical examples of a physical token are: driver's license, passport, health card, resident card, etc. In many cases, users are required to present such a physical token to service providers in order to avail their services. Generally, a physical token cannot be used without revealing the totality of the identity of the token holder. This traditional way of proving identity reveals much more information than is strictly necessary, since the user cannot control the release of each datum on the identity card. For example, if Alice wants to prove that she is over 18, she shows the service provider an identity card such as driver's license or resident card. In addition to ensuring that Alice is over 18 or not, producing her driver's license additionally reveals her date of birth, her address, and otheridentifying information. This exposes the user to the risks of loss of privacy, identity theft, impersonation and fraud.

[0053] The rapid development of internet technologies encourages the digitization of almost every service offered by governmental bodies (e.g., municipalities). The simultaneous growth in the population living in urban areas increases the interest in adopting smart concepts such as smart city platforms to improve citizens' living and working standards. Smart city platforms group several systems and / or subsystems that interact to optimize resource utilization and achieve efficient management of the services offered by a city or municipality. These platforms act as a single window system to connect the authorities (e.g., city), various service providers (e.g., Library, Health services) and the users (citizens). They also provide citizens access with the most essential personalized city services on disposal using technology solutions such as mobile applications. The mobile applications channels the users (citizens) requests seamlessly to the city services through the smart city platform.

[0054] For instance, Alice is a user of a smart city platform and wants to update her address with the health services, library and community center. Alice supplies her new address along with necessary proofs (tokens) to the smart city platform using the mobile application. The smart city platform checks whetherthe request is valid and if all the supporting proofs (e.g., driver's license) are attached in the correct format. The platform then sends the request to the health services, library and community center to update Alice's address. Once the address is updated, the response (i.e., the address is updated) is notified back to Alice. Nevertheless, the smart city platforms involve exchange of huge amounts of citizens sensitive information while interacting with various entities on the platform.

[0055] A digital badge is provided based on a distributed ledger making it possible to verify an authorization without disclosing additional information to the verifier and in particular without disclosing the identity of the user (e.g., verification of a vaccination status without revealing the name or other personal information about the person).

[0056] FIG. 2 illustrates a platform that encrypts the identity of the user requesting the public service using a key specific to the public service performing the verification, in accordance with some embodiments. Despite the use of a distributed ledger, the identity is never disclosed to other users of the ledger since the encrypted user identity is used for verifying the user’s authorization to access the service. Thus, a decentralized framework is proposed to provide minimal leakage of users private information when their tokens are shared to avail services from the service providers on a smart city platform. The proposed framework is developed considering the architecture of a smart city platform. The platform provides the business logic framework to support: verification of the users, the exchangeof information, interface with trusted entities, use of business logic to compute answers and programmatically automate the process. The platform also has a dedicated mobile application through which the citizens can register and manage their city services' subscriptions, and interact with the city via the platform.Smart city platforms

[0057] A mobile application of a smart city platform connects the users to the platform and thereby to the city. The mobile application provides a range of functionalities including creating a pair of public and private keys used to represent a user uniquely in the system, attaching signatures and public key certificates with the queries, receiving and storing digital badges in a secure location, sharing them at the request of the users.

[0058] Most smart city platforms available in the market use centralized architectures to implement and manage their operations. In a centralized architecture, the smart city platform acts as a trusted entity between the citizens and the services provided and offered by third-party service providers and the city. The platforms are responsible for receiving requests, processing and evaluating them according to the defined access rules, and enforcing other conditions on usage. The centralized architecture is popularly adopted because it is easy to setup and manage, and is cost efficient. It also requires a looser coordination between peers. However, the downsides of using a centralized architecture especially in the context of smart city platforms are as follows.Trust

[0059] Smart city platform users (citizens, service providers and city) need to trust the platform to share their sensitive information via the platform.Closed system

[0060] Most of the operations, business logic and data management in a centralized architecture are not transparent which raises trust issues. In addition, verifiability of information (e.g., authenticity of an issuing authority) is not easy, especially in-case of a dispute (e.g., allegations on issuing a token or using users private information) the auditing will be internal and closed (i.e., access is limited to a set of authorized personals).Single point of failure

[0061] If a centralized smart city platform experiences down time, the functionality of every service will be affected.Conflicting responsibilities

[0062] Since the platforms are responsible for the functioning of the whole eco-system, it may have conflicts of interest during certain operations. For example, to guarantee privacy, users information should not be visible to anyone except the intended party. But, to identify an individual, the platform may have to store and access some information about the users.Targeted attacks

[0063] Since the platform is a single point of contact for both the service providers and the users, it attracts targeted attacks such as denial of services. To avoid the above shortcomings, a blockchainbased architecture with a decentralized network of computing nodes is considered. The characteristics of a blockchain technology, namely immutability, transparency, public verifiability and Integrity create trust among multiple mistrusting entities that want to interact with other. The distributed nature of execution guarantees maximum up-time and a fault tolerant system.Blockchain and Smart Contracts

[0064] A blockchain is a decentralized, distributed, and often times public, trusted ledger that records transactions across the system in a sequential form. Transactions are stored in units (blocks) which include a hash of the previous blocks. As illustrated in FIG. 4, a set of nodes called Consensus nodes 412, can use a consensus protocol (e.g., PBFT, RAFT) and are responsible to agree on the ordering of blocks and maintain a consistent view in all nodes, so that any involved record cannot be altered retroactively, without the alteration of all subsequent blocks. Blockchains are of three types: public, private and permissioned blockchains. Typical characteristics of a blockchain include immutability, traceable, verifiability, transparency and decentralized trust.Types of blockchain networksPublic blockchain

[0065] The distinction between public and private blockchain is who is allowed to participate in the network, execute the consensus protocol and maintain the shared ledger. A public blockchain network is completely open and anyone can join and participate in the network. The network typically has an incentivizing mechanism to encourage more participants to join the network. E.g., Bitcoin, Ethereum™.Private blockchain

[0066] A private blockchain network requires an invitation and must be validated by either the network starter or by a set of rules put in place by the network starter. Businesses who set up a private blockchain, will generally set up a permissioned network. This places restrictions on who is allowed to participate and what transactions they may perform. Participants need to obtain an invitation or permission to join. The access control mechanism could vary: existing participants could decide future entrants; a regulatory authority could issue licenses for participation; or a consortium could make the decisions instead. Once an entity has joined the network, it will play a role in maintaining the blockchain in a decentralized manner.Permissioned blockchain

[0067] Permissioned blockchains allow for a mix between the public and private blockchains and support many customization options. These include allowing anyone to join the permissioned network after suitable verification of their identity, and allocation of select and designated permissions to perform certain activities on the network. In permissioned blockchains, data is stored according to an access policy that is written by the blockchain administrators. The policy determines the read and write accesses of users and parts of a transaction that will be observable to parties. The task of executing and verifying transactions is performed by a designated set of nodes (C-nodes in the proposed design), e.g., Ripple, Corda, Hyperledger fabric.Public-Permissioned blockchain

[0068] In this hybrid type of blockchain, "public" means that everyone can be a user. In other words, the data and functions (smart contracts) published on a public blockchain can be viewed and verified by anyone. A public permissioned blockchain, referred to herein as a city blockchain or C- chain, may be considered as public to allow anyone who needs to access the blockchain content such as public keys of the issuing authority, schema of digital badges, etc., for verifying a digital badge. Also, interested parties can view the various smart contracts deployed on C-chain and their functionality. Permissioned means that the network nodes that ensure (or achieve) consensus of transactions on the ledger are governed, in this case services of a city. The smart city is the administered party that will be able to interact and trigger smart contracts execution on the blockchain. This facilitates that no unauthorized party involve in interfering with the blockchain functionality.Smart contract

[0069] A smart contract is a public piece of code that resides on the blockchain and specifies a protocol that is run on the underlying consensus computer, a process that guarantees trusted execution. Smart contracts provide an attractive solution to achieve distributed and trustworthy operations for smart city platforms. A smart contract is normally deployed in byte-code and uses Application Binary Interface (ABI) to represent its functions. A smart contract includes data and functions that can be invoked by the smart city's transactions, or by other smart contracts through passing messages. A transaction is a package of data that is signed by an account and is aimed at another account, or to execute the ABIs of a contract. A message is similar to a transaction, but is sent by a contract to another contract to run the ABIs of the contract.Distributed and Verifiable Digital Badges

[0070] A distributed framework is proposed to issue and manage digital badges that smart city platform users can use to share and manage their information (tokens) on the platform, according to their preferences. A digital badge (also referred to herein as an authorization badge) is a certified statement made about a user and issued by an authorized entity (for e.g., health services is responsible for issuing health related digital badges) for the benefit of their users. This may be an element of personal identification (e.g., date of birth or proof of residency in a municipality), or membership in a sponsored group, or any other information which the issuer is willing to certify.

[0071] The proposed framework can complement existing smart city platforms on the market, providing an added value to the residents. In some embodiments, a framework is incorporated in a smart city platform. Reference will now be made to FIG. 3 and FIG. 4 to describe the proposed framework.Registration Step

[0072] Referring to FIG. 3, a citizen 301 who wishes to use the digital badge service first installs the smart city mobile application on their device and requests to the broker 302 the creation of an account with a personal identifier (arrow 1 in FIG. 3). The broker 302 replies with a token (arrow 2) that the citizen 301 (also called “Alice” herein) presents to a trusted authority (TA) 303 (arrow 3). Among other things, the token contains a one-time symmetric encryption key, encrypted with the authority’s public key, which will be used to encrypt the authority’s reply.

[0073] The citizen 301 also provides a government issued identity and authenticates themselves to the authority 303. Upon successful verification of the identity, the authority 303 generates a number of designator tickets (DT). Each DT is signed by the TA 303, is destined to a consensus node (reference 412 in FIG. 4), and is encrypted with that node’s public key. It may contain:the name of the consensus node• the ID of the user (called the designator) on this consensus node• a timestamp and validity duration

[0074] After expiration of a DT, the corresponding consensus node being sent this ticket will refuse to generate a badge for the user, which will require a re-validation of the user’s credentials by the trusted authority 303. For instance, one may require a re-authentication of the designators every year.

[0075] A TA 303 may generate one or more designator tickets. This collection of designator tickets is then encased in a verified designator ticket (VDT), which is destined to the broker 302. It can either be transmitted directly to the broker 302 by the TA 303, (arrow 4), or sent back to Alice (i.e. the citizen 301) which has to relay it to the broker 302. The VDT is signed by the TA 303, encrypted and destined to the broker 302, so Alice cannot peruse or modify its contents.

[0076] The broker 302 then stores into a secure local database 304 the association between the citizen’s ID on the platform, and the designator tickets associated to this citizen 301 for each consensus node. The mobile app issues a private and public key pair, and the public key is stored by the broker 302 in association with this user ID.

[0077] This registration step (or procedure) may be repeated multiple times for multiple trusted authorities. In such a way, validated credentials for multiple TA 303 can be stored for the same user ID.Digital Badge Request Process

[0078] FIG. 4 illustrates a system model 400 of distributed and verifiable digital badges, in accordance with some embodiments. The use of blockchains and smart contracts 430 are shown. In the embodiment shown, the smart contracts 430 residing (i.e. deployed) on the blockchain 420 comprise Request Contract (RC) 431 , Access Control Contract (ACC) 432, Badge Contract (BC) 433, Signing Contract (SC) 434, and Request Data Contract (RDC) 435. The blockchain makes it possible to ensure the integrity of the badges thanks to the consensus nodes made up of the servers of the authorities issuing badges. Smart contracts, on the other hand, contain the code that is used to carry out the verification in the databases of the authorities (e.g., the validity of a driver’s license). The public existence of this code ensures the integrity of the badge creation and verification process.

[0079] More precisely, the architecture of the system is composed of the following elements.

[0080] A public permissioned blockchain, and referred to as a city blockchain or C-chain 420. The C-chain 420 is established and managed by a set of city service providers. The C-chain 420 will be used to store, (i) information about the digital badges (name of the badge, conditions to get the badge, validity period, attributes of the badge issuing authority (e.g. public key, website)), (ii) access control policies (e.g., badge can be accessed by users with attribute) that governs the access rules and conditions to the badges, (iii) badge verification methods and process (e.g., how to read a badge's QR code, issuing authority public key look up process), (iv) information about the signing authorities (e.g., list of authorities signed a badge), and (v) authenticated supplementary information (e.g. status of a badge, such as “issuing” or “stopped”) for evaluation of the policies.

[0081] A set of public services, called the Consensus nodes or C-nodes 412. Each service in the system represents a consensus node 412 in the blockchain network running a full instance of the blockchain software; each consensus node 412 communicates with the other consensus nodes 412. Public services receive digital badge requests from a broker 408 (each badge request being received at the broker 408 from a user device), and are responsible for verifying the authenticity of the identity of a citizen 402 subscribed to the service (the identity being received form the user device), verifying (the signature of the signer) and validating (conditions that are to be satisfied) the received request. If the request passes verification and validation requirements, it is submitted to other C-nodes 412 for approval and publication on the C-chain 420. Establishing such a C-chain 420 will be an attractive proposition for both the city services and smart city, and can be further used as a platform for new paid services. Using the city services for secure identity verification is well justified as the services have long-term relationship with the citizens 402, and can implement secure identity verification mechanisms based on these relationships. A digital badge is then generated and signed.

[0082] A smart city platform, called in the following the Broker 408. The platform is responsible for collecting identifiers of users on various public services, receiving one or more requests for digital badges (where, in some embodiments, several requests for badges for different services may be received by the platform), forwarding such requests to appropriate consensus nodes, and optionally relaying the produced badges back to the users.

[0083] A set of users of the platform, called the Citizens 402. Citizens 402 have confidential information collected about them on various public services, and are the subject and the requesters of digital badges.

[0084] A set of digital badge consumers, called the Verifiers 414. Verifiers are the end point of the process of producing a digital badge, and are the ones requiring the information contained in the badge for their operation.

[0085] One or more Signing Authorities 418, which are trusted entities that can apply additional signatures to a digital badge to attest to its authenticity. Again, the role of consensus node 412 and signing authority 418 can be shared by the same entity.

[0086] It is assumed that each entity X is in possession of a private-public key pair for an arbitrary encryption scheme, labelled in the following PUX,PRX). Public keys may be known by each entity, while private keys remain secret and only known from their owners.

[0087] All the operations for requesting a badge are performed through the exchange of tickets. Each ticket may be made of:• a one-time symmetric encryption key, encrypted with the public key of the ticket’s recipient• a set of two elements, encrypted with the one-time session key: 1) the ticket’s payload, is typically a tuple made of variable elements depending on the actual ticket type; 2) the ticket’s signature, which is a digest of the ticket’s payload signed with the issuer’s private key. This mechanism could be replaced by other forms of authenticity checks, such as the use of an HMAC.

[0088] To avoid the replay of a ticket, its payload may contain a pair of elements which correspond to the timestamp of the moment when the ticket is generated, and the maximum time the ticket should be considered valid. In the following, to avoid clutter, we shall only define the payload of each ticket, as the rest of its contents can be reconstructed by knowledge of the sender and the receiver.

[0089] FIG. 4 describes the process that takes place when the citizen 402 (hereby called “Alice”) requests the generation of a digital badge, to be used by the verifier 414 (hereby called “the library”). FIG. 4 shows the relationships and communications occurring between the various elements of the system, including the C-chain 420.

[0090] Unless mentioned otherwise, all communications between peers described in the following are encrypted with a one-time randomly generated session key for a symmetric encryption algorithm. The one-time key itself is encrypted with the public key of the recipient. In addition, each request and response message is hashed and signed with the issuer’s private key. This mechanism allows the confidentiality, authenticity and integrity of each message, without the need for a dedicated secure communication channel.

[0091] As previously noted, in some embodiments, the C-chain 420 will perform the following tasks: (i) handling requests from the interested users via a smart city for a digital badge (arrow orstep 3 in FIG. 4), (ii) evaluate access conditions using the stored access policies, (iii) enforce the access decision (e.g., triggering next step in the process flow that may be either rejecting the request or going ahead with creation of the badge, steps 4-5), (iv) create the requested badge, if the requester meet the access conditions, and send it for signing (steps 6-7), as well as (v) finally, delivering the badge to the user via the smart city (step 8).

[0092] First, the verifier 414 requests the validation of an assertion about a user (i.e. citizen 402) (step 1). This request is then forwarded by the user 402 to the broker 408 (step 2). The broker 408 verifies each request for information such as the requester's identity, the badge requested, digital signature, access conditions, etc.

[0093] Upon successful validation of the information, the broker 408 forwards the request (step 3) to the municipal service responsible for issuing the badge in question. Each service (issuing authority) in the system represents a consensus node 412 in the blockchain network running a full instance of the blockchain software and communicates with the other consensus nodes.

[0094] The service responsible to produce the digital badge validates the citizen's information and fetches the required inputs from its internal database (referred to herein as an Oracle 415) to generate the badge (steps 4-5). For example, to issue a COVID19 immunization digital badge, the health care system verifies a patient's immunization record and issues the badge if the patient is fully vaccinated.

[0095] Then the badge is sent by the consensus nodes 412 to a signing authority 418 (step 6) that will digitally sign the badge and return it to the consensus nodes 412 (step 7). In most cases the signing authority 418 is the same as the service responsible for producing the badge, but this is not mandatory. The digital badge is encrypted using a one-time symmetric encryption key, and published in encrypted form as a new node on the blockchain. Finally, this badge is also delivered (step 8) to the citizen 402 through the broker 408. This completes the transaction on the blockchain network.

[0096] The broker 408 receives the badge, which it first encrypts with a session key destined for the verifier 414. This encrypted badge is then encrypted once more, along with a clear copy of the badge, with a session key destined for the citizen 402. This payload is then transmitted to the citizen 402 (step 9).

[0097] The citizen 402 can check the authenticity of the badge by checking the digital signatures and verifying the respective keys of the issuing authority on the blockchain (optional step 11). If the citizen 402 accepts the badge as legitimate, it can then provide the other (encrypted) copy of the badge to the verifier 414 (step 10).

[0098] The verifier 414 can decrypt this badge, and then check its authenticity by checking the digital signatures and verify the respective keys of the issuing authority on the blockchain (optional step 12).

[0099] A variation on this exchange, illustrated in FIG. 5, can be considered. The architecture of the system of FIG. 5 comprises a citizen 502, a database 506, a broker 508, consensus nodes 512, a verifier (or library) 514, an Oracle 515, a signing authority 518, a public permissioned blockchain 520, and smart contracts 530 residing (i.e. deployed) on the blockchain 520, the smart contracts 530 including RC 531 , ACC 532, BC 533, SC 534, and RDC 535. In this model, steps 1-7 unfold in the same manner as described above with reference to FIG. 4. However, the badge is not sent to the broker 508, but is transmitted directly from the consensus node 512 to the citizen 502 (step 8).Adversarial Model

[0100] The following assumptions may be made about the adversarial mode: (i) Citizens - Malicious, (ii) Trusted Authority (TA) - Trusted, (iii) blockchain facilitator (smart city) - Honest but curious, (iv) Consensus nodes - Honest but curious, (v) SA- Honest but curious, (vi) Verifiers - Honest but curious, and (vii) smart city app - Trusted and tamper-proof.

[0101] It is assumed that the agent (i.e. the smart city mobile app) as implemented is tamper- evident and will run as specified. It is also assumed that the TA is trusted and that it follows the protocol faithfully. However, the users may not be trusted (and indeed may be malicious): they may request badges to which they are not entitled. They are also interested in learning details of other users in the system through their interaction with the blockchain, or through transactions that may have been unsuccessful. The consensus nodes and other authorities are honest but curious: they follow the prescribed protocol, but aim to learn additional information about the entities involved in a transaction. It may be assumed that the communication among the entities in the system is secure (e.g., is over TLS).Trust model

[0102] The trust model for the proposed data sharing system is as follows.

[0103] The verifier trusts the issuer to issue the badges that it receives. To establish this trust, a badge is expected to either:

[0104] include a proof establishing that the issuer generated the badge (e.g., digital signature), or

[0105] have been transmitted in a way clearly establishing that the issuer generated the badge and was not tampered with in transit or storage.

[0106] All entities trust the blockchain to be tamper-evident and to be a correct record of which data is controlled by which entities.

[0107] The user and verifier trust the broker to issue true credentials about the user, and to revoke them quickly when appropriate.

[0108] No party needs to trust the verifier.Smart Contracts

[0109] As discussed above, the various processes needed to request a badge, evaluate the access conditions, connect to an external data source (e.g., website), create a badge and deliver it are rendered as smart contracts that are stored on the blockchain and executed by the consensus nodes network. The smart contracts 430 of FIG. 4 (RC 431 , ACC 432, BC 433, SC 434 and RDC 435) all have a self-destruct method (that makes the smart contract inaccessible), that can be invoked by the owner (i.e. the smart city) of the contract. The functionalities of each smart contract are discussed below.Setup and Registration

[0110] FIG. 6A illustrates, in a call flow diagram 600, an example of a method of registration of distributed and verifiable digital badges , in accordance with some embodiments. The method is as follows:

[0111] • Alice would like to use digital badges to share her information, for this:

[0112] - She installs the smart city mobile app 601 , and signs-up using her email address and providing some basic personal information such as name, date of birth, gender, etc.

[0113] - After sign-up, the smart city mobile app 601 generates a public and private key pair forAlice at 610.

[0114] - The smart city app 601 communicates with the broker 602, by sending Alice’s identifier on the platform and her public key at 611. The broker 602 stores the public key associated to Alice’s ID 612 in the database 604.

[0115] - The broker 602 then generates a token destined to a trusted authority (TA) 603 at 613, and transmits the token to the smart city app at 614.

[0116] - Alice will then digitally submit at 615: (i) her supporting identification documents (e.g., driver's license, passport, immigration documents, public key, etc.), (ii) a proof of public-key ownership (e.g., a digitally signed message using the keys) and (iii) the token generated by the broker 602 to the TA 603.

[0117] • On successful verification of the identity and the confirmation of the public-key ownership, the TA 603 will:

[0118] - Generate at 616 a designator ticket and send it to the broker 602 at 617. The broker 602 stores this ticket in its database (table) 604 and associates it to Alice’s identifier at 618.

[0119] -The database is managed and used by the smart city to uniquely identify each citizen while serving their requests.Requesting a digital Badge

[0120] FIG. 6B illustrates, in a call flow diagram 620, an example of a method of requesting a distributed and verifiable digital badge, in accordance with some embodiments. In this diagram, arrows in solid lines represent communication between peers, and their numerical label corresponds to the matching arrow in the architecture of FIG. 5. Arrows in dotted lines represent smart contract calls and returns. An example will be described with reference to FIG. 6B.

[0121] Once Alice completes setup and registration phase, she can request a digital badge from the broker at 621 , choosing from the list of available digital badges presented on the smart city mobile app. This request takes the form of a badge request ticket (BRqT). A badge may be destined to a specific verifier. Its payload may contain the badge ID, the badge title, the identifier of the verifier that will consume the badge, and Alice’s identifier in the broker’s platform.

[0122] On receiving the request, the broker retrieves the session key, decrypts the payload, and verifies the signature of the message. It then checks whether the ID stored in its database matches the public key used for the signature. Invalid credentials result in an error message sent back to Alice at 622.

[0123] If Alice’s credentials are valid, the broker selects the appropriate consensus node to contact based on the badge to be requested. To enhance the privacy, the broker creates a transaction in a way that it does not reveal any personal identifiable information about Alice to the blockchainconsensus nodes except the concerned service’s consensus node who is the issuing authority of the badge.

[0124] For this, the smart city creates a one-time symmetric key, encrypts it using the service’s public key, and uses this session key to submit a badge ticket (BT). Its payload may contain the badge ID, the badge title, the identifier of the verifier that will consume the badge, and Alice’s identifier in the service’s platform.

[0125] The broker sends a transaction requesting the badge to the blockchain network by invoking the Request Contract (RC) at 623. The RC is the top-level smart contract that coordinates the global production of a digital badge by calling one or more other smart contracts. The RC receives a BRqT and outputs either a signed badge or an error reply. Globally, the RC checks that the request is valid, triggers the production of the badge, requests optional signatures on the badge and returns it to the caller. The badge itself may optionally be stored on the blockchain (i.e. the distributed ledger) itself. The flowchart of the process 700 implemented by the RC is illustrated in FIG. 7.Access Control Contract (ACC)

[0126] Each digital badge may have different access requirements (or conditions) and these are captured in (i.e., the access conditions may be evaluated by) different Access Control smart Contracts (ACC). All these ACCs are written and deployed by the smart city by gathering the access requirements from the badges issuing services for each digital badge. The first step (step 702 of FIG. 7) in the RC is thus to invoke the access control contract (ACC) (624 in FIG. 6B) by inputting Alice’s information to check (step 704 of FIG. 7) if the access conditions are met to process her request. FIG. 8 illustrates a flowchart of the operation 800 of the ACC smart contract. As can be seen from FIG. 8, once invoked by the RC, the ACC assesses (step 802) whether the user is known (i.e. among the list of authorized users for the requested service). If this is not the case, the ACC denies access (step 804). Otherwise, if the user is known (i.e. the authorization of the user to access the service is verified), the ACC then assesses whether the query is valid (step 806). If this is not the case, ACC denies access (step 804). Otherwise, if the query is valid, access is granted (step 808).Badge Contract (BC)

[0127] Returning to FIG. 7, after having invoked the ACC at step 702 to check access, the RC determines at step 704 whether access has been granted. If access has not been granted, an error is generated (step 706). Otherwise, the RC invokes the BC at step 708 in order to generate the badge. In particular, once the access conditions for a badge are met, the respective issuing service retrieves the necessary input values from its internal database to generate a badge, or fetches thisinformation from an external oracle (see 630, 631 in FIG. 6B). The input is then fetched with the request and forwarded to the network of consensus nodes. The consensus nodes network then processes the transaction and invokes the BC to create the requested badge. FIG. 9 illustrates a flowchart of the operation 900 of the BC smart contract.

[0128] The BC creates the requested badge with the input from ACC, as illustrated in FIG. 9. In particular, the BC requests data at step 902, creates the badge based on the data at step 904, and outputs the badge at step 906. Returning to FIG. 7, the RC then assesses at step 710 whether additional signatures are needed. If this is the case, the RC invokes at step 712 the Signing Contract (SC) to get the badge signed by at least one authorized signing authority. The RC then reassesses at step 710 whether additional signatures are needed. When additional signatures are no longer needed, the RC writes the badge on the blockchain (step 714) and the signed badge is output (step 716).Signing Contract (SC)

[0129] Each badge may be signed by one or more authorized signers (or signing authorities). The list is made available to the smart contract using a function HstSAQ. The badge contract thus calls the signing contract (SC) (632 in FIG. 6B), which in turn passes the badge to a number of signing authorities (633 in FIG. 6B) and retrieves the signed badge (634 in FIG. 6B). Once all the signatures have been gathered, the badge is returned to the badge contract (635 in FIG. 6B). This is illustrated in the flowchart of FIG. 10, which illustrates the process 1000 implemented by the SC. As can be seen from FIG. 10, the SC passes the badge to signing authorities for signing at step 1002 and retrieves the signed badge at step 1004.

[0130] The badge is then returned to the request contract (637 in FIG. 6B), which returns it to the broker (638 in FIG. 6B). The rest of the process occurs out of the blockchain as described herein above.Smart Resident Card

[0131] FIG. 11A illustrates an example of a smart resident card 1100A with a QR code and the subscription information view on a mobile device , in accordance with some embodiments.

[0132] In some embodiments, the smart city platform offers a smart card (resident, non-resident, tourist, etc.) as in 1100A to its users based on their resident status to manage their registration, and grant them access to activities and events offered by the city. The platform uses a centralized system called the “ticket office” to automate and manage the cards, while ensuring that personal identification information is secure and ethically managed. This feature enables digital registrations and facilitates access to numerous services limiting citizens visits to city hall and reduces bottlenecks during peakhours. The smart card 1100A offers high-level autonomy and a gradual integration of a range of services through a single digital card. The solution keeps residents informed, in real time, of the activities taking place around the city and involves them as a community in suggesting recommendations and decision-making based on user activity.

[0133] FIG. 11 B illustrates another example smart resident card 1100B offered by a smart city, in accordance with some embodiments. The smart card 1100B contains information such as citizen's name, the list of subscriptions by the citizen, family members information, etc. The problem discussed above applies here as well that is sharing the smart cards leak more information than necessary. To overcome this, the smart city aims to replace citizens personal identifiable information on the smart cards with the digital badges using the proposed framework. In other words, the smart cards as in 1100B are created using multiple digital badges that may be issued by multiple issuing authorities. Once a citizen completes her registration, with the consent of the citizen, the smart city triggers a series of transactions requesting multiple digital badges required for the smart card generation. These digital badges are then bundled together to generate the smart card 1100B. Finally, the smart card 1100B is delivered it to the citizen (i.e., smart city mobile app).Photo digital badge

[0134] One of the primary items in an identity proof is a photo of the user. Considering the importance of a photograph to avoid fraudulent scenarios, the proposed framework suggests the citizens to request for a digital badge fortheir most recent photo in regular intervals of time (say every six months). To get a photo digital badge, the citizen may have to present herself over a video call or in person to the TA for physical appearance and verification. On confirming the identity, the TA would attest (embedding an encrypted message) the photograph (that may be captured during the appointment) of the citizen and supply it back to the citizen. The citizen will then submit a request attaching the attested photo to the smart city. Like any other digital badge request, the smart city may attach the necessary information with the photo digital badge request and forward it to the concerned city service to process. If issued, the photo digital badge is delivered to the citizen (i.e., smart city mobile app).

[0135] FIG. 12 is a schematic diagram of a computing device 1200 such as a server or other computer in a device. As depicted, the computing device includes at least one processor 1202, memory 1204, at least one I / O interface 1206, and at least one network interface 1208.

[0136] Processor 1202 may be an Intel or AMD x86 or x64, PowerPC, ARM processor, or the like. Memory 1204 may include a suitable combination of computer memory that is located either internally or externally such as, for example, random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM).

[0137] Each I / O interface 1206 enables computing device 1200 to interconnect with one or more input devices, such as a keyboard, mouse, camera, touch screen and a microphone, or with one or more output devices such as a display screen and a speaker.

[0138] Each network interface 1208 enables computing device 1200 to communicate with other components, to exchange data with other components, to access and connect to network resources, to serve applications, and perform other computing applications by connecting to a network (or multiple networks) capable of carrying data including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi, WiMAX), SS7 signaling network, fixed line, local area network, wide area network, and others. The network interface 1208 may use any suitable communication link(s). For instance, short range communication link(s) such as Wi-Fi or Bluetooth or long range communication link(s) such as 2G, 3G, 4G or 5G cellular communications may be supported.

[0139] In some embodiments, the computing device 1200 may be part of a computing system comprising components connected in various ways including directly coupled, indirectly coupled via a network, and distributed over a wide geographic area and connected via a network (which may be referred to as “cloud computing”). In particular, the computing device 1200 may be part of a cloud computing system operable to deliver computing service through shared resources, software, and data over a network. As such, the memory 1204 may, in some embodiments, include cloud storage.

[0140] The foregoing discussion provides example embodiments of the inventive subject matter. Although each embodiment represents a single combination of inventive elements, the inventive subject matter is considered to include all possible combinations of the disclosed elements. Thus, if one embodiment comprises elements A, B, and C, and a second embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly disclosed.

[0141] The embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.

[0142] Program code is applied to input data to perform the functions described herein and to generate output information. The output information is applied to one or more output devices. In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements may be combined, the communication interface may be a softwarecommunication interface, such as those for inter-process communication. In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combination thereof.

[0143] Throughout the foregoing discussion, numerous references will be made regarding servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium. For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions.

[0144] The technical solution of embodiments may be in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided by the embodiments.

[0145] The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines and particularly configured computer hardware arrangements.

[0146] Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein.

[0147] Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification.

[0148] As can be understood, the examples described above and illustrated are intended to be exemplary only.

Claims

WHAT IS CLAIMED IS:1 . A digital authorization verification system comprising: one or more servers, each server having a secure internal server database storing a list of authorized users for a service specific to the one or more servers; a secure distributed ledger shared by the one or more servers; and a platform communicatively coupled to the one or more servers and having a secure internal platform database, the platform configured to encrypt a user identity of a user requesting access to the service for use in verifying, using the distributed ledger and the list of authorized users, an authorization of the user to access the service.

2. The digital authorization verification system of claim 1 , wherein the platform comprises: at least one platform processor; and a platform memory storing instructions which when executed by the at least one platform processor configure the at least one platform processor to perform a registration procedure comprising: receiving the user identity from a user device; verifying an authenticity of the user identity using a trusted third party; issuing an encryption key pair comprising a first public key and a first private key specific to the user; and storing, in the secure internal platform database, a correspondence between the user identity and the first public key.

3. The digital authorization verification system of claim 2, wherein the at least one platform processor is configured to perform a badge request procedure comprising: receiving from the user device a request for an authorization badge to access the service, the request including the first public key and an indication of the service; verifying the user identity of the user requesting access to the service; andupon successful validation of the user identity, transmitting the request to a given one of the one or more servers associated with the service for which the request for the authorization badge is received.

4. The digital authorization verification system of claim 3, wherein the given server has a second public key and a second private key associated therewith, further wherein the at least one platform processor is configured to perform the badge request procedure further comprising: obtaining the user identity using the correspondence between the user identity and the first public key; encrypting the user identity with the second public key, thereby generating an encrypted user identity; and recording the request for the authorization badge to the distributed ledger.

5. The digital authorization verification system of claim 4, wherein the given server comprises: at least one server processor; and a server memory storing instructions which when executed by the at least one server processor configure the at least one server processor to perform the badge request procedure further comprising: decrypting the encrypted user identify using the second private key; verifying the authorization of the user to access the service based on the list of authorized users for the service; and in response to the authorization of the user being verified, generating the authorization badge, recording the authorization badge to the distributed ledger, and transmitting the authorization badge to the at least one platform processor.

6. The digital authorization verification system of claim 5, wherein, subsequent to generating the authorization badge, the at least one server processor is configured to request at least one signing authority to digitally sign the authorization badge.

7. The digital authorization verification system of claim 4, wherein the distributed ledger has smart contracts residing thereon, further wherein the at least one platform processor is configured to invoke the smart contracts to perform the badge request procedure.

8. The digital authorization verification system of claim 5, wherein the distributed ledger has smart contracts residing thereon, further wherein the at least one server processor is configured to invoke the smart contracts to perform the badge request procedure.

9. The digital authorization verification system of claim 4 or 5, wherein the smart contracts comprise a request contract configured to coordinate production of the authorization badge by calling at least another one of the smart contracts, an access control contract configured to evaluate one or more access conditions associated with the authorization badge, a badge contract configured to create the authorization badge, and a signing contract configured to get the authorization badge digitally signed by at least one signing authority.

10. The digital authorization verification system of claim 4, wherein the at least one platform processor is configured to: receive a plurality of requests for authorization badges for different services; and perform the badge request procedure for each request of the plurality of requests.11 . The digital authorization verification system of any one of claims 1 to 10, wherein the distributed ledger is a public permissioned blockchain, and further wherein the one or more servers comprise a network of consensus nodes using a consensus protocol to achieve consensus of transactions on the distributed ledger.

12. A computer-implemented method for digital authorization verification, the method comprising: receiving, by a platform in a digital authorization verification system, from a user device, a user identity of a user requesting access to a service ; verifying, by the platform, an authenticity of the user identity using a trusted third party; issuing, by the platform, an encryption key pair comprising a first public key and a first private key specific to the user; andstoring, by the platform in a secure internal platform database of the platform, a correspondence between the user identity and the first public key.

13. The method of claim 12, comprising performing a badge request procedure comprising: receiving, by the platform, from the user device, a request for an authorization badge to access the service, the request including the first public key and an indication of the service; verifying the user identity of the user requesting access to the service; and upon successful validation of the user identity, transmitting the request to a given one of the one or more servers associated with the service for which the request for the authorization badge is received.

14. The method of claim 13, wherein the given server has a second public key and a second private key associated therewith, wherein performing the badge request procedure further comprises: obtaining, by the platform, the user identity using the correspondence between the user identity and the first public key; encrypting, by the platform, the user identity with the second public key, thereby generating an encrypted user identity; and recording, by the platform, the request for the authorization badge to a secure distributed ledger shared by the one or more servers.

15. The method of claim 14, wherein performing the badge request procedure further comprises: decrypting, by the given server, the encrypted user identity using the second private key; verifying, by the given server, the authorization of the user to access the service based on a list of authorized users for the service stored in a secure internal server database of the one or more servers; and in response to the authorization of the user being verified, generating, by the given server, the authorization badge, recording, by the given server, the authorization badge to thedistributed ledger, and transmitting the authorization badge to the at least one platform processor.

16. The method of claim 15, comprising, subsequentto generating the authorization badge, requesting, by the given server, at least one signing authority to digitally sign the authorization badge.

17. The method of claim 14, wherein the platform is configured to invoke smart contracts residing on the distributed ledger to perform the badge request procedure.

18. The method of claim 15, wherein the server is configured to invoke smart contracts residing on the distributed ledger to perform the badge request procedure.

19. The method of claim 14, comprising: receiving, by the platform, a plurality of requests for authorization badges for different services; and performing, by the platform, the badge request procedure for each request of the plurality of requests.

Images