Identity verification

Abstract

Trust Network A trust network for assessing the authenticity of an identity document comprises an issuer, which issuer issues one or more verifiable credentials such as name, date of birth, educational qualifications, work experience, the trust network further comprising a holder, which in use owns or holds the verifiable credentials in a digital wallet and a verifier for validating or authenticating the credential or credentials. The trust network further comprises a scheme, which provides a tokenisation service. In use, 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.

Description

[0001] Identity Verification

[0002] 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.

[0003] 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.

[0004] 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.

[0005] 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.

[0006] The trust vested by the relying party in such a document depends on the document itself being genuine and un-falsified. 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.

[0007] 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.

[0008] 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_info endpoint at the Identity Provider.

[0009] 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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.

[0014] 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.

[0015] US11507943B discloses a decentralized identity model is a step forward in providing privacy for the user but suffers from some privacy limitations. Firstly, it is premised on the user having a single principal identity (a legal identity). Each user creates a single decentralized identifier (DID) for that principal identity on a blockchain, and that is the anchor point for that user. Each new relationship that is set up from that point is based on this principal identity, therefore creating a fingerprint of the user. A second limitation is that the user may need to have a decentralized identity created by a number of different service providers that each anchor on different blockchains. The patent attempts to solve these flawed assumptions by creating an aggregation of one or more blockchain anchored principal identities into personas unique to each service provider.

[0016] US2015074774 discloses a unified wallet which can combine passes (credentials) from multiple wallets and orchestrate authentication and access to multiple services based on the permissions granted by the passes of the multiple wallets. The premise of this invention is digital wallets, meaning applications or devices, that can confirm identity, authenticate access, and process payment transactions, aim to address some of these problems, but will generally restrict the user to the particular wallet format that is supported by the digital wallet. A user may therefore have to install or carry an increasing number of different digital wallets.

[0017] US2015294307 uses tokens for identification and / or authentication that are held at an operating system level and can then be used across multiple applications on that device and / or delegated to other devices. US2017373852 relates to authentication cryptograms between an application and a resource provider. The invention allows for authentication cryptograms to be based on user exclusive data.

[0018] 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.

[0019] 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 which 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.

[0020] 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.

[0021] Preferred aspects of the invention can be found in the sub-claims.

[0022] The invention advantageously dissociates the general compliance and maintenance from the holder without requiring the use of an intermediary between the parties by provision of a scheme. 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. In an advantageous embodiment the signatures (proofs) of the credential or credentials are replaced by the tokenised value which can be held by the credential wallet and can be 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, 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. An exemplary embodiment of the invention will now be described in greater detail with reference to the drawings in which:

[0023] Fig. 1 shows a schematic of a trust network;

[0024] Fig. 2 shows a flow diagram of credential issuance and

[0025] Fig. 3 shows a flow diagram of credential usage

[0026] 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. A verifier may be a biometric verification provider, such as iProov ®. An example of such a biometric verification system is disclosed in GB2584547, which is wholly incorporated herein by reference. 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.

[0027] 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 can facilitate 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] The various components of the system described herein may be implemented as a computer program using a general-purpose computer system. Such a computer system typically includes a main unit connected to both an output device that displays information to an operator and an input device that receives input from an operator. The main unit generally includes a processor connected to a memory system via an interconnection mechanism. The input device and output device also are connected to the processor and memory system via the interconnection mechanism.

[0034] One or more output devices may be connected to the computer system. Example output devices include, but are not limited to, liquid crystal displays (LCD), plasma displays, OLED displays, various stereoscopic displays including displays requiring viewer glasses and glasses-free displays, cathode ray tubes, video projection systems and other video output devices, loudspeakers, headphones and other audio output devices, printers, devices for communicating over a low or high bandwidth network, including network interface devices, cable modems, and storage devices such as disk, tape, or solid state media including flash memory. One or more input devices may be connected to the computer system. Example input devices include, but are not limited to, a keyboard, keypad, track ball, mouse, pen / stylus and tablet, touchscreen, camera, communication device, and data input devices. The invention is not limited to the particular input or output devices used in combination with the computer system or to those described herein.

[0035] The computer system may be a general-purpose computer system, which is programmable using a computer programming language, a scripting language or even assembly language. The computer system may also be specially programmed, special purpose hardware. In a general-purpose computer system, the processor is typically a commercially available processor. The general- purpose computer also typically has an operating system, which controls the execution of other computer programs and provides scheduling, debugging, input / output control, accounting, compilation, storage assignment, data management and memory management, and communication control and related services. The computer system may be connected to a local network and / or to a wide area network, such as the Internet. The connected network may transfer to and from the computer system program instructions for execution on the computer, media data such as video data, still image data, or audio data, metadata, review and approval information for a media composition, media annotations, and other data.

[0036] A memory system typically includes a computer readable medium. The medium may be volatile or nonvolatile, writeable or nonwriteable, and / or rewriteable or not rewriteable. A memory system typically stores data in binary form. Such data may define an application program to be executed by the microprocessor, or information stored on the disk to be processed by the application program. The invention is not limited to a particular memory system. Time-based media may be stored on and input from magnetic, optical, or solid-state drives, which may include an array of local or network attached disks.

[0037] A system such as described herein may be implemented in software, hardware, firmware, or a combination of the three. The various elements of the system, either individually or in combination may be implemented as one or more computer program products in which computer program instructions are stored on a non-transitory computer readable medium for execution by a computer or transferred to a computer system via a connected local area or wide area network. Various steps of a process may be performed by a computer executing such computer program instructions. The computer system may be a multiprocessor computer system or may include multiple computers connected over a computer network or may be implemented in the cloud. The components described herein may be separate modules of a computer program, or may be separate computer programs, which may be operable on separate computers. The data produced by these components may be stored in a memory system or transmitted between computer systems by means of various communication media such as carrier signals. Having now described an example embodiment, it should be apparent to those skilled in the art that the foregoing is merely illustrative and not limiting, having been presented by way of example only. Numerous modifications and other embodiments are within the scope of one of ordinary skill in the art and are contemplated as falling within the scope of the invention.

Claims

Claims1. 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, the wallet having an identifier, and a verifier for validating or authenticating the credential, wherein the trust network further comprises a scheme, which scheme provides a tokenisation service, 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 1, 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