Unified authentication system for decentralized identity platforms

A unified authentication system for decentralized identity platforms is disclosed. In various embodiments, a request comprising one or more identity claims and a digital address is received. The digital address is used to verify, via a verification node associated with a digital address provider, the one or more identity claims. Access to a service is provided, in response to the request, based at least in part on a response from the verification node indicating the one or more identity claims have been verified. The verification node is configured to obtain consent, in real time, from a user with which the digital address is associated, prior to providing said response indicating the one or more identity claims have been verified.

BACKGROUND OF THE INVENTION

With the convergence of the physical world and online or “cyber” worlds (via the Internet and other cloud-connected technologies), it has become more critical than ever to provide an infrastructure and system to enable trustable, accountable, and secure human-cyber identities for use online.

Many attempts to provide this type of system have been proposed, but each of them attempts to symptomatically solve what is a more fundamental problem—current incarnations of Cyber Identity are clone-able, subject to identity theft, and are inherently untrustworthy because of that.

In response to this, a backlash of government regulations and corporate policies have tried to solve the identity theft symptom by creating greater requirements for privacy and control over identity data, but they do not solve the root problem. Attempts to accommodate these requirements or policies have resulted in replacing one flawed system with a new version of the same flawed system. These attempts have resulted in fragmented, multi-viewpoint, technical-oriented approaches, organizations and working groups which apply better technology but with the same philosophy that ultimately does not solve the root problem.

It is right and necessary to ensure both privacy and security of identity data but also ensure that Cyber Identity can be trustable and accountable online, just as offline identity can be trustable and accountable.

DETAILED DESCRIPTION

A unified, decentralized identification and authentication system is disclosed. In various embodiments, a system as disclosed herein includes devices and protocols that perform secure registration, issuance, storage, and verification of digital credentials bound to unique human identities. The unique binding of a digital credential to a human identity is enforceable at registration time across mutually independent credential issuers, so long as those issuers cooperate with a repository of identity disambiguation information as disclosed herein. In various embodiments, a previously registered human user attempting to register with any (arbitrary) credential issuer will be known or discovered by the issuer to be the owner of an already issued credential. In various embodiments, the system prevents the issuance of multiple credentials to a single user.

FIG.1is a block diagram illustrating an embodiment of a unified authentication system for decentralized identity platforms. In the example shown, the system100enables a user102of a device104, such as a mobile device, laptop computer, desktop computer, or other device trusted by user102, to obtain a digital address or other digital identity and/or credential to be used to access services from service providers such as service providers106,108. In the example shown, the user102uses a selected digital identity app110,112on device104to obtain a digital address or other digital identity or credential as disclosed herein. The digital identity app110,112interacts with an associated digital address provider (or other digital identity provider)114,116comprising a digital address provider layer118. Examples of a digital address provider114,116include, without limitation, decentralized credential providers such as CIVIC, SOVRIN, EVERNYM, or other providers.

In the example shown, the digital address provider114,116may interact with a verified credential issuer120,122, e.g., to verify information extracted from documents or entered via device104in connection with digital address self-registration (e.g., as described below) and/or to facilitate access to verifiable credentials provided by issuers120,122, such as to provide secure access to a service to a user with whom a previously-issued digital address has been issued. In various embodiments, a verified credential issuer120,122facilitates higher-assurance digital identity credentials to be created. Examples of a verified credential issuer120,122include, without limitation, a bank or other financial institution; a government agency such as the Department of Motor Vehicles, the State Department, the Department of Homeland Security, the Internal Revenue Service, and other agencies; healthcare providers and insurers; credit reporting bureaus; and any entity having unique, special, and/or privileged access to information, personnel, processes, and expertise to verify identity information.

In various embodiments, to register a digital address, a digital address provider such as digital address provider114,116receives from an associated digital identity app110,112an identity disambiguation data, sometimes referred to herein as an “identity disambiguator”. In various embodiments, an identity disambiguator comprises a value uniquely associated with a single human user. No other human user would have or produce the same value for the identity disambiguator, and each human is capable of generating only the one identity disambiguator that is unique to that human.

