WO2022214773A1

WO2022214773A1 - Verifiable credential

Info

Publication number: WO2022214773A1
Application number: PCT/GB2021/050857
Authority: WO
Inventors: David Chadwick
Original assignee: Verifiable Credentials Limited
Priority date: 2021-04-07
Filing date: 2021-04-07
Publication date: 2022-10-13

Abstract

The method of obtaining a verifiable credential is herein described. The method comprises reading a machine-readable label (63), such as a QR code, and determining, from the machine-readable label, an identity of a verifiable credential holder (67) and a subject identifier for a user (2). The method comprises sending, to the verifiable credential holder, a request for verifiable credential. The request includes an address of a service (101) to be accessed, an identity of a policy server (42) containing a policy (8) for the service, a policy match parameter for identifying the policy and the subject identifier which allows the verifiable credential holder to retrieve the verifiable credential containing personal attributes of the user from a verifiable credential issuer. The method comprises receiving, from the verifiable credential holder, the verifiable credential for the user, sending, to a verifiable credential verifier (39) for the service, a validation request which includes the verifiable credential and the policy match parameter, receiving, from the verifiable credential verifier, a reply to the validation request and displaying an outcome and/or the verifiable credential in dependence on the reply.

Description

Verifiable credential

Field

The present invention relates to a verifiable credential.

Background

The World Wide Web Consortium (W3C) Verifiable Credentials (VC) Data Model defines a user-centred identify ecosystem. Identity providers issue cryptographically- protected VCs to a user, who stores them and releases them to service providers when needed. The approach merely requires the service provider to trust the identity providers. Thus, the user can present multiple VCs issued by different identity providers to service providers as required.

D. W. Chadwick et ah: “Improved Identity Management with Verifiable Credentials and FIDO” IEEE Communications Standards Magazine, volume 3, pages 14 to 20 (2019) describes combining Fast Identity Online (FIDO) Universal Authentication Framework (UAF) for password-less authentication and W3C VC architectures and extending the UAF protocol to provide strong authentication and authorization.

Summary

According to a first aspect of the present invention there is provided a (computer- implemented) method comprising reading a machine-readable label, determining, from the machine-readable label, an identity of a verifiable credential holder and a subject identifier for a user, and sending, to the verifiable credential holder, a request for a verifiable credential, the request including an address of a service (or “a resource”) to be accessed, an identity of a policy server containing a policy for the service, and a policy match parameter for identifying the policy and the subject identifier allowing the verifiable credential holder to retrieve the verifiable credential from a verifiable credential issuer for the user. The method further comprises receiving, from the verifiable credential holder, the verifiable credential containing personal attributes of the user, sending, to a verifiable credential verifier for the service, a validation request which includes the verifiable credential and the policy match parameter, receiving, from the verifiable credential verifier, a reply to the validation request; and displaying an outcome (such as request granted or request denied) and/ or the verifiable credential in dependence on the reply.

This can allow a user to present a physical credential in the form of a machine-readable label (such as a QR code) to a device and, as result, the device can display only personal attributes required thereby implementing minimal disclosure.

The method may further comprise performing mutual authentication with the verifiable credential holder before sending the request for the verifiable credential. The validation request may further comprise a Boolean attribute for instructing the verifiable credential verifier to whether to include the personal attributes in the reply to the validation request.

According to a second aspect of the present invention there is provided a (computer- implemented) method comprising receiving, from a remote device, a request for a verifiable credential for a user, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, and a policy match parameter for identifying the policy and the subject identifier for allowing the verifiable credential holder to retrieve the verifiable credential from a verifiable credential issuer for the user. The method comprises retrieving the policy from the policy server according to the policy match parameter, retrieving the verifiable credential for the user from a verifiable credential issuer according to the policy and sending the verifiable credential to the remote device.

The method may further comprise performing mutual authentication with the remote device before receiving the request for the verifiable credential. The method may further comprise performing mutual authentication with the verifiable credential issuer before retrieving the verifiable credential from the verifiable credential issuer.

The method may further comprise, during a registration phase, sending a registration request to the verifiable credential issuer, the registration request identifying a user, receiving, from the verifiable credential issuer, attributes for the user, generating a random number and using the random number as the subject identifier for the user, sending the subject identifier to the verifiable credential issuer and storing a verifiable credential skeleton comprising the attributes, the verifiable credential skeleton linked with the verifiable credential issuer and the subject identifier.

According to a third aspect of the present invention there is provided a (computer- implemented) method comprising, during a registration phase sending a registration request to a verifiable credential issuer, the registration request identifying a user, receiving, from the verifiable credential issuer, attributes for the user, generating a random number and using the random number as the subject identifier for the user, sending the subject identifier to the verifiable credential issuer and storing a verifiable credential skeleton comprising the attributes, the verifiable credential skeleton linked with the verifiable credential issuer and the subject identifier.

The machine-readable optical label may be a QR code or other form of barcode.

The verifiable credential may comprise at least one attribute type and a corresponding attribute value, at least one attribute and plural corresponding attribute values and/ or a set of at least one embedded attribute type and corresponding attribute value.

The request for the verifiable credential may include information (AuthnCreds) for later identifying a response to the request. According to a fourth aspect of the present invention there is provided a (computer- implemented) method comprising receiving a request from a verifiable credential holder, the request including a verifiable credential skeleton containing a set of attributes (or “specified set of attributes”) and a subject identifier. The method comprises retrieving the set of attributes from an identity provider server using the subject identifier, comparing the attributes retrieved from the identity provider server with the attributes contained in the verifiable credential skeleton to determine a match, and, upon a positive determination, creating a verifiable credential containing the set of attributes, wherein the verifiable credential is bound to the subject identifier, and sending the verifiable credential to the verifiable credential holder.

The method may further comprise, during a registration phase prior to receiving the request, receiving a registration request from the verifiable credential holder, the registration request identifying a user, retrieving attributes for the user from the identity provider server, sending the attributes for the user, to the verifiable credential holder, receiving the subject identifier from the verifiable credential holder, storing the subject identifier linked to the attributes and sending the identity of the verifiable credential holder and the subject identifier to a print server for printing a physical certificate for the user.

According to a fifth aspect of the present invention there is provided a (computer- implemented) method comprising, during a registration phase, receiving a registration request from a verifiable credential holder, the registration request identifying a user. The method comprises retrieving attributes for the user from an identity provider server, sending the attributes for the user, to the verifiable credential holder, receiving the subject identifier from the verifiable credential holder, storing the subject identifier linked to the attributes and sending the identity of the verifiable credential holder and the subject identifier to a print server for printing a physical certificate for the user.

According to a sixth aspect of the present invention there is provided computer program code comprising instructions, which when executed by at least one processor, causes the at least one processor to perform the method of any one of first, second, third, fourth or fifth aspects. According to a seventh aspect of the present invention there is provided a computer program product comprising a machine-readable medium (which may be a non- transitory machine-readable medium) storing thereon the computer program code of the sixth aspect.

According to an eight aspect of the present invention there is provided apparatus configured to perform the method of any one of first, second, third, fourth or fifth aspects. According to a ninth aspect of the present invention there is provided a device operable as a verifying device, the device comprising at least one processor, memory, display, a reader for reading a machine-readable label and a verifier application. The device is configured, during a resource access phase, to read the machine-readable label, to determine, from the machine-readable label, an identity of a verifiable credential holder and a subject identifier for a user, to send, to the verifiable credential holder, a request for verifiable credential, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, and a policy match parameter for identifying the policy and the subject identifier for allowing the verifiable credential holder to retrieve verifiable credential from a verifiable credential issuer for the user, to receive, from the verifiable credential holder, the verifiable credential containing personal attributes of the user, to send, to a verifiable credential verifier for the service, a validation request which includes the verifiable credential and the policy match parameter, to receive, from the verifiable credential verifier, a reply to the validation request and to display an outcome and/or the verifiable credential(s) in dependence on the reply.

According to a tenth aspect of the present invention there is provided a server operable as a verifiable credential holder, the server comprising at least one processor and memory. The server is configured, during a resource access phase, to receive, from a remote device, a request for a verifiable credential for a user, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, and a policy match parameter for identifying the policy and the subject identifier for allowing the verifiable credential holder to retrieve verifiable credentials from a verifiable credential issuer for the user, to retrieve the policy from the policy server according to the policy match parameter, to retrieve the verifiable credential for the user from a verifiable credential issuer according to the policy and to send the verifiable credential to the remote device.

