GB2587075A - Proving identity - Google Patents

Abstract

A proof of identity device including electronic storage configured to store a plurality of identity payloads, the proof identity device maybe a smartcard or tag. Each payload having an independently verifiable payload signature as determined by cryptographically signing that identity payload individually. Wherein each identity payload is associated with an identified attribute type and includes an identity attribute of that attribute type. The attributes may include name, biometric such as facial image, age, nationality. Performing an identity sharing function by processing a received interrogation signal, from an identity-requesting device, to determine therefrom at least one requested attribute type, accessing the electronic storage to match the requested attribute type to the attribute type associated with one of the stored identity payloads, and providing that identity payload and its payload signature to the identity requesting device directly. The device may provide both identity-sharing and electronic payment functions.

Description

Proving Identity

Technical Field

This disclosure relates to methods and devices for proving identity and related devices and methods.

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.

Summary

A first aspect of the present invention provides a proof of identity device ("terminal-or "Yoti Key") comprising: electronic storage configured to store a plurality of identity payloads, each having an independently verifiable payload signature as determined by cryptographically signing that identity payload individually, wherein each identity payload is associated with an identified attribute type and comprises an identity attribute of that attribute type; a processor coupled to the electronic storage, which is configured to perform an identity sharing function by: processing a received interrogation signal, from an identity requesting device, to determine therefrom at least one requested attribute type, accessing the electronic storage to match the requested attribute type to the attribute type associated with one of the stored identity payloads, and providing that identity payload and its payload signature to the identity requesting device directly In embodiments, the proof of identity device may comprise a data interface (communications interface) coupled to the processor, via which the interrogation signal is received and via which the identity payload and the payload signature are provided Each cryptographically signed identity payload may comprise data of or derived from an identifier that is unique to the proof of identity device, the unique identifier being accessible to the identity requesting device for verifying the provided identity payload.

Each identity payload may be encrypted based on the unique identifier, the data derived from the encrypted attribute being data of the encrypted attribute.

The unique identifier may be readable via the data interface.

The unique identifier may be stored in read-only memory of the proof of identity device.

In some cases, the memory may be read only for end-users only, but not to a distributer or manufacturer.

The processor may be configured to execute an identity application, the identity application being configured to implement the identity sharing function.

The processor may be configured to execute an operating system, the operating system being configured to provide the unique identifier to the identity requesting device independently of the identity application Part of the reason the chip ID may be trusted to be authentic is because the OS provides it.

The unique identifier may be a serial number of a chip comprised in the proof of identity device.

The electronic storage may be configured to store a cryptographically signed operator identifier, and the processor may be configured to provide the cryptographically signed operator identifier to the identity requesting device.

The electronic storage may be configured to store an operator payload comprising the operator identifier and having an independently verifiable payload signature, and the processor may be configured to provide the operator payload and its payload signature with the identity payload.

The proof of identity device may be a passive proof of identity device comprising a power transfer circuit coupled to the data interface and the processor, which is configured to draw electrical power via the data interface to power the processor to perform the identity sharing function.

The data interface may be a contactless data interface.

The proof of identity device may be embodied as a smartcard.

The following identity attributes may be comprised in the identity payloads: a name, a biometric, an age-related identity attribute, a nationality.

Another aspect of the invention provides an identity requesting device("reader") comprising: a data interface (communications interface); a processor coupled to the data interface and configured to determine at least one identity attribute type to be requested, instigate via the data interface to a proof of identity device an interrogation signal which conveys the determined identity attribute type, receive via the data interface from the proof of identity device an identity payload comprising an identity attribute of the requested type with an associated attribute signature, and verify the attribute signature based on the received identity payload using an expected public key.

In embodiments, the identity requesting may comprise an output device configured to output to a user of the proof of identity device the identity attribute type to be requested.

The reader may thus be used to verify the identity embodied in the identity attribute(s).

Payment plus identity Another aspect of the invention provides an electronic payment device comprising: a data interface; electronic storage configured to store: (i) a payment application, (ii) an identity application and (iii) at least one associated identity payload having a verifiable payload signature as determined by cryptographically signing that identity payload; and a processor coupled the data interface and the electronic storage for executing the applications; wherein the identity application is configured, when executed on the processor, to provide directly to an interrogating device via the data interface the identity payload and its payload signature; and wherein the payment application is configured, when executed on the processor, to provide directly to an interrogating device via the data interface payment authorization data for authorizing an electronic payment.

The payment device may be configured to operate according to an interrogation protocol, in which: an exchange is conducted between the electronic payment device and the interrogating device to determine whether both the payment and identity applications are mutually supported by the electronic payment device and the interrogating device.

The payment device may be embodied in a payment card.

The payment authorization data comprise a PAN (payment card number or primary account number).

The data interface may be contactless The device may operate according to an interrogation protocol, in which o an exchange is conducted between the terminal and the reader to determine mutually supported application(s) o An appropriate application is selected.

The protocol may comprise determining that both payment and identity applications are mutually supported by the terminal and the reader, if it is the reader is used for payment and identity verification, and determining mutual support for payment and identity for separate payment and identity readers if different readers are used Creating Yoti Key Another aspect provides a method of populating a proof of identity device with identity data, the method comprising the following steps: receiving from a user device at a digital identity system an electronic message comprising an attribute key and an identifier of a writer device; using the attribute key to locate, in a database, at least one identity attribute; providing to a signing service an identity payload comprising the located identity attribute for cryptographic signing, thereby generating a payload signature; using the identifier in the electronic message to transmit to the writer device an electronic message comprising or indicating the identity payload and its payload signature; and at the writer device, causing the identity payload and its payload signature to be stored in electronic storage of the proof of identity device, the proof of identity device comprising a data interface for providing the stored identity payload and its payload signature to an interrogating device In embodiments, a writer device ID (identifier) may be captured by the user device from the writer device, e.g. as displayed visual code (e.g. QR code or other 2D or 3D barcode).

The identity attribute(s) may be encrypted using the writer ID.

The writer ID may be a chip serial number.

The chip may be a MULTOS chip.

The chip serial number may be known to the signing/encryption service (collectively, "Yoti"), as every chip in MULTOS world is a known device So at time of assignment to Yoti, Yoti is assigned a key that is known to Yoti (and the KMA). Yoti then used a derived key to share with third parties.

The key shared with Yoti may be linked to cryptographic key.

Another aspect of the invention provides a method of performing an identity sharing function at a proof of identity device comprising electronic storage configured to store a plurality of identity payloads, each having an independently verifiable payload signature as determined by cryptographically signing that identity payload individually, wherein each identity payload is associated with an identified attribute type and comprises an identity attribute of that attribute type; and a processor coupled to the electronic storage; the method comprising: processing, by the processor, a received interrogation signal, from an identity requesting device, to determine therefrom at least one requested attribute type; accessing the electronic storage to match the requested attribute type to the attribute type associated with one of the stored identity payloads; and providing that identity payload and its payload signature to the identity requesting device directly.

Another aspect of the invention provides a_method of performing an identity requesting function at an identity requesting device comprising a communications interface and a processor coupled to the communications interface, the method comprising: determining at least one identity attribute type to be requested; instigating via the communications interface to a proof of identity device an interrogation signal which conveys the determined identity attribute type; receiving via the communications interface from the proof of identity device an identity payload comprising an identity attribute of the requested type with an associated attribute signature; and verifying the attribute signature based on the received identity payload using an expected public key.

The identity requesting device may be used to verify the identity embodied in the identity attribute(s).

Another aspect of the invention provides a_computer program comprising computer-readable code configured, when executed one or more processors, to implement the methods or device functionality above.

Brief Description of the Drawings

For a better understanding of the present invention, and to show how embodiments of the same may be carried into effect, reference is made by way of example only to the following figures, in which: Figure 1 shows a schematic block diagram of a proof of identity device Figure 2 shows a schematic block diagram of an embedded chip contained in a proof of identity device.

Figure 3 is a schematic function block diagram showing a software architecture for a proof of identity device.

Figure 4 is a schematic block diagram showing data and code held on an embedded chip of a proof of identity device.

Figure 5A shows the steps performed by an identity requesting device to obtain and verify identity information from the proof of identity device.

Figure 5B shows how the identity requesting device can instigate a payment request to the proof of identity device Figure 6 shows a highly schematic functional block diagram of a digital identity system.

Figure 7 shows a flow diagram for an identity sharing process mediated by the digital identity system.

Figure 8 shows a flow diagram for a process in which a bearer device obtains a sharing token.

Figure 9 shows a highly schematic block diagram of a user device.

Figure 10 shows a method by which a user of a device can create a digital identity for himself within the digital identity system.

Figure 11 shows an overview of the process by which identity attributes of an existing digital identity are written onto a proof of identity device.

Figure 12 provides a high-level overview of different routes by which a user may obtain different types of proof of identity device.

Figure 13 shows an example of a process by which the identity application of Figure 3 can be written onto a multi-application proof of identity device.

Figure 14 shows details of the process by which a user may obtain a personalised ID smart card onto which digital identity attributes can be written.

Figure 15 shows details of the process in which a user obtains a proof of identity device from a website.

Figure 16 shows an example of a process by which verified identity attributes may be written to a proof of identity device.

Figure 17 shows a process of writing identity attributes to a proof of identity device Figure 18 shows a tag write process, namely where a user obtains a proof of identity device online Figure 19 shows the process by which signing certificates are distributed and used to verify attributes read from proof of identity devices.

Detailed Description

A proof of identity device in accordance with the invention is described below.

In the described embodiments, the proof of identity device takes the form of a passive, low-cost electronic device which is configured to facilitate the selective sharing of identity data stored thereon, and which may be referred to in the following description as a "Yoti Key-.

The primary purpose of a Yoti Key is to facilitate the sharing of verified identity data in an offline context, i.e. without requiring intemet connectivity at the time the identity of a user of the Yoti Key is verified by another party. Identity attributes are stored with cryptographically-verifiable attribute signatures, which allows them to be read from the device and verified using a pre-obtained public signature verification key.

A Yoti Key can take various forms, such as a smart card, tag or sticker having embedded electronics.

Figure 1 shows a highly schematic block diagram of a Yoti Key 100 which contains an embedded chip 102 denoted by a dotted area Examples of suitable chips include Infineon SLE77 GOK, SLC32 and SLE78. These are a class of chip with a smartcard operating system built upon the highly secure MULTOS card operating system. MULTOS is CEW EAL 7 certified in certain applications and provides a true application execution environment to allow processing to be performed on the chip itself. Another example is the M_LFARE DESFire EV2. Such chips are suitable for incorporation in a variety of devices, including smart cards, tags etc. Figure 2 shows a schematic block diagram of the embedded chip 102, which has embodied on it a central processing unit (CPU) 202, a bus 204, a transceiver 212, and memory 205 The memory 205 and the transceiver 212 are coupled to the CPU 202 via the bus 204.

The memory 205 of the embedded chip 102 includes volatile memory in the form of random access memory (RAM) 208 and non-volatile memory comprising read only memory (ROM) 210 and electronically erasable programmable read-only memory (EEPROM) 206. Whilst an embedded chip of this nature will typically include both volatile and non-volatile memory, it will be appreciated that this memory can take forms other than that shown in Figure 2. For example, modern smartcards may include an amount of flash memory as an alternative or in addition to the EEPROM.

An antenna 214 is shown coupled to the transceiver 212 via which data-carrying signals can be transmitted and received wirelessly. The transceiver 212 modulates data provided by the CPU 102 for transmission and demodulates received data signals for processing by the CPU 202. The Yoti Key 100 is a passive device which is powered by electrical power drawn via the antenna 214 when in proximity to an external device from which electrical power can be drawn. Hence, the antenna 214 functions both as a data interface for transmitting/receiving data to from external devices and as a means of receiving electrical power. A power transfer circuit 213 is shown, which is coupled to the CPU 202 and the other components of the chip 102 in order to provide electrical power thereto.

The transceiver 212 and antenna 214 allow the Yoti Key 100 to communicate based on Near-Field Communication (NEC) technology. NEC is a short-range communication technology that allows wireless communication between nearby devices, typically within a few centimetres of each other. NFC is the mechanism by which the Yoti Key 100 communicates with external reader devices in order to implement the processes described below.

Figure 3 is a schematic function block diagram showing a software architecture for the Yoti Key 100. A "software stack" is shown to comprise an operating system (OS) 308 which executes on the CPU, and which in turn allows applications to run on the OS 308. Examples of suitable operating systems include N/ULTOS, JavaCard etc. At least one application is installed on the smartcard, which is an identity application 302 that implements the identity sharing functionality described below. The functionality of the Yoti Key 100 can also be extended beyond this by the provision of one or more additional applications that run on the OS 308. For example, the identity application 302 can be run in conjunction with the payment application 304 so that the single Yoti Key 100 can provide both identity-sharing and electronic-payment functions An application running on the OS 308 can access data stored in the memory 205 and can also access the transmit/receive functions provided by the transceiver 212 to the extent that is permitted by the OS 308.

Figure 4 is a schematic diagram showing data and code which is stored in the memory 205 of the embedded chip 102.

The memory 205 is shown to hold a chip identifier (ID) 402 which functions as a unique identifier of the Yoti Key 100 In addition, identity data in the form of a plurality of individual identity attributes 408 are shown to be stored in the memory 205.

Each identity attribute 412 is an individual piece of identity information of a user in possession of the Yoti Key such as: * name, * date of birth, * gender, * biometric, such as a facial image ("selfie"), * passport or other ID document number, * passport or other ID document expiry date, * health attributes (e.g. blood type, medication etc.), * user identifier, which may for example be a hash of one or more other attributes. One example is a "User Hash", which is a hash of the name and date attributes of birth plus a salt.

* etc. Each identity attribute 412 has been cryptographically signed individually by a trusted provider of identity information (referred to below as "Yoti") in order to generate an attribute signature 410 for verifying that identity attribute 412. Each of the multiple identity attributes 408 has a separate attribute signature 410 for verifying that attribute individually and which is stored in association therewith. Because each identity attribute 412 is individually signed, each identity attribute 412 can be verified individually using an associated public signature verification key provided by Yoti and therefore any combination of one or more of the identity attributes 402 can be shared from the Yoti Key 100 Not all of the identity attributes have to be shared in a given scenario Each of the identity attributes 408 has also been encrypted using an attribute encryption key 416. The attribute encryption key 416 comprises data of the chip ID 402, which is to say that data of the chip ID 402 has been used to encrypt each of the identity attributes 408. In the present context, data of an identifier refers generally to all or part of the identifier itself or to data derived therefrom using cryptographic processing. Hence, the attribute encryption key 416 can comprise all or part of the chip ID 402 or can be a key that is otherwise derived from the chip ID 402 with cryptographic processing.

Encrypting the identity attributes 408 based on the chip ID 402 is a way of preventing the attributes being validly copied onto a different chip. In the event that an attribute and its associated attribute signature are copied onto a different chip, the attribute signature 410 will remain valid however it will no longer be possible to decrypt the identity attribute using the chip ID of the chip onto which it has been copied. A particular situation this is addressing is one in which identity attributes from different Yoti Keys are copied onto the same chip as each other.

To illustrate this, it is useful to consider a scenario in which a Yoti Key is used to provide proof of age. This could for example be in a retail context where a user is attempting to purchase age-restricted items in a retail outlet. Proof of age can be provided using two identity attributes: an age attribute and a biometric attribute such as a facial image. The age and biometric attributes are read from the Yoti Key by a reader device in the retail outlet and a supervisor can check that the facial image attribute matches the face of the actual user presenting the Yoti Key and can also check that the age-requirement is met from the age attribute. In this context, a younger user who does not meet the age requirement might attempt to circumvent the age checks by, for example, copying their signed facial attribute onto a blank Yoti Key along with an age attribute of an older user which does meet the age requirement. These age identity attributes would each have a valid attribute signature however the fact that they have been encrypted using an encryption key which no longer matches the chip ID of the Yoti Key on which they are stored means that they cannot be meaningfully decrypted using that chip ID. Hence this use of the chip ID prevents identity attributes from being "cloned" onto a different chip.

Each attribute signature 410 is generated by using a private attribute signing key to sign an identity payload comprising the encrypted attribute 412. The data of the encrypted attribute 412 is derived from the chip ID 402 and is thus verifiable using the attribute signature 410 and a public counterpart to the private attribute signing key (i.e. the public signature verification key). However, it will be appreciated that encryption based on the chip ID 402 is just one mechanism of incorporating data of or derived from the chip ID 402 in the signed identity payload. For example, as an alternative, a copy of the chip ID 402 could be included in the signed payload which can then be compared with the chip ID provided by the operating system 308. Because the chip ID is included in the signed identity payload it cannot be altered without invalidating the attribute signature 410. In general, provided the signed payload comprises data that allows it to be matched to the chip ID, this provides a mechanism of detecting when an attribute has been cloned onto a different chip.

The chip ID 402 can be requested by an external device from the operating system 308 directly, independently of the identity application 302, in order to decrypt the identity attributes obtained from the identity application 302 of the Yoti Key 100. Thus, encrypting the attributes 408 using data of the chip ID 402 provides an additional layer of trust because the chip ID 402 is provided directly by the operating system 308.

The memory is also shown to hold code of the operating system 308 and of the applications 302, 304 that may be executed thereon. Each application is shown to be associated in the memory 205 with an application identifier which uniquely identifies that application The application identifiers associated with the identity application 302 and the payment application 304 are denoted by reference numerals 302a and 304a respectively.

An external device can request a specific application based on the unique application ID associated with it. Thus, when a user presents the identity card 100 to a reader device, the reader device can request for example, either the identity application 302 or the payment application 304.

Each identity attribute 412 is also associated with an attribute type indicator 410 which indicates a type of the identity attribute, such as name, age, date of birth, biometric etc. A reader device can request one or more of specific identity attribute types. The fact that the attributes are individually signed makes it possible for them to be individually verified hence any selection of one or more of the identity attributes 408 can be obtained and verified, without the user necessarily having to release all of the identity attributes stored on the Yoti Key 100.

Figure 5A shows the steps performed by an external device (reader) 514 in order to obtain and verify identity information from the Yoti Key 100 Steps are denoted by numbered circles In step 1, the external device 514 obtains a public signature verification key 516 for verifying each attribute signature 410. The public signature verification key 516 is a public counterpart to a private cryptographic key held by Yoti and used to generate the attribute signatures 410. The public signature verification key 516 is comprised in a certificate obtained from a certificate distribution service 512.

At step 2, the external device 514 is shown in communication with the Yoti Key 100. The transceiver 212 and antenna 214 allow two-way communication to be conducted between the external device 514 and the Yoti Key 100. The external device 514 instigates an attribute request 522 to the Yoti Key 100 which comprises application identification data for matching to the identifier of the identity application 202 and identifies a selection of one or more identity attributes types that the external device 514 wishes to obtain. These are matched to the corresponding identity attribute(s) stored on the Yoti Key 100 based on the attribute type 414 associated with each identity attribute 412. The attribute request is processed by the identity application 404 and the identity application 404 provides the selected attribute or attributes 524 back to the external device 514 in accordance with the attribute request 522.

At step 3, the external device 514 instigates an identifier request 532 to the Yoti Key 100.

This request is handled purely by the OS 308 without the involvement of the identity application 302, and the chip ID 402 provided by the OS 308 in response can therefore be trusted even if the identity application 404 has been compromised.

Steps 2 and 3 can be carried out in any order or in parallel. Although described as separate steps, identity attributes and the chip ID could be requested simultaneously depending on the configuration of the Yoti Key 100. The requests to the Yoti Key 100 are embodied in one or more interrogation signals instigated by the external device 514 to the Yoti Key 100.

At step 4, the identity attribute or attributes 524 received from the identity application 302 are decrypted by an attribute description component 524 using the chip ID 402 obtained from the Yoti Key OS 308. Additionally, the cryptographic signature or signatures 544 of the one or more selected identity attributes 524 are verified by a signature verification component 544 using the public signature key 516. These steps may be carried out in any order, or in parallel. The attributes will be determined to be valid, therefore, only if both the attribute signature 410 of each received attribute is valid and each attribute has been meaningfully decrypted using the chip ID 402.

This means that if any of the attributes has been cloned from a different device they will not be meaningfully decrypted at this point, since the different device will have a different chip ID, and the process will fail as a consequence.

Assuming the identity attributes are valid, they are passed in their decrypted form to a processing component 548 for processing, along with an indication of their validity.

The attribute decryption component 542 and signature verification component 544 are software components of the reader device or a device to which it is connected, implemented by computer-readable code executed on one or more processors thereof.

Multi-Application Implementation Figure 5B shows how the external device 514 can, having verified the identity attributes 524, instigate a payment request 552 to the Yoti Key 100 which is processed by the payment application 204. In order to achieve this the payment request includes the application identification data for matching to the payment application ID 304a.

An example use case is age verification, where at step 2 in Figure 5A, an age attribute and a selfie are obtained as part of the selected attributes 524 in a retail context and a retailer checks that the selfie matches the face of the actual person presenting the card and that they meet a specified age requirement. Assuming they do, then the retailer can instigate the step of Figure 5B to allow a payment to proceed in respect of an age restricted good or service for example.

The payment application 304 may for example be an application of the kind found in contactless bank/credit cards. Alternatively, it may be an application that provides a "payment token" for authorising payment. Payment tokenisation is known per-se.

As another example, the identity application 302 may be implemented in conjunction with a loyalty scheme application, which collects reward points when the Yoti Key 100 is used in certain pre-defined circumstances.

Digital Identity System: The identity data is written onto the Yoti Key 100 in a secure and verifiable manner as described later. The identity data that is written onto the Yoti Key is derived from an existing digital identity of a user, which in turn has been verified based on an identity document such as a passport or driving license The attribute write process is described in detail below. First, in order to provide relevant context to this process, a digital identity system is briefly described. The digital identity system is used to create and manage digital identities which, once created, can be used to obtain verified identity data to be written to a Yoti Key for offline use.

Figure 6 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.

Reference is made to International patent application published as W02016/128569 and United States patent applications published as: U52016/0239653; U52016/0239657; US2016/0241531; US2016/0239658; and 1J52016/0241532, each of which is incorporated herein by reference in its entirety. These disclose variants of a digital identity system (the YOTI/uPass system as it is referred to therein) in which a verified digital identity may be created for sharing with other entities. The digital identity may be anchored to a trusted source of identity information, such as a passport, driving license, ID card etc. In that case, verification is provided based on the trusted source of identity information. The digital identity system 1 may be configured as disclosed in any of the aforementioned.

By way of example, in the following, the digital identity system 1 takes the form of the "YOTI"/"Yoti" system as disclosed W02016/12856. Features of the YOTI system that are relevant to the present invention are summarized below.

The Yoti system allows a user create a verified digital identity which may be referred to herein as the user's "Yoti". As described in further detail below, a Yoti comprises a set of digital identity attributes which the user can share with other user's to prove some aspect of his identity.

The functions of the Yoti system are accessed via an application (Yoti app) executed on a user device, such as a smartphone, which communicates with the Yoti system I via the interne. The Yoti app can capture sharing tokens and authorize the sharing of identity application as described later. Note, the YOTI app is a full-functionality application that is distinct from the identity app 302 on Yoti Key itself The digital identity system 1 (Yoti backend) is shown to comprise a secure store 602 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 602 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 602 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 608 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 6, 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 7 shows a flow diagram for an identity sharing process (Yoti share) conducted between two entities that is mediated by the digital identity system E In this example, the entities are users (not shown) operating respective user devices 702 (bearer device) and 704 (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 702 renders accessible to the capturing device 704 a "sharing token" 706 that is associated, within the digital identity system 1, with the bearer device 702. The sharing token 706 can take various forms. In the present example, the sharing token 706 is bound to an underling bearer credential In the case that the user of the bearer device 702 (the bearer) is sharing identity attribute(s) with the user of the capturing device 704 (the validator/capturer), the sharing token 706 is associated in the digital identity system I with the bearer's attribute(s) to be shared.

The sharing token 706 is rendered available by the bearer device 702 with a policy 708, which identifies any identity attribute types the bearer is willing to share with the user of the capturing device 704 (the capturer) and any identity attribute types the bearer requires the capturer to share in return. This is referred to as a "sharing request".

These are captured at the capturing device 704 so that the user of the capturing device 704 can review the sharing request. Assuming the user accepts the sharing request, at step S4, the capturing device 704 sends, in an electronic message to the digital identity system 1, the captured sharing token 706 and policy 708, together with a capturer credential 710. 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 712 (Dk(Uk)) and a set of one or more attribute keys 714, which identify the location(s) of the capturer's attributes, in the secure store 602, to be shared in accordance with the policy 708. The user key 712 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 710 is validated at the digital identity system 1, by the validation service 14b, and if it is valid, the attribute key(s) 714 are used to locate the capturer's attribute(s) to be shared, and the capturer's user key 712 is used to decrypt those attribute(s) for sharing. This may also require the policy 706 provided by the capturing device 704 to match a policy associated with the sharing token 702.

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

The receipt 716a sent to the bearer device 702 (bearer receipt) comprises or indicates any identity attributes of the capturer that have been shared with the bearer. Likewise, the receipt 716b sent to the capturing device 704 (capturer receipt) comprises or indicates any identity attributes of the bearer that have been shared with the validator (as associated with the sharing token 706). In the present example, a receipt indicates attributes by way of a link in the receipt to a memory location(s) at which the attributes are stored.

As part of the process, the identity attribute or attributes to be shared are, once decrypted using the relevant user key Uk, stored at one or more addressable memory locations from which they can be accessed based on the receipt. This process is referred to as publication, and the attributes stored at the addressable memory location are referred to as published attributes. Each receipt comprises a link in the form of a token (attribute token) which identifies the addressable memory location or locations at which the published identity attribute or attributes are stored (note, this is distinct from the sharing token 706). The published identity attributes are no longer decrypted using the user key and thus the user key is not required to interpret them. However, they may be encrypted based on a transaction identifier comprised in the receipt so that the receipt is required no only to locate the published identity attributes but also to decrypt them. Any entity in possession of the receipt can obtain and decrypt the published identity attributes.

Each receipt 716 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. Hence, an entity in possession of a receipt can be sure that the receipt and the published attributes, it links to is valid.

Figure 8 shows a flow diagram for a process in which the bearer device 702 obtains the sharing token 706 for use in the above process. The bearer device 702 transmits to the digital identity system a bearer credential 808, in association with the policy 708. 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 812 and one or more attribute keys 814 for locating, in the secure store 602, the bearer attributes to be associated with the sharing token 706. This allows the attribute(s) to be located and decrypted for subsequent sharing. In response, the bearer device 702 receives the sharing token 706 for use in the process of Figure 7. At this point, as well as being bound to the specified bearer identity attribute(s) (if any), the sharing token 706 is bound to the policy 708 as received from the bearer device 702, and can only be used to share attributes in accordance with the policy 708 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 sharing token 706 to cause a release of identity attributes from the digital identity system I. The sharing token 706 is also associated with the bearer device 702 and thus functions as an identifier of the bearer device 702.

Figure 9 shows a highly schematic block diagram of a user device 900 such as the bearer or capturing device 702, 704. An identity application 902 is executed on a processor of the user device 900 (not shown) in order to allow the user device 900 to interface with the digital identity system, e.g. in order to participate the process of Figure 7 or 8. The identity application 902 is secured by a PIN (personal identification number) or other secret user authentication data 904 which a user must enter, in order to unlock the identity application 902, in a local user authentication process performed at the user device 900. 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 904. 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 900, or it may be performed remotely at the digital identity system, by the biometric user authentication service 608. For example, an additional requirement may be imposed in the process of Figure 7 and/or 8, 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 602. 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 Figure 10 shows an example method by which a user of a device can create a digital identity for himself within the digital identity system I. Although the process is described in the context of enrolling the capturing device 704, this is the process that is followed by any user creating a digital identity within the digital identity system I. At step S202a, the user uses his device 704 to capture a set of N attributes Ia2,...,aNI, where N>l, from an identity document 1004, such as a passport, driving licence, national identity document etc. These may for example be captured using a camera of the device 1 006 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 1006 an image of his face, i.e. his selfie, which is also an attribute of the user denoted al 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 {al, a2,...,aNI, denoted }a} for convenience below. That is, the selfie al and the additional attribute(s) captured from the document 1004.

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 704, 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 a user key generator 1002. To provide optimum security, the user key generator 1002 can be implemented as a dedicated, hardware security model of the system, e.g. in accordance with the FIE'S 14-2 standard. In response to receiving the device key Dk, the user key generator 1002 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 1002.

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 al,...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 attribute ("Item key/attribute key" lk); in this case, the item key lk is unencrypted with the user key Uk. The encrypted item key Uk(Ik) 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 is stored, and also where the item key Uk(Ik) for that attribute is stored. The device key Dk is used to decrypt Dk(Uk), Uk is used to decrypt Uk(Ik), and Ik is used to decrypt the identified attribute Ik(a).

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

A respective entry 602(1), . 602(N) is created in the secure store 602 for each of the attributes al,...,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 Kal,...,KaN 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 message 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 identify both where the encrypted attribute Ik(a) is held, and where the encrypted item key Uk(lk) for that attribute is held.

At step S208b, the enrolment service 14a responds to the enrolment request by transmitting an electronic response message to a network address associated with the device 704. 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 identity 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 use only credential for the user that is bound to his device 704 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 d1D of the device 704, 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 I with the credential c. By virtue of these associations, the credential is bound to both the user and the device 704.

In this example, the user identifier ulD comprises image data of the selfie captured at step S202b, which in 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 (A/IL) using the image(s) themselves or information extracted from them, e.g. an NIL 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.

Yoti Keys -Attribute Writing: Figure 11 shows an overview of the process by which identity attributes of an existing digital identity are written onto a Yoti Key 100. This is an extension of the identity sharing process described above with reference to Figures 7 and 8. To facilitate the writing of identity attributes, the bearer device 702 is equipped with the necessary NFC communication functionality for it to be able to write to the embedded chip of the Yoti Key 100. As will be apparent, the steps of Figure 11 correspond generally to the steps already described above with reference to Figures 7 and 8 and therefore the description of Figure 11 focusses on the extensions of this process that are implemented in this context. It will be appreciated that all of the above description of Figures 7 and 8 applies equally to the corresponding steps of Figure 11.

At step S1102, the bearer device 702, which is referred to as a tag writer in this context, obtains a sharing token, which is captured by the capturing device 704 at step S1104. In general, a tag writer can be a device or a system of devices which cooperate to implement the described functionality.

In this context, the capturing device 704 is a user device of a user who wishes for his identity attributes to be written to a Yoti Key 100 and is engaging in the identity sharing process of Figure 7 with the tag writer 702 in order to share the applicable identity attributes with the tag writer 702 for that purpose. The attribute types to be written to the smartcard 100 are identified in a policy associated with the sharing token presented by the tag writer 702, although this is not shown explicitly in Figure 11.

At step S1106 the captured sharing token is transmitted from the user device 704 to the validation service 14b along with the other data needed to release the identity attributes specified in the policy, as described above.

In response, at step S1108, a receipt is transmitted from the digital identity system Ito the tag writer 702, which comprises an attribute token (link) for retrieving the identity attributes to be written to the Yoti tag. As noted above, as part of the Yoti share, these attributes are published and the attribute token identifies the memory location or locations to which they are published so that they can be retrieved by an entity in possession of the receipt. This is a one-way Yoti share, in which the user of the capturing device 704 authorises his identity attributes to be shared with the tag writer 702.

The tag writer 702 does not retrieve the identity attributes at this point because they still need to be encrypted and signed before they are written onto the Yoti Key 100. As noted, the attributes are encrypted using the chip ID, which is read from the Yoti Key 100 to which the identity attributes are to be written by the tag writer 702. The tag writer 702 provides the attribute token identifying the memory location or locations at which the published identity attributes are stored, along with the chip ID read from the Yoti Key 100, to a signing service 1107. That is, the tag writer 702 provides the attribute token as received from the digital identity system in the receipt at step S1108 to the signing service 1107 along with the chip ID. At step S1112, the signing service 1107 uses the attribute token to obtain the published identity attributes from the digital identity system 1, encrypts them using the chip ID and signs them using a pricate attribute signature key. The encrypted and signed attributes are passed back to the tag writer 702 at step S1114 so that they can be written onto the Yoti Key at step S1116.

Figure 12 provides a high-level overview of different routes by which a user may obtain different types of Yoti Key. Two types of Yoti Key are considered in this context: a smartcard device which also has the user's identity information physically printed on its surface in the manner of a conventional ID cards (ID smartcard) and a dedicated tag referred to as a Yoti Tag (but which can take any physical form in general).

For the ID smartcard, the user's identity information is printed on the card before the attributes are written to it. An ID smart card printed with a user's identity information is referred to as a "personalized" ID smart card. Hence additional measures are introduced to ensure that the identity data written to the embedded chip of the ID smart card matches the identity data pre-printed on the surface of the card.

As can be seen in Figure 12, there are three routes by which a user may obtain a Yoti key in this example.

To obtain a personalised ID smart card, as shown by the left-hand flow of Figure 12, a user places an order (S1202) for a personalised ID smart card. In this example, the order is placed with a third party ID card provider via their website. In the United Kingdom this could for example be an ID card issued under the PASS (proof of age standards) scheme. At step S1204 the personalised ID smart card is mailed to the user. Note, at that this point, although the ID smart card is personalised with the user's printed identity information, the user's digital identity attributes have not yet been written to its embedded chip. These are written after the user received the card. A subsequent process beginning at step S1206 is followed in order to write the user's digital identity attributes to the ID smart card. In order to do this the user needs to have a pre-existing Yoti (i.e. a pre-existing digital identity within the Yoti system) or they need to create a Yoti for themselves in the manner described above in order to proceed.

The second and third flows shown in Figure 12 relate to a Yoti Tag which a user can order from a website associated with the Yoti system (S1208) or which they can obtain in person (51210) from an authorised Yoti key provider at an identified location. Following the first flow, a Yoti user can also take a personalised ID smart card to such a location at step 51210 in order to have their Yoti attributes written onto it. At step S1214, the user's Yoti attributes are written onto the Yoti Key (ID smart card or Yoti Tag). This can be at the location to which the user has taken his personalised ID smart card or at which he is obtaining a Yoti tag in person following one of the first two flows shown in Figure 12. Alternatively, following the third flow on the right-hand side, where the user is obtaining a Yoti Tag through the Yoti website, once that order has been processed (S1210), then the writing step S1214 can be performed before the Yoti Tag is sent to the user (S1216).

Figure 13 shows an example of a process by which the identity application 302 of Figure 3 can be written onto a multi-application Yoti Key such as a MULTOS smart card. In this example, the identity application 302, which may be referred to in this context as the MULTOS Yoti app, is written onto the smart card chip by an authorised third party outside of the domain of the Yoti system (third party application writer) In order to ensure the MULTOS Yoti app is written in a secure and verifiable manner, at step S1302 a default master key is exchanged between the Yoti system 1 and a third-party application writer system which is denoted by reference numeral 1300. At step S1304, an application binary (ALU), embodying the N1ULTOS Yoti app is sent from the Yoti system 1 to the third party system 1300.

At step S1306, the unique chip ID is read from the embedded chip to which the application binary (ALU) needs to be written The chip ID is referred to as the MCD ID in the context of MULTOS With MULTOS, an enablement step (51308) is required, in which enablement data is obtained by the third party system from a MULTOS card application (CA) application programming interface (API). The enablement data is sent to the embedded chip in order to allow the following steps to continue.

At step 51310, a card-unique application key is created by diversifying the default master key using the chip ID obtained at step S1306. The unique card application key is injected into the ALU to create a personalised ALU that is unique to the chip to which it is being written. At step S1312 the personalised ALU is loaded onto the chip and at this point the chip is now ready to receive Yoti digital identity attributes according to the process outlined in Figure 12 Figure 14 shows further details of the process by which a user may obtain a personalised ID smart card onto which digital identity attributes can be written, following the first flow on the left hand side of Figure 12. In placing an order for a personalised ID smart card at step S1202, the user's identity details are captured so that they can printed on the personalised ID smart card. At the time this order is processed, the chip ID is captured from the ID smart card and stored with the user details printed or to be printed on the ID smart card in a data store 1404 at step S1402. The data store 1404 is maintained by the third-party 1D card provider.

The personalised ID smart card is then provided to the user and at this point does not contain his Yoti attributes. Storing the chip ID in association with the identity data printed on the card provides a means of ensuring that the data that is written to the chip on the card is consistent with the data printed on its surface.

Figure 15 shows further details of the right hand flow of Figure 12 in which a user orders a Yoti Tag from the Yoti website. This is based on the process described above with reference to Figure 4: a Yoti share is performed in which the user shares his identity attributes with a component of the Yoti system 1 itself The specific steps will now be described in further detail.

Only existing Yoti users are able to order a tag. For other users, it is necessary to go through the process of becoming a user via the Yoti app as described above. A user with a Yoti starts the order process from a consumer website (Yoti website) hosted on a web sewer 1502.

At step 1502, a Yoti share between the Yoti user and the web server 1502 is initiated. The Yoti user captures a sharing token presented by the consumer website using their Yoti app.

This can for example be presented in the form of QR code or other visual code that is displayed as part of the content of the consumer website.

At step S1503 the Yoti user approves the sharing request.

At step S1504 the Yoti application sends details of the sharing request to the Yoti backend I. In response, at step S1505, the Yoti backend returns an attribute token to the web sewer 1502 which allows the web server 1520 to retrieve the attributes shared by the user at step S1506.

At step S1507, the shared attributes are stored in a database 1522 (Yoti Key attribute database) which is provided for the purpose of temporarily storing attributes to be written to Yoti keys. During order fulfilment, at step S1508, the attributes are written to the Yoti tag. Once written, the attributes are deleted from the Yoti Key attribute database 1522 (S1509).

The Yoti tag can then be mailed to the user at step S1510 now that the tag is ready for use.

Figure 16 shows an example of a process by which verified identity attributes may be written to a MULTOS Yoti Key. These are the steps that would be performed after the identity application 302 has been written to the N4ULTOS chip following the process of Figure 13. It is assumed at this point that the user already has an existing Yoti from which the identity attributes can be obtained.

The process of Figure 16 relates specifically to a personalised ID smart card on which the user's identity data has been printed but to which his identity attributes have not yet been written At step S1601, the user adds the personalised ID smart card to his Yoti via the Yoti app This involves a process that has some similarity to the Yoti enrolment process described above, in which the user captures an image of the surface of the ID smart card on which their identity data has been printed using the Yoti app which is passed to the Yoti backend 1 at step S1602.

The captured image of the personalised 1D smart card is verified at step S1603, and at step S1604 the corresponding user details are obtained from the third-party ID card provider. It is noted that the third party ID card provider is the party from which the Yoti user obtains the personalised ID smart card at step S1202 of Figure 12, which is general may be different from the third party 1300 of Figure 13 which writes the identity application to the Yoti key.

The user details can be obtained for example using an application programming interface (API) provided by or on behalf of the ID card provider.

At step S1605 the third party ID card provider returns the user details associated with the ID smart card including the corresponding chip ID as captured and stored at step 51402 of Figure 14. The image data of the ID smart card captured at step S 1601 can be matched to the corresponding data held by the third party ID card provider based on a unique identifier of the ID smart card that is printed on its surface. The user's details and the chip ID are stored at the third party ID card provider system in association with the card ID The chip 1D as received from the third party ID card provider system at step S1605 is then added as an additional identity attribute to the user's digital identity. From the point at which it is added, the card ID attribute becomes another identity attribute which the user can share in exactly the same way as his other Yoti identity attributes. The purpose of the chip ID attribute is described below with reference to Figure 17.

Figure 17 shows a process of writing identity attributes to a Yoti key. The process flow of Figure 17 covers the first two scenarios of Figure 12, i.e. where a user obtains a personalised ID smart card or a Yoti tag in person. In both of those scenarios, the Yoti user is required to go to a specific location where there will be provided a Yoti key writer and an authorised individual will write the attributes to the Yoti key using a key writer application. This would correspond to step 51210 of Figure 12.

The Yoti key writer app is denoted by reference numeral 1700 and is executed on a tag writer device equipped with NFC communication technology that allows it to write attributes to a Yoti key 100 At step S1701, the Yoti key 100 is presented to the writer device and the key writer app 1700 reads the chip ID therefrom.

At step S1702, a Yoti share is initiated, in which the Yoti user scans a sharing token presented by the key writer app 1700 with their Yoti app denoted by reference numeral 1720.

This broadly follows the process described above with reference to Figure 11 and therefore there are details of that underlying process are not repeated here but which are described above.

At step S1703, the Yoti user approves the sharing request, and at step S1704 the Yoti app 1700 sends details of the sharing request to the Yoti backend 1. At step S1705, the Yoti backend 1 returns an attribute token to the key writer app 1700 In response to the details of the sharing request sent from the Yoti app 1720 to the Yoti backend 1, the Yoti backend 1 publishes the identity attributes of the user as requested in the sharing request. The attribute token acts as a link to the memory location at which the published identity attributes are stored hence the attribute token can be used to obtain the published identity attributes from the Yoti backend 1.

At step S1706, the key writer app 1700 forwards the received attribute token together with the chip ID to a Keys API 1722 in a key payload request. This is embodied in one or more electronic messages sent from the key writer app 1700 to the Keys API 1722. The Keys API 1722 provides an interface to a signing API 1108. The Keys API 1722 and Signing API 1108 are components of the signing service 1107 first mentioned above with reference to Figure 11, which encrypts and signs identity attributes to be written to the Yoti Key 100.

At step S1707, the Keys API 1722 uses the attribute token received from the key writer app 1700 in the preceding step to obtain the user's identity attributes from the Yoti backend 1 The Yoti backend 1 returns the user's identity attributes to the Keys API 1722 at step S1708.

For a personalised ID smart card, as described above with reference to Figure 16, it is necessary for the user to associate the personalised ID smart card with their Yoti before their Yoti identity attributes can be written to it. They do so following the process of Figure 16 in which the chip ID becomes associated with their Yoti. In this case, at step S1708, the chip ID is returned from the Yoti backend to the key's API 1722 along with the identity attributes to be written to the Yoti key.

As noted, in the process of Figure 16, the chip ID itself can be stored as an additional identity attribute and in that case the policy bound to the sharing token presented at step S1702 can specify that, in addition to the attribute types to be written to the Yoti key, the chip 1D attribute is also required. In that event, the chip 1D is obtained along with the order, identity attributes at step S1708 in exactly the same way.

Step S1709 is an additional check that is performed in this context where the Keys API 1722 verifies that the chip ID attribute returned by the Yoti backend 1 at step S1708 matches the chip ID read from the Yoti Key and received from the key writer app at step S1706. In that case, the process will only be allowed to continue if the chip 1Ds do match.

At step S1710, the Keys API 1722 requests the identity attributes, the chip ID and any other applicable data that is going to be written to the Yoti key to be signed by the signing service 1108. In order to do so, it provides the identity attributes as received from the Yoti system 1 along with the other data to the signing service 1108. These are signed and encrypted at step S1711 and returned to the Keys API at step S1712. Along with the signed attributes, an identifier of a signing key that was used to sign the attributes is also returned.

At step S1713, the Keys API 1722 creates a key payload which contains the signed attributes and a security block, which in turn contains the attribute signatures and the key identifier.

At step S1714, the key payload is returned to the key writer app 1700, and at step S1715 the Yoti key is presented to the tag writer device again. A mutual authentication is performed between the Yoti key and the tag writer app 1700 to create a secure communication session between them. From this point all communications between the Yoti key 100 and the writer app 1700 are encrypted.

At step S1716, the key payload is written to the Yoti key 100.

At step S1717, the key writer app 1700 notifies the Keys API 1722 that the payload has been written to the Yoti key 100.

Figure 18 shows a tag write process that is used in the third branch of Figure 12, namely where a user orders a Yoti key online. In this case, the writing process is handled by an authorised member of Yoti staff in order to write the identity attributes to the Yoti key before it is sent to the user. The process of Figure 18 assumes that the user has already carried out the steps of Figure 15 to authorise the writing of his identity attributes onto the Yoti key. The process of Figure 18 would be performed as part of the order fulfilment step S1508 of Figure 15.

At step S1801, the authorised Yoti staff member selects a pending order to process This is an order that has been submitted via the consumer website, which means the identity attributes to be written to the Yoti key have already been stored in the Yoti Key attributes database 1522.

The pending order is selected via a registration website hosted on a web server 1820 which may be the same or different from the web server 1520 hosting the consumer website. The registration website 1820 generates, at step 1802, a visual code, such as a QR code, containing a unique identifier linked to the order to be processed. Note this QR code is different than the one used during a Yoti share, i.e. it is different from a sharing token. The Yoti staff member will use the key writer 1700 to scan the QR code.

At step S1803, the Yoti key 100 is presented to the key writer device and the key writer app 1700 reads the unique chip ID therefrom.

From here, the process is similar to that described above with reference to Figure 17, At step S1804, the key writer app 1700 instigates a request to the Keys API 1722 for a key payload along with the chip ID read from the Yoti key 100 At step S1805, the Keys API 1722 retrieves the attributes to be written to the Yoti key 100 from the Yoti Key attribute database 1522. To enable this, the request from the key writer app 1700 to the Keys API 1722 includes the code captured from the registration website at step S1802 and uniquely associated with the order to be processed. This allows the user's identity attributes to be retrieved from the Yoti Key attribute database 1522.

Thereafter, the process proceeds just as described above with reference to Figure 17. The only difference in this context is that the identity attributes have been obtained by the key API 1722 from the Yoti Key attribute database 1522. These attributes are passed to the signing API 1108 and signed and encrypted and written to the Yoti key 100 just as described above.

Once this process is complete, the attributes that have been written to the Yoti key 100 are purged from the Yoti Key attribute database 1522 and the Yoti staff member marks the order as complete on the registration website Figure 19 shows the process by which signing certificates are distributed and used to verify attributes read from Yoti keys The certificate distribution service 512 periodically checks for new signing certificates issued by the signing API 1108 (S1901).

At step S1902, a tag reader instigates a request for any new signing certificates from the certificate distribution service 512, obtains any new signing certificate and stores it so that it may be used later in an offline context This is performed periodically as part of a

background process when the tag reader is online.

Step S1903 is an initial one-time configuration step between the tag reader and the key's API 1722.

A tag reader application 1922 is executed on a reader device (corresponding to the reader device 514 shown in Figures 5a and 5b). A reader software development kit (SDK) is provided to allow the reader application 1922 to interface with the certificate distribution service 1920 and the Keys API 1722 in the manner described above. The reader SDK also allows the reader application 1922 to interface with the Yoti key 100 in the manner described below.

At step S1905, the reader app 1922 initiates a Yoti Key read. A user presents the Yoti Key to the reader device at step S1905, and a mutual authentication is performed between the Yoti Key 100 and the reader SDK of the reader app 1922 to create a secure communication session. From this point, all communications between the Yoti Key 100 and the reader SDK are encrypted. This allows the identity attributes to be read from the Yoti Key securely at step 51906 along with the associated security object at step S1907.

At step S1908, the security object is verified to ensure that the attributes are genuine using the corresponding signing certificate obtained at step 1. The correct signing certificate can be identified based on the key identifier stored on the Yoti Key as part of the security object (see e.g. step S1713 of Figure 17). Assuming the attributes are genuine, then they are passed at step S1909 to a processing component 1924 so that they can be used for their intended purpose of verifying the user's identity.

Certificate distribution service (CBS) In order to secure the information written to Yoti keys, a form of public key infrastnicture (PKI), called an RSA 3072 bit digital signature is used. This signature requires a public key (certificate) to be distributed so that the tag reader SDK can validate an attribute signature and verify that: 1. The Yoti key was indeed issued by Yoti and not an unauthorised party writing their own NFC tags 2. That the Yoti key hasn't been tampered with or cloned since it was issued by Yoti, e.g. by someone changing their name or date of birth.

In this context the use of RCA does not encrypt the data on the tag The tag is simply signed to prevent modification/tampering.

Claims (25)

1. Claims A proof of identity device comprising: electronic storage configured to store a plurality of identity payloads, each having an independently verifiable payload signature as determined by cryptographically signing that identity payload individually, wherein each identity payload is associated with an identified attribute type and comprises an identity attribute of that attribute type; a processor coupled to the electronic storage, which is configured to perform an identity sharing function by: processing a received interrogation signal, from an identity- 113 requesting device, to determine therefrom at least one requested attribute type, accessing the electronic storage to match the requested attribute type to the attribute type associated with one of the stored identity payloads, and providing that identity payload and its payload signature to the identity requesting device directly.
2. 2. The proof of identity device of claim 1, wherein the proof of identity device comprises a communications interface coupled to the processor, via which the interrogation signal is received and via which the identity payload and the payload signature are provided.
3. 3 The proof of identity device of claim 1 or 2, wherein each cryptographically signed identity payload comprises data of or derived from an identifier that is unique to the proof of identity device, the unique identifier being accessible to the identity requesting device for verifying the provided identity payload.
4. 4. The proof of identity device of claim 3, wherein each identity payload is encrypted based on the unique identifier, the data derived from the encrypted attribute being data of the encrypted attribute.
5. 5. The proof of identity device of claim 3 or 4 when dependent on claim 2, wherein the unique identifier is readable via the communications interface.
6. 6 The proof of identity device of claim 3,4 or 5, wherein the unique identifier is stored in read-only memory of the proof of identity device.
7. 7. The proof of identity device of any of claims 3 to 6, wherein the unique identifier is a serial number of a chip comprised in the proof of identity device
8. 8. The proof of identity device of any preceding claim, wherein the processor is configured to execute an identity application, the identity application being configured to implement the identity sharing function.
9. 9. The proof of identity device of claim 8, wherein the processor is configured to execute an operating system, the operating system being configured to provide the unique identifier to the identity requesting device independently of the identity application.
10. 10. The proof of identity device of any preceding claim, wherein the electronic storage is configured to store a cryptographically signed operator identifier, and the processor is configured to provide the cryptographically signed operator identifier to the identity requesting device
11. 11. The proof of identity device of claim 10, wherein the electronic storage is configured to store an operator payload comprising the operator identifier and having an independently verifiable payload signature, and the processor is configured to provide the operator payload and its payload signature with the identity payload.
12. 12. The proof of identity device of claim 2 or any claim dependent thereon, wherein the proof of identity device is a passive proof of identity device comprising a power transfer circuit coupled to the communications interface and the processor, which is configured to draw electrical power via the communications interface to power the processor to perform the identity sharing function.
13. 13. The proof of identity device of claim 2 or any claim dependent thereon, wherein the communications interface is a contactless communications interface.
14. 14. The proof of identity device of any preceding claim, wherein the proof of identity device is embodied as a smartcard.
15. 15. The proof of identity device of any preceding claim, wherein one or more of the following identity attributes is comprised in the identity payloads: a name, a biometric, an age-related identity attribute, a nationality.
16. 16. A method of performing an identity sharing function at a proof of identity device comprising electronic storage configured to store a plurality of identity payloads, each having an independently verifiable payload signature as determined by cryptographically signing that identity payload individually, wherein each identity payload is associated with an identified attribute type and comprises an identity attribute of that attribute type; and a processor coupled to the electronic storage; the method comprising: processing, by the processor, a received interrogation signal, from an identity requesting device, to determine therefrom at least one requested attribute type; accessing the electronic storage to match the requested attribute type to the attribute type associated with one of the stored identity payloads; and providing that identity payload and its payload signature to the identity requesting device directly.
17. 17. An identity requesting device comprising: a communications interface; a processor coupled to the communications interface and configured to determine at least one identity attribute type to be requested, instigate via the communications interface to a proof of identity device an interrogation signal which conveys the determined identity attribute type, receive via the communications interface from the proof of identity device an identity payload comprising an identity attribute of the requested type with an associated attribute signature, and verify the attribute signature based on the received identity payload using an expected public key.
18. 18. The identity requesting device of claim 1817 wherein the identity requesting device comprises an output device configured to output to a user of the proof of identity device the identity attribute type to be requested.
19. 19. A method of performing an identity requesting function at an identity requesting device comprising a communications interface and a processor coupled to the communications interface, the method comprising: determining at least one identity attribute type to be requested; instigating via the communications interface to a proof of identity device an interrogation signal which conveys the determined identity attribute type; receiving via the communications interface from the proof of identity device an identity payload comprising an identity attribute of the requested type with an associated attribute signature; and verifying the attribute signature based on the received identity payload using an expected public key.
20. 20. The method of claim 19, wherein the identity requesting device is used to verify the identity embodied in the identity attribute(s).
21. 21. An electronic payment device comprising: a communications interface; electronic storage configured to store: (i) a payment application, (ii) an identity application and (iii) at least one associated identity payload having a verifiable payload signature as determined by cryptographically signing that identity payload; and a processor coupled to the communications interface and the electronic storage for executing the applications; wherein the identity application is configured, when executed on the processor, to provide directly to an interrogating device via the communications interface the identity payload and its payload signature; and wherein the payment application is configured, when executed on the processor, to provide directly to an interrogating device via the communications interface payment authorization data for authorizing an electronic payment.
22. 22. The electronic payment device of claim 21, configured to operate according to an interrogation protocol, in which: an exchange is conducted between the electronic payment device and the interrogating device to determine whether both the payment and identity applications are mutually supported by the electronic payment device and the interrogating device.
23. 23. A method of populating a proof of identity device with identity data the method comprising the following steps: receiving from a user device at a digital identity system an electronic message comprising an attribute key and an identifier of a writer device; using the attribute key to locate, in a database, at least one identity attribute; providing to a signing service an identity payload comprising the located identity attribute for cryptographic signing, thereby generating a payload signature; using the identifier in the electronic message to transmit to the writer device an electronic message comprising or indicating the identity payload and its payload signature; and at the writer device, causing the identity payload and its payload signature to be stored in electronic storage of the proof of identity device, the proof of identity device comprising a communications interface for providing the stored identity payload and its payload signature to an interrogating device
24. 24. The method of claim 23, wherein the identity attribute(s) is encrypted using a writer device identifier, the writer device identifier having been captured by the user device from the writer device
25. 25. A computer program comprising computer-readable code configured, when executed one or more processors, to implement the method or device functionality of any preceding claim.