In various embodiments, the digital address provider114,116checks a distributed identity disambiguation repository124to verify the identity disambiguator has not been used previously to issue a digital address. The distributed identity disambiguation repository124may comprise any accessible storage medium, such as a public blockchain or a local database.

In various embodiments, the distributed identity disambiguation repository124sits one layer above the prior typical decentralized identity efforts layer. In some embodiments, the distributed identity disambiguation repository124works for decentralized identity in much the way ICANN/DNS works for website addresses. The distributed identity disambiguation repository124prevents a person from registering more than one identity disamiguator and allows for interoperability and clearing among various digital address providers114,116without requiring any disclosure of the user's personal information, including biometric information.

In various embodiments, the distributed identity disambiguation repository124comprises a database that may be implemented using a blockchain or other distributed ledger and/or distributed database technology. In various embodiments, regardless of implementing technology the distributed identity disambiguation repository124database has multiple nodes operated by various participating organizations.

In various embodiments, the distributed identity disambiguation repository124operates as disclosed herein to ensure that each human user has no more than one digital address. In some embodiments, it does this by employing its own uniquely formatted DID-like locator, e.g., an “identity disambiguator” as disclosed herein. In some embodiments, the identity disambiguator is combined with addressing information to generate and provide a digital address that may be used to identify and is uniquely associated with the one human user with whom the identity disambiguator is uniquely associated.

In various embodiments, an identity disambiguator as disclosed herein is derived from a group of data or other attributes considered to be unique to one human user. An identity disambiguator in various embodiments can be reproduced any number of times to produce for a given human user the same identity disambiguator and no other, so that each human user can obtain through registration only one digital address and only that human user can obtain that digital address, since the human user can produce only one identity disambiguator and no other human user can produce that same identity disambiguator.

In various embodiments, an identity disambiguator as disclosed herein is derived deterministically from the user's quantized biometric data and (in some embodiments) an identity registry salt, but reveals no information regarding the biometric data. In some embodiments, the identity registry salt comprises a single global value shared among digital address providers114,116,118and the distributed identity disambiguation repository124. In some embodiments, the identity registry salt is cryptographically combined with quantized biometric data through a one-way function to produce the identity disambiguator. In some embodiments, the value of the identity registry salt is not secret.

In various embodiments, the arrows showing interactions between entities inFIG.1represent communications sent using a Common API, such as a standards-based API. In some embodiments, the Common API takes the place of existing proprietary APIs used by the disparate existing credential issuers and related entities. In some other embodiments, proprietary APIs continue to be used. For example, proprietary APIs may be used by some subset of digital identity apps110,112and digital address providers114,116. Such proprietary APIs may be published or otherwise made available to entities participating in the system100, for example.

FIG.2is a flow diagram illustrating an embodiment of a process to issue a digital credential. In various embodiments, the process200ofFIG.2is performed by a digital address provider, such as digital address providers114,116ofFIG.1. In the example shown, at202identity documents are received and verified. In various embodiments, a user, such as user102ofFIG.1, may use a digital app (e.g.,110,112) running on a user device (e.g.,104) to take photos or other images (e.g., PDF) of identity documents. The app may perform optical character recognition (OCR) or other processing to extract identity information from the documents and provide the information to the digital address provider. In some embodiments, the app may send the image or other representation of the entire document(s) to the digital address provider.

At204, information to generate identity disambiguation data is obtained. In some embodiments, an app and user device may be used to obtain biometric information, such a facial recognition, fingerprint, or voice (e.g., spoken standard phrase) data. In some embodiments, a biometric scanner provided by and/or otherwise trusted by a digital identity provider may be used, e.g., a scanner that is plugged into or otherwise connected to a user device of the user. In some embodiments, biometric data is not required, obtained, or used to register a digital address. Instead, other information that is not biometric data but is (sufficiently likely to be) unique to one human person, such as an array of values that includes one or more of biographical information (date of birth, city of birth), a numeric or alphanumeric identifier issued by the government or other authority (e.g., social security number), and/or other data may be used to generate identity disambiguation data as disclosed herein.