According to an eleventh aspect of the present invention there is provided a server operable as a verifiable credential holder, the server comprising at least one processor and memory. The server configured, during a registration phase, to send a registration request to a verifiable credential issuer, the registration request identifying a user, to receive, from the verifiable credential issuer, attributes for the user, to generate a random number and using the random number as the subject identifier for the user, to send the subject identifier to the verifiable credential issuer, and to store a verifiable credential skeleton comprising the attributes, the verifiable credential skeleton linked with the verifiable credential issuer and the subject identifier.

The server may be configured, during a resource access phase, to receive, from a remote device, a request for a verifiable credential for a user, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, and a policy match parameter for identifying the policy and the subject identifier for allowing the verifiable credential holder to retrieve the verifiable credential from a verifiable credential issuer for the user, to retrieve the policy from the policy server according to the policy match parameter, to retrieve the verifiable credential for the user from a verifiable credential issuer according to the policy, and to send the verifiable credential to the remote device.

According to a twelfth aspect of the present invention there is provided a server operable as a verifiable credential issuer, the server comprising at least one processor; and memory. The server is configured, during a resource access phase, to receive a request from a verifiable credential holder, the request including a verifiable credential skeleton containing attributes and a subject identifier, to retrieve attributes from an identity provider server using the subject identifier, to compare the attributes retrieved from the identity provider server with the attributes contained in the verifiable credential skeleton to determine a match and, upon a positive determination, to create a verifiable credential containing the attributes, wherein the verifiable credential is bound to the subject identifier, and sending the verifiable credential to the verifiable credential holder. According to a thirteenth aspect of the present invention there is provided a server operable as a verifiable credential issuer, the server comprising, at least one processor; and memory. The server is configured, during a registration phase, to receive a registration request from a verifiable credential holder, the registration request identifying a user, to retrieve attributes for the user from an identity provider server, to send the attributes for the user, to the verifiable credential holder, to receive the subject identifier from the verifiable credential holder and to store the subject identifier linked to the attributes; and to send the identity of the verifiable credential holder and the subject identifier to a print server for printing a physical certificate for the user.

The server may be further configured, during a resource access phase, to receive a request from a verifiable credential holder, the request including a verifiable credential skeleton containing attributes and a subject identifier, to retrieve attributes from an identity provider server using the subject identifier, to compare the attributes retrieved from the identity provider server with the attributes contained in the verifiable credential skeleton to determine a match and, upon a positive determination, to create a verifiable credential containing the attributes, wherein the verifiable credential is bound to the subject identifier, and sending the verifiable credential to the verifiable credential holder

According to a fourteenth aspect of the present invention there is provided a system comprising the device of the tenth aspect, the server of the eleventh aspect, the server of the twelfth aspect and a network interconnecting the device and servers. The system may further comprise a server operable as a verifiable credential verifier. The system may further comprise server operable as a policy server to store and retrieve a policy in a policy database.

According to a fifteenth aspect of the present invention there is provided a system comprising the server of the thirteenth aspect, the server of the fourteenth aspect and a print service comprising a print server and a printer.

The system may further comprise a server operable as a identify provider server to store and retrieve attributes in an identify provider database. According to a sixteenth aspect of the present invention there is provided a (computer- implemented) method, comprising, during registration receiving, from a requester, a request to register for a verifiable credential, the request including an identity of a verifiable credential issuer, and an authentication parameter, sending a request to register for the verifiable credential to the verifiable credential issuer, the request including the authentication parameter, receiving, from the verifiable credential issuer, a request to create a FIDO key pair, the request including a challenge, sending a request to create a FIDO key pair to a local FIDO authenticator, the request including the challenge, receiving, from the local FIDO authenticator, an attestation object containing a public FIDO key, sending a response to the verifiable credential issuer, the response including the public FIDO key, receiving, from the verifiable credential issuer, attributes for the user, in response to user input selecting at least some of the attributes, creating verifiable credential skeletons including selected attributes and sending confirmation of registration to the requester.

The requester may be a web browser.

According to a seventeenth aspect of the present invention there is provided a (computer-implemented) method comprising receiving, from a verifiable credential holder, a request to register for a verifiable credential, the request including an authentication parameter, sending a request to register for the verifiable credential to an identity provider server, receiving, from identity provider server, a user handle, sending a challenge to the verifiable credential holder, receiving, from the verifiable credential holder, a response to the challenge, the response including the public FIDO key, sending a request for attributes to an identity provider server, the request including the user handle, and, in response to receiving the attributes, sending the attributes to the verifiable credential holder. According to an eighteenth aspect of the present invention there is provided a

(computer-implemented) method receiving a request for a verifiable presentation from a requester, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, a policy match parameter for identifying the policy, and an authentication parameter, determining whether a verifiable presentation exists for the service according to the policy match parameter and, upon a negative determination: generating an ephemeral key pair comprising an ephemeral public key and an ephemeral private key, requesting the policy from the policy server, requesting, from at least one verifiable credential issuer, verifiable credential(s) bound to the ephemeral public key, the verifiable credential(s) containing attributes selected according to the policy, creating a verifiable presentation including the verifiable credential(s) and the authentication parameter, and storing the verifiable presentation, and, upon a position determination: retrieving the verifiable presentation and, if necessary, replacing a previous authentication parameter in the verifiable presentation with the authentication parameter (or “the current authentication parameter”). The method further comprises signing the verifiable presentation with the ephemeral private key and sending the verifiable presentation to the requester.

Requesting the verifiable credential(s) may comprise sending the ephemeral public key signed with the ephemeral private key to the verifiable credential issuer and receiving the verifiable credential(s) from the verifiable credential issuer, wherein the verifiable credential(s) comprises attributes attached to the public key.

The attributes may be a subset of attributes held in an identifier provider database. The requester may be a browser application. The browser application may be configured, in response to receiving the verifiable presentation, to forward the verifiable presentation to a web server.

The requester may be a wallet application. The wallet application may be configured, in response to receiving the verifiable presentation, to forward the verifiable presentation to a remote server for storage and to generate a pointer to the verifiable presentation at the remote server. The wallet application may further be configured to present a label which includes the pointer for reading by another device.

According to a nineteenth aspect of the present invention there is provided a (computer-implemented) method comprising presenting a machine-readable label comprising an identity of a policy server containing a policy for a service, a policy match parameter for identifying the policy, and an authentication parameter, reading a machine-readable label which includes a pointer to a verifiable presentation at the remote server, retrieving the verifiable presentation from the remote server and sending, to a verifiable credential verifier for the service, a validation request which includes the verifiable presentation and the policy match parameter, receiving, from the verifiable credential verifier, a reply to the validation request and displaying an outcome and/or the verifiable credential(s) in dependence on the reply.

According to a twentieth aspect of the present invention there is provided computer program code comprising instructions, which when executed by at least one processor, causes the at least one processor to perform the method of any one of seventh, eighteenth, nineteenth or twentieth aspects.

According to a twenty-first aspect of the present invention there is provided a computer program product comprising a machine-readable medium (such as a non-transitory machine-readable medium) storing thereon the computer program code of the twenty- first aspect.

According to a twenty-second aspect of the present invention there is provided a service (or “application” or “module”) operable as a verifiable credential holder. The service is configured, during a registration phase, in response to receiving, from a requester, a request to register for a verifiable credential, the request including an identity of a verifiable credential issuer and an authentication parameter, to send a request to register for the verifiable credential to the verifiable credential issuer, the request including the authentication parameter, in response to receiving, from the verifiable credential issuer, a request to create a FIDO key pair, the request including a challenge, to send a request to create a FIDO key pair to a local FIDO authenticator, the request including the challenge, in response to receiving, from the local FIDO authenticator, an attestation object containing a public FIDO key, to send a response to the verifiable credential issuer, the response including the public FIDO key, in response to receiving, from the verifiable credential issuer, attributes for the user, to prompt the user to select attributes and, in response to user input selecting at least some of the attributes, to create verifiable credential skeletons including selected attributes and to send confirmation of registration to the requester. The service is preferably implemented in software in a device comprising at least one processor and memory.

According to a twenty-third aspect of the present invention there is provided a server operable as a verifiable credential issuer, the server comprising at least one processor and memory. The server is configured, during a registration phase, in response to receiving, from a verifiable credential holder, a request to register for a verifiable credential, the request including an authentication parameter, to send the authentication parameter in a request to register for the verifiable credential to an identity provider server, in response to receiving, from identity provider server, a user handle, to send a FIDO challenge to the verifiable credential holder, in response to receiving, from the verifiable credential holder, a response to the challenge, the response including the public FIDO key, to send a request for attributes to identity provider server, the request including the user handle, and, in response to receiving the attributes, to send the attributes to the verifiable credential holder.

