EP3669513A1

EP3669513A1 - Digital identity system

Info

Publication number: EP3669513A1
Application number: EP18768835.3A
Authority: EP
Inventors: Robin TOMBS; Julie DAWSON
Original assignee: Yoti Holding Ltd
Current assignee: Yoti Holding Ltd
Priority date: 2017-09-07
Filing date: 2018-09-06
Publication date: 2020-06-24
Also published as: WO2019048574A1

Abstract

In one example, a digital identity system comprises: a computer interface for receiving electronic messages; electronic storage configured to store verified digital identities, each comprising identity data captured from a respective identity document of a respective user and received in an electronic message; an identity verification module configured to verify each of the digital identities using data captured from the respective identity document; a record creation module configured to create, in the electronic storage, a record of a verified relationship between the verified digital identity of a first user and the verified digital identity of a second user; and a messaging module configured to receive a message instruction from the first user, and send a relationship-sharing message to a third party device according to the message instruction, the relationship-sharing message confirming the verified relationship between the first and second verified digital identities.

Description

Digital Identity System

Technical Field This disclosure relates to a digital identity system. Background

From time to time people need to prove some aspect of their identity, and often the most compelling way to do this is with a passport or other national photo ID such as a driving licence or (in jurisdictions which mandate them) an identity card. However whilst these documents are greatly trusted due to the difficulty involved in making fraudulent copies and their issuance by government institutions, they are also sufficiently valuable that it is preferable not to have to carry them everywhere with us. There are also other situations, in which the use of such physical documents to provide identity may not be possible or practice, for example in an online context.

Summary Various aspects of the present invention focus on situations in which a first user needs or wishes to demonstrate, to a third party entity (device or user), the existence of an established relationship with a second user(s). This disclosure recognises that there are in fact three elements that are needed to properly evidence such a relationship: firstly, the first user, who is asserting the relationship, needs to prove his own identity, i.e. that he "is who he says he is"; secondly, the first user needs to prove the second user's identity, i.e. that the second user is who the first user says he is; thirdly, the first user needs to prove the existence of a genuine relationship between the first and second users whose identities have been established. A digital identity system is provided, which allows a user to demonstrate the existence of such relationships - also referred to herein as "Connections" - to a third party, using a messaging function or other information-providing function of the digital identity system. This allows a first user to demonstrate - to a third party - the existence of an established relationship with a second user. In line with the three elements set out above, the digital identity system provides verified digital identities and stores records of verified relationships between those verified digital identities, such that a first user can use the messaging or other function of the system to confirm, to a third party entity, the existence of a verified relationship between his verified digital identity and the verified digital identity of a second user.

The mechanisms used to verify the digital identities and the relationships can vary depending on the context, and in some contexts more robust checks may be needed than in others. What is material is that sufficient checks are in place to ensure that: a) the first user's digital identity is verified in that the system is sufficiently confident that the first user, who is asserting the relationship, is the person to which that digital identify corresponds (first element above), b) the second user's digital identity is verified in that the system is sufficiently confident that the second user is the person to which that digital identify corresponds (second element above), and c) the relationship between those digital identities is verified in that the system is sufficiently confident that there is indeed a genuine relationship between the first and second users (third element above). The invention has various applications, including the prevention of fraud and criminal activity. For example, the invention can be used to demonstrate that one of the users is authorized to act on behalf of the other, e.g. as a legal agent, medical practitioner or an authorized agent or representative in some other capacity, as a means of combatting fraud. Another use case is allowing a parent or other family member to prove the existence of a genuine familial relationship with a child, to a school or similar institution, as a means of combatting child abduction.

A first aspect of the invention provides a digital identity system comprising: a computer interface for receiving electronic messages; electronic storage configured to store verified digital identities, each comprising identity data captured from a respective identity document of a respective user and received in an electronic message; an identity verification module configured to verify each of the digital identities using data captured from the respective identity document; a record creation module configured to create, in the electronic storage, a record of a verified relationship between the verified digital identity of a first user and the verified digital identity of a second user; and a messaging module configured to receive a message instruction from the first user, and send a relationship-sharing message to a third party device according to the message instruction, the relationship-sharing message confirming the verified relationship between the first and second verified digital identities.

The identity document is a physical, real-world document, such as a passport, driving license or (national) identity card. Data can be captured from the identity document using an image capture device, by reading an electronic device (e.g. chip) embedded in the document, e.g. as found in modem passports in certain territories, or a combination of both. The biometric data captured from the document would typically be in the form of an identification photograph, but it may be possible to capture other forms of biometric data, such as a fingerprint or a fingerprint template, from the document which can be used instead of, or in addition to, an identification photograph. In the future, it is anticipated that certain passports and other identity documents may provide alternative forms of biometric data.

In preferred embodiments of the first aspect, the captured data used to verify the digital identity comprises biometric data captured from the respective identity document and the identity verification module is configured to verify each of the digital profiles by comparing the biometric data with a biometric identifier captured from the respective user. That is, the digital identities are "anchored" to identity documents, which may also be referred to as anchoring documents in this context. This provides a high level of confidence that the user providing the biometric is the "owner" of the identity document. However, it is not essential, as there may be contexts in which the fact that the user has the identity document available to him is sufficient proof of identity.

A second aspect of the invention provides a digital identity system comprising: a computer interface for receiving electronic messages; electronic storage configured to store verified digital identities, each comprising a respective biometric identifier captured at a respective device; an identity verification module configured to verify each of the digital identities based on at least one liveness detection test performed at the respective device to verify that the respective biometric identifier has been captured from an actual living user of the respective device; a record creation module configured to create, in the electronic storage, a record of a verified relationship between the verified digital identity of a first user and the verified digital identity of a second user; and a messaging module configured to receive a message instruction from the first user, and send a relationship-sharing message to a third party device according to the message instruction, the relationship-sharing message confirming the verified relationship between the first and second verified digital identities.

In accordance with the second aspect, the digital identities are validated on the basis that the biometric identifiers comprised therein have been captured from an actual, living human.

The biometric identifier (ID) of the first or second aspect can for example be a facial image ("selfie") captured at a user device of the respective user, using an image capture device or other form of biometric sensor, such as a fingerprint reader or any other sensor capable of capturing data from the user that can be used as a biometric identifier (i.e. that is sufficiently unique to that user to serve as an identifier in the context of the system). In the preferred embodiments of the first aspect referred to above, this biometric identifier is compared with the biometric data captured from the identity document to verify that the user providing the biometric identifier is indeed the "owner" of the identity document. This can, for example, be part of an enrolment process in which a user provides the captured identity document data along with the captured biometric, where the creation of a digital identity based on the captured identity document data is conditional on the biometric identifier matching the biometric data. In this context, all digital identities within the system are verified digital identities, which are verified at the time of creation. However, this is not essential, and in general it is acceptable for the first and second users' digital identities to be verified provided they are verified before the relationship-sharing message is sent to the third party entity, as the transmission of the relationship-sharing message is conditional on those digital identities, and the relationship between them, having been verified.

In accordance with the second aspect, anchoring to an identity document is not required, as there are situations in which it is sufficient to verify that the biometric identifiers (e.g. facial images) have been captured from real humans at the time they are provided to the system, at the device that is providing the biometric identifier to the digital identity system, in contrast to a "spoofed" identifier that has been captured, for example, from a photograph or model of a human. In this context, the relationship- sharing message serves to demonstrate to the third party that the system is sufficiently confident that a relationship exists between the people having those biometric IDs (e.g. having those faces), without those e.g. faces needing to be anchored to an identity document.

However, there are also situations in which it will be desirable to combine the liveness detection of the second aspect with the anchoring of the first aspect. The highest level of confidence is obtained when the biometric identifier is both matched with captured biometric data of the identity document (as in the preferred embodiments of the first aspect set out above) and subject to liveness verification as in the second aspect, to ensure that the user providing the biometric identifier at his device is both the owner of the identity document and an actual human using that device when the biometric identifier is captured.

Preferably the system comprises a relationship verification module configured to verify the relationship between the digital identities of the first and second users. The relationship can be verified based on information provided, by both of the first and second users, that demonstrates the existence of the relationship. For example, the relationship verification module may be configured to verify the relationship in response to receiving consent of the first user and consent of the second user. The first and second users can provide their respective consent to the digital identify system directly, e.g. by way of respective messages to the digital identify system, or one of the users can provide consent to the other user (e.g. by presenting a credential to the other user), who in turn provides the other user's consent to the digital identity system along with his own consent (e.g. by transmitting the other user's credential, along with his own credential) to the digital identity system. This can be part of a "uPass" or "Yoti" transaction, where those terms are defined below. The invention is not limited in this respect, and relationships can be verified in various ways, depending on the context. For example, it may be possible to verify a relationship between two digital identities by cross-referencing data of those identities with a trusted database, such as a government database or the database of another trusted institution. In embodiments, the relationship verification module may be configured to verify the relationship in response to one of the first and second users (accepting user, who can be either of those users) accepting, at a device operated by that user, an association request instigated by the other of the first and second users (requesting user). (That is, although it is the first user in this context who is asserting the relationship with the second user, generally, the recording of that relationship may be instigated by either the first or the second user). The relationship verification module may be configured to receive a response accepting the request from the device of the user accepting the request.