At206, the data received at204is used to generate identity disambiguation data, i.e., an identity disambiguator, as disclosed herein. In various embodiments, the identity disambiguator is generated by the digital identity app running on the user's device, which avoids having the data used to generate the identity disambiguator being sent to the digital address provider. Since the user's biometric and/or other information cannot be discerned from the identity disambiguator, this approach may be considered more private and/or secure.

At208, the digital address provider verifies the identity disambiguator has not been registered previously. For example, the digital address provider may access a distributed identity disambiguation repository, such as distributed identity disambiguation repository124ofFIG.1, to determine whether the identity disambiguator has been used previously to obtain a digital address. If at210it is determined that the identity disambiguator has not been used previously to obtain a digital address, then at212the digital address provider registers the identity disambiguator by storing a corresponding record in the distributed identity disambiguation repository and generates and returns to the user (e.g., via the digital identity app or other user interface) a digital address for the user.

If it is determined at210that the identity disambiguator has been used previously to obtain a digital address, then at214an existing address/identity exception handling process is triggered. For example, the digital address provider may return a response indicating the process has failed because the user has already obtained a digital address. The response may include instructions to “recover” the digital address, if the user has lost the digital address and/or information needed to reference or otherwise use it. A credential, address, or other information based on and/or associated with the previously-registered identity may be generated and/or provided.

Various techniques and processes may be provided for and/or used to obtain a digital address, in various embodiments, including without limitation self-registration, e.g., using a digital identity app running on a user-trusted device; in person registration, e.g., by presenting oneself and identity documents at a physical location, such as an office of a verified credential issuers; and augmented self-registration, e.g. using a digital address provider-trusted biometric scanning device, such as one that plugs into a USB of or otherwise connects to a user device used to register.

FIG.3is a functional flow block diagram illustrating an embodiment of a process to obtain a digital address. In the example shown inFIG.3, the process300enables the user102to obtain a digital address through a self-registration process via a digital identity app110running on a secure user device, e.g., a device capable of storing private PKI keys.

The user downloads the digital identity app110, e.g., from digital address provider114, launches the app, and initiates the process. The app may prompt the user to take images or and/or otherwise upload identity documents, e.g., driver's license, passport, other identity documents, etc., including in some embodiments a photo of the user, as represented by the arrow labeled “1” inFIG.3. The app110extracts personal data from the documents and/or photo. The app110may perform a biometric scan of the user. In some embodiments, the biometric scan information is used to verify the user against the identifying documents, e.g., compare the live face with the face in the ID picture, compare live biometric against a machine-readable representation of the same biometric embedded in the identifying document or in another data source, etc. If the comparison fails, the transaction is terminated. If the comparison passes, the app deterministically quantizes all or a subset of the biometric information, via a repeatable function such as a fuzzy extractor and optionally combined with identity repository salt, as described above, by means of a pseudo-random, one-way transform (such as a cryptographic hash function) to produce the identity disambiguator.

If the example shown, the app110verifies via communications with one or more verified credential issuers (arrow “2”) all or some of the personal data extracted from the documents and/or photo. In some alternative embodiments, the digital address provider114performs this check. For example, the Department of Motor Vehicles may be queried to verify that a submitted driver's license is valid and that the name, address, date of birth, photo, and other information extracted from the driver's license by the app110(or digital address provider114) matches information in the verified credential issuer's records.

Referring further toFIG.3, in the example shown, the app110provides to the digital address provider114(arrow “3”) data extracted from the documents and/or photo provided by the user (and/or the documents and/or photo themselves) and the identity disambiguator computed by the app110, e.g., based on biometric or other information obtained by the app110from the user102.