According to a twenty-fourth aspect of the present invention there is provided a device, the device comprising at least one processor and memory. The device is configured, in response to receiving a request for a verifiable presentation from a requester, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, a policy match parameter for identifying the policy, and an authentication parameter, to determine whether a verifiable presentation exists for the service according to the policy match parameter. The device is configured, upon a negative determination: to create an ephemeral key pair comprising an ephemeral public key and an ephemeral private key, to request the policy from the policy server, to request verifiable credential(s) bound to the ephemeral public key, the verifiable credential(s) containing attributes selected according to the policy from at least one verifiable credential issuer, to create a verifiable presentation including the verifiable credential(s) and the authentication parameter and to store the verifiable presentation. The device is configured, upon a position determination: to retrieve the verifiable presentation and, if necessary, to replace a previous authentication parameter in the verifiable presentation with the authentication parameter. The device is configured to sign the verifiable presentation with the ephemeral private key and to send the verifiable presentation to the requester.

According to a twenty-fifth aspect of the present invention there is provided a device comprising at least one processor, memory, a display and a reader or interface for reading a machine-readable label. The device is configured to present a machine- readable label comprising an identity of a policy server containing a policy for a service, a policy match parameter for identifying the policy, the address of the remote server and an authentication parameter, to read a machine-readable label which includes a pointer to a verifiable presentation at the remote server, to retrieve the verifiable presentation from the remote server, to send, to a verifiable credential verifier or the service, a validation request which includes the verifiable presentation and the policy match parameter, to receive, from the verifiable credential verifier, a reply to the validation request and to display an outcome and/or the verifiable credential(s) in dependence on the reply. According to a twenty-sixth aspect of the present invention there is provided a system comprising the device of the twenty-fifth aspect, the device of the twenty-sixth aspect, the remote server and a network interconnecting each device with the remote server.

Brief Description of the Drawings

Certain embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a schematic block diagram of a first verifiable credential system; Figure 2 illustrates steps carried out prior to downloading a verifiable credential;

Figure 3 illustrates a method of downloading a verifiable credential;

Figures 4A, 4B and 4C illustrate pages displayed during downloading the verifiable credential shown in Figure 3 in a desktop computer environment;

Figure 5 illustrates a method of accessing a resource which includes selecting and presenting a verifiable credential in a verifiable presentation;

Figure 6 illustrates obtaining a verifiable credential during resource access shown in Figure 5;

Figure 7A, 7B and 7C illustrate pages presented to a user during resource access in a desktop computer environment; Figure 8A, 8B and 8C illustrate screens displayed during downloading the verifiable credential shown in Figure 3 in a mobile device environment;

Figure 9A and 9B illustrating viewing verifiable credentials in a mobile device environment;

Figure 10A and 10B illustrate screens presented to a user during resource access in a mobile device environment;

Figure 11 is a schematic block diagram of a system used to register a physical credential with a verifiable credential holder;

Figure 12 illustrates a method of registering a physical credential with a generic verifiable certificate holder acting on behalf of a real holder which may not possess a computing device;

Figure 13 is a schematic block diagram of a second verifiable credential system in which a holder possessing a physical credential and a verifier verifies an electronic equivalent of the physical credential provided by a generic verifiable certificate holder;

Figure 14 illustrates a method of accessing a resource using a physical credential; Figure 15A and 15B illustrate screens presented to a user during resource access in a mobile device environment using a physical credential;

Figure 16 is a schematic block diagram of a third verifiable credentials system in which a device displays a QR code; and

Figure 17 illustrates a method of accessing a resource using a displayed QR code. Detailed Description of Certain Embodiments

System overview

Referring to Figure l, a first verifiable credentials system l is shown. The system 1 allows a user 2 to register for a verifiable credential 3 (herein also referred to as a “certificate” or “VC”) issued by an issuing authority 4, to exchange a FIDO key pair with the issuing authority 4, to store a skeleton 5, which is an unsigned verifiable credential, on a computing device 6, such as a laptop computer or a mobile phone, to select attributes 7 from the skeleton 5 according to a policy 8 (“a verifier’s policy”) of a verifying authority 9, to request a verifiable credential 3 from the issuing authority 4 that matches the verifier’s policy 8 and to encapsulate the verifiable credential 3 in a verifiable presentation 10 (or “VP”).

The system 1 may include more than one issuing authority 4 and the user 2 may contact multiple issuing authorities 4 using the FIDO key it has for each one to obtain multiple verifiable credentials 3 and to include multiple verifiable credentials 3 in a verifiable presentation 10. A verifiable credential holder 11 generates an ephemeral asymmetric key pair 12_PU, 12_PR, including a private key 12_PR stored in hardware 36 in the device 6 and a public key 12_PU which the VC holder 11 passes to VC issuers 13 asking for attributes 7 to be attached to the ephemeral key 12 in the verifiable credential 3, in other words, in a digitally-signed skeleton 5.

In this example, the user 2 is a nurse or doctor, the issuing authority 4 is a COVID-19 diagnostic testing authority and the verifying authority 6 is a hospital where the user 2 works. The user 2 is required to prove that he or she has COVID-19 immunity and, thus, safe to work at the hospital. Although a medical setting is given, certificates 3 can be issued and used in a variety of other, different contexts. For example, the issuing authority 4 can be of another, different type such as a government agency, for instance a passport issuing office, or a commercial entity, such as a bank issuing a credit card. An issuing authority 4 may issue more than one certificate. For example, a diagnostic testing authority may provide immunity certificates for different diseases. There may be more than one issuing authority 4, each issuing one or more certificates 3. Thus, a user may collect more than one certificate 3. Similarly, there may be more than one verifying authority 9, which again can be of another, different type, such as a public service provider or a commercial entity, such as a bank, shop or bar. Referring still to Figure l, the issuing authority 4 has a VC issuer server 13 (or “VC issuer”), a corresponding VC issuer database 18, a FIDO server 19, an identity provider (IDP) server 20, and a corresponding IDP database 21 which holds personal details about the user 2 including attributes 7, each attribute typically taking the form of an attribute type AT and an attribute value AV. The issuing authority 4 forms part of an identity provider 22 which may have an IDP web server 23.

The device 6 typically comprises a processor 25, memory 26, data storage 27, user input devices 28 (which can include touch screen, fingerprint reader etc.), a display 29, a network interface 30 and, optionally, at least one camera 31, such as a rear-facing camera. The device 6 includes a web browser application 32 (or “browser”), a VC holder application 11 (or “VC holder”) and a corresponding VC holder database 33 and a FIDO authenticator 34 for generating and storing FIDO keys 35 which are stored in secure hardware 36. The FIDO authenticator 34 authenticates the user, for example, using a PIN, fingerprint, facial recognition or other authentication approach, before allowing the user access to private keys stored in hardware 36.

Referring still to Figure 1, the verifying authority 9 has a web server 37 including an Application Programming Interface (API) 38 and a VC verifier server 39 and corresponding VC verifier database 40. The verifying authority 9 creates a policy 8 to store in its policy registry 41. The policy registry 41 has a policy server 42 and policy database 43 which allows the policy 8 to be shared with the user device 6. The policy server 42 stores tables 98 (Figure 13) which includes entries 87 (Figure 13), each entry 87 (Figure 13) including a policy match 88 (Figure 13) and an associated policy 8.

The VC Holder 11 on the user device 6 can communicate with the VC issuer 13 and the policy registry 41, and the browser 32 can communicate with the issuing authority’s IDP web server 23 and the verifying authority’s web server 37 via a network 44, such as the Internet.

Attributes download