The relationship verification module may be configured to transmit the association request in response to an instruction from the device of the user instigating the request.

The association request may be transmitted to the device of the user accepting the request with at least one piece of supporting evidence, wherein the record creation module is configured to receive a copy of the supporting evidence and store it as part of the record of the verified relationship.

In order for the first user to instigate the relationship-sharing message, depending on the implementation, he may be required to take additional steps at that point in time to demonstrate that the digital identity is actually his. This can take the form of an authentication process, wherein the user provides secret user authentication data (such as a password or PIN) that is matched with corresponding authentication data associated with the digital identity. Biometric authentication may also be used at this point, wherein the user is required to provide a biometric identifier captured at that device (preferably subject to liveness detection), which is matched with the biometric identifier in his account. Where the digital identity is anchored to an identity document, then this biometric identifier must also match biometric data captured from the identity document. The point at which the user instigates the Share can be the point at which the digital identity is verified using the biometric identifier, or the digital identity can be verified separately, e.g. as part of an earlier enrolment process, in which case the biometric identifier provided as part of the authentication needs to match the separately-verified biometric identifier of the user's digital identity.

The "relationship-sharing message" is equivalently referred to herein as a "Share" or "confirmation message".

As an alternative to the messaging module of the first and second aspects, an API (application programming interface) may be provided, via which an authorized third party can obtain information about connections between users of their own volition.

Any of the information conveyed to the third party in a relationship-sharing message can be comprised in or indicated by the message. For example, the message can comprise a link to or other identifier of a memory location from which the information can be obtained.

A third aspect of the invention provides a digital identity system comprising: a computer interface for receiving electronic messages; electronic storage configured to store verified digital identities, each comprising identity data captured from a respective identity document of a respective user and received in an electronic message; an identity verification module configured to verify each of the digital identities using data captured from the respective identity document; and a record creation module configured to create, in the electronic storage, a record of a verified relationship between the verified digital identity of a first user and the verified digital identity of a second user.

A fourth aspect of the invention provides a digital identity system comprising: a computer interface for receiving electronic messages; electronic storage configured to store verified digital identities, each comprising a respective biometric identifier captured at a respective device; an identity verification module configured to verify each of the digital identities based on at least one liveness detection test performed at the respective device to verify that the respective biometric identifier has been captured from an actual living user of the respective device; and a record creation module configured to create, in the electronic storage, a record of a verified relationship between the verified digital identity of a first user and the verified digital identity of a second user.

In embodiments, the digital identity system of the third or fourth aspects may comprise a third party interface configured for use by an authorized third party device in retrieving data of the record.

The third party interface may be an API (application programming interface). Alternatively or in addition to the messaging module or third party interface, the system can comprise some other form of information releasing component configured to selectively release information about the recorded relationship to a third party device or other third party entity. In embodiments of any of the first to fourth aspects, the captured data used to verify the digital identity may comprise biometric data captured from the respective identity document, and the identity verification module may be configured to verify each of the digital profiles by comparing the biometric data with a biometric identifier captured from the respective user.

The identity document may be a passport, driving license, or identity card.

The relationship-sharing message sent to the third party device may comprise at least part of the identity of the first or second user's verified digital identity.

The relationship-sharing message sent to the third party device may comprise or indicate: at least part of the captured identity data of the first user's verified digital identity, and/or separately-provided identity data matching the captured identity data; and at least part of the identity data of the second user's verified digital identity, and/or separately-provided identity data matching the captured identity data.

The digital identity system may comprise a relationship verification module configured to verify the relationship between the digital identities of the first and second users. The relationship verification module may be configured to verify the relationship in response to one of the first and second users accepting, at his device, an association request instigated by the other of the first and second users. The relationship verification module may be configured to receive a response accepting the request from the device of the user accepting the request.

The messaging module may be configured to include or indicate a copy of the supporting evidence in the relationship-sharing message sent to the third party device.

The record creation module may be configured to store the copy of the supporting evidence only if it receives confirmation that the user accepting the request has reviewed the supporting evidence.

The confirmation may be comprised in the response received from the device of the user accepting the request.

The digital identity of the second user may comprise a messaging identifier for transmitting messages for receiving by the second user.

The digital identity system may be configured to use the messaging identifier in the second user's digital identity to transmit, for receiving by the second user, a notification that the relationship-sharing message has been sent.

The digital identity of the first user may comprise a messaging identifier for transmitting electronic messages for receiving by the first user. The digital identity system may be configured to use the messaging identifier in the first user's digital identity to transmit, for receiving by the first user, a notification that the relationship-sharing message has been sent.

The digital identity system may comprise a messaging identifier verification module configured to verify the or each messaging identifier.

The messaging identifier verification module may be configured to verify the or each messaging identifier by using the messaging identifier to transmit a verification message, and verifying the messaging identifier if an expected response is received.

The digital identity system may be configured to erase or invalidate the record of the verified relationship in response to a request from the second user, whereby the first user cannot confirm the relationship to third party entities thereafter.

The relationship-sharing message sent to the third party device may comprise an indication of a type of the relationship. The relationship-sharing message may include or indicate at least one of:

message content specified in the message instruction; a name of the first user and/or second user derived from the captured identity data of his digital identity; an image of the first and/or second user derived from his digital profile, the image being an image derived from the captured identity data or an image that matches an image of the captured identity data; a date of birth of the first and/or second user from the captured identity data of his digital profile; a gender of the first and/or second user derived from the captured identity data of his digital identity; and a nationality of the first and/or second user derived from the captured identity data of his digital identity. The digital identity system may be configured to retain a history of relationship-sharing messages sent for the verified relationship, which is accessible to at least one of the first and second users. The digital identity system may be configured to receive a response to the relationship- sharing message from the third party device, and communicate the response to at least one of the first and second users. The creation of the record may be instigated by the first user and the record creation module may be configured to set a flag of the record to indicate whether or not the second user is permitted to confirm the relationship to third parties.

The identity verification module may be configured to verify each of the digital profiles by applying document verification to the captured data.

The captured identity data of the digital profile may comprise at least part of the captured data used to verify the digital identity. The biometric data may comprise an identification photograph and the biometric identifier is a facial image.

The relationship verification module may be configured to verify the relationship between the digital identities of the first and second users in based on at least one electronic consent message received at the digital identify system, which confirms that both the first user and the second user have consented to the relationship being recorded.

The relationship verification module may be configured to verify the relationship between the digital identities of the first and second users based on a first electronic message received from the first user and confirming the consent of the first user and a second electronic message received from the second user and confirming the consent of the second user. The relationship verification module may be configured to verify the relationship between the digital identities of the first and second users based on an electronic message received from one of those users, which confirms that both of those users have consented to the relationship being recorded. The electronic message may comprise a credential of the other user that has been captured by the user from which the electronic message is received, and thereby confirms that the other user has consented to the relationship being recorded, wherein the relationship verification module is configured to match the received credential with a credential associated with the other user's digital identity.

The digital identity system may be configured to erase or invalidate the record of the verified relationship in response to a request from the first user, such that it cannot be shared with third party devices thereafter.

The record may be of a relationship between at least three digital identities of at least three users, including the first and second user.

The relationship-sharing message may comprise or consist of a code or link, wherein the digital identity may be configured to store details of the verified relationship at a memory location that is accessible to the third party device using the code or link, such that the code confirms the verified relationship.

The copy of the supporting evidence is stored in association with the link or code such that the link or code can be used to retrieve the supporting evidence, whereby the link or code in the relationship-sharing message indicates the supporting evidence.

The relationship-sharing message may be in the form of: an email or a text message. The record of the verified relationship may be stored on a blockchain implemented in the electronic storage.

The blockchain may be implemented by a plurality of distributed electronic storage devices of the electronic storage.

The blockchain may be a public or private blockchain.

The blockchain record may comprise at least one of: proof of the relationship, and proof that consent was given to record the relationship. The record may be an anonymized record.

The anonymized record may comprise a hash of at least part of the digital identity of each of the users, generated using a hash key, such that the relationship between those digital identities cannot be determined from the anonymized record without the hash key.

The anonymized record may comprise a hash of data about the relationship and/or a hash of data of the digital identity of each of the users, generated using a hash key, such that the relationship and/or the identities of the users cannot be determined from the anonymized record without the hash key.

A confidence value may be stored in association with the record.

The confidence value may be increased in response to another user or entity vouching for the relationship.

The confidence value may be rendered available to the third party device.

The confidence value may be stored on the blockchain.

Another aspect of the invention provides a digital identity system comprising: electronic storage configured to store digital identities; and a record creation module configured to store, on a blockchain, a record of a relationship between the digital identity of a first user and the digital identity of a second user.

A fifth aspect of the invention provides a system for connecting digital identities comprising: a computer interface for receiving electronic messages; a record creation module configured to create an electronically-stored record of a verified relationship between a verified digital identity of a first user and a verified digital identity of a second user, each of the digital identities comprising identity data captured from a respective identity document of a respective user, each of the digital identities having been verified at the digital identity system using data captured from the respective identity document.

A sixth aspect of the invention provides a system for connecting digital identities comprising: a computer interface for receiving electronic messages; a record creation module configured to create an electronically-stored record of a verified relationship between a verified digital identity of a first user and a verified digital identity of a second user, each of the digital identities comprising a respective biometric identifier captured at a respective device, each of the digital identities having been verified at the digital identity system based on at least one liveness detection test performed at the respective device to verify that the respective biometric identifier has been captured from an actual living user of the respective device.

In embodiments, the system of the sixth or seventh aspect can comprise any feature of the digital identity systems disclosed herein.

Another aspect of the invention provides a method in which steps are performed to implement any of the aforementioned features of any of the above mentioned aspects, and a computer program product comprising executable instructions configured to carry out the method when executed.

Brief Description of Figures

For a better understanding of the present invention, and to show how embodiments of the same may be carried into effect, reference is made to the following figures in which:

Figure 1 shows a schematic block diagram of a digital identity system;

Figure 2 shows a signalling diagram for an identity sharing process;

Figure 3 shows a signalling diagram for a process of obtaining a sharing token;

Figure 4 shows a schematic block diagram of a user device executing an identity application;

Figure 5 shows a signalling diagram for an enrolment process; and Figures 6A to 6C show, at different respective time instants, a user interface rendered on a display of a user device, via which a user may create and share verified Connections to other users. Detailed Description

Preferred embodiments of the invention are described below. First, by way of context, a digital identity system is described. Digital identities are created and managed by the digital identity system and in the described examples these digital identities form the basis of verified Connections between users of the digital identity system.

Figure 1 shows a highly schematic functional block diagram of a digital identity system 1 from which verified identity attributes are released when certain conditions are satisfied.

The following documents (the "uPass/Yoti Documents") are referred to herein, and each of these documents is also incorporated by reference herein, in its entirety: published PCT application WO2016/28569 (application no. PCT/EP2016/053076); published Unites States patent application US20160239653 (application no. 14/622527); published United States patent application US20160239657 (application no.14/622709); published United States patent application US20160241531 (application no. 14/622549); published United States patent application US20160239658 (application no. 14/622737); United States patent 9648496 and corresponding published application US20160241532 (application no. 14/622740). Unless otherwise indicated, any terms user herein - such as "uPass" and "YOTI" (equivalently, "yoti" or "Yoti") - have meanings as defined in those documents. In particular, in embodiments of any aspects of the invention disclosed herein, a digital identity may take the form of a "uPass" or "YOTI" as defined in the aforementioned documents. The uPass/Yoti Documents describe a particular form of digital identity system, in which a user can, for example, create a profile of their digital identity (referred to therein as a uPass or YOTI) based on an identity document, such as a passport, and a self-captured image of their face (selfie). The digital identity system 1 may be configured in accordance with any of the above. By way of example, in the following, the digital identity system 1 takes the form of the ΎΟΤΙ" system as disclosed WO2016/2856. Features of the YOTI system that are relevant to the present invention are summarized below.

The digital identity system 1 is shown to comprise a secure store 102 in which digital identity attributes may be stored securely. A digital identity in this context refers to a digital identity attribute or set of such attributes defining an identity of a user. A user's identity attributes are encrypted using a user key that is held on the user's own device, which the user must provide in order for them to be decrypted. Attributes are stored at locations in the secure store 102 that are identified by database keys (attribute keys) which are also held on a user's own device. The only thing that links a user's attributes together in the secure store 102 are the attribute keys held by the user. The digital identity system 1 is also configured to provide various services, including an enrolment service 14a which allows users to create digital identities, a validation service 14b which allows a user to share all or part of his digital identity with another user, and a biometric user authentication service 108 which can verify a user biometrically based on a biometric digital identity attribute (e.g. comprising facial image data).

In order to enrol with the enrolment service 14a, the user may be required to submit data captured from an identity document (e.g. by taking an image thereof or reading a chip therein). The attributes are derived from the captured identity document data, and may be verified by matching a biometric of the identity document with a biometric captured from the user (e.g. self-image or "selfie") using a biometric sensor (e.g. image capture device) of their user device.

Although not shown in Figure 1 , the digital identity system 1 comprises one or more processors (CPUs/GPUs etc.) on which computer programs are executed in order to provide the above services, and a network interface that allows the digital identity system 1 to communicate with external devices (such as user devices) via a network such as the Internet. Figure 2 shows a flow diagram for an identity sharing process conducted between two entities that is mediated by the digital identity system 1. In this example, the entities are users (not shown) operating respective user devices 202 (bearer device) and 204 (validator device/capturing device).

The process can be a one-way sharing process in which only one user shares identity attribute(s) with the other, or it can be a two way process in which each shares identity attribute(s) with the other. In order to initiate the process, at step S2, the bearer device 202 renders accessible to the capturing device 20 a token 206 that is associated, within the digital identity system 1 , with the bearer device 202. The token 206 can take various forms. In the following examples, it is in the form of a sharing token bound to an underling bearer credential.

In the case that the user of the bearer device 202 (the bearer) is sharing identity attribute(s) with the user of the capturing device 204 (the validator/capturer), the token 206 is associated in the digital identity system 1 with the bearer's attribute(s) to be shared.

The token 206 is rendered available by the bearer device 202 with a policy 208, which identifies any identity attribute types the bearer is willing to share with the user of the capturing device 204 (the capturer) and any identity attribute types the bearer requires the capturer to share in return.

These are captured at the capturing device 204 and, at step S4, the capturing device 204 sends, in an electronic message to the digital identity system 1 , the captured token 206 and policy 1028, together with a capturer credential 210. In the case that the capturer is sharing one or more identity attributes with the bearer, these are also sent with an encrypted version of the capturer's user key 22 (Dk(Uk)) and a set of one or more attribute keys 214, which identity the location(s) of the capturer's attributes, in the secure store 102, to be shared in accordance with the policy 208. The user key 22 is encrypted using a device key (Dk) that is also accessible to the digital identity system 1 , so that it can be descripted thereat. The capturer credential 210 is validated at the digital identity system 1 , by the validation service 14b, and if it is valid, the attribute key(s) 214 are used to locate the capturer's attribute(s) to be shared, and the capturer's user key 212 is used to decrypt those attribute(s) for sharing. This may also require the policy 206 provided by the capturing device 204 to match a policy associated with the token 202.

At steps S6a and S6b, the digital identity system 1 transmits (or otherwise renders accessible), to the bearer and capturing devices 202, 204, respective identity receipts 216a, 216b (paired receipts).

The receipt 216a sent to the bearer device 202 (bearer receipt) comprises or indicates any identity attributes of the capturer that have been shared with the bearer. Likewise, the receipt 216b sent to the capturing device 204 (capturer receipt) comprises or indicates any identity attributes of the bearer that have been shared with the validator (as associated with the token 206). A receipt may indicate attributes for example by way of a link in the receipt to a memory location at which the attributes are stored (published). Each receipt 216 may be cryptographically signed, to generate a cryptographic signature for the receipt, using a private key held securely within the digital identity system, so that its contents can be verified cryptographically using the corresponding public key. Figure 3 shows a flow diagram for a process in which the bearer device 202 obtains the token 206 for use in the above process. The bearer device 202 transmits to the digital identity system a bearer credential 308, in association with the policy 208. In order to associate the token with identity attribute(s) to be shared, the bearer device sends these together with the bearer's user key 312 and one or more attribute keys 314 for locating, in the secure store 102, the bearer attributes to be associated with the token 206. This allows the attribute(s) to be located and decrypted for subsequent sharing. In response, the bearer device 202 receives the token 206 for use in the process of Figure 2. At this point, as well as being bound to the specified bearer identity attribute(s) (if any), the token 206 is bound to the policy 208 as received from the bearer device 202, and can only be used to share attributes in accordance with the policy 208 to which it is bound. As described above, a matching policy may be required to be presented to the digital identity system 1 in order to use the token 206 to cause a release of identity attributes from the digital identity system 1. The token 206 is also associated with the bearer device 202 and thus functions as an identifier of the bearer device 202.

Figure 14 shows a highly schematic block diagram of a user device 400 such as the bearer or capturing device 202, 204. An identity application 402 is executed on a processor of the user device 400 (not shown) in order to allow the user device 400 to interface with the digital identity system, e.g. in order to participate the process of Figure 2 or 3. The identity application 402 is secured by a PIN (personal identification number) or other secret user authentication data 404 which a user much enter, in order to unlock the identity application 402, in a local user authentication process performed at the user device 400. This means that a user can only share their identity attribute(s) once they have successfully completed the local user authentication process by entering the correct PIN to unlock the app. Hence the user's identity attributes are secured by the PIN 404. This is one way of authenticating a user in order to release his identity attributes.

Further or alternatively, biometric authentication may be used to secure a user's identity attributes. This can be performed locally at the user device 400, or it may be performed remotely at the digital identity system, by the biometric user authentication service 108. For example, an additional requirement may be imposed in the process of Figure 2 and/or 3, wherein the user in question is required to submit a captured biometric (e.g. a selfie captured at their device) along with the other elements (credential etc.) for comparison with a corresponding biometric identity attribute held in the secure store 102. In this case, the user provides the attribute key for locating the biometric identity attribute (and the user key for decrypting it). The identity attribute(s) in question will only be released for sharing with the other user if the captured biometric matches the biometric identity attribute. This is another way of authenticating a user in order to release his identity attributes. A layer of verification can also be provided by anchoring the identity attributes to an identity document or other anchoring document (passport, driving licence, ID card etc.). In this case the identity attributes can be captured from or otherwise matched to the anchoring document. As noted, this can for example form part of the enrolment process, in which a user creates a digital identity for himself.

As will be appreciated, these are just some examples of user authentication processes that a user can engage in order to obtain a set of verified identity attributes. Generally any suitable user authentication process can be implemented in order to verify that the set of identity attributes in question does correspond to the user engaging in the user authentication process (and not somebody else).

Different user authentication methods may be available, possibly with different levels of confidence/robustness. In some cases, a user authentication requirement may be specified within the policy 208 itself. The user authentication requirement may denotes a required type(s) of user authentication process. In that case, the release of identity attributes in the process of Figure 2 is contingent on successful completion of a user authentication process (s) of the required type(s). Figure 5 shows an example method by which a user of a device can create a digital identity for himself within the digital identity system 1. In the following example, the user in question is the bearer, however the description applies equally to the capturing user. At step S202a, the user uses his device 202 to capture a set of N attributes {a2,...,aN}, where N>1 , from an identity document 502, such as a passport, driving licence, national identity document etc. These may for example be captured using a camera of the device 14 or from an NFC chip embedded in the document, or a combination of both. At step S202b, the user captures using the camera of the device 202 an image of his face, i.e. his selfie, which is also an attribute of the user denoted a1 by convention herein.

At step S204, the user transmits to the enrolment service 14a of the digital identity system 1 an electronic identity creation request comprising the set of attributes {a1 , a2,...,aN}, denoted {a} for convenience be!ow. That is, the selfie a1 and the additional attribute(s) captured from the document 502.

In response to the enrolment request, the enrolment service 14a generates (S206) a user key Uk for the user. The user key Uk is encrypted with a device key Dk for the device 202, wherein Dk(Uk) denotes a version of Uk encrypted with Dk. To generate the user key Uk, the enrolment service 14a inputs the device key Dk to the user key generator 502. To provide optimum security, the user key generator 502 can be implemented as a dedicated, hardware security model of the system, e.g. in accordance with the FIPS 14-2 standard. In response to receiving the device key Dk, the user key generator 502 generates the user key Uk and outputs only the encrypted version of it Dk(Uk) to the enrolment service 14a. The unencrypted version Uk is never rendered directly accessible by the user key generator 502. At step S208a, the enrolment service 14a uses the device key Dk to decrypt the encrypted version of the user key Uk, and uses the unencrypted version of the user key Uk to encrypt each of the attributes a1 ,...aN. The user key Uk may be used directly to encrypt the attributes. Alternatively, each attribute may be encrypted with a key unique to that attributr ("Item key/attribute key" Ik); in this case, the item key Ik is unencrypted with the user key Uk. The encrypted item key Uk(lk) is held in the identity system 1 , in a manner such that the user can send a message to the identity system which comprises Dk(Uk) and identifies where a given one of their attributes a is stored, and also where the item key Uk(lk) for that attribute is stored. The device key Dk is used to decrypt Dk(Uk), Uk is used to decrypt Uk(lk), and Ik is used to decrypt the identified attribute lk(a).

Note that them terminology "data encrypted with a key" is not limited to direct encryption of that data with that key, an also covers, for example, a situation where the data is directly encrypted with a a different key, and the different key is encrypted directly with that key (among others).

A respective entry 102(1),..., 102(N) is created in the secure store 1502 for each of the attributes a1 aN. Each entry is a key-value pair, whose value is the encrypted version of that attribute, denoted Uk(a1) Uk(aN), and whose database key Ka1 ,...,KaN of is a randomly generated sequence. The database key is needed to locate that key-value pair in the database. Below, {Ka} is used to denote the set of database keys for the set of attributes {a}. Alternatively {Ka} may comprise, for each attribute, the user massage may comprise at least one respective pointer (or other data identifying where the relevant target data is stored). The pointer(s) for that attribute may identity both where the encrypted attribute lk(a) is held, and where the encrypted item key Uk(lk) for that attribute is held.

At step S208b, the enrolment service responds to the enrolment request by transmitting an electronic response message to a network address associated with the device 202. The response comprises the encrypted version of the user key Dk(Uk), the set of database keys {Ka} and a credential c. Once the request has been sent, the set of database keys {Ka} is purged from the digital identity system 1. This means that the entries 21 (1 ),...21 (N) are not associated with the user anywhere in the digital identify system 1 ; the only association that exists between those entries and the user arises by virtue of the fact that the user holds the set of database keys {Ka}.

The credential is a one-time only use credential for the user that is bound to his device 202 and a user identifier ulD of the user. At step S208c, the enrolment service 14a stores in a second data store 33 of the digital identity system 1 an identifier dID of the device 202, in association with the credential c and a state of the credential. The credential is in a valid state. The state subsequently changes to either "used" or "expired", upon use or if it is not used within a certain duration form its creation. The user ulD is also stored in association with the device identifier dID, and is thereby associated in the digital identify system 1 with the credential c. By virtue of these associations, the credential is bound to both the user and the device 202.

In this example, the user identifier ulD comprises image data of the selfie captured at step S202b, which is some embodiments may also be encrypted with the user key Uk. Herein, the term image data of an image (or sequence of images) is used to mean the image itself or selective information extracted from the image(s), such as a local binary pattern (LBP) generated from the image(s) or a set of parameters generated by training a machine learning model (ML) using the image(s) themselves or information extracted from them, e.g. an ML model may be trained using LBPs which have been extracted from the original image(s).

Such selfie image data is one example of what is referred to herein as a biometric template of the user. Alternative biometric templates include image data of a fingerprint image, retinal image, or an image capturing some other suitable biometric feature of the user. In general, the user identifier ulD may comprise any such biometric template(s) and/or a non-biometric identifier such as a secret(s) known only to the user. The information embodied in the user identifier ulD is voluntarily made available by the enrolling user during enrolment, on the understanding that it is only being stored at the digital identity system 1 to prevent others from being able to gain access to their stored attributes.

The device key Dk itself is also stored in the second store 33, in association with a hash (e.g. HMAC) of Dk(Uk). The hash of an input value means an output value obtained by applying a hash function, such as an HMAC function, to the input value. The advantage of a hash is that it is impossible to recover the original input value from the output value alone. In the present disclosure, this property is exploited by using the hash H(Dk(Uk)) as an index for Dk. This allows Dk to be stored in association with Dk(Uk) without having to store Dk(Uk) at the digital identity system 1 itelf (as noted above, Dk(Uk) is held only by the user). This allows Dk to be located when (and only when) the user device subsequently presents Dk(Uk) to the digital identity system, by re-hashing Dk(Uk) and using the result to locate Dk. Anchoring digital identities to underlying identity documents in this manner is one of the mechanisms by which digital identities are verified in the described system.

Digital identities may also be verified based on "liveness" testing. Returning to Figure 1 , the digital identity system 1 is also shown to comprise a liveness detection module 109 which is configured to carry out one or more liveness tests in order to verify a user's digital identity. The liveness detection module 220 may also processes biometric data (e.g. image data) exhibiting human characteristics (e.g. facial characteristics) in order to check for the presence of one or more required liveness attributes which indicate the human characteristics have been captured directly from a living human. "Liveness detection" refers to techniques of detecting whether an entity, which may exhibit what are ostensibly human characteristics, is actually a real, living being or is a non-living entity masquerading as such. A liveness test may take the form of a verification process that is performed to verify that biometric data (or what appears to be biometric data), such as facial image data, has been captured directly from an actual living human, as opposed to a "spoofing" entity masquerading as such (e.g. a photograph or a video played on a device, a model etc.).

The term "image data of a captured image" can refer to all or part of the image itself (raw image data) or data derived from the image (such as a feature vector etc.) in a pre-processing step, which can be performed at the digital identity system 1 , or remote from it (e.g. at the user device 400).

The liveness detection process applied by the liveness detection module 109 comprises checking for the presence of at least one liveness characteristic of a user of the device 400 from image data captured at the device 400.

For example, as part of the enrolment process of Figure 5, the user may be required to submit an image captured at the device 202, using the device's camera, to which the liveness test can be applied (liveness image). The selfie that is captured for comparison with the identity document 502 may comprise or be derived from the liveness image, or they may be separate images. The liveness image can be a video image (comprising a sequence of frames) and certain tests may require a video image. Depending on the nature of the liveness test, the user may be required to perform certain actions that must be adequately captured in the video image, in order to pass the liveness test. . However, for other tests, the liveness image could be a static image.

The liveness test may be performed, for example, by detecting 3D facial structure in the captured video image. One specific example of this is involves detecting motion of 3D landmark points on the captured facial structure. That is, in a video image of a moving (e.g. rotating) face, the distances between points such as the eyes, ears, nose, mouth, etc. will be seen to vary in the image as the face moves if the face is indeed 3D. This allows 3D structure to be detected using a 2D camera. Alternatively, 3D imaging can be used, such as stereoscopic imaging, or using infrared arrays etc.

In another example, the liveness image is a video image and the liveness detection module 109 may determine that the user in the video image is alive by detecting skin colour variations (e.g. blushing or skin colour changes indicative of a heart beat) or some other physiological signal.

Another form of liveness test is based on "challenge-response", wherein an output is provided to elicit a response from a user of the device 202, and the system checks for an expected response in the image(s). The output may be randomised to make the test harder to spoof. For example, the user may be asked to say a randomly selected word, and the system may check for lip movement matching that word in a captured video image.

The liveness detection module 109 may also implement multiple liveness detection tests to increase overall robustness.

The following documents (the "Liveness Documents") are also referred to herein, and each of these documents is also incorporated by reference herein, in its entirety: published PCT application WO2017/025573 (application no. PCT/EP2016/069079); published United States patent application US20170046583 (application no. 14/822804); published United States patent application US20170048244 (application no. 14/822803). The Liveness Documents relate to liveness detection, and disclose various liveness detection tests. In embodiments, the liveness detection test or tests of the second, fourth and sixth aspects can be any one of the liveness tests disclosed in any of these documents, or any combination thereof. However, the invention is not limited in this respect, and the one or more liveness detection tests may be other types of liveness detection test. The one or more liveness tests performed by the liveness detection module 109 can be any of the liveness tests disclosed therein or any combination thereof. However, the technology is not limited to these particular liveness tests.

In another example, the camera used to capture the liveness image is an infrared camera. In such cases, the liveness detection module 110 may be configured to determine a liveness of the user using at least one thermal image (thermogram) from the infrared camera, to check for the presence of a heat distribution that indicates liveness. Preferred embodiments of the invention will now be described by way of example only.

In the embodiments described below, a mechanism referred to as "Yoti Connect" (YC) is provided as a means of implementing the invention. In this context, Yoti Connect refers to functionality of a digital identity system that is provided to allow users to establish verified connections (i.e. relationships, in the above-defined sense) between their digital identities, and share those connections with third party entities, such as third party users or devices. The digital identity system takes the form of a digital identity system as described in the uPass/Yoti Documents. Yoti Connections are created and managed by a connection management system 110, which is a subsystem of the digital identity system 1 in this example, but which could also be an external system.

The functionality represented by the various models 108, 109 and services 14a, 14b shown in Figure 1 , and the functionality of the connection management system 110, is provided by identity management code (executable instructions, i.e. software) executed on the digital identity system 1. Although not shown in Figure 1 , at least one processor, such as a CPU or set of CPUs/CPU cores (e.g. in a multicore processor) is needed to execute the identity management code. However, the digital identity system 1 can comprise multiple processors which execute different parts of the code to implement the described functionality. These can be provided in one or more computing devices, such as servers. In the case of multiple computing devices, these may or may not be geographically distributed, for example in different data centres. Although not shown in Figurel , at least one network interface is also needed to allow the digital identity system to transmit and receive electronic messages, via a digital computer network such as the Internet (not shown). The digital identity system 1 can have multiple such interfaces, and the term "computer interface" is used herein to refer to the collection of hardware, in the form of one or more network interfaces, and software that allows the digital identity system to transmit and receive electronic messages. The digital identity system 1 also comprises electronic storage, in the form of one or more computer-readable electronic storage devices, such as solid state or magnetic storage devices. The secure store 102 which holds the digital identities for the users is implemented at the hardware level as electronic storage (such as magnetic and/or solid state storage media, and/or any other suitable form of computer readable storage media), as well as the identity management code for execution on the one or more processors. With multiple storage devices, these can be localized or geographically distributed, e.g. in different data centres. The connection management system 110 allows users to establish and share connections "remotely", i.e. via the computer network using respective networked devices (e.g. user devices, such as smartphones or other user operated computing devices), without requiring face to face contact necessarily (that is, although the techniques can be applied in a context where users do happen to have face to face contact, this is not a requirement).

The connection management system 110 may comprise various modules that are not shown in Figure 1 , which represent discrete functions performed by the connection management module 110, such as verifying relationships between users, creating records of verified relationships, creating and sending, via the computer network, electronic messages relating to verified relationships, and interfacing with external systems, such as an external (public or private) blockchain. That is, any of the Connection-related functions disclosed herein may be implemented as functional modules of the connection management system 110.

The connection management system 110 enhances the identity-sharing capabilities of the digital identity system 1 , such that users can - in addition to sharing their own verified identities with other users as described above - share Connections (relationships) which they have to other users and which have been verified. Examples of Connection-related functions are described below in further detail. Unless otherwise indicated, these functions are carried out by the connection management system 110, in response to messages received from the user device 400 where applicable.

Yoti Connections (YC)

Figure 6A shows an example of a user interface which may be rendered on a display of the user device 400 to allow a user to create and share Connections. The user device 400 communicates with the connection management system 10 via the computer network, to the extent that is necessary in order to carry out such functions in response to inputs received from the user at the user interface.

Selectable 600 options are provided via which a user may, among other things, view Connections which have already been verified between him and other users and pending Connections requests which he has sent and/or which he has received from other users. Each of the other users is represented on the user interface by an identity summary which corresponds to that user's digital identity within the digital identity system. An option may also be provided for the user to view all of his Connections that have been shared (either by himself or by another user to whom he is Connected, with his consent). A record of every connection sharing event associated with the user may be marinated for this purpose.

Users create Connections (relationships, in the above-defined sense), which are verified via mutual consent of the users. Once created, generally, either of the users can share the connection. However, there may be certain circumstances in which only one of the users is permitted to share the Connection, examples of which are described later. An individual (requesting user) uses his Yoti to log in to YC and invites another individual (responding user/recipient) to confirm a Connection. The recipient receives the invitation by email from YC, or via some other digital communication mechanism, e.g. as a text message - e.g. SMS or instant messaging, using a messaging app (application), or via a social media platform - or push notification. For example, if the recipient has a YC account, he could receive a Connection invitation as a push notification as well as email.

The invitation includes a messaging identifier, such as an email address or mobile phone number for the recipient. The invitation also specifies a type of relationship to be established

The recipient creates an anchored Yoti with a verified email address, mobile number or other messaging identifier, which needs to matches the messaging identifier used in the invitation) and then log in to review the invitation (who created the invite, what is the type of Connection) and decide whether to accept it (confirm the Connection) or reject the invitation.

In order to send a Connection request, the user selects a connection creation element 602 on the user interface. As shown in Figure 6B, this causes a connection creation menu 612 to be displayed via which the user can enter details of the Connection he wishes to create, such as a type of the Connection (from a drop-down menu 614 in this example). The type can for example be one of Family/Friend, Child, Father, Mother, Family Member, Mother etc. Additionally, input fields 616 are provided into which the user can enter the details of another user of the digital identity system 1 with whom he wishes to establish a Connection. Once the necessary information has been entered, the user selects a send connection element 618 in order to send a connection request to the other user. Confirmed Connections can then be shared by either party through Yoti Connection with another individual or an organisation (or any other third party). The sharer enters the name of, and email address, of the individual. That is, either user can instigate a Share to the third-party, which is in the form of an electronic message transmitted to a device associated with the third party. Herein, the user instigating the Share is referred to as the first user and the other user in the relationship is referred to as the second user. For the avoidance of any doubt it is noted again that, in general, the user instigating the Share may be the user who sent the invitation to establish the Connection, or the user who responded. With reference to Figure 6A, the user can share, with a third user or other entity, a verified Connection he has established with a second user a user. The verified Connection is shared by selecting a connection sharing element 604 associated with the second user on the user interface. As shown in Figure 6C, this cases a connection sharing menu 622 to be displayed, having fields 624 into which the user can enter details of the third entity with whom he wished to share the verified Connection. Although not shown in Figure 6C, the user may also enter message content to be included in the message sent to share the Connection. Both people to which the Connection relates receive a copy of the Share, e.g. via email, as does the target of the share (i.e. the third party).

The Share confirms the Connection, and preferably indicates the type of connection, and preferably comprises respective identity data of both of the first and second users. For example, the Share contains can contain (or otherwise confirm) the verified names of both of the Connected parties (matching the names on the respective identity documents to which their digital identities are anchored), the type of relationship and possibly also the verified facial photos (which can for example be the identification photographs taken from the identity documents, or later-captured selfies that have been verified as matching the identification photographs on the documents).

Either party in a Connection can add a document / file / image, or other attachment, as "Supporting evidence" for the Connection. The other party gets notified of the Supporting evidence and can review it (preferably view only, without being able to edit it) and tick that they agree that the supporting evidence can be shared with a third party. An indication of whether or not the recipient has accepted the supporting evidence is included in his response.

The supporting evidence can take any desired form, such as a Power of Attomey document or certification confirming a carer or doctor for example is qualified. When sharing a Connection, the sharer can tick that they want the Supporting Evidence to be included in the Connection share, and provide the supporting evidence to be included in the request. The instigator of the Connection Share can also choose to include message text (up to a set length), or other message content. That is, he can freely add text or other content to the message, as he desires (noting that both the third party, and the other party to the Connection, will receive a copy of this).

This could for example take the form of an instruction that the Connected party (e.g. brother) can pick up a named child from a nursery, or that the date of birth of a child is Day/Mth/Year and the school has permission to take them on a specific school trip. The connection can be send using a messaging identifier, such as an email address, for the third party that is stored at the digital identity system. For example, the third party could also be a user of the digital identity system and the messaging identifier may be stored in association with his digital identity. For example, individuals acting on behalf of an organisation can inform one, or both, of the Connected Organisations the email address they should share the Connection with. They can also enter an email address for that organisation that they want to be their official email to receive such shared Connections. Verified organization entities could for example be provided an email address within a network domain of the digital identity system itself.

However, it is not essential that the third party is a user of the digital identity system, or that he has a messaging identifier registered with the digital identity system, as the instigator of the share can specify the messaging identifier for the third party when instigating the share.

For example, one of the Connected individuals can just enter the email address they think is most appropriate for an organisation to receive the shared Connection. A history of Shared may be provided as part of a YC user's account to see Shares they have sent. Confirmation, if provided by the target, that they have received the Connection details may also be stored at the digital identity system, for example as part of the Share history. This could be by clicking on a Confirm receipt in the email or by logging in to YC and seeing the Connection details in their account history. A permission management mechanism of the digital identity system may also be provided, so that some individuals (e.g. a parent) can limit the Connection with a child so that only the parent can share the Connection. As another example, some individuals may only want a tax advisor to be able to share a Tax Adviser Connection with a specific organisation (e.g. HMRC) or only share the Connection once or up to a certain expiry date (e.g. contractor on a fixed term contract with an employer).

If a connected party sees the other individual share the Connection with a person or organisation they don't think is appropriate, then they can archive (erase or invalidate) the Connection so that it cannot be shared any further. If the non-sharer individual does not think a Share was appropriate, they can archive the Connection to prevent further Shares, but also email the recipient of the Share to explain any problems. A parent may also be able to link several connections into a "Family" Connection which they can share in one sharing transaction. This is one example of a relationship that is created between more than two digital identities, and in general relationships can be created between two or more parties, provided they all of the parties concert consent to the creation of the relationship.

YC users may also be able select people from an electronic address book to invite to be a 'Friend' Connection. This will be an important feature if, for example, a concert goers want to invite a lot of friends, or in any other context where a user wants to establish a relatively large number of relationships at the same time.

An API may also be provided, via which certain authorized third parties can access information about Connections. It may be that the third parties are sufficiently trusted to be permitted to access such information of their own volition (which will be made clear to the users using the YC service). Alternatively, permission from at least one of the users of the Connection may be required to allow the third party to access information about that Connection via the API.

Ticket-Touting: One use-case of the API is to prevent ticket touting, also known as ticket scalping.

Ticket touting is the practice of an entity (tout) acquiring a potentially large number of tickets to, say, an event which they have no intention of using personally, i.e. where they have no intention of attending the event themselves, particularly for the purpose of selling them on at a premium. Whilst popular, oversubscribed events in particular have always been somewhat vulnerable to touting, historically the inter-personal nature of ticket purchases kept touting in check to some extent. Ticketing companies will be able to use a simple API to check the email addresses and Names entered by a person paying for several tickets to a concert. The API confirms whether the email addresses are Connected, the time of the invitation to create the Connection, and the time of the Confirmation (i.e. the time the Connection was accepted). An additional name matching requirement or requirements may also be imposed, wherein at least the Last Name (surname) on the ticket needs to match that of the digital identity in question (or closely match using fuzzy logic).

This presents significant challenges for large scale ticket touts. The API check can be restricted to approved ticketing companies, for example.

In the anti-touting use case, a first user is only permitted to transfer a ticket he has purchased to a second user, if there is a pre-existing relationship between the first and second users. That is, only if the first and second user have established a connection before the first user purchases the ticket. Whilst this requirement can be strictly enforced, it may be preferable to allow some leeway as circumstances can occasionally arise in which it is legitimate for a non-touting user to transfer a ticket to another user he does not have a pre-existing Connection with. For example, it might happen that a user legitimately purchases four tickets, allocates three of those tickets to friends, and then one friend falls ill or cannot use the ticket for some other valid reason. In that case, the purchasing user may find himself in a position where he needs to reallocate the ticket - or ask the person who cannot attend to reallocate the ticket- to either: 1) another friend who has a Connection timestamp prior to purchase date or

2) an unconnected person or a connected person where the timestamp is after the purchase date. In these circumstances, a strict approach would only permit 1), but never 2). However, a less rigid approach might allow 2) in certain circumstances. For example, the decision to allow 2) can be based on the purchasing user's past behaviour, and in particular on the extent to which that user has attempted to transfer tickets in situation 2) before. For example, it could be that a user is allowed to transfer a certain number of tickets within a certain time frame (e.g. two per month) or a certain percentage of the tickets he purchases (e.g. no more than 1 in every 10 purchased tickets) to an unconnected user or to a connected user where the timestamp of the connection is after the purchase date. In this context, the fact that a user is attempting a transfer in situation 2) can be one of multiple factors that are considered by the system in determining whether to allow the transfer, where those factors can be balanced to give some flexibility to legitimate users whilst still preventing large scale touting.

The amount of leeway, if any, can be chosen by the ticketing company, for example. When relying on Connections between email addresses, a tout may have a network of "mules" (users working for the tout), with whom the tout has pre-existing Connections based on the mules' email addresses. In this scenario, measures can be taken to prevent a scenario in which the tout transfers the tickets to those mules, and the mules then effectively sell the tickets by transferring the email addresses to purchasing users.

A simple way of preventing this by requiring a ticket purchaser, when purchasing a ticket on behalf of another user, to provide an actual name of the other user who will be receiving the ticket. They may be a full name (available via YC if the friend has already connected) or at least a given name/last name of the second person. This defeats touts trying to create lots of emails and complete Connections with mules and then transfer ownership of the email from mules to ticket buyers wanting to buy from touts. Where a ticket tout has a network of mules, with whom he has pre-existing connections, the tout can transfer the tickets to his mules at any time by virtue of these pre-existing connections. A user purchasing a ticket from the tout can to create a Connection with one of the mules after the ticket has been purchased but before it has been transferred to the mule. Once that Connection has been created, the tout can then transfer the ticket to the mule. In order to prevent the mule from being able to transfer the ticket to the user, it is appropriate in this context to use the original purchase time of the ticket from the ticketing company, rather than the time at which it was transferred to the mule, as a basis for determining whether to allow the transfer of the ticket from the mule to the user. In that case, the fact that the mule and the user happen to have a pre-existing connection when the mule receives the ticket is not determinative, and the transfer may be automatically refused on the basis that the mule and the user did not have a pre-existing relationship when the ticket was purchased by the tout.

A sixth aspect of the present invention provides a digital identity system comprising: a computer interface for receiving electronic messages; electronic storage configured to store digital identities of respective users; a record creation module configured to create, in the electronic storage, a time-stamped record of a relationship between the digital identity of a first user and the digital identity of a second user, the record being created in response to an electronic message received from one of the first and second users; and an asset tracking module configured to associate an asset with the digital identity of the first user; wherein the asset tracking module is configured to: receive a request to transfer the asset from the first user to the second user, compare: 1 ) a timestamp associated with the asset with 2) the timestamp of the record of the relationship between the first and second users, and reject or accept the request based on that comparison, wherein if the request is accepted, the asset tracking module is configured to associate the asset with the digital identity of the second user. The timestamp associated with the asset may comprise a time at which the asset became available to the first user.

The timestamp associated with the asset may comprise a time at which the asset was first purchased (by the first user, or another user). The asset may be a ticket.

The request may be refused if the timestamp associated with the asset is earlier than the timestamp of the record.

The timestamp of the record may denote a time at which the record was created, or a time at which the creation of the record was requested. The digital identity system may comprise an information-providing component configured to provide, to a third party receiving the asset, a name of the second user, to prevent a user with a different name from using the asset.

The name may be determined from the second user's digital identity, or provided by the first user when purchasing the asset.

The name to be provided to the third party may be associated with the asset, and can be changed on notice to the first user or with the consent of the first user. The name to be provided to the third party may be associated with the asset, and cannot be changed or cannot be changed without consent from an entity from which the ticket was purchased.

A seventh aspect of the invention provides a digital identity system comprising: a computer interface for receiving electronic messages; electronic storage configured to store digital identities of respective users; a record creation module configured to create, in the electronic storage, a time-stamped record of a relationship between the digital identity of a first user and the digital identity of a second user, the record being created in response to an electronic message received from one of the first and second users; and an asset tracking module configured to associate an asset with the digital identity of the first user, and store, in association with the digital identity, a time at which the asset became available to the first user; wherein the asset tracking module configured to: receive a request to transfer the asset from the first user to the second user, compare: 1 ) the time at which the asset became available to the first user with 2) the timestamp of the record of the relationship between the first and second users, and reject or accept the request based on that comparison, wherein if the request is accepted, the asset tracking module is configured to associate the asset with the digital identity of the second user.

The asset may be a ticket.

The request may be refused if the time at which the asset became available to the first user is earlier than the timestamp of the record.

The timestamp of the record may denote a time at which the record was created, or a time at which the creation of the record was requested.

The asset tracking module can for example be in the form of an asset tracking system as disclosed in the following documents (the "Asset Tracking Documents"), each of which is incorporated herein by reference in its entirety: published United States patent application US20160350861 (application no. 14/726333); United States patent 9519796 and corresponding published United States patent application US2016350547 (application no. 14/726315); and published PCT application WO2016/193156 (application no. PCT/EP2016/062034). This discloses an asset tracking system that operated in complement to a digital identity system, in which asset transfers may be recorded. However, any system which can track asset transfers may be used in the present context, such as an external blockchain. Ticketing sites can provide feedback about attendance confirmation via the API so that Yoti YC can build up an algorithm of attendance ratio by ticket buyers and those assigned tickets. That is, feedback from the ticket companies about tickets exchanged on the basis of Yoti Connect can be used to determine an anti-touting metric of the kind described in the Asset Tracking Documents.

An event organiser might choose to use Yoti at the entrance to check tickets but does not need to, as the ticket holders email, photo and actual name are shared earlier with the ticketing site (when buyer first makes purchase and when each friend confirms ownership of their assigned ticket by sharing email, photo and name). Blockchain:

The record of a verified Connection can be stored on a public or private blockchain. A blockchain is a digital ledger, in which transactions are recorded as a sequence blocks, where each block comprises a record of at least one transaction and, typically, a timestamp and a link to the previous block in the blockchain, in the form of a hash pointer. To provide a distributed ledger, a blockchain can be stored in a distributed manner and managed by a peer-to-peer network, which adheres to a protocol for validating new blocks. Once a new block has been validated and added, it cannot be altered without altering all of the previous blocks, which would require collusion within the network. In this sense, a blockchain is immutable.

In this context, a transaction recorded on the blockchain can be the creation of a verified Connection, by mutual agreement of the parties to the Connection. Although the blockchain record of the Connection is immutable, the Connection can still be revoked by recording the revocation of the Connection as a subsequent transaction on the blockchain. The amount of information recorded on the blockchain can vary with different implementations. As a minimum, the blockchain record for any given Connection must provide sufficient proof that the Connection exists between the parties in question.

The identities of the parties to a Connection can be anonymized. For example, the blockchain record of the connection may comprise a hash of each party's identity data, rather than the identity data itself, generated using a hash key. This preserves the anonymity of those parties, as the record is meaningless without the hash key.

However, any third party with the hash key can see immutable proof that the connection was made, between who and when. They can do this by hashing the relevant identity data with the hash key and comparing the result with the hash stored on the blockchain. If either party to the connection revokes the connection, then this is also recorded on the blockchain. Consent given by one party to the other party to a Connection can also be recorded on the blockchain. Again, either party can revoke the consent and this will also be recorded on the blockchain as a later transaction. Where a supporting evidence document, such as a power of attorney, is provided for the connection, a hash of the document can recorded on the blockchain to support either the proof or the consent. This prevents the content of the document from being derived from the blockchain, but a third party with access to a copy of the document and the hash key can verify that the copy of the document by hashing it with the hash key and comparing the result with the hash on the blockchain.

Another party (e.g. Law Society or regular user) may be able to support, verify or vouch for a connection, which is assigned a confidence value. The more people who vouch, the higher the confidence value of the connection, equivalent to the contingent trust mechanism of the Yoti/uPass system. This verification can either be done privately (e.g. just through the Yoti system), or more likely on an immutable ledger (e.g. the block chain).

In this manner, it is possible to create an immutable audit trail of the connection and the rights under it that cannot be faked or amended.

It will be appreciated that, whilst specific embodiments of the invention have been described, these are not exhaustive. The scope of the invention is not defined by the described embodiments but only by the appendant claims.

Claims

1. A digital identity system comprising:

a computer interface for receiving electronic messages;

electronic storage configured to store verified digital identities, each comprising identity data captured from a respective identity document of a respective user and received in an electronic message;

an identity verification module configured to verify each of the digital identities using data captured from the respective identity document;

a record creation module configured to create, in the electronic storage, a record of a verified relationship between the verified digital identity of a first user and the verified digital identity of a second user; and

a messaging module configured to receive a message instruction from the first user, and send a relationship-sharing message to a third party device according to the message instruction, the relationship-sharing message confirming the verified relationship between the first and second verified digital identities.

2. A digital identity system according to claim 1 , wherein the captured data used to verify the digital identity comprises biometric data captured from the respective identity document, and the identity verification module is configured to verify each of the digital profiles by comparing the biometric data with a biometric identifier captured from the respective user.

3. A digital identity system according to claim 1 or 2, wherein the identity document is a passport, driving license, or identity card.

4. A digital identity system according to claim 1 , 2 or 3, wherein the relationship- sharing message sent to the third party device comprises at least part of the identity of the first or second user's verified digital identity.

5. A digital identity system according to claim 4, wherein the relationship-sharing message sent to the third party device comprises or indicates: at least part of the captured identity data of the first user's verified digital identity, and/or separately-provided identity data matching the captured identity data; and

at least part of the identity data of the second user's verified digital identity, and/or separately-provided identity data matching the captured identity data.

6. A digital identity system according to any preceding claim, comprising a relationship verification module configured to verify the relationship between the digital identities of the first and second users.

7. A digital identity system according to claim 6, wherein the relationship verification module is configured to verify the relationship in response to one of the first and second users accepting, at his device, an association request instigated by the other of the first and second users.

8. A digital identity system according to claim 7, wherein the relationship verification module is configured to receive a response accepting the request from the device of the user accepting the request.

9. A digital identity system according to claim 7 or 8, wherein the relationship verification module is configured to transmit the association request in response to an instruction from the device of the user instigating the request.

10. A digital identity system according to claim 7, 8 or 9, wherein the association request is transmitted to the device of the user accepting the request with at least one piece of supporting evidence, wherein the record creation module is configured to receive a copy or a hash of the supporting evidence and store it as part of the record of the verified relationship.

11. A digital identity system according to claim 10, wherein the messaging module is configured to include or indicate a copy or hash of the supporting evidence in the relationship-sharing message sent to the third party device.

12. A digital identity system according to claim 10 or 11 , wherein the record creation module is configured to store the copy or hash of the supporting evidence only if it receives confirmation that the user accepting the request has reviewed the supporting evidence.

13. A digital identity system according to claim 12, when dependent on claim 6, wherein the confirmation is comprised in the response received from the device of the user accepting the request.

14. A digital identity system according to any preceding claim, wherein the digital identity of the second user comprises a messaging identifier for transmitting messages for receiving by the second user.

15. A digital identity system according to claim 14, wherein the digital identity system is configured to use the messaging identifier in the second user's digital identity to transmit, for receiving by the second user, a notification that the relationship-sharing message has been sent.

16. A digital identity system according to any preceding claim, wherein the digital identity of the first user comprises a messaging identifier for transmitting electronic messages for receiving by the first user.

17. A digital identity system according to claim 16, wherein the digital identity system is configured to use the messaging identifier in the first user's digital identity to transmit, for receiving by the first user, a notification that the relationship-sharing message has been sent.

18. A digital identity system according to any of claims 14 to 17, comprising a messaging identifier verification module configured to verify the or each messaging identifier.

19. A digital identity system according to claim 18, wherein the messaging identifier verification module is configured to verify the or each messaging identifier by using the messaging identifier to transmit a verification message, and verifying the messaging identifier if an expected response is received.

20. A digital identity system according to any preceding claim, wherein the digital identity system is configured to erase or invalidate the record of the verified relationship in response to a request from the second user, whereby the first user cannot confirm the relationship to third party entities thereafter.

21. A digital identity system according to any preceding claim, wherein the relationship-sharing message sent to the third party device comprises an indication of a type of the relationship.

22. A digital identity system according to any preceding claim, wherein the relationship-sharing message includes or indicates at least one of:

message content specified in the message instruction;

a name of the first user and/or second user derived from the captured identity data of his digital identity;

an image of the first and/or second user derived from his digital profile, the image being an image derived from the captured identity data or an image that matches an image of the captured identity data;

a date of birth of the first and/or second user from the captured identity data of his digital profile;

a gender of the first and/or second user derived from the captured identity data of his digital identity; and

a nationality of the first and/or second user derived from the captured identity data of his digital identity.

23. A digital identity system according to any preceding claim, wherein the digital identity system is configured to retain a history of relationship-sharing messages sent for the verified relationship, which is accessible to at least one of the first and second users.

24. A digital identity system according to any preceding claim, wherein the digital identity system is configured to receive a response to the relationship-sharing message from the third party device, and communicate the response to at least one of the first and second users.

25. A digital identity system according to any preceding claim, wherein the creation of the record is instigated by the first user and the record creation module is configured to set a flag of the record to indicate whether or not the second user is permitted to confirm the relationship to third parties.

26. A digital identity system according to any preceding claim, wherein the identity verification module is configured to verify each of the digital profiles by applying document verification to the captured data.

27. A digital identity system according to any preceding claim, wherein the captured identity data of the digital profile comprises at least part of the captured data used to verify the digital identity.

28. A digital identity system according to claim 2 or any claim dependent thereon, wherein the biometric data comprises an identification photograph and the biometric identifier is a facial image.

29. A digital identity system according to claim 6 or any claim dependent thereon, wherein the relationship verification module is configured to verify the relationship between the digital identities of the first and second users is based on at least one electronic consent message received at the digital identify system, which confirms that both the first user and the second user have consented to the relationship being recorded.

30. A digital identity system according to claim 29, wherein the relationship verification module is configured to verify the relationship between the digital identities of the first and second users based on a first electronic message received from the first user and confirming the consent of the first user and a second electronic message received from the second user and confirming the consent of the second user.

31. A digital identity system according to claim 29, wherein the relationship verification module is configured to verify the relationship between the digital identities of the first and second users based on an electronic message received from one of those users, which confirms that both of those users have consented to the relationship being recorded.

32. A digital identify system according to claim 31 , wherein the electronic message comprises a credential of the other user that has been captured by the user from which the electronic message is received, and thereby confirms that the other user has consented to the relationship being recorded, wherein the relationship verification module is configured to match the received credential with a credential associated with the other user's digital identity.

33. A digital identity system according to any preceding claim, wherein the digital identity system is configured to erase or invalidate the record of the verified relationship in response to a request from the first user, such that it cannot be shared with third party devices thereafter.

34. A digital identity system according to any preceding claim, wherein the record is of a relationship between at least three digital identities of at least three users, including the first and second user.

35. A digital identity system according to any preceding claim, wherein the relationship-sharing message comprises or consists of a code or link, wherein the digital identity system is configured to store details of the verified relationship at a memory location that is accessible to the third party device using the code or link, such that the code confirms the verified relationship.

36. A digital identity system according to claim 35 when dependent on claim 10, wherein the copy or hash of the supporting evidence is stored in association with the link or code such that the link or code can be used to retrieve the supporting evidence or the hash of the supporting evidence, whereby the link or code in the relationship-sharing message indicates the supporting evidence.

37. A digital identity system according to any preceding claim, wherein the relationship-sharing message is in the form of: an email or a text message or a social media message.

38. A digital identity system comprising:

a computer interface for receiving electronic messages;

electronic storage configured to store verified digital identities, each

comprising a respective biometric identifier captured at a respective device;

an identity verification module configured to verify each of the digital identities based on at least one liveness detection test performed at the respective device to verify that the respective biometric identifier has been captured from an actual living user of the respective device;

39. A digital identity system comprising:

a computer interface for receiving electronic messages;

electronic storage configured to store verified digital identities, each

comprising identity data captured from a respective identity document of a respective user and received in an electronic message;

an identity verification module configured to verify each of the digital identities using data captured from the respective identity document; and

a record creation module configured to create, in the electronic storage, a record of a verified relationship between the verified digital identity of a first user and the verified digital identity of a second user.

40. A digital identity system comprising:

a computer interface for receiving electronic messages; electronic storage configured to store verified digital identities, each comprising a respective biometric identifier captured at a respective device;

an identity verification module configured to verify each of the digital identities based on at least one liveness detection test performed at the respective device to verify that the respective biometric identifier has been captured from an actual living user of the respective device; and

41. A digital identity system according to claim 39 or 40, comprising a third party interface configured for use by an authorized third party device in retrieving data of the record.

42. A digital identity system according to claim 39, wherein the third party interface is an API.

43. A digital identity system according to any preceding claim, wherein the relationship is verified in response to receiving, at the digital identity system, an electronic message, which confirms the relationship and identifies the first and second users.

44. A digital identity system according to any preceding claim, wherein the record of the verified relationship is stored on a blockchain implemented in the electronic storage.

45. A digital identity system according to claim 45, wherein the blockchain is implemented by a plurality of distributed electronic storage devices of the electronic storage.

46. A digital identity system according to claim 44 or 45, wherein the blockchain is a public blockchain.

47. A digital identity system according to claim 44 or 45, wherein the blockchain is a private blockchain.

48. A digital identity system according to any of claims 44 to 47, wherein the blockchain record comprises at least one of: proof of the relationship, and proof that consent was given to record the relationship.

49. A digital identity system according to any preceding claim, wherein the record is an anonymized record.

50. A digital identity system according to claim 49, wherein the anonymized record comprises a hash of data about the relationship and/or a hash of data of the digital identity of each of the users, generated using a hash key, such that the relationship and/or the identities of the users cannot be determined from the anonymized record without the hash key.

51. A digital identity system according to any preceding claim, wherein a confidence value is stored in association with the record.

52. A digital identity system according to any preceding claim, wherein the confidence value is increased in response to another user or entity vouching for the relationship.

53. A digital identity system according to claim 51 or 52, wherein the confidence value is rendered available to the third party device.

54. A digital identity system according to any of claims 51 to 53 when dependent on claim 44, wherein the confidence value is stored on the blockchain.

55. A digital identity system comprising:

a computer interface for receiving electronic messages;

electronic storage configured to store digital identities of respective users; a record creation module configured to create, in the electronic storage, a time-stamped record of a relationship between the digital identity of a first user and the digital identity of a second user, the record being created in response to an electronic message received from one of the first and second users; and

an asset tracking module configured to associate an asset with the digital identity of the first user;

wherein the asset tracking module is configured to: receive a request to transfer the asset from the first user to the second user, compare:

1 ) a timestamp associated with the asset with

2) the timestamp of the record of the relationship between the first and second users,

and reject or accept the request based on that comparison, wherein if the request is accepted, the asset tracking module is configured to associate the asset with the digital identity of the second user.

56. A digital identity system according to claim 55, wherein the asset is a ticket.

57. A digital identity system according to claim 55 or 56, wherein the request is refused if the timestamp associated with the asset is earlier than the timestamp of the record.

58. A digital identity system according to any of claims 55 to 57, wherein the timestamp of the record denotes a time at which the record was created, or a time at which the creation of the record was requested.

59. A digital identity system according to any of claims 55 to 58, wherein the timestamp associated with the asset comprises a time at which the asset became available to the first user.

60. A digital identity system according to any of claims 55 to 58, wherein the timestamp associated with the asset comprises a time at which the asset was first purchased.

61. A digital identity system according to any of claims 55 to 60, comprising an information-providing component configured to provide, to a third party receiving the asset, a name of the second user, to prevent a user with a different name from using the asset.

62. A digital identity system according to claim 61 , wherein the name is

determined from the second user's digital identity, or provided by the first user when purchasing the asset.

63. A digital identity system according to claim 61 or 62, wherein the name to be provided to the third party is associated with the asset, and can be changed on notice to the first user or with the consent of the first user.

64. A digital identity system according to claim 61 or 62, wherein the name to be provided to the third party is associated with the asset, and cannot be changed or cannot be changed without consent from an entity from which the ticket was purchased.

65. A system for connecting digital identities comprising:

a computer interface for receiving electronic messages;

a record creation module configured to create an electronically-stored record of a verified relationship between a verified digital identity of a first user and a verified digital identity of a second user, each of the digital identities comprising identity data captured from a respective identity document of a respective user, each of the digital identities having been verified at the digital identity system using data captured from the respective identity document.

66. A system for connecting digital identities comprising:

a computer interface for receiving electronic messages;

a record creation module configured to create an electronically-stored record of a verified relationship between a verified digital identity of a first user and a verified digital identity of a second user, each of the digital identities comprising a respective biometric identifier captured at a respective device, each of the digital identities having been verified at the digital identity system based on at least one liveness detection test performed at the respective device to verify that the respective biometric identifier has been captured from an actual living user of the respective device.

67. Executable program instructions stored on non-transitory computer-readable storage media and configured when executed on one or more processors, to implement the functionality of the system of any preceding claim.

68. A computer-implemented method comprising steps performed to implement the functionality of the system of any of claims 1 to 66.