The digital address provider114checks the distributed identity disambiguation repository124(arrow “4”) to verify the identity disambiguator has not been registered previously. If not, the digital address provider114uses the identity disambiguator to generate a digital address for the user, which is returned to the user (arrow “5”) via the digital identity app110. If the digital address provider114determines via the distributed identity disambiguation repository124that the identity disambiguator has been registered previously, the response (arrow “5”) indicates the registration process failed and, in some embodiments, provides instructions to recover the digital address registered by the user previously.

FIG.4is a functional flow block diagram illustrating an embodiment of a process to issue a digital address. In various embodiments, the process400ofFIG.4may be used to register (i.e., obtain a digital address) in person, e.g., by the user102going to a physical location associated with a verified credential issuer120(arrow “1”), such as a bank, Department of Motor Vehicles office, or other location. At the physical location, a worker, kiosk, etc. obtains and verifies identity document and biometric information from the user102and provides extracted information, e.g., via an encrypted communication and/or channel, to the digital address provider114(arrow “2”).

In some embodiments, the verified credential issuer120generates the identity disambiguator and provides the generated identity disambiguator to the digital address provider114(arrow “2”). In some alternative embodiments, the verified credential issuer120send biometric and/or other information to the digital address provider114(arrow “2”), which generates the identity disambiguator.

The digital address provider114checks the distributed identity disambiguation repository124(arrow “3”) to verify the identity disambiguator has not been registered previously. If not, the digital address provider114uses the identity disambiguator to generate a digital address for the user, which is returned to the user via the verified credential issuer120(arrow “4”). If the digital address provider114determines via the distributed identity disambiguation repository124that the identity disambiguator has been registered previously, the response (arrow “4”) indicates the registration process failed and, in some embodiments, provides instructions to recover the digital address registered by the user previously.

FIG.5is a functional flow block diagram illustrating an embodiment of a process to issue a digital address. In various embodiments, the process500ofFIG.5produces an identity disambiguator while allowing the digital address provider to know that the identity disambiguator is correct and allowing the user to know that no biometric data was leaked to any party. In the example shown, the user102connects a digital address provider-trusted biometric scanner device502(e.g., a camera with a USB interface) to a user-trusted app/device110(e.g., a smart phone running an app capable of performing the required protocol with the scanner502) (arrow “1”). In response to the scanner502being connected and/or some other prompt, the user-trusted app110sends a “registration start” message (arrow “2”) to the digital address provider114. The digital address provider114returns a randomly generated nonce to the user-trusted app/device110(arrow “3”), which passes the nonce to the scanner device502(arrow “4”). The scanner device502performs a biometric scan of the user (arrow “5”) and uses the data obtained via the scan along with other attributes of the person to generate an identity disambiguator, as described above. The scanner device502in addition is used to scan the user's identification documents, and compares data extracted from the documents to data obtained via the scan. If any comparison fails, the transaction stops.

The scanner device502digitally signs a concatenation of the nonce (received via arrows “3” and “4”, as described above), the identifying documentation (scanned in the previous step), and the identity disambiguator and returns it, along with the raw biometric scan data, to the user-trusted app/device110(arrow “6”). The user-trusted app/device110recomputes the identity disambiguator from the raw biometric data and verifies that the resultant identity disambiguator matches the one signed by the scanner device502(thus assuring that the identity disambiguator is correct and that no biometric information is being leaked). The user-trusted app/device110may interact with the user to generate its own version of biometric data (arrow “7”), e.g., to be compared to the corresponding raw data received from the scanner device502.

The user-trusted app/device110sends to the digital address provider114(arrow “8”) the digitally signed concatenation of the nonce, identifying documentation, and identity disambiguator received from the scanner device502(arrow “6”). The digital address provider114verifies the scanner device502's signature on the concatenation of the nonce, identifying documentation, and identity disambiguator. If verification fails, the transaction stops. If the verification passes, the digital address provider114extracts information from the identity documentation and verifies it with the verified credential issuer120(arrow “9”) and checks the distributed identity disambiguation repository124(arrow “10”) to verify the identity disambiguator has not be registered previously. If not, the digital address provider114uses the identity disambiguator to generate a digital address for the user, which is returned to the user via the user-trusted app/device110(arrow “11”). If the digital address provider114determines via the distributed identity disambiguation repository124that the identity disambiguator has been registered previously, the response (arrow “11”) indicates the registration process failed and, in some embodiments, provides instructions to recover the digital address registered by the user previously.

FIG.6Ais a functional flow block diagram illustrating an embodiment of a process to use a digital credential to verify a claim. In various embodiments, the process600ofFIG.6Amay be implemented to enable a service provider, such as service provider106in the example shown, to use a digital address registered previously by a user, such as user102, to provide access to a service based on identity claims presented by the user, for example by using the digital address provided by the user to verify the user's identity claims in real time.

In the example shown, the user102invokes (arrow “1”) an app110to access a service provided by a service provider, such as service provider106. The app110may be an app provided by and/or otherwise associated with and/or configured to access the service from service provider106. The app106sends to the service provider106(arrow “2”) data that includes one or more identity claims of the user102(e.g., name, address, last four digits of social security number or other identification number, etc.) and the digital address obtained previously by the user102, e.g., via one or more of the processes illustrated inFIGS.2through5.

The service provider uses the digital address to verify the identity claims with an associated digital address provider, e.g., digital address provider114in this example (arrow “3”). For example, the digital address may be associated with digital address provider114, e.g., may include address and/or routing information that resolves to digital address provider114. Or, in some embodiments, a digital address presented to any digital address provider participating in a system as disclosed herein, such as any digital address provider participating in a digital address provider layer or network, such as digital address provider layer118ofFIG.1, and the receiving digital address provider uses the address to locate the user's data for verification.

In the example shown, the digital address provider114interacts with the user102via out-of-band communications (arrow “4”) to verify whether the user consents to its identity claims being verified by the service provider106via the digital address provider114. If the user102consents (arrow “4”), the digital address provider114checks the identity claims received from the service provider106(arrow “3”) against corresponding previously-stored and previously-verified identity information of the user102(e.g., previously-stored identity claim data associated with the user102's digital address). If the data matches, the digital address provider114returns a response (arrow “6”) indicating the identity claims are verified. If the data does not match or if the user102refuses to consent, then the response (arrow “5”) indicates the verification failed. In some alternative embodiments, instead of checking the identity claims received from the service provider106against corresponding previously-stored and verified information of the user102, the digital address provider114instead provides access to credentials that are derived from identity data of the user102(usually from a credential issuer). These credentials are capable of proving to the service provider106that an identity claim is true either by providing signed proof of the data itself or in a zero-knowledge way (a “provable” yes or no) that the service provider106can trust without actually needing to compare to the identity data itself.

Referring further toFIG.6A, the service provider responds to the user (arrow “6”) to provide the requested service, if the verification passed, or indicating the service cannot be provided in the event the verification failed.

In some embodiments, the process600ofFIG.6Amay be used to provide via digital address provider114, e.g., to service provider106, a “zero knowledge” proof required by the service provider114to provide a service to user102via app110. The user102may not provide an explicit and/or specific identity claim to the service provider106, and instead may request a service that requires and implicitly prompts the service provider106to perform a zero knowledge verification. For example, to access a service available only to persons aged 21 or older, service provider106may be required to verify the user102meets the age requirement. Rather than require the user102to state their age (arrow “2”), the service provider106may simply require the user102to provide the user's digital address, which the service provider106then uses to ask the digital address provider114(arrow “3”) to verify the user102is at least 21 years of age. The digital address provider114requests permission (arrow “4”) from the user102to provide (arrow “5”) the verifiable credential requested by the service provider106(i.e., verifying the user102is 21 years or older), which the service provider106then relies on to provide access to the service (arrow “6”). Note in the above example the user102never provides or is asked to provide the user's age, and the service provider106never has access to the user102's precise age or date of birth.

Note that as illustrated inFIG.1andFIG.6A, the digital address provider114is one of a plurality of digital address providers that also includes digital address provider116and other digital address providers. In various embodiments, a digital address as disclosed herein is used to route identity verification requests by service providers, such as service provider106in the example shown inFIG.6A, to any digital address provider that participates in the digital address ecosystem as disclosed herein. In the example shown inFIG.6A, the digital address presented by and associated with the user102has been used to route a verification request by service provider106to the digital address provider114. In other examples, the verification request by service provider106may have been routed to the digital address provider116, which would in various embodiments have been equally able to service the request, as disclosed herein.

FIG.6Bis a functional flow block diagram illustrating an embodiment of a process to use a digital credential to verify a claim. In various embodiments, the process620ofFIG.6Bmay be implemented to enable a service provider, such as service provider106in the example shown, to use a digital address registered previously by a user, such as user102, to provide access to a service based on identity claims presented by or otherwise associated with the user, for example by using the digital address provided by the user to verify the user's identity claims in real time.

In the example shown inFIG.6B, the process620is similar to the process ofFIG.6A, except that the data against which the user's identity claims are verified is stored in a verifiable credential repository622. Upon receiving a request from service provider106to verify a claim (arrow “3”) and obtaining the user102's permission to perform the verification (arrow “4”), the digital address provider114requests (arrow “5”) and obtains (arrow “6”) a verifiable credential corresponding to the request/identity claim, and returns the a verifiable presentation of the credential to the service provider106(arrow “7”). In various embodiments, the service provider106does not receive the credential itself, just a presentation of the credential that supplies the necessary proof of an identity claim. In some embodiments, the digital address provider114may perform the further step of verifying the (continued) validity of the verifiable credential received/obtained from verifiable credential repository622(arrows “5” and “6”), e.g., by querying an issuer of the verifiable credential.

In some embodiments, the verifiable credential obtained from verifiable credential repository622may be pre-verified, e.g., by a credential issuer and/or other entity associated with one or more of the verifiable credential (arrow “6”) and the verifiable credential repository622. In some embodiments, the verifiable credential (arrow “6”) may be generated in real time, e.g., in response to the request for the verifiable credential (arrow “5”). For example, the verifiable credential may be generated based on other data that is stored by and/or obtained at request time by verifiable credential repository622. In some embodiments, the verifiable credential repository622may be the same as, maintained by, and/or otherwise associated with a verified credential issuer, such as verified credential issuers120,122ofFIG.1, and in some such embodiments the verifiable credential obtained from the verifiable credential repository622(arrows “5” and “6”) may be generated and verified, implicitly or otherwise, by the verified credential issuer120,122, e.g., prior to sending the verifiable credential to the service provider106(arrow “6”).

FIG.7is a flow diagram illustrating an embodiment of a process to use a digital credential to verify a claim. In various embodiments, the process700ofFIG.7is performed by a service provider, such as service provider106in the example shown inFIG.6.

In the example shown, at702one or more identity claims and a digital address are received. At704, the digital address is used to verify the identity claims, e.g., as described above in connection withFIG.6. If the identity claims are verified (706), the identity claims are used at708to provide the requested service. For example, the identity claim data may be used to perform the service, or access to the service may be provided based on the user's identity and/or in a manner determined at least in part by the user's identity, as determined and verified via the identity claims. If the identity claims are not verified (706), then at710identity verification failure and/or exception processing is performed. For example, the user may be notified that the service cannot be provided due to identity verification failure.

In various embodiments, techniques disclosed herein may be used to provide secure access to services via a system that protects user biometric and other data from risk of disclosure; minimizes the risk of user data, credentials, and/or identity information being cloned or otherwise stolen; and ensures that each human user has and is able to obtain only one digital address and/or other digital identity and which ensure that each human user is the only user able to obtain that user's unique digital address and/or other digital identity.