A registration process by which the user 2 obtains attributes 7 and creates a VC skeleton 5 will now be described. Referring to Figures 1 and 2, the user 2 takes a diagnostic test (step S2.1) and the test result are stored in the testing authority’s IPD database 21 (step S2.2). The testing authority 4 provides the user 2 with personal authenticating details about the test, for example by a text message, e-mail or letter, allowing the user to obtain the test results from the VC issuer 13 (step S2.3). Referring to Figures 1, 3 and 4A, the user 2 navigates to a web page 45₁ of the issuing authority’s IDP web server 23 using their browser 32 and, via their browser 32 enters their authenticating details via fields 46₁, 46₂ on a web page 45₂ (step S3.1). The web server 23 returns a registration request, Registration Request, to the browser 32 (step S3.2). The Registration Request contains a script that calls the VC holder 11 and the VC holder 11 passes the Registration Request to the VC issuer 13 (steps S3.3 & S3.4). The authenticating details may take the form of, for example, the name of the user’s doctor and test number. The authenticating details, however, can take other forms, such as National Health Service (NHS) Number, Batch number, Date of Vaccination. The VC issuer 13 authenticates the user 2 using the IDP server 20 of the issuing authority 4 that originally provided the user with this information (step S3.5). After successful authentication, the VC issuer 13 sends a request to the VC holder 11 to create a new FIDO key pair using its FIDO authenticator 34 using the FIDO challenge-response registration protocol (step S3.6). Upon successfully registering a new FIDO public key for the user 2 (step S3.7), the VC issuer 13 retrieves a set of attributes 7 (step S3.8), each attribute (or “item of personal information”) comprising an attribute type AT and corresponding attribute value AV or an embedded set of attribute types and values, and forwards these to the VC holder 11 (step S3.9). For example, the value of an address may include street name, house number and city, each of these being an attribute type and value. An attribute type AT may have more than one attribute value AV.

Referring to Figures 1, 3 and 4B, the VC holder 11 presents a window 47 listing the attributes 7 and prompting the user 2 to select which attributes 7 he or she wishes to store (step S3.10). Attributes can include, for example, user details, such as name, date of birth and/or NHS number, test details, such as date of test number, test type, test result, and test expiry date, and/or vaccination details, such as date of vaccination, vaccination type, vaccination batch number and vaccination expiry date. The user 2 is asked for consent. Referring to Figures 1, 3 and 4C, upon selection, the selected details are stored as a VC skeleton 5 in the VC holder database 33 (step S3.11). Confirmation is presented to the user via a page 45₃ in the browser 32 (step S3.12). Attribute selection and VP presentation (Access Resource)

A process in which the user 2 (Figure 1) selects attributes 7 and presents a verifiable presentation 10 to the verifying authority 9 (Figure 1) will now be described.

Referring to Figure 5A, 7A and 8A, using their web browser 32, the user 2 navigates to a web page 55₁ of the verifying authority 9 and sends an access request to the web server 37 (step S5.1). The web server 37 sends a reply requesting a verifiable presentation VP. The request contains the identity of the policy server 42, a policy match parameter PolicyMatch and authentication credentials, AuthnCreds (step S5.2). The browser 32 sends the request for the verifiable presentation VP to the VC holder 11, which identifies the service provider (i.e., the web server 37) and the policy server 42 (step S5.3). The authentication credentials AuthnCreds contains information which allows the web server 37 to identify the verifiable presentation VP when received from the VC verifier 39. Any form of identifying information can be used, such as a simple nonce (i.e., an arbitrary number).

The VC holder 11 checks the VC holder database 33 to determine whether a verifiable presentation VP already exists (step S5.4). A verifiable presentation VP may already exist, for example, because the user 2 has recently visited this same web server 37. If a verifiable presentation VP does not exist (step S5.5), then the VC holder 11 creates a new entry in the VC holder database 33 (step S5.6) and obtains a verifiable credential VC 3 from the relevant VC issuer 13 and creates a verifiable presentation VP 10 (steps S5-7to S5.16). To create the correct verifiable presentation VP, the VC holder 11 retrieves the verifier’s policy 8 from the policy server 42 (steps S5.7). Cycling through policy elements (or “policy components") (step S5.8), the VC holder 11 retrieves any verifiable credentials skeletons 5 from the VC holder database 33 that match this policy 8 (step S5.9) and presents a window 56 listing these skeletons (i.e., potential future verifiable credentials) and asking the user to choose the ones that are required (step S 5.10). If the user hovers the cursor over a skeleton 5 or clicks it, then the VC holder 11 presents a window 57 listing the attributes 7 of the skeleton 5 that the verifying authority 9 has requested in its policy 8. If a verifiable credential skeleton 5 does not exist, then the user will be informed that the policy 8 cannot be matched and that the user will need to register with one or more issuing authorities 4.

Referring to Figures 6A and 6B, assuming the user 2 has at least one skeleton 5 to match each of the policy elements, then the VC holder 11 sends an authentication request to the VC issuer 13 which includes a user name used for locating the FIDO key for the user 2 (step S5.14 & S6.1). The VC issuer 13 authenticates the user using the FIDO challenge-response authentication (step S6.2).

The VC holder 11 creates an ephemeral key pair Pu^EPH, Pr^EPH i2pu, 12PR for the VC verifier 39 (step S6.3). The lifetime of the ephemeral key pair Pu^EPH, Pr^EPH 12_PU, 12_PR depends on the risk assessment of the issuer 13. The lifetime can be a short as 5 minutes (or even shorter), for example, in the case of fast-changing personal financial information, such as a bank statement, between 10 and 60 minutes ( e.g ., 30 minutes), for instance, for credit card information, or 24 hours (or even longer), for example, for a driving licence. The VC holder 11 stores the ephemeral public key Pu^EPH i2pu in its database 33 (step S6.4) and the ephemeral private key Pr^EPH 12_PU in secure hardware 36, and sends a signed copy of the public key Pu^EPH 12_PU to the VC issuer 13 (step S6.5), along with a request for the attributes 7_S that match the verifier’s policy 8.

The VC issuer 13 retrieves the required attributes 7_S from the IDP database 21 via IDP server 20 (step S6.7), creates verifiable credentials VC with them (step S6.8), signs them with its permanent private key (step S6.9) and forwards these to the VC holder 11 (step S6.10). The required attributes 7_S is a subset of the superset of attributes 7 held by the IDP database 21. The attributes 7 stored in skeletons 5 in the device 6 is a subset of the superset of attributes 7, although they can be the same. The verifiable credentials are sent encrypted over the TLS connection.

Attributes AT, AV may change or expire and so skeletons 5 in the VC holder 11 may be modified or even deleted by the issuing authority 4. The VC issuer 13 forwards modified skeletons, and notifies the VC holder 11 of the identity of any skeletons that have been deleted. Upon receipt, the VC holder 11 deletes the deleted skeletons (step S6.11) and asks the user if he or she consents to the update of any modified skeletons

(step S6.12). Referring again to Figure 5A, the VC holder 11 creates a verifiable presentation VP for the service provider, placing inside it the verifiable credentials 3 retrieved from the VC issuer 13 (steps S5.14 & S5.16).

Referring to Figure 5B, if a verifiable presentation VP already exists (step S5.17) or is created, then the VC holder 11 now includes the authnCreds received from the service provider SP into this verifiable presentation VP 10, digitally signs the verifiable presentation VP 10 (step S5.18), and forwards the verifiable presentation VP 10 to the web browser 32 (step S5.19 & S5.20).

The web browser 32 accesses the web server 37, presenting the verifiable presentation VP 10 containing the verifiable credentials 3 (step S5.21). After performing TLS mutual authentication with the VC verifier 39 (step S5.22), the web server 37 requests an access decision from the VC verifier 39, passing it the policy match PolicyMatch, the verifiable presentation VP, a Boolean attribute Atts (step S5.23). The Boolean attribute Atts is set to TRUE or FALSE, and informs the VC verifier 39 whether to return all the attributes AT, AVs along with the granted or denied access decision (where TRUE signals return them, and FALSE signals do not return them).

The VC verifier 39 verifies the verifiable presentation VP signature (step S5.24) and signatures of the verifiable credentials VCs (S5.25). The VC verifier 39 parses the verifiable credentials VCs and creates corresponding skeletons (step S5.26). The VC verifier 39 stores the skeletons in VC verifier database 40 (step S5.27).

The VC verifier 39 retrieves the policy match parameter PolicyMatch from the policy database 43 and the policy 8 to identify the matching VC skeletons (steps S5.28, S5.29, S5.30, S5.31 &S5.32).

Upon successfully identifying the matching VC skeletons, the VC verifier 39 sends confirmation to the web server 37 that access has been granted (step S5.33). In turn, the web server 37 returns the request Access to the web browser 32 (step S5.34). Referring to Figure 7C, confirmation is presented to the user via a page 55₃ in the browser 32.

Mobile environment Figures 4A, 4B and 4C illustrate the user 2 downloading attributes in a desktop computing environment. However, the user device 6 may be a mobile device.

Referring to Figures 8A, 8B and 8C, screen shots taken during the process of downloading attributes in a mobile device are shown. The pages and messages are similar to those presented to the user in the desktop computing environment.

Referring in particular to Figure 8A, the user 2 navigates to the web page 45₁ of the issuing authority 4 using their web browser 32 and, on a following page 45₂, the user is prompted to authentication information. Upon successful authentication, the user is presented with a message 47 asking the user if he or she wishes to open VC Holder app 11. If the user selects “Open”, then the VC Holder app 11 is opened and presents a page 48 of selectable buttons including “Contents”, “Scan QR Code”, “Add Card”, “Add Device”, “Backup” and “Recover”. Referring in particular to Figure 8B, the user 2 is prompted with a message 49 to authenticate and key is created (step S3.2; Figure 3). The VC issuer 13 retrieves a set of attributes AT, AV and forwards these to the VC holder 11 (step S3.3). The VC holder 11 presents a window 50 identifying the certificate skeletons. The user is able to view the attributes and their values via a series of windows 5I₁, 51₂, 513. The user is asked for consent.

Referring in particular to Figure 8C, upon selection, the selected details (i.e., the skeleton) are stored in the VC holder database 33 (step S3.5). The device returns to the app page 48 and then confirmation is presented to the user via a page 45₃ in the browser 32 in the same way as in the desktop environment (step S3.6).

Referring to Figures 9A and 9B, the user can open the VC Holder app 11 via a home screen 52 and inspect, on a screen 53, different certificate skeletons. If the user selects a certificate skeleton, the device presents window(s) 54 via which the user can view attributes and their values. Figures 7A, 7B and 7C illustrated the user 2 selecting and presenting a certificate to the verifying authority 9 in a desktop computing environment.

Referring to Figures 10A, 10B and 10C, screen shots taken during the process of selecting and presenting a certificate in a mobile device are shown. The pages 55₁, 55₂, 55₃ and messages 56, 57 are similar to those presented to the user in the desktop computing environment, although additional pages 55A and messages 58, 59 may be used to inform the user of progress and prompt the user to authenticate. Referring to Figure 10B, upon selecting a card (i.e., a verifiable credential) to submit to the web server 37, the VC holder app page 48 can display a message 58 to inform the user that the card is being fetched and another message 59 prompting the user to authenticate. Physical certificate

Referring to Figure 1, the user 2 is challenged by a verifier authority 9 to provide selective disclosure of the contents in a credential. This can range from full disclosure, i.e., disclosure of all personal attributes (or “attributes”), to zero disclosure, i.e., no disclosure of any attributes. Furthermore, there maybe situations when a user 2 does not have a device 6 or it may be inappropriate or inconvenient to use or carry a device which provides the VC holder functionality and is used to store VC skeletons 5. Notwithstanding this, a user 2 may still wish to be able to provide proof of identity, proof of age or even photo ID, and the verifier may not need or want to see the entire contents of the credential.

The specific credential needed by a verifier 39 can vary according to circumstance. For example, a user may need to provide proof of identity, such as name or NHS number, in one situation, for example, when needing treatment at a hospital, but may need to provide only proof of age (or date of birth) in another, different context, for instance when buying alcohol at a supermarket or liquor store. When buying alcohol, it is not necessary to show name or other personal details.

Referring to Figure 11, a physical certificate 61 can be used in the form of a sheet of paper 62 (or other suitable medium) on which a machine-readable label 63 (or “identifier”) is printed on one side. The machine-readable label 63 may take the form of a QR code. The reverse side may contain the full details of the certificate, e.g., name and date of birth. The user 2 can now show the machine- readable label without revealing any personal information on the reverse. The physical certificate 61 is issued by an issuing authority 4’ using a print service 65. In lieu of a VC holder 11 (Figure 1) on a device 6 (Figure 1) which is in the possession of the user 2 (Figure 1), a remote VC holder server 67 (herein referred to as a “generic VC holder” or “GVC holder”) is used which stores VC skeletons 5 in its database 69. As will be explained hereinafter, a certificate reading device 70 (Figure 13) is used to read the label 63 and, according to a policy 8 (Figure 13), only relevant subset 7_A, 7_B of attributes 7 are displayed at the reading device 70.

Referring also to Figure 12, a process of registering a user 2 and generating the physical certificate 61 will now be described.

Using a web browser 75, an authorised person 76 at the issuing authority 4’ sends a request Register to the GVC holder 67 to register the user 2 (step S12.1). The request Register includes a user handle identifying the user 2.

After TLS mutual authentication with the GVC issuer 13’, the GVC holder 67 sends a registration request to the GVC issuer 13’ (step S12.2). The GVC issuer 13’ stores a TLS session ID in its GVC issuer database 19’ for later retrieval.

The GVC issuer 13’ retrieves attributes for the user 2 from the IDP server 20 which are stored in the IDP database 21 (step S12.3). The GVC issuer 13’ stores the attributes in memory (step S12.4) and forwards the attributes to the GVC holder 67 (step S12.5). The GVC holder 67 creates a random subject identifier, SubjectID (step S12.6) and forwards the subject identifier to the GVC issuer 13’ (step S12.7). The subject identifier may take the form of a sufficiently-long string (e.g., 20 or more) of alphanumeric characters. After retrieving the TLS session ID from the GVC issuer database 19’ and checking the TLS session ID, the GVC issuer 13’ stores the subject identifier in GVC issuer database 19’ (step S12.8). The GVC issuer 13’ sends an instruction to make a physical certificate to the print sever 85 which prints the physical certificate 61 using a printer 86 (step S12.9). The physical certificate 61 includes a machine-readable optical label 63, such as a QR code, containing the identity of the GVC holder 67 and the subject identifier. The reverse may hold the attributes of the user. Once it has received confirmation that the certificate 61 has been printed, the GVC issuer 13’ sends confirmation to the GVC holder 67 (step S12.10). The GVC holder 67, using the attributes, creates a VC skeleton 5 in the GVC holder database 69 storing the URL of the issuer, the subject identifier, and the JSON object (step S12.11) and sends confirmation to the web browser 75 that registration has been successfully completed (step S12.12).

Referring to Figure 13, a second verifiable credentials system 1’ is shown.

The second verifiable credentials system 1’ is similar to the first verifiable credentials system 1 (Figure 1). The second system 1’, however, includes a remote (or “cloud- based”) GVC holder 67 instead of a VC holder 11 (Figure 1) on the user’s device 6 (Figure 1).

As shown in Figure 13, the system 1’ includes a VC verifier 39 and VC verifier database 40 which in this case is provided by a verifier service 9’. The system 1’ includes a policy server 42 and a policy database 43 which stores tables 98 which includes entries 87, each entry 87 including a policy match 88 and an associated policy 8. The policy match 88 takes the form of a verb-noun pair, such as “enter A&E” or “buy alcohol”, where the noun may be the subject or object. Other policy match formats may be used.

Verifying entities 101, such as hospitals and supermarkets, have certificate reading devices 70 which are used to read the physical certificate 61. The reading devices 70 take the form of a mobile phone, tablet computer or other form of general-purpose computing device, although they maybe a dedicated (i.e., purpose-built) computing device.

A reading device 70 comprises a processor 105, memory 106, data storage 107, user input 108, a display 109, a network interface 110 and a reader 111, which preferably takes the form of a camera, but can take the form of, for example, a barcode reader.

The device 70 runs a verifier application 112 (or “verifier app”) having settings 113 appropriate to the verifying entity 101. In particular, the settings 113 includes its identity (or “service provider address”) in the form of a URL, the identity of the policy server 42, also in the form of a URL, and the policyMatch parameter 88 that should be sent to it. Referring also to Figures 14, 15A and lB, a process by which a reading device 70 is able to obtain and display a selective subset 7_A, 7_B of attributes 7 in a relevant verifiable credential 5_A, 5_B will now be described.

The physical certificate 61 has been registered with the GVC holder 67 using the process hereinbefore described. The machine-readable label 63 contains the URL of the GVC holder 67 and the subject identifier. The certificate reading device 70 opens the verifier app 112, for example, from a home screen, and the user 102 of the certificate reading device 70 is presented with a page 103₁ giving him or her the option to scan the machine-readable label 63, which in this case, is the form of QR code or other optically-read barcode. The verifier app 112 has access to the reader 111, which in this case is a camera, and so the verifier app 112 can display an image 104 captured by the camera 111. The verifier app 112 recognises the label 63 and processes the information contained in the label 63.

The verifier app 112 reads the label 63 (step S14.1). The verifier app 112 informs the user 102 of progress via a screen 103₂ which informs the user 102 that it is retrieving credentials 5_A, 5B.

The verifier app 112 performs TLS mutual authentication with the GVC holder 67 and then sends a “GET VC” request to the GVC holder 67 to get a verifiable credential to match its policy (step S14.2). The “Get VC” request includes the URL of the service provider 101 (i.e., the verifying entity), authentication credentials containing the subject identifier SubjectID, the identity of the policy server 42 and a policy match parameter 88, such as, for example, “enter A&E”, indicating its policy 8. The GVC holder 67 checks whether a verifiable credential for the URL of the service provider already exists (step S14.3).

If a verifiable credential does not exist, then the GVC holder 67 retrieves the policy 8 from the policy server 42 using the policy match 88 (step S14.4). The GVC holder 67 extracts the subject identifier from the authentication credentials (step S14.5) and uses the policy and the subject identifier to retrieve a matching skeleton from the GVC holder database 69 (step S14.6). If there is no matching skeleton, then the GVC holder 67 returns an error to the verifier app 112 (step S14.7).

If there is a matching skeleton 5, then the GVC holder 67 performs TLS mutual authentication with the GVC issuer 13’ and sends a request for the GVC issuer 13’ to issue a verifiable credential matching the policy 8 (step S14.8). The request includes the filtered skeleton 5 and the subject identifier. The GVC issuer 13’ retrieves the user handle from its database 19’ and uses the user handle to retrieve attributes from the IDP server 20 (step S14.9).

The GVC issuer 13’ checks the returned attributes (step S14.10). If the attributes have been updated (in other words, if the returned attributes do not match the attributes contained in the skeleton), then the GVC issuer 13’ sends an error message to the GVC holder 67 informing it that the attributes have been updated, which in turn informs the verifier app 112 that the certificate in no longer valid (step S14.11). Otherwise, the GVC issuer 13’ creates a verifiable credential VC according to the verifier’s policy and bound to the subject identifier (step S14.12) and digitally signs it (step S14.13) and records the activity in an audit log. The verifiable credential VC contains only those attributes AT, AV needed by the verifying entity 101, that is, the attributes specified in the policy.

The GVC issuer 13’ sends the verifiable credential VC to the GVC holder 67 (step S14.14). The GVC holder 67 stores the verifiable credential VC and the URL of the service provider in its database 69 (step S14.15). The GVC holder 67 forwards the verifiable credential VC to the verifier app 112 (step S14.16).

After performing TLS mutual authentication with the VC verifier 39, the verifier app 112 requests an access decision from the VC verifier 39 using the policy match, the verifiable credential VC, the Boolean attribute Atts (step S14.18). The verifier app 112 informs the user 102 of progress via a screen 103₃, namely that it is validating the credential.

The VC verifier 39 verifies the signature of the verifiable credential VC (S14.19). The VC verifier 39 parses the verifiable credential VC and creates a corresponding skeleton (step S14.20). The VC verifier 39 stores the skeleton in the VC verifier database 40 together with the URL of the VC issuer 4’ (steps S14.21 & S14.22). The VC verifier 39 retrieves the matching policy from the policy server 42 using the policy match (step S14.23). If there is no matching policy, then the VC verifier 39 informs the verifier app 112 that there is no match. Otherwise, the VC verifier 39 retrieves the matching skeleton from the VC verifier database 40 using the policy (steps S14.24 & S14.25).

Upon successfully identifying a matching VC skeleton (step S14.26), the VC verifier 39 sends confirmation to the verifier app 112 that access has been granted (step S14.27).

In turn, the verifier app 112 informs the user 102 via a screen 103₄ (step S14.28). The verifier app 112 can display the relevant verifiable credential 5_A, 5_B including a subset of the attributes 7_A, 7_B if the Boolean attributes Attn is TRUE.

In the second verifiable credentials system T, the subject identifier, SubjectID, is used instead of the ephemeral key 12_PU, 12_PR (Figure 1) for the user 2 and VC holder 11 (Figure 1). This is because the GVC holder 67 is unable to bind an ephemeral key to the user 2. Accordingly, the GVC holder 67 does not generate a verifiable presentation VP 10. Nevertheless, the GVC holder 67 acts like a VC holder 11 (Figure 1) and authenticates to a VC issuer, namely GVC issuer 13’, and obtains a selectively-disclosed verifiable credential VC, this time bound to the unique subject identifier, SubjectID, rather than to an ephemeral key. The GVC holder 67 then provides the verifiable credential VC to the VC verifier 39.

Device-to-device machine-readable labels

Referring to Figure 16, a third verifiable credentials system 1” is shown.

The third verifiable credentials system 1” is similar to the first verifiable credentials system 1 (Figure 1). For example, the user 2 has a user device 6 which includes a VC holder 11 and a VC holder database 33. The user device 6, however, also includes a wallet application 77, although the VC holder 11 and the wallet application 77 may be combined in one application. The third system 1” is similar to the second verifiable credentials system T (Figure 13). For example, the system 1” has a verifier service 9’ which includes a VC verifier 29 and a verifier database 28. The third system 1” is also similar to the second system 1’ (Figure 13) in that there are verifying entities that can ask the user 2 to provide credentials. The verifying entity uses a device 70’ which displays a machine-readable label 122, for example in the form of a QR code, which includes the identity 123 of the policy server 42 and a policy match 88 which is used by the user’s device 6 to obtain the policy 8 from the policy server 42. A printer 143 can be used to print out a physical document 144 which includes the label 122. In return, the user’s device 6 displays a machine-readable label 133, for instance in the form of a QR code, which provides a pointer 134 to a verifiable presentation 10 which is provided by a relay service 141 which includes a relay server 142 and a relay server database 143.

The relay service 141 can help enable the disclosure of credential content which is not size limited. Even though a label (such as a QR code) has a limited data capacity (currently 2953 bytes for model 2 QR codes), the content can include photos which exceed this limit, even for jpeg greyscale thumbnail images.

The registration user 2 registers for a verifiable credential 3 in the same way as hereinbefore described in relation to Figure 3. Referring also to Figures 16, 17A and 17B, a process by which a reading device 70 is able to obtain and display attributes 7 in a verifiable credential 3 will now be described.

The wallet app 77 and the verifier app 112 are opened on the user’s device 6 and the verifying user’s device 70 respectively.

The verifier app 112 displays, on display 109, a label 122 in the form of a QR code, which is presented to the camera 31 or other form of reader of the user’s device 6 (step S17.1). In a similar way to described hereinbefore, the wallet app 77 has access to the camera and so the wallet app 77 can display an image (not shown) captured by the camera 31. The wallet app 77 recognises the label 122 and processes the information contained in the label 122. The label 122 contains the identity of the policy sever 32, a policy match and authentication credentials. The wallet app 77 sends a request for verifiable presentation VP to the VC holder 11 which is on the same device (step S17.2). The request for verifiable presentation VP includes the identity of the service provider, provided by the verifier app 112, the identity of the policy server 42, the policy match and the authentication credentials.

The VC holder 11 checks the VC holder database 33 to determine whether a verifiable presentation VP already exists (step S17.3). For example, a verifiable presentation VP may already exist if the user has recently accessed this service provider before. If a verifiable presentation VP does not exist (step S17.4), then the VC holder 11 creates a new entry in the VC holder database 33 (step S17.5) and obtains verifiable credentials VCs from the relevant VC issuers 27 and creates a verifiable presentation VP in substantially the same way as hereinbefore described with reference to Figures 5 and 6 (steps S17.5 to S17.15).

If a verifiable presentation VP exists or is created, then the VC holder 11 includes the authentication credentials in the VP and signs it and then forwards the verifiable presentation VP to the wallet app 77 (step S17.19). In turn, the wallet app 77 sends the verifiable presentation VP to the relay server 32 to be stored (step S17.20). The relay service returns the exact storage location of the verifiable presentation VP to wallet app 7 (step 17.21).

The wallet app 77 displays on display 31, a label 133 in the form of a QR code, which is presented to the camera 111 or other form of reader of the verifying user’s device 70 (step S17.22). In a similar way to described hereinbefore, the verifier app 112 has access to the camera 111 and so the verifier app 112 can display an image (not shown) captured by the camera 111. The verifier app 112 recognises the label 133 and processes the information contained in the label 133. The label 133 contains a pointer to the verifiable presentation VP including the identify of relay server 142. The verifier app 112 gets the verifiable presentation VP from the relay server 142 (step S 17.23).

The verifier app 112 requests an access decision from the VC verifier 39 using the policy match parameters PolicyMatch, the verifiable presentation VP, Boolean attributes Atts in substantially the same way as hereinbefore described with reference to Figure 5 (steps S17.24 to S17.33).

Upon successfully identifying matching VC skeletons (step S17.34), the VC verifier 39 sends confirmation to the verifier app 112 that access has been granted along with the attributes of user 2 if Boolean attributes Atts was set to TRUE (step S17.35). In turn, the reader user 102 of the verifier app 112 tells the user 2 of the wallet app 77 that his or her credentials are good (step S17.36).

Modifications It will be appreciated that various modifications may be made to the embodiments hereinbefore described. Such modifications may involve equivalent and other features which are already known in the design, manufacture and use of verifiable credentials and component parts thereof and which may be used instead of or in addition to features already described herein. Features of one embodiment maybe replaced or supplemented by features of another embodiment.

Although an optically- readable label is described, other forms of labels and other forms of label reading could be used, such as, for example, by barcode scanning, by RF communication, e.g., BlueTooth (RTM) or near-field communication, or even by sound. Although claims have been formulated in this application to particular combinations of features, it should be understood that the scope of the disclosure of the present invention also includes any novel features or any novel combination of features disclosed herein either explicitly or implicitly or any generalization thereof, whether or not it relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems as does the present invention. The applicants hereby give notice that new claims may be formulated to such features and/or combinations of such features during the prosecution of the present application or of any further application derived therefrom.

Claims

1. A method, comprising: reading a machine-readable label; · determining, from the machine-readable label, an identity of a verifiable credential holder and a subject identifier for a user; sending, to the verifiable credential holder, a request for a verifiable credential, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, and a policy match parameter for identifying the policy and the subject identifier allowing the verifiable credential holder to retrieve the verifiable credential from a verifiable credential issuer for the user; receiving, from the verifiable credential holder, the verifiable credential containing personal attributes of the user; sending, to a verifiable credential verifier for the service, a validation request which includes the verifiable credential and the policy match parameter; receiving, from the verifiable credential verifier, a reply to the validation request; and displaying an outcome and/or the verifiable credential in dependence on the reply.

2. The method of claim l, further comprising: performing mutual authentication with the verifiable credential holder before sending the request for the verifiable credential.

3. The method of claim 1 or 2, wherein the validation request further comprises a

Boolean attribute for instructing the verifiable credential verifier to whether to include the personal attributes in the reply to the validation request.

4. A method, comprising: · receiving, from a remote device, a request for a verifiable credential for a user, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, and a policy match parameter for identifying the policy and the subject identifier for allowing the verifiable credential holder to retrieve the verifiable credential from a verifiable credential issuer for the user; · retrieving the policy from the policy server according to the policy match parameter; retrieving the verifiable credential for the user from a verifiable credential issuer according to the policy; and sending the verifiable credential to the remote device.

5. The method of claim 4, further comprising: performing mutual authentication with the remote device before receiving the request for the verifiable credential.

6. The method of claim 4 or 5, further comprising: · performing mutual authentication with the verifiable credential issuer before retrieving the verifiable credential from the verifiable credential issuer.

7. The method of any one of claims 4 to 6, further comprising, during a registration phase: · sending a registration request to the verifiable credential issuer, the registration request identifying a user; receiving, from the verifiable credential issuer, attributes for the user; generating a random number and using the random number as the subject identifier for the user; · sending the subject identifier to the verifiable credential issuer; and storing a verifiable credential skeleton comprising the attributes, the verifiable credential skeleton linked with the verifiable credential issuer and the subject identifier.

8. A method, comprising, during a registration phase: · sending a registration request to a verifiable credential issuer, the registration request identifying a user; receiving, from the verifiable credential issuer, attributes for the user; generating a random number and using the random number as the subject identifier for the user; · sending the subject identifier to the verifiable credential issuer; and storing a verifiable credential skeleton comprising the attributes, the verifiable credential skeleton linked with the verifiable credential issuer and the subject identifier.

9. The method of any one of claims 1 to 8, wherein the machine-readable optical label is a QR code.

10. The method of any one of claims 1 to 9, wherein the verifiable credential comprises a set of attributes, optionally wherein the set of attributes comprises zero, one or more or a set of attribute types and corresponding attribute values, a set of embedded attribute types and corresponding attribute values.

11. The method of any one of claims 1 to 10, wherein the request for verifiable credential includes information for later identifying a response to the request.

12. A method, comprising: · receiving a request from a verifiable credential holder, the request including a verifiable credential skeleton containing a set of attributes and a subject identifier; retrieving the set of attributes from an identity provider server using the subject identifier; comparing the attributes retrieved from the identity provider server with the set of attributes contained in the verifiable credential skeleton to determine a match; and upon a positive determination, creating a verifiable credential containing the set of attributes, wherein the verifiable credential is bound to the subject identifier, and sending the verifiable credential to the verifiable credential holder.

13. The method of claim 12, further comprising, during a registration phase prior to receiving the request: receiving a registration request from the verifiable credential holder, the registration request identifying a user; retrieving attributes for the user from the identity provider server; · sending the attributes for the user, to the verifiable credential holder; receiving the subject identifier from the verifiable credential holder; storing the subject identifier linked to the attributes; and sending the identity of the verifiable credential holder and the subject identifier to a print server for printing a physical certificate for the user.

14. A method, comprising, during a registration phase: receiving a registration request from a verifiable credential holder, the registration request identifying a user; retrieving attributes for the user from an identity provider server; · sending the attributes for the user, to the verifiable credential holder; receiving the subject identifier from the verifiable credential holder; storing the subject identifier linked to the attributes; and sending the identity of the verifiable credential holder and the subject identifier to a print server for printing a physical certificate for the user.

15. Computer program code comprising instructions, which when executed by at least one processor, causes the at least one processor to perform the method of any one of claims 1 to 14.

16. A computer program product comprising a machine-readable medium, optionally, a non-transitory machine-readable medium, storing thereon the computer program code of claim 15.

17. A device operable as a verifying device, the device comprising: at least one processor; · memory; display; a reader for reading a machine-readable label; and a verifier application; wherein the device is configured, during a resource access phase: · to read the machine-readable label; to determine, from the machine-readable label, an identity of a verifiable credential holder and a subject identifier for a user; to send, to the verifiable credential holder, a request for verifiable credential, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, and a policy match parameter for identifying the policy and the subject identifier for allowing the verifiable credential holder to retrieve verifiable credential from a verifiable credential issuer for the user; to receive, from the verifiable credential holder, the verifiable credential containing personal attributes of the user; · to send, to a verifiable credential verifier for the service, a validation request which includes the verifiable credential and the policy match parameter; to receive, from the verifiable credential verifier, a reply to the validation request; and to display an outcome and/or the verifiable credential(s) in dependence on the reply.

18. A server operable as a verifiable credential holder, the server comprising: at least one processor; and memory; the server configured, during a resource access phase: · to receive, from a remote device, a request for a verifiable credential for a user, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, and a policy match parameter for identifying the policy and the subject identifier for allowing the verifiable credential holder to retrieve verifiable credentials from a verifiable credential issuer for the user; · to retrieve the policy from the policy server according to the policy match parameter; to retrieve the verifiable credential for the user from a verifiable credential issuer according to the policy; and to send the verifiable credential to the remote device.

19. A server operable as a verifiable credential holder, the server comprising: at least one processor; and memory; the server configured, during a registration phase: · to send a registration request to a verifiable credential issuer, the registration request identifying a user; to receive, from the verifiable credential issuer, attributes for the user; to generate a random number and using the random number as the subject identifier for the user; · to send the subject identifier to the verifiable credential issuer; and to store a verifiable credential skeleton comprising the attributes, the verifiable credential skeleton linked with the verifiable credential issuer and the subject identifier.

20. The server of claim 19, further configured, during a resource access phase: · to receive, from a remote device, a request for a verifiable credential for a user, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, and a policy match parameter for identifying the policy and the subject identifier for allowing the verifiable credential holder to retrieve the verifiable credential from a verifiable credential issuer for the user; · to retrieve the policy from the policy server according to the policy match parameter; to retrieve the verifiable credential for the user from a verifiable credential issuer according to the policy; and to send the verifiable credential to the remote device.

21. A server operable as a verifiable credential issuer, the server comprising: at least one processor; and memory; the server configured, during a resource access phase: to receive a request from a verifiable credential holder, the request including a verifiable credential skeleton containing attributes and a subject identifier; to retrieve attributes from an identity provider server using the subject identifier; to compare the attributes retrieved from the identity provider server with the attributes contained in the verifiable credential skeleton to determine a match; and · upon a positive determination, to create a verifiable credential containing the attributes, wherein the verifiable credential is bound to the subject identifier, and sending the verifiable credential to the verifiable credential holder.

22. A server operable as a verifiable credential issuer, the server comprising: · at least one processor; and memory; the server configured, during a registration phase: to receive a registration request from a verifiable credential holder, the registration request identifying a user; · to retrieve attributes for the user from an identity provider server; to send the attributes for the user, to the verifiable credential holder; to receive the subject identifier from the verifiable credential holder; and to store the subject identifier linked to the attributes; and to send the identity of the verifiable credential holder and the subject identifier to a print server for printing a physical certificate for the user.

23. The server of claim 21, further configured, during a resource access phase: to receive a request from a verifiable credential holder, the request including a verifiable credential skeleton containing attributes and a subject identifier; · to retrieve attributes from an identity provider server using the subject identifier; to compare the attributes retrieved from the identity provider server with the attributes contained in the verifiable credential skeleton to determine a match; and upon a positive determination, to create a verifiable credential containing the attributes, wherein the verifiable credential is bound to the subject identifier, and sending the verifiable credential to the verifiable credential holder

24. A system comprising: the device of claim 17; the server of claim 18 or 20; · the server of claim 21 or 23; and a network interconnecting the device and servers.

25. The system of claim 24, further comprising: a server operable as a verifiable credential verifier.

26. The system of claim 24 or 25, further comprising: a server operable as a policy server to store and retrieve a policy in a policy database.

27. A system comprising: the server of claim 19 or 20; the server of claim 22 or 23; and a print service comprising a print server and a printer.

28. The system of any one or claims 24 to 27, further comprising: a server operable as a identify provider server to store and retrieve attributes in an identify provider database.

29. A method, comprising · receiving, from a requester, a request to register for a verifiable credential, the request including an identity of a verifiable credential issuer and an authentication parameter; sending a request to register for the verifiable credential to the verifiable credential issuer, the request including the authentication parameter; · receiving, from the verifiable credential issuer, a request to create a FIDO key pair, the request including a challenge; sending a request to create a FIDO key pair to a local FIDO authenticator, the request including the challenge; receiving, from the local FIDO authenticator, an attestation object containing a public FIDO key; · sending a response to the verifiable credential issuer, the response including the public FIDO key; receiving, from the verifiable credential issuer, attributes for the user; in response to user input selecting at least some of the attributes, creating verifiable credential skeletons including selected attributes; and · sending confirmation of registration to the requester.

30. The method of claim 29, wherein the requester is a web browser.

31. A method, comprising: · receiving, from a verifiable credential holder, a request to register for a verifiable credential, the request including an authentication parameter; sending a request to register for the verifiable credential to an identity provider server; receiving, from the identity provider server, a user handle; · sending a FIDO challenge to the verifiable credential holder; receiving, from the verifiable credential holder, a response to the challenge, the response including the public FIDO key; sending a request for attributes to the identity provider server, the request including the user handle; · in response to receiving the attributes, sending the attributes to the verifiable credential holder.

32. A method, comprising: receiving a request for a verifiable presentation from a requester, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, a policy match parameter for identifying the policy, and an authentication parameter; determining whether a verifiable presentation exists for the service according to the policy match parameter; and · upon a negative determination: generating an ephemeral key pair comprising an ephemeral public key and an ephemeral private key; requesting the policy from the policy server; requesting, from at least one verifiable credential issuer, verifiable credential(s) bound to the ephemeral public key, the attributes selected according to the policy; creating a verifiable presentation including the verifiable credential(s) and the authentication parameter; and storing the verifiable presentation; · upon a position determination: retrieving the verifiable presentation; and replacing a previous authentication parameter in the verifiable presentation with the authentication parameter; signing the verifiable presentation with the ephemeral private key; and · sending the verifiable presentation to the requester.

33. The method of claim 32, wherein requesting the verifiable credential(s) comprises: sending the ephemeral public key signed with the ephemeral private key to the verifiable credential issuer; and receiving the verifiable credential(s) from the verifiable credential issuer, wherein the verifiable credential(s) comprises a set of attributes attached to the public key.

34· The method of claim 32 or 33, wherein the set of attributes are a subset of attributes held in an identifier provider database.

35. The method of any one of claims 32 to 34, wherein the requester is browser application.

36. The method of claim 35, wherein the browser application is configured, in response to receiving the verifiable presentation, to forward the verifiable presentation to a web server.

37· The method of any one of claims 32 to 34, wherein the requester is wallet application.

38. The method of claim 37, wherein the wallet application is configured, in response to receiving the verifiable presentation, to forward the verifiable presentation to a remote server for storage and to generate a pointer to the verifiable presentation at the remote server.

39. The method of claim 38, wherein the wallet application is further configured to present a label which includes the pointer for reading by another device.

40. A method, comprising: presenting a machine-readable label comprising an identity of a policy server containing a policy for a service, a policy match parameter for identifying the policy, and an authentication parameter; reading a machine-readable label which includes a pointer to a verifiable presentation at the remote server; retrieving the verifiable presentation from the remote server; and sending, to a verifiable credential verifier for the service, a validation request which includes the verifiable presentation and the policy match parameter; receiving, from the verifiable credential verifier, a reply to the validation request; and displaying an outcome and/or the verifiable credential(s) in dependence on the reply.

41. Computer program code comprising instructions, which when executed by at least one processor, causes the at least one processor to perform the method of any one of claims 29 to 40.

42. A computer program product comprising a machine-readable medium, optionally, a non-transitory machine-readable medium, storing thereon the computer program code of claim 41.

43. A module operable as a verifiable credential holder, configured, during a registration phase: in response to receiving, from a requester, a request to register for a verifiable credential, the request including an identity of a verifiable credential issuer and an authentication parameter, to send a request to register for the verifiable credential to the verifiable credential issuer, the request including the authentication parameter; in response to receiving, from the verifiable credential issuer, a request to create a FIDO key pair, the request including a challenge, to send a request to create a FIDO key pair to a local FIDO authenticator, the request including the challenge; in response to receiving, from the local FIDO authenticator, an attestation object containing a public FIDO key, to send a response to the verifiable credential issuer, the response including the public FIDO key; in response to receiving, from the verifiable credential issuer, attributes for the user, to prompt the user to select attributes; and in response to user input selecting at least some of the attributes, to create verifiable credential skeletons including selected attributes; and to send confirmation of registration to the requester.

44. A server operable as a verifiable credential issuer, the server comprising: at least one processor; and memory; the server configured, during a registration phase: in response to receiving, from a verifiable credential holder, a request to register for a verifiable credential, the request including an authentication parameter, to send a request to register for the verifiable credential to an identity provider server; in response to receiving, from identity provider server, a user handle, to send a FIDO challenge to the verifiable credential holder; in response to receiving, from the verifiable credential holder, a response to the challenge, the response including the public FIDO key, to send a request for attributes to identity provider server, the request including the user handle; and in response to receiving the attributes, to send the attributes to the verifiable credential holder.

45. A device, the device comprising: at least one processor; and memory; wherein the device is configured: in response to receiving a request for a verifiable presentation from a requester, the request including an address of a service to be accessed, an identity of a policy server containing a policy for the service, a policy match parameter for identifying the policy, and an authentication parameter, to determine whether a verifiable presentation exists for the service according to the policy match parameter; and upon a negative determination: to generate an ephemeral key pair comprising an ephemeral public key and an ephemeral private key; to request the policy from the policy server; to request, from at least one verifiable credential issuer, verifiable credential(s) bound to the ephemeral public key, the verifiable credential(s) containing attributes selected according to the policy to create a verifiable presentation including the verifiable credential(s) and the authentication parameter; and to store the verifiable presentation; upon a position determination: to retrieve the verifiable presentation; and to replace a previous authentication parameter in the verifiable presentation with the authentication parameter; to sign the verifiable presentation with the ephemeral private key; and to send the verifiable presentation to the requester.

46. A device, comprising: at least one processor; memory; a display (109); and a reader or interface for reading a machine-readable readable label; wherein the device is configured: to present a machine-readable label comprising an identity of a policy server containing a policy for a service, a policy match parameter for identifying the policy, and an authentication parameter; to read a machine-readable label which includes a pointer to a verifiable presentation at the remote server; to retrieve the verifiable presentation from the remote server; and to send, to a verifiable credential verifier for the service, a validation request which includes the verifiable presentation and the policy match parameter; to receive, from the verifiable credential verifier, a reply to the validation request; and to display an outcome and/or the verifiable credential(s) in dependence on the reply.

47. A system comprising: · the device of claim 45; the device of claim 46; the remote server; and a network interconnecting each device with the remote server.