Identity verification

Abstract

The trust network comprises an issuer which issues one or more verifiable credentials such as name, date of birth, educational qualifications, work experience, a holder, which in use owns or holds the

Description

The verification of the true identity of a natural person is becoming essential in an increasing range of contexts. Anti-money laundering regulations require that large transactions, privileged operations and the opening of financial services accounts be attributed to persons whose identities have been adequately established. Security concerns require that persons traveling or entering sensitive installations should not conceal their true identities, so that their past records may first be scrutinized. The most generally accepted source of evidence of the true identity of a person is that issued by governments. In order to issue passports or national identity cards, governments require trusted documentation, adequate corroboration and, if necessary, investigation. In countries where national identity cards do not exist, such as the United States or United Kingdom, reliance is placed on the driving license, and a substantial obligation of due diligence is placed on the Motor Vehicle or Driver administrative bodies that issue driving licenses. Thus, the physical possession of a government-issued identity document (ID) such as a passport, identity card or high-trust driving license is generally considered a trustworthy corroboration of the identity asserted by an individual. In a number of countries, digital identities are being created with the aspiration of being used instead of physical documents. In the European Union, the elDAS Regulations permit the use of compliant digital identities throughout the member states. Normally, to establish an elDAS digital identity in the first place, a person must present themselves together with their government issued identity document. The trust vested by the relying party in such a document depends on the document itself being genuine and un-falsifled. For this reason, governments have for centuries invested in increasingly sophisticated methods of printing and laminating such documents, in a race to keep ahead of the increasing sophistication of forgers. In the last decade electronic means have been added, with the insertion of microchips into documents complying with the ICAO 9303 standard. Such microchips contain the information printed in the document, plus a digital certificate signed by the issuing authority. Under current cryptographic practice, such certificates are considered impossible to forge and hence represent the best possible guarantee of the authenticity of the information contained in the chip, which is readable contactlessly using NFC technology. To facilitate the online identification of users, the Open ID Connect protocol was developed, which has been widely adopted. OpenlD Connect is an interoperable authentication protocol based on the OAuth 2.0 framework of specifications (IETF RFC 6749 and 6750), which simplifies the verification of the identity of users based on the authentication performed by an Authorization Server and to obtain user profile information in an interoperable and REST-like manner. The OpenlD Connect protocol, in abstract, follows these steps: The end user navigates to a website or web application (the Relying Party) via a browser and initiates a login. The end user is then redirected to an Identity Provider, trusted by the Relying Party, and verifies their identity to the Identity Provider, typically by signing in using their username and password. The Identity Provider then returns an Access Token to the Relying Party using a redirect URL, and the Relying Party uses the Access Token in a call to the Identity Provider to retrieve the user information, either in the form of an Identity Token or as JSON returned from a call to the user jnfo endpoint at the Identity Provider. OpenlD Connect enables application and website developers to launch sign-in flows and receive verifiable assertions about users across web-based, mobile, and JavaScript clients and advantageously removes the responsibility of setting, storing, and managing passwords which is frequently associated with credential-based data breaches. However, it still requires the use of databases of identity documents and the more widespread its use becomes, the greater the likelihood of data breaches. The large OpenlD user base also has significant investment in their own OpenlD infrastructure. To address these perceived problems, a decentralized identity approach is gaining popularity. Decentralized identity is a concept that gives back control of identity to consumers through the use of an identity wallet or digital wallet in which they collect verified information about themselves from certified issuers (such as the Government). By controlling what information is shared from the wallet to requesting third parties (e.g., when registering for a new online service), the user is able to better manage their identity online and their privacy. Decentralized trust networks operate on the ability of credentials which can be issued to a holder, and claims made by the holder based upon those credentials which are to be verified, without an intermediary sitting between the parties. Such trust networks rely upon cryptographic key pairs of the issuer, whereby the credential is signed by the issuer’s private key and can be verified by a verifier (Relying Party) using the issuer’s public key. Making the issuer’s public key available to the verifier in a verifiable data registry or other well-known locale preserves privacy of the use of the credentials by avoiding the need for the verifier to “call home” to the issuer. The data model for verifiable credentials typically allows the issuer of the credential to specify terms of use, including validity period, permitted use and a financial value for reliance upon the credential. Whilst these can be specified, the privacy-preserving characteristics of these credentials means that these terms are generally reliant on the goodwill of the verifier to adhere to them. There is therefore a lack of any technical restriction as well as a lack of enforceable commercial governance in trust networks utilising the technical standards. One method by which this is being counteracted is a closed trust network. In such a model issuers, credential wallets and other repositories used by holders and verifiers operate in a closed network, usually where there is a common benefit. For example, an employer may issue credentials to their employees to obtain access or entitlements for their own resources, such as a building access pass. In such a closed network, all actors are assumed to be trusted and any disparity in the value obtained by being part of the network is dealt with outside of the network ecosystem itself. Another method uses crypto-tokens. In this model, the verifier is required to exchange a cryptotoken with a specification that can include a financial value specified by the Issuer in the credential. The crypto-token itself may operate on a blockchain infrastructure to maintain privacy between the issuer and verifier. Smart contracts can be used to enforce terms associated with the credential. In such networks, the issuer, credential wallet of the holder, and verifier are generally locked to the vendor of the crypto-token exchange. The crypto-token exchange therefore also becomes an intermediary in the transaction flow. A further method is the Trust Registry: In this model, the verifier pays a licence fee to access the public key of the Issuer of a credential it wishes to verify. The keys may be shared as a downloadable list or transactionally (key by key). The limitation to such a model using a downloadable list is that it is either a fixed price regardless of the volume of credentials verified, or is self-reported by the verifier on trust. For a per transaction model, a significant number of issuers (or keys used per issuer) is required and regular key rotation is required in order to prevent the verifier obtaining all the required keys. EP3629516 discloses an exemplary decentralized identity approach in which a private key is generated in dependence on start information; subsets of supplied user information are encrypted by means of the secret key such that all user information items is encrypted; the private key is discarded; the encrypted subsets of the user information items are distributed; and the secret key is regenerated for the decrypting of at least one of the encrypted subsets of the supplied user information items. The known decentralized approaches, however, suffer from the problem that the costs of compliance and infrastructure maintenance fall on the individual wallet owner, who will rarely be able or want to bear them. There is therefore still a need to provide means to assess the authenticity of an identity document remotely, using the devices available to members of the public alone, in an automated, reliable and fast way in order to minimize cost, in particular to the user being identified, minimize the time required, and maximize the reliability of the result. However, the means by this is currently being approached does not provide the technical means to solve this issue for open-networks where value exchange is required to incentivise the issuance of credentials into the trust network. According to the invention, there is provided a trust network for assessing the authenticity of an identity document comprising an issuer, which issuer issues one or more verifiable credentials, a holder, which in use owns or holds the verifiable credential in a digital wallet and a verifier for validating or authenticating the credential, wherein the trust network further comprises a scheme, which scheme provides a tokenisation service and the issuer issues the one or more verifiable credentials specifying the scheme, wherein the holder calls the tokenisation service of the scheme or schemes and sends the wallet identifier and signature or proof of the credential, the scheme then tokenises the wallet identifier and signature of the credential, creating a lookup record with the original value and the tokenised value and the tokenised value is returned to the holder. According to a second aspect of the invention, there is provided a method of assessing the authenticity of an identity document using a trust network in accordance with the features of Claim 1. Preferred aspects of the invention can be found in the sub-claims. The invention advantageously avoids the use of an intermediary between the parties. This allows offline issuance and presentation of credentials (e.g. using BLE (Bluetooth Low Energy), NFC (Near Field Communication) or other peer-to-peer network services) to continue. An exemplary embodiment of the invention will now be described in greater detail with reference to the drawings in which: Fig. 1 shows a schematic of a trust network; Fig. 2 shows a flow diagram of credential issuance and Fig. 3 shows a flow diagram of credential usage Verifiable credentials are a digital representation of a person’s identity and credentials, such as their name, date of birth, educational qualifications, work experience, and more. Unlike traditional identity documents like passports or a driver’s licence, verifiable credentials are stored digitally and can be easily accessed and verified online. They are designed to be tamper-evident and secure, making it very difficult for fraudsters to falsify them. In known systems there are three fundamental roles when it comes to utilizing verifiable credentials: the issuer, which is a person or organization that issues verifiable credentials such as a government department issuing a national ID or a college issuing a diploma to a person; a holder: which is a person or organization that owns or holds the verifiable credential in their digital wallet and a verifier, who is the person or organization validating or authenticating the credential like a security agent at the airport checking the passport. The digital wallet can be stored on a user’s smartphone or other handheld device such as a tablet or, alternatively, it would be possible to hold the information in a web wallet. A digital or web wallet is an app or secured storage which contains data, protected biometrically or by other access features of the platform, that can enable a user to interact with other services, in which the app is the only app that can access the data within the app. Figure 1 shows a trust network of a first exemplary embodiment in which in order to provide commercial governance to trust networks, a fourth party, here called scheme, is included in addition to issuers, holders and verifiers. The fourth party, here called scheme, provides a tokenisation service to the trust network and facilitates payments between participants. The issuer does not need to directly call the scheme's tokenisation service. This is a privacy-preserving feature. Additionally, the scheme can provide other operational activities including but not limited to setting the types of credentials it supports, the rules under which parties to the network operate and their obligations and liabilities to each other. The scheme may also set commercial terms such as price for credential issuance and verification. Unlike other implementations of commercial governance, this invention allows for multiple schemes to interoperate with verifiable presentation of claims from multiple credentials across these schemes. The design of the trust network is extensible such that multiple schemes can operate in parallel. Actions attributable to the holder are assumed to be performed by their credential wallet or equivalent. Figure 2 shows an exemplary flow diagram for credential issuance, in which the issuer of a credential is required to specify the scheme or schemes under which they are issuing it. In order to call the tokenisation service of a scheme, wallets would require a known end-point. This would be a relatively minor amendment to the existing W3C data format and could utilise the existing decentralized identifier (DID) method format. The wallet should remain agnostic to schemes -whereas issuers and / or verifiers could specify a priority or priorities (price, service, liability, certification, range of attributes etc.). They may, in accordance with the existing W3C data model for verifiable credentials specify the credential type or other commercial terms for use. The data model has the ability to specify credential type and commercial model. A minor amendment to this data model would extend that to schemes. Upon receipt of the credential or at any time prior to its presentation to a verifier, the holder calls the tokenisation service of the scheme or schemes under which the credential has been issued, sending the wallet identifier and signature or proof of the credential. The scheme tokenises the wallet identifier and signature of the credential, creating a lookup record with the original value and the tokenised value. The tokenised value is returned in the response to the request from the holder. Figure 3 shows an exemplary flow diagram for credential usage. To share a claim with a verifier, the holder requests details of the scheme or schemes in which the verifier participates. The verifier returns information of their scheme participation (optionally with a preference) to the holder. The verifiable presentation of claims from one or more credentials is then prepared. The claim includes the terms of use for the credential. The signatures (proofs) of the credential or credentials are replaced by the tokenised value held by the credential wallet. The verifiable presentation of claims is then shared with the verifier. The verifier makes a selective disclosure of the terms of use from the credential or credentials it wishes to verify. The verifier prepares the information to share with the scheme's tokenisation service using the selective disclosure. This is performed so that personal data from the credential does not need to be shared with the tokenisation service, yet still allows the integrity of the data it does require to be verified. This enables the scheme to enforce the terms of use - e.g. if the credential has expired, the verifier could not alter it without invalidating the information sent to the scheme and therefore the scheme could reject the request. This could also prevent another verifier from using the credential. The verifier calls the scheme’s tokenisation service to look-up the tokenised value of the proof request along with their agreement to terms of use of the credential. This agreement may include payment or a promise to pay. The scheme then obtains the original signature value retrieved from the look-up and verifies the signature of the terms of use using the original value of the signature. The scheme then returns the original signature value to the verifier. The verifier uses the original signature value to verify the claims in the verifiable presentation made by the holder. The holder may make periodic requests to obtain new tokenised values for the signatures of the credentials that it holds from the scheme as described with respect to Figure 2. These requests may be based on time, when a good network connection is next established, or on the number of uses of a particular credential. This reduces the risk that a verifier maintains their own record of tokenised and original signature values. The use of the term verifiable credential includes, but is not limited to, those defined by the Worldwide Web Consortium (W3C), the Internet Engineering Task Force (IETF) and mobile Documents (mDocs) as described in the International Standards Organization (ISO) 18013-5 guidelines

Claims

1. A trust network for assessing the authenticity of an identity document comprising an issuer, which issuer issues one or more verifiable credentials, a holder, which in use owns or holds the verifiable credentials in a digital wallet and a verifier for validating or authenticating the credential, wherein the trust network further comprises a scheme, which scheme provides a tokenisation service and the issuer issues the one or more verifiable credentials specifying the scheme, wherein the holder calls the tokenisation service of the scheme or schemes and sends the wallet identifier and signature or proof of the credentials, the scheme then tokenises the wallet identifier and signature of the credential, creating a lookup record with the original value and the tokenised value and the tokenised value is returned to the holder.

2. A trust network according to Claim I. wherein the scheme is specified by use of a Decentralized Identifier (DID) to associate the verifiable credentials with the holder.

3. A trust network according to Claim 1 or Claim 2, wherein the issuer and / or verifier specifies a priority or priorities to the scheme or schemes.

4. A trust network according to any one of Claims 1 to 3, wherein to share a claim with a verifier, the holder requests details of the scheme or schemes in which the verifier participates and the verifier returns information of their scheme participation to the holder.

5. A trust network according to any one of Claims 1 to 4, wherein the signature or proof of the credential or credentials are replaced by the tokenised value held by the credential wallet and shared with the verifier.

6. A trust network according to any one of Claims 1 to 5, wherein the verifier makes a selective disclosure of the terms of use from the credential or credentials it wishes to verify to the scheme.

7. A trust network according to any one of Claims 1 to 6, wherein the verifier calls the scheme’s tokenisation service to look-up the tokenised value of the signature or proof request and the scheme then obtains the original signature value retrieved from the lookup and verifies the signature of the terms of use using the original value of the signature and then returns the original signature or proof value to the verifier.

8. A trust network according to Claim 7, wherein the verifier uses the original signature value to verify the claims in the verifiable presentation made by the holder.

9. A trust network according to any one of Claims 1 to 8, wherein the holder can make periodic requests to obtain new tokenised values for the signatures of the credentials that it holds from the scheme.

10. A trust network according to Claim 9, wherein the periodic request is based on at least one of time, when a good network connection is next established or on the number of uses of a particular credential.

11. Use of a trust network according to any one of Claims 1 to 10 to assess the authenticity of an identity document.

Images