A method of digitally authenticating a user's health or travel status

Abstract

A method of digitally authenticating a user's health or travel status, the method comprising: sending a certificate representative of health or travel document data associated with a user to a verifying entity; the verifying entity carrying out verification on the certificate and, if the certificate is verified, providing a credential based on the verified certificate; and authenticating the user associated with the health or travel document data based on the credential.

Description

[0001] A METHOD OF DIGITALLY AUTHENTICATING A USER’S HEALTH OR TRAVEL

[0002] STATUS

[0003] FIELD OF THE INVENTION

[0004] The present invention relates to a method of digitally authenticating a user’s health or travel status. In addition, the present invention relates to a method of digitally authenticating a user’s health or travel status performed at a user device, an authenticator, and a verifying entity.

[0005] BACKGROUND OF THE INVENTION

[0006] Authentication of a user or passenger’s clearance, heath check and admissibility status can be beneficial and indeed be required in several scenarios. For example, at pre-departure when a passenger wishes to apply for a travel authorisation, create an Airline Frequent Flyer account, perform a flight check-in, self-bag drop, lounge access, outbound security, duty free shopping, self-boarding at departures, border crossing at arrivals or a transportation hub such as an airport or train station, hire a car, check-in a hotel, avail incountry services (car rentals) or attend an event, a passenger may be required to pass an identity, admissibility, boarding or an event entry pass check in order to proceed. This may include proving identity, travel authorisation, valid boarding pass, valid entry pass, vaccination status or recent test result. A health check may be made when attempting to gain access to a public venue such as a restaurant or a bar.

[0007] A user or passenger’s identity is needed and authenticated throughout the journey at various touchpoints. The identity is checked by authenticating the travel document such as a passport or a National ID card. A passenger may present their identifier to a government Travel Authorisation (ETA / eVisa) through online channels and other necessary travel documents to a verifier such as an airport check-in desk and the result is verified manually by the staff. This method results in large amounts of vulnerable personnel sensitive data being stored centrally. In addition, such methods are not standardized, there exists a lack of interoperability of digital solutions, and the methods require an internet connection to perform verification. Other existing techniques include using a proprietary application on a mobile device which may be based on a wallet on the device and performing a look up into a decentralized database such as a distributed ledger.

[0008] It is therefore desirable to provide a method of authentication overcoming these drawbacks.

[0009] SUMMARY OF THE INVENTION

[0010] The invention is defined by the independent claims to which reference should now be made. Optional features are set forth in the dependent claims.

[0011] Existing verification methods using central databases having personnel sensitive information such as identity (biographic and / or biometric) and sensitive health data are particularly vulnerable to attacks such as DNS spoofing. A verifier may be unsure that the consulted website is the intended source of data, and an internet connection is required at the time of verification. Inventors of the present invention have appreciated the need for an ecosystem that can facilitate exchange of sensitive information between entities such as airlines, airports, governments and in-country partners such as hotels, and car rentals without a centralised database containing sensitive personal information.

[0012] The inventors of the present invention have also appreciated the need for authentication methods such as travel identity document, travel authorisation, health pass, airline and airport membership, hotel and event entry pass status authentication methods that can be performed offline while providing only the necessary data to the relevant verifying parties. That is, personnel or other necessary data may be represented in the form of certificates, and a verified certificate may be provided to an authenticator in the form of a credential, rather than the presentation of the actual document itself on which the credential is ultimately based. This advantageously provides a zero-knowledge proof, or in other words, questions regarding physical travel document data associated with a passenger may be answered without revealing the data itself. This also advantageously provides a separation between trust and data in that the passenger is authenticated without having to explicitly provide data to the verifier.

[0013] The inventors have yet further appreciated the ability to manage verification of a certificate representative of personnel or travel data in real-time. In other words, a credential based on a verified certificate may be revoked if considered to be no longer compliant. Arrangements of the present disclosure provide solutions to manage a user or passenger’s health and travel status. Arrangements disclosed herein enable entities such as airlines to perform the pre-boarding checks and confirm a passenger’s membership status, airports may then validate the boarding and membership status for airport services, and governments may perform pre-clearance checks pre-departure and admissibility checks at arrivals. Arrangements also provide solutions for individuals to claim their identity or other statuses and conveniently share that status to be able to provide an easy and convenient check-in process at, or access to, services within an ecosystem such as hotels, car rentals, and attending events.

[0014] According to an aspect of the present invention, there is provided a method of digitally authenticating a user’s health and / or travel status, the method comprising: sending a certificate representative of health or travel document data associated with a user to a verifying entity; the verifying entity carrying out verification on the certificate and, if the certificate is verified, providing a credential based on the verified certificate; and authenticating the user associated with the health or travel document data based on the credential. The health or travel document data may be collectively termed travel authorisation data, and the method may similarly be for digitally authenticating a user’s travel authorisation status.

[0015] Arrangements disclosed herein will be described in examples with respect to a passenger, health and travel document data associated with a passenger, and a passenger device. However, it will be appreciated that the described examples are applicable to a user, health and travel document data associated with a user, and a user device. A passenger is used as an example of a user, such as when the user travels through a transportation hub such as an airport.

[0016] Health data may non-exhaustively include, for example, a test result such as a PCR test result or antigen test result, and / or proof of vaccination or vaccination status. Significantly, the certificate is representative of the health data and, in some embodiments, does not comprise the passenger’s health data. Similarly, all personnel data may not be included in a credential, for example, the travel authorisation or a membership credential may not comprise all of the passport biographic and biometric data. The data included in the credential may be varied, which may depend on the required used of the credential. For example, a hotel check-in or an event entry may require fewer personnel data points than a travel authorisation (such as for an airline) or a membership for airport services. In this way, only the necessary information is disclosed, and sensitive, vulnerable data need not be transferred between entities.

[0017] The certificate may comprise a data schema and definition describing the data fields required by the various stakeholders within the travel continuum or ecosystem to adequately prove a passenger’s fit to travel status. The credential may comprise a data schema and credential definition describing the data fields required by relevant government agencies, airlines, airports, partners, and interested parties to adequately prove a passenger’s trusted traveller status (that is, that they meet the authentication requirements to travel or enter a particular organisation).

[0018] The certificate and or the credential may comprise identity (biographic and / or biometric) data associated with the passenger’s identity. In this way, it can be verified that the passenger presenting the credential is the valid holder of the credential. That is, the authentication may comprise verifying that a passenger providing the credential is the passenger associated with the presented data. The passenger’s digital identity information may be biographic and / or biometric data associated with the passenger, or a reference to a travel document (passport, identification (ID) card, driver license, social security number, International Civil Aviation Organisation (ICAO) digital travel credential (DTC), etc.).

[0019] In some embodiments, the credential may be a verifiable credential. One or more additional credentials may be derived from a DTC embedded on the verifiable credential. The one or more additional credentials may be derived for use in subsequent verification steps in the travel continuum. For example, a hotel, a car rental agency, or an event may not need to know the full identification information about a passenger as found on a passport, but only given name, surname, and passport number for example. This may be achieved due to the “selective disclosure” of a verifiable credential, a feature allowing only particular information contained within the credential to be disclosed.

[0020] Authentication is based on the credential provided following verification of the certificate. Therefore, similarly to the certificate, the credential may not contain the passenger’s health or travel data but instead only the relevant information needed for authentication of the passenger’s health or travel status. The certificate is not shared with the authenticator, only to the verifying authority, who provide the credential for authentication. In other words, the authenticator can request only the data required for authentication, and not the entire credential, thereby protecting privacy. In some embodiments, no data can be sent to the authenticator without approval from the passenger.

[0021] The credential used for authentication of the passenger’s status may be termed a trusted traveller credential, which may be a trusted traveller credential for identity, travel authorisation, airline boarding pass, memberships, hotels, and events, etc.

[0022] The verification by the verifying entity may be based on one or more rules. In more detail, complex rules or business rules can be implemented at the time the credential is issued. The rules may be implemented through machine readable governance which allows policies to be implemented quickly within a decentralized secure system. For example, the rules may non-exhaustively include determining whether one or more of: the passenger has a valid travel authorisation; the passenger has given consent; ; the passenger data has been verified; the passenger is pre-cleared and has been issued a boarding pass.

[0023] Advantageously, providing such an authentication method enables an entity or authority to manage a credential or pass for an individual in real-time. That is, a credential may be initially authenticated in accordance with described embodiments. However, in response to a change in one or more criteria, the credential may be revoked. For example, if a data issuer is not trusted anymore (for example: the passport / national ID card signing key was compromised and the passport has been revoked; the passport was revoked by the issuing country; airline membership card has expired or has been blocked by the airline / airport), if a credential was issued under particular conditions which subsequently change (for example, an airline has put a passenger on a no-fly list), or if a particular vaccine is not considered effective anymore, the corresponding issued credential can be revoked immediately. In some embodiments, the credential is revoked by the verifying entity. It is particularly advantageous that an authenticating entity performing authentication needs not take any action in response to the changing criteria and revocation of the credential - the credential will be revoked such that it will not pass an authentication.

[0024] Similarly, a certificate representative of a passenger’s health data may initially not be verified by the verifying entity and a credential may not be provided as the certificate and ultimately the passenger’s health status does not meet the particular requirements for verification or satisfy the relevant rules. Criteria may then change, for example the requirements for health data may become lower or more lenient. The verifying entity may, in response to this change, issue the corresponding credential which may then be used for authentication. Again, the authenticating entity need not act.

[0025] Updating or revoking a credential in real time may comprise updating at least one of the one or more rules in response to a change in one or more criteria.

[0026] While verification of the certificate and issuing of the credential have been described with respect to a verifying entity such as an aviation entity, a government entity, or a private entity, it will be appreciated that the verification process may comprise an additional issuing agent carrying out one or more of the steps of issuing the credential to a passenger. That is, the verifying entity may comprise, or may work in conjunction with, an issuing entity or issuing agent. For example, the issuing agent may perform one or more of: displaying a unique identifier such as a QR code, or sending and receiving communication signals such as a Bluetooth signal, for a passenger to establish a secure connection with the issuing agent; receiving identity information about a passenger associated with the health data; matching information regarding the passenger, for example using standard correlation API that may be used to retrieve information about a passenger into a specific IT environment (this may be done by, but may not be limited to, a secure database lookup); formatting information following the data schema and credential definition as published into the distributed ledger; generating and issuing the credential to the passenger over the established secure connection; reporting on credentials issued to passengers; and revoking credentials upon request by the verifying entity or issuer. In the embodiments described herein, it will therefore be appreciated that where a verifying entity is described, or steps performed by a verifying entity are described, said verifying entity may comprise, or work in conjunction with, an issuing agent to carry out one or more steps of the method described.

[0027] In some embodiments, the credential may be provided to an authenticator or authenticating entity using one or more communication or media methods which may include: a unique identifier such as a QR code, Bluetooth low energy (BLE) or Bluetooth classic, Ultra-sonic (uses device’s standard speaker and microphone), or Wi-Fi Direct (ad-hoc network).

[0028] The credential data may be held on a passenger device, such as in the digital wallet of a passenger device. This advantageously enables peer-to-peer authentication of the credential, which provides offline authentication. The inventors of the present invention have appreciated that this is a much-needed condition for broad adoption of decentralized identity. To provide offline authentication, the method may comprise the authenticator accessing an online network to cache decentralized identifiers or trusted issuers. No personal data should be stored in cache from the passenger’s perspective. In this way, when a peer-to-peer offline connection is made between the passenger device and the authenticator, the authenticator has a record of trusted issuers without requiring further connection to an online network, and thus authentication may be performed offline.

[0029] In some embodiments, the authentication comprises one or more of: receiving the credential representative of the passenger’s health and / or travel document data; checking the credential against a distributed ledger; decoding the credential to make sure the credential originated from a trusted source; and automating the process, meaning the authentication can be provided by the authenticator without requiring action from the verifying entity.

[0030] In some embodiments, the method comprises applying a cryptographic signature to the health and / or travel document data to prevent alteration of the data. The authenticator may view the cryptographic signature of the verifying entity or issuer and know that the data has arrived unaltered, and as written to the credential. In this way, security of the data is further improved.

[0031] The method may further comprise receiving the certificate representative of the data associated with the passenger from a data source. For example, a passenger may undergo one or more tests or vaccinations at a health data source such as a test centre, testing laboratory, or vaccination centre, the one or more tests or vaccinations providing the health data through test results or vaccination status. In response, the passenger may receive the certificate representative of the health data. The health data source such as laboratory or clinic may obtain the health data by, for example, collecting a sample from the passenger and linking the sample to the passenger, and subsequently issuing a health check record as proof of the health data such as being tested or vaccinated. This may be achieved by issuing a credential proving, for example, that a test sample has been taken. This may be a third and separate credential from the health credential and trusted traveller credentials.

[0032] Similarly, in some embodiments, when a passenger applies for a travel document such as a Travel Authorisation (ETA / eVisa) through a mobile application or website provided by a destination government’s immigration agency, the passenger shares a digital identity credential (i.e. a trusted traveller credential) and other necessary information. The provided information may then be checked for admissibility in the central immigration systems and a travel authorisation (TA) is issued to the passenger. Therefore, a TA record linked to the passenger’s travel identity is created and subsequently a further travel authorisation credential is issued to the passenger, which may be a fourth credential.

[0033] In some examples, a TA credential of lower assurance level may be created by capturing an image of a visa sticker on a travel document such as a passport and validated against a visa template database. For example, this lower level of assurance for checking valid visas may be adequate for a flight check-in, thereby replacing existing manual checks by staff and advantageously reduces margins for manual errors.

[0034] In some examples, a passenger may sign up for a service such as an frequent flyer program associated with an entity such as an airline. The passenger may complete an online sign up through an airline’s website or application and, upon submission, a passenger record may be created in an airlines central database and a credential may be issued as an AirlinelD, which may be a fifth credential.

[0035] Similarly, in some embodiments, a passenger may sign up for a service such as an airport membership. The passenger may complete an online sign up through an Airport’s website or application and, upon submission, a passenger record may be created in an Airport central database and a credential issued as an AirportID, which may be a sixth credential. Similarly, a seventh credential may be issued upon a successful flight check-in as a boarding pass credential.

[0036] In some examples, a passenger’s identity may be matched to a record such as a laboratory record, immigration record, airlines, airports, or hotel records to ensure the correct passenger is associated with the data and the subsequently issued certificate is associated with the correct passenger. In some embodiments, receiving the certificate may comprise establishing a secure link between the data source and the passenger by a unique identifier associated with the passenger. For example, when a laboratory obtains a passenger’s health data, through a test or sample, or an immigration agency obtains a passenger’s admissibility data through the travel authorisation and DTC, or an airline and airport obtain a passenger’s fit to fly data through the described Airline and Airport IDs, the passenger may first present a unique identifier such as a QR code which may be scanned by the issuer. In this way, confidence is provided that the data is associated with the correct passenger and trust is established between the issuer and the passenger. In some examples, if entities such as airlines and / or airports support biometrics enabled seamless travel at departures and biometrics enabled border control at arrivals, and the passenger has consented to sharing the biometrics while sharing the identity data, the passenger identity (biographic and biometric) are linked with the flight check-in (boarding pass) and government records, and the passenger can simply and conveniently progress through the airport essentially using the face as an identity. By enabling biometrics, an entity such as an airport may provide the functionality and / or infrastructure to perform biometric scanning such as facial recognition scanning at one or more checkpoints on a passenger’s journey through the airport.

[0037] In some embodiments, the certificate representative of health or travel document data is a first certificate, and the method further comprises: sending a second certificate representative of health or travel document data associated with the passenger to the verifying entity; the verifying entity carrying out verification on the second certificate and, if the second certificate is verified, providing a second credential based on the verified second certificate; and authenticating the passenger associated with the health or travel document data based on the second credential.

[0038] In some embodiments, the verifying entity is a first verifying entity and the certificate representative of health or travel document data is a first certificate, and the method further comprises: sending a second certificate representative of health or travel document data associated with a passenger to a second verifying entity; the second verifying entity carrying out verification on the second certificate and, if the second certificate is verified, providing a second credential based on the verified second certificate; and authenticating the passenger associated with the health or travel document data based on the second credential.

[0039] In some embodiments, the providing the credential based on the verified certificate comprises providing an assurance level associated with the credential, the assurance level indicating a level representative of the amount of health or travel document data required for verification.

[0040] In some embodiments, sending the certificate representative of health or travel document data associated with a passenger to the verifying entity comprises sending the certificate via an intermediary entity; providing the credential based on the verified certificate comprises providing the credential via the intermediary entity; and the assurance level is determined by the intermediary entity.

[0041] Exemplary details for integrating the described solution will now be described.

[0042] A Trust Network Controller (TNC) provides a representational state transfer (REST) based application programming interface (API) enabling entities or third parties wishing to issue and / or verify verifiable credentials (VCs). VCs are electronic versions of a user or passenger s details (e.g. passport, visa, or boarding passes) that then can be used to verify that credential in a secure format at various points during a passenger’s journey.

[0043] The REST services are intended to be primarily consumed by any third parties. To support this usage, REST services have been defined to enable the management of connections (between Agents), the issuance and the verification / presentation of VCs including DTCs.

[0044] Functionality is exposed via a secure RESTful API that facilitates the use of VCs and perform operations requested by third parties.

[0045] Base URL

[0046] The high-level URL signature of an API REST service call is https: / / {domain} / api / v2.0 / tnc which is followed by the desired API function, {domain} being the provided domain name for access to the service.

[0047] JSON Web Tokens

[0048] Any call to the REST services provided in the TNC may require the use of a JSON web token. This may be to be triggered before any further interaction with the REST services. Once the token has been returned in response to the API REST service invocation it may be used for all subsequent API REST service calls.

[0049] The token service is a POST type REST invocation.

[0050] Request Path: https: / / {domain} / api / v1.0 / authentication / authenticate

[0051] Request Message (Schema):

[0052] The username and password to use in the authenticate requests will be provided upon request.

[0053] The returned JSON web token must be embedded in the HTTP header as follows:

[0054] Authorization: Bearer: {JSON web token} where: {JSON web token} is the returned token value string from the response. In some examples, tokens obtained in this way are time limited and expire after 24 hours. A mobile application that uses this will need to request a new token before the expiry of the token to ensure no interruption to the mobile application user.

[0055] Response Message (Schema):

[0056] Mime Type

[0057] In this example, all API web service calls require Content-Type: application / json to be set as the mime type.

[0058] Swagger Documentation

[0059] In development / trial / demo environments the swagger documentation will be available and can be accessed using the following url: https: / / {domain} / swagger-ui / index.html This provides all main interfaces, request / response types in Open Api v3.0 format.

[0060] The JSON format can be found at: https: / / {domain} / v3 / api-docs

[0061] Connection REST Services

[0062] The following API REST Service calls are available for use by applications to manage the connections between the mobile applications agent and the TNCs cloud agent. These comprise of the following REST services:

[0063] • Get Connection

[0064] • Delete Connection

[0065] • Get All Connections

[0066] • Get Invitation

[0067] Get Connection

[0068] Use this API to get the connection details from the TNC’s cloud agent for a specific connection.

[0069] The Get Connection service is a GET type REST invocation.

[0070] Request Path: / connection / {connectionld}

[0071] Request Message (Schema):

[0072] {connectionld} - The connection id from the mobile’s agent for which to get connection information for. In this example, this is mandatory and should be provided as part of the request path for the request. No request body is required for this service.

[0073] Response Message (Schema):

[0074] If a valid connection is found in the TNCs cloud agent then a response will be returned similar to the example below:

[0075] If the connection is not found then the following response will be returned:

[0076] Delete Connection

[0077] Use this API to delete a specific connection from the TNC’s cloud agent and the mobile’s agent when the connection is finished with.

[0078] The Delete Connection service is a DELETE type REST invocation.

[0079] Request Path: / connection / {connectionld}

[0080] Request Message (Schema): {connectionld} - The connection id from the mobile s agent for which to delete the connection for. In this example, this is mandatory and should be provided as part of the request path for the request. No request body is required for this service.

[0081] Response Message (Schema):

[0082] If a valid connection is found in TNCs cloud agent and is successfully deleted then the following will be returned:

[0083] If the connection is not found in the cloud agent, then a response will be returned similar to the example below:

[0084] Get All Connections

[0085] Use this API to list all connections that have been made between the mobile’s agent and the TNC’s cloud agent using the specific alias for the users’ mobile phone.

[0086] The Get All Connection service is a GET type REST invocation.

[0087] Request Path: / connection / {alias}

[0088] Request Message (Schema): {alias} - The alias being used to identity the mobile phone, for which to get the connection information for. This is mandatory and is provided as part of the request path for request. For more details on this value, refer to Supported Values table below. No request body is required for this service.

[0089] Response Message (Schema):

[0090] If valid connections are found in the TBCs cloud agent for given alias, then a response will be returned similar to the example below:

[0091] The results are a list of connections details, one record for each connection found. If no connections are found for the given alias, then a response will be returned similar to the example below:

[0092] Get Invitation

[0093] Use this API to obtain a connection invitation from the TNC’s cloud agent, that can be used by the mobile application to establish a connection with the Cloud Agent.

[0094] The Get Invitation service is a GET type REST Invocation.

[0095] Request Path: / invitation / {alias}

[0096] Request Message (Schema):

[0097] {alias} - The alias being used to identity the mobile phone, for which to get a connection invitation for. This is mandatory and is provided as part of the request path for request. For more details on this value, refer to Supported Values table below. No request body is required for this service.

[0098] Response Message (Schema):

[0099] If valid connections are found in the TBCs cloud agent for given alias, then a response will be returned similar to the example below:

[0100] {cloud-agent-domain} - The domain used by the TNC’s cloud agents that is provided for the mobiles’ agent to make DIDComm connections and communications. connection d - the connection id allocated by the TNCs cloud agent to be used in further requests. invitation_url - the URL to use to establish a connection to the TNC’s Cloud agent services from the wallet’s agent.

[0101] Issue VCs REST Services

[0102] The following API Rest service calls are available for applications that need to issue trusted VCs of certain types. These services comprise of the following REST Services:

[0103] • Issue VC

[0104] • Invite and Issue VC

[0105] Issue VC

[0106] Use this API to issue a trusted VC of a particular type containing specific data that then can be used for verification in future. The VC if successfully issued will be placed in the user’s mobile wallet in secure format on acceptance of an offer the given VC. The sending of the offer to the mobile’s agent and the acceptance and issuance of the VC itself is initiated by this request, however the rest of this process is asynchronous to this request. This service is used when a previous connection for the mobiles agent has been made previously using the Get Invitation request for the same alias.

[0107] The Issue VC Service is a POST type REST invocation.

[0108] Request Path: / invitation / {alias}?vcType={vcType}

[0109] Request Message (Schema):

[0110] {alias} - The alias being used to identity the mobile phone, for which to issue the specified VC for. In this example, this is mandatory and is provided as part of the request path for request. For more details on this value, refer to Supported Values table below.

[0111] {vcType} - the type of VC to issue. In this example, this is a mandatory request parameter. Refer to Supported Values table below for more details on this parameter. data - In this example, a mandatory a list of name value pairs and will depend on the type of VC to be issued what the parameters will be. Refer to Supported Values table below for more details on the contents of this type.

[0112] Response Message (Schema):

[0113] If valid connection is found in the TBCs cloud agent for the given alias, and the data supplied is valid in the request then a response similar to example shown below will be returned:

[0114]

[0115]

[0116] The contents of the response will depend greatly on the type of VC being issued. Refer to appendices table below for more detailed examples for different VC types.

[0117] Invite and Issue VC

[0118] Use this API to request a connection invite between the mobiles agent and the TNC’s cloud agent, and once the DIDComm connection is established issue a VC of the specific type - this combines the Get Invitation and Issue VC in one call.

[0119] In this example, the offer and issuance of the will happen as soon as the mobiles agent has established the DIDComm connection to the TNC’s cloud agent and is asynchronous to this request.

[0120] The Issue VC Service is a POST type REST invocation.

[0121] Request Path: / invitation / {alias} / issue-vc?vcType={vcType}

[0122] Request Message (Schema):

[0123] {alias} - The alias being used to identity the mobile phone, for which to get a connection invitation for and issue the VC of the specified type against. This is mandatory and is provided as part of the request path for request. For more details on this value, refer to Supported Values table below.

[0124] {vcType} - the type of VC to issue. In this example, this is a mandatory request parameter. Refer to Supported Values table below for more details on this parameter. data - In this example, a mandatory a list of name value pairs and will depend on the type of VC to be issued what the parameters will be. Refer to Supported Values table below for more details on the contents of this type. Response Message (Schema):

[0125] If valid connection is found in the TBCs cloud agent for the given alias, and the data supplied is valid in the request then a response similar to one shown below will be returned:

[0126] {cloud-agent-domain} - The domain used by the TNC’s cloud agents that is provided for the mobiles’ agent to make DIDComm connections and communications. connectionjd - the connection id allocated by the TNCs cloud agent to be used in further requests. invitation_url - the URL to use to establish a connection to the TNC’s Cloud agent services

[0127] Verify / Presentation of VCs REST Services The following API Rest service calls are available for applications that need to verify and present the contents of a credential to be used in further processing once a VC has been issued. These services comprise of the following REST Services:

[0128] • Request Proof for VC

[0129] • Retrieve Proof for VC

[0130] Request Proof for VC

[0131] Use this API to request a proof for a VC, verify that a given VC is valid (i.e. has not been revoked or tampered with) and expose the requested fields from the VC to the requesting mobile application.

[0132] The Request Proof for VC service requires a previous connection to have been established between the mobiles’ agent and the TNCs cloud agent service as provided in the Get Invitation request.

[0133] The Request Proof for VC service is a POST type REST invocation.

[0134] Request Path: / request-proof-vc / {alias}?vcType={vcType}

[0135] Request Message (Schema): {alias} - The alias being used to identity the mobile phone, for which to request proof for. This is mandatory and is provided as part of the request path for request. For more details on this value, refer to Supported Values table below.

[0136] {vcType} - the type of VC that proof is being requested for. This is a mandatory request parameter. Refer to Supported Values table below for more details on this parameter, attributes - A list of the attributes retrieved from the given VC. This is dependent on the type of VCs for which the proof request is being requested. Refer to Supported Values table below for additional information on this parameter. If the attribute list is empty then all the attributes will be requested for the proof and exposed once accepted by the user, auto-verify - true / false indicator which determines whether the VC on the requesting of proof should also be verified as part of the request.

[0137] Response Message (Schema):

[0138] If valid connection is found in the TBCs cloud agent for the given alias, and the VC is valid and has not been tampered with or revoked then a response such as the example shown below is returned: presentation_exchange_id - this is the presentation exchange id used by the TNCs cloud agent for the current presentation of proof. This will be used in the Retrieve Proof for VC request.

[0139] Retrieve Proof for VC

[0140] Use this API to retrieve the proof for a specified VC, used when approval of access to the VC has been given by the User and will retrieve the specified fields from the Request Proof for VC request that had been issued previously. The mobile application can use the fields exposed from the presentation within its own processing.

[0141] The Retrieve Proof for VC service is a GET type REST invocation.

[0142] Request Path: / retrieve-proof-vc / {exchangeld}?vcType={vcType}

[0143] Request Message (Schema):

[0144] {exchangeld} - The presentation exchange id returned in the response to a Request Proof for VC request. In this example, this is mandatory and is provided as part of the request path for request.

[0145] {vcType} - the type of VC that the retrieval of proof is being requested for. This is a mandatory request parameter. Refer to Supported Values table below for more information on this parameter.

[0146] No request body is required for this service.

[0147] Response Message (Schema):

[0148] If a valid presentation is found for the given presentation exchange id then a response such as the example shown below is returned: attributes - a list of name / value pairs with the name of the attribute in the VC and the value of the attribute in the VC as value. This list will only contain those attributes from the VC that were requested in the original Request Proof for VC request and will depend on the VC type that the proof request was for. Refer to Supported Values table below for more information on this parameter.

[0149] Supported Values The following Supported Values table shows supported values for certain fields or more information on parameters making up a request value.

[0150] Error Handling

[0151] The following general HTTP codes will be used to indicate problems encountered during processing of a request for a service and apply to all REST services.

[0152] A general format of an error corresponding to code 400 may be as follows. A Bad Request response from a service is as follows (there could be additional fields in there dependent on the response):

[0153] General properties for the fields returned are: success - true / false indicator whether the request was successful or not - will be set to false in case of error. error - error object (see more details below) provide more details on the failure that occurred. This will only be set when success field is false. In some examples, not all fields will be filled in for all errors. A breakdown of the error object may be as follows: timestamp - the time in milliseconds when the error occurred (since midnight 1stJanuary 1970). status - a status code representing the type of error that has been raised. If not set default as -1. error - The specific error that occurred - default is “unsupported service”. message - A message providing more information on the error that occurred - default is “the service is not implemented yet”. field - indicates which field in the request caused a problem or for which url this problem occurred - default is “n / a”.

[0154] The following table shows common error status codes used in the services and may not be exhaustive:

[0155] Additional information regarding data attributes and values may be as follows.

[0156] The following table describes the element names and values that can be used in the data object of the Issue VC and Invite and Issue VC request types when the vcType field is set to dtc_type1_identity.

[0157] The Issue VC service request type in this case may be provided in accordance with the following example:

[0158] Attribute names and values

[0159] The following table describes the attribute names and values that are used in the various attribute objects in the responses to Issue VC and Retrieve Proof for VC requests and the names used in the attributes for a Request Proof for VC request, when the vcType field is set to dtc_type1_identity.

[0160] In an example, a Request Proof for VC dtc_type1_identity request may be as follows:

[0161] The response of the Retrieve Proof for VC associated with this presentation exchange may then be as follows:

[0162] It will be understood by the skilled person that the described APIs are merely exemplary.

[0163] In some embodiments, authentication may take place, for example, during one or more of: a TA application for governments agencies, check-in process for airlines, services for an airport, and check-in at a hotel or entry pass for an event. By providing the relevant digital credential, the authentication of the passenger’s identity, health, travel authorisation, fit-to- travel, or membership status may be carried out in addition to typical check-in procedures, conveniently allowing passengers to complete the check-in process including a health and other travel statuses check remotely.

[0164] According to another aspect of the invention, there is provided a method of digitally authenticating a user’s health or travel status, performed at a user device, the method comprising the user device: sending a certificate representative of health or travel document data associated with a user; receiving a credential based on the certificate being verified; and providing the credential for authentication.

[0165] The passenger device may comprise any suitable electronic device such as a mobile device, tablet computer, laptop computer, or the like.

[0166] According to another aspect of the invention, there is provided a user device comprising means for digitally authenticating a user’s health or travel status, the user device comprising: means for sending a certificate representative of health or travel document data associated with a user; means for receiving a credential based on the certificate being verified; and means for providing the credential for authentication.

[0167] The passenger device may be configured to download, install, and run an application for performing one or more of the method steps according to techniques of this disclosure. Such an application may be configured to: receive and store minimal personal information about a passenger (enough to positively identify the individual to an issuer’s system when conducting future interactions) which may be, for example, identity information such as passport / national ID card data (this may be received via passenger input or through communication with a camera of the electronic device which may scan a passenger’s passport / national ID card); generate and display a unique identifier such as a QR code to establish a secure connection with a data source; receive and store a credential issued by the health data source providing that a sample has been taken; receive and store the certificate representative of data associated with the passenger; send the certificate representative of data associated with the passenger to a verifying entity; receive, from the verifying entity, the credential based on the certificate being verified; provide the credential to an authenticator for authentication; and facilitate an identity check to confirm association of the passenger with the credential (and ultimately the health and travel data). Secure connections are established between the passenger device and the verifier, and between the passenger device and the authenticator. The secure connection may be established using the Aries framework connection protocols and DIDComm messaging. Once the connection has been established, all message data exchanged may be cryptographically encoded in such a way that only the two connected parties can decrypt the messages.

[0168] The application may comprise or may be in addition to and used in conjunction with, a digital wallet of an electronic device. For example, one or more of the certificate and credentials referenced herein may be stored, generated, and displayed using a digital wallet of an electronic device.

[0169] Thus, a passenger’s experience is made efficient and convenient through use of an electronic device capable of facilitating the authentication of the passenger’s health and travel status through communication with a data source, a verifying entity, and an authenticator. In addition, such an application may also allow for consolidation of travel documents such as embarkation-disembarkation cards, travel authorisations, and boarding passes by enabling, for example, purchasing of such travel documents through the application. It is particularly advantageous that an authenticating entity such as an airline or a partner organisation associated with the airline may verify clearance to board through the application. That is, a remote check-in process may be conveniently facilitated through the passenger device including health and travel status checks.

[0170] The authenticator may utilize a corresponding application, which may similarly run on a suitable electronic device. The authenticator application may facilitate one or more of: presenting a unique identifier such as a QR code to invite passengers or holders to establish a secure connection with the authenticator; establishing a secure connection to a passenger using Aries framework connection protocols and DIDComm messaging; requesting and receiving presentation of proof attributes, as defined by data schema, published in the distributed ledger over the secure connection; authenticating the credential and ensuring data integrity and valid issuer origin through the use of cryptography and matching DI Ds (Digital I Dentifiers) in the distributed ledger; running business rules used for authentication; and providing a result of authentication and sending result to the passenger over a secure connection.

[0171] According to another aspect of the invention, there is provided a method of digitally authenticating a user’s health or travel status, performed at an authenticator, the method comprising the authenticator: receiving a credential representative of a verified certificate representing health or travel document data associated with a user; and authenticating the passenger associated with the data based on the credential.

[0172] An authenticator or authenticating entity carrying out the authentication may comprise an entity such as an airline check-in desk at a transportation hub or an in-country entity such as a hotel, car rental agency or an event venue configured to receive the credential from the passenger and authenticate the passenger based on the credential. The credential may be provided to the authenticator through one or more communication or media methods which may include: a unique identifier such as a QR code, Bluetooth low energy (BLE) or Bluetooth classic, Ultra-sonic (uses device’s standard speaker and microphone), or Wi-Fi Direct (ad-hoc network). Alternatively, the authenticator or authenticating entity may be a remote entity. That is, authentication may be provided online remotely via a wired or wireless connection, for example, by an airline organisation via an online check-in process or through an application of an electronic device.

[0173] According to another aspect of the invention, there is provided a method of digitally authenticating a user’s health or travel status, performed at a verifying entity, the method comprising: receiving a certificate representative of health or travel document data associated with a user; verifying the certificate and, if the certificate is verified, providing a credential based on the verified certificate. The credential may comprise identity data associated with the user’s identity.

[0174] The methods performed at any of the entities including the passenger device, the authenticator, and the verifying entity, are performed digitally and may comprise one or more features of the methods of digitally authenticating a passenger’s necessary status as described herein. That is, each of the steps of the described methods may be performed or carried out digitally.

[0175] According to another aspect of the invention, there is provided a system for digitally authenticating a user’s health or travel status, the system comprising: a module configured to send a certificate representative of health or travel document data associated with a user to a verifying entity; the verifying entity being configured to carry out verification on the certificate and, if the certificate is verified, providing a credential based on the verified certificate; and a further module configured to authenticate the user associated with the health or travel document data based on the credential.

[0176] The system may comprise one or more modules configured to provide the method of any embodiment described herein. The system may comprise means for performing the method of any embodiment described herein.

[0177] According to another aspect of the invention, there is provided a user device for digitally authenticating a user’s health or travel status, the user device comprising: a module configured to send a certificate representative of health or travel document data associated with a user; a receiving module configured to receive a credential based on the certificate being verified; and a further module configured to provide the credential for authentication. According to another aspect of the invention, there is provided a authenticator for digitally authenticating a user’s health or travel status, the authenticator comprising: a receiving module configured to receive a credential representative of a verified certificate representing health or travel document data associated with a user; and an authenticating module configured to authenticate the user associated with the health or travel data based on the credential. The authenticator may be, or may comprise, an authenticating device.

[0178] According to another aspect of the present invention, there is provided a verifying entity for digitally authenticating a user’s health or travel status, the verifying entity comprising: a receiving module configured to receive a certificate representative of health or travel document data associated with a user; and a verifying module configured to verify the certificate and, if the certificate is verified, providing a credential based on the verified certificate. The verifying entity may be, or may comprise, a verifying device.

[0179] The modules of the above described aspects may comprise a computer or mobile device which may be coupled to a communication network either wireless or via a wired connection.

[0180] According to another aspect of the invention, there is provided computer program for carrying out the method according to embodiments described herein.

[0181] According to another aspect of the invention, there is provided a non-transitory computer- readable medium having stored thereon instructions that, when executed by a processor, cause the processor to perform the steps of the method according to embodiments described herein.

[0182] Arrangements described herein provide a decentralized identity system providing one or more of the following: provision of verifiable data to the government, State, verifying entity or issuing authority; facilitation of issuers to join a decentralized ecosystem and ensure interoperability; compliance on data privacy regulations and provision of a secure authentication method (providing GDPR compliance including avoiding central databases, relying on strong cryptographic standards, and being open source); and be trusted by passengers (ensuring data cannot be controlled by a single organization).

[0183] From the foregoing, it will be appreciated that the mobile communication or device may include a computing device, such as a desktop computer, a laptop computer, a tablet computer, a personal digital assistant, a mobile telephone, a smartphone, an internet enabled television, an internet enabled television receiver, an internet enabled games console or portable games device.

[0184] It will also be appreciated that this invention finds application as a system for processing a user or customer, a device such as a portable device for use by an agent for processing the customer or a device such as a portable device for use by the passenger, as well as a method or computer program for processing the customer or passenger. In addition, this invention finds application as a system for providing services to a customer or user which may be used by an airline agent or other transport services provider agent.

[0185] From the foregoing, it will be appreciated that one or more of the entities including the passenger device, verifying entity, and authenticator or authenticating entity may comprise a computer processor running one or more server processes for communicating with client devices. The server processes comprise computer readable program instructions for carrying out the operations of the present invention. The computer readable program instructions may be, or source code or object code written in or in any combination of suitable programming languages including procedural programming languages such as C, object orientated programming languages such as C#, C++, Java, scripting languages, assembly languages, machine code instructions, instruction-set-architecture (ISA) instructions, and state-setting data.

[0186] The wired or wireless communication networks described above may be public, private, wired, or wireless network. The communications network may include one or more of a local area network (LAN), a wide area network (WAN), the Internet, a mobile telephony communication system, or a satellite communication system. The communications network may comprise any suitable infrastructure, including copper cables, optical cables or fibres, routers, firewalls, switches, gateway computers and edge servers.

[0187] The one or more entities of the decentralised system described above may comprise a Graphical User Interface which may be a Graphical Passenger Interface. Embodiments of the invention may include an on-screen graphical passenger interface. The passenger interface may be provided, for example, in the form of a widget embedded in a web site, as an application for a device, or on a dedicated landing web page. Computer readable program instructions for implementing the graphical passenger interface may be downloaded to the client device from a computer readable storage medium via a network, for example, the Internet, a local area network (LAN), a wide area network (WAN) and / or a wireless network. The instructions may be stored in a computer readable storage medium within the client device.

[0188] As will be appreciated by one of skill in the art, the invention described herein may be embodied in whole or in part as a method, a system, or a computer program product including computer readable instructions. Accordingly, the invention may take the form of an entirely hardware embodiment or an embodiment combining software, hardware and any other suitable approach or apparatus.

[0189] The computer readable program instructions may be stored on a non-transitory, tangible computer readable medium. The computer readable storage medium may include one or more of an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk.

[0190] Exemplary embodiments of the invention may be implemented as a circuit board which may include a CPU, a bus, RAM, flash memory, one or more ports for operation of connected I / O apparatus such as printers, display, keypads, sensors and cameras, ROM, a communications sub-system such as a modem, and communications media.

[0191] In addition, the above detailed description of embodiments of the invention are not intended to be exhaustive or to limit the invention to the precise form disclosed. For example, while processes or blocks are presented in each order, alternative embodiments may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and / or modified. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed in parallel or may be performed at different times.

[0192] The teachings of the invention provided herein can be applied to other systems, not necessarily the system described above. The elements and acts of the various embodiments described above can be combined to provide further embodiments. While some embodiments of the inventions have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the disclosure. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the methods and systems described herein may be made without departing from the spirit of the disclosure.

[0193] BRIEF DESCRIPTION OF THE DRAWINGS

[0194] The invention will now be described in more detail, by way of example, with reference to the accompanying drawings, in which:

[0195] Figure 1 is a schematic diagram illustrating exemplary pathways and functionality of the method for authenticating a user’s health or travel status embodying an aspect of the present invention;

[0196] Figure 2a is a schematic diagram illustrating a user and user device embodying an aspect of the present invention;

[0197] Figure 2b is a schematic diagram illustrating a data source entity, a user device, and a user embodying an aspect of the present invention;

[0198] Figure 2c is a schematic diagram illustrating a verifying entity, a user device, and a user embodying an aspect of the present invention;

[0199] Figure 2d is a schematic diagram illustrating a verifying entity, a user device, and a user embodying an aspect of the present invention;

[0200] Figure 2e is a schematic diagram illustrating a verifying entity, a user device, and a user embodying an aspect of the present invention;

[0201] Figure 3a is a schematic diagram illustrating a user and user device embodying an aspect of the present invention; Figure 3b is a schematic diagram illustrating a verifying entity, a user device, and a user embodying an aspect of the present invention;

[0202] Figure 3c is a schematic diagram illustrating a verifying entity, a user device, and a user embodying an aspect of the present invention;

[0203] Figure 3d is a schematic diagram illustrating a verifying entity, a user device, and a user embodying an aspect of the present invention;

[0204] Figure 4a is a schematic diagram illustrating a health data source entity, a user device, and a user embodying an aspect of the present invention;

[0205] Figure 4b is a schematic diagram illustrating a health data source entity, a user device, and a user embodying an aspect of the present invention;

[0206] Figure 4c is a schematic diagram illustrating a health data source entity, a user device, and a user embodying an aspect of the present invention;

[0207] Figure 4d is a schematic diagram illustrating a verifying entity, a user device, and a user embodying an aspect of the present invention;

[0208] Figure 4e is a schematic diagram illustrating a verifying entity, a user device, and a user embodying an aspect of the present invention;

[0209] Figure 4f is a schematic diagram illustrating a verifying entity, a user device, and a user embodying an aspect of the present invention;

[0210] Figure 5a is a schematic diagram illustrating a authenticator, a user device, and a user embodying an aspect of the present invention;

[0211] Figure 5b is a schematic diagram illustrating a authenticator, a user device, and a user embodying an aspect of the present invention; and

[0212] Figure 6 is a schematic diagram of a system comprising a user; a user device; a verifying entity; and an authenticator embodying an aspect of the present invention. Like features are denoted by like reference numerals.

[0213] DETAILED DESCRIPTION

[0214] An example method for digitally authenticating a user’s health or travel status will now be described in more detail with reference to Figures 1 to 6. In the described examples, the user is a passenger.

[0215] In the following described example, Figure 1 illustrates an overview of two use cases, each of which is described in more detail below. These use cases include: (1) a government travel authorisation application (1001); and (2) airline check-in and departure (1003).

[0216] The first example will be described in relation to a government travel authorisation application 1001 , and particularly a smart path authorisation. In this example, the passenger may create a digital identity through an onboarding processing, which in this example is an electronic Known Your Customer (eKYC) customer onboarding process. The government as an issuer will generate a digital travel credential 1005 (which in this example is an ICAO DTC Type 1) that is stored on a passenger’s device, for example within a wallet 1007 on a passenger’s mobile device. The digital wallet 1007 may be an Aries Bifold wallet, which may be a stand alone secure wallet. The wallet may be configured to receive, stored, and share credentials based on the user’s consent. The DTC 1005 may be a smartpath DTC, which may be used for enrolment into an application such as a smartpath hub.

[0217] The passenger then further begins the travel authorisation application using one of the governments provided online channels (such as a TA mobile application 1009 or using a website). The government, after performing the background checks, will issue a travel authorisation verifiable credential that will include the DTC 1005. The mobile application 1009 may provide any of the associated functionalities with respect to mobile applications described herein including scanning and validating a travel document such as a passport, or requesting information from the digital wallet 1007. The application 1009 may issue a DTC into a separate mobile wallet, and issue a travel authorisation into a separate mobile wallet.

[0218] As has been described in detail herein, and as will be described in more detail below, the government travel authorisation may provide a user or passenger with one or more of the following functionalities 1008: travel authorisation; check-in; self-bag drop; security screening; outbound border clearance; airline lounge access; retail and wayfinding; boarding; inbound border clearance; and onward travel clearance.

[0219] The second example illustrated in Figure 1 includes airline check-in and departure. Passenger travel authorisation is provided through an airline website 1011 and a mobile application which in this example is a wallet application 1013.

[0220] The airline website 1011 provides one or more of the following functionalities in accordance with embodiments described herein: issuing airline ID credential; login with airline ID credential; requesting DTC from wallet application 1013; request travel authorisation credential from wallet application 1013; and issue biometric boarding pass credential simulating enrolment to smart part. The wallet application 1013 provides one or more of the following functionalities in accordance with embodiments described herein: scan and validate travel document such as a passport; initialize with DTC; receive airline ID credential; share existing travel authorisation credential; scan and validate travel document such as a VISA; issue and share travel authorisation credential; receive and display biometric boarding pass.

[0221] As has been described in detail herein, and as will be described in more detail below, the airline-related process 1003 may provide a user or passenger with one or more of the following functionalities 1008: airline loyalty (for example in relation to a passenger’s airline membership status); check-in; self-bag drop; security screening; airline lounge access; retail and wayfinding; and boarding.

[0222] The system uses the Linux Foundation for Public Health, Cardea project ( https: / / www. Ifph . io / projects / cardea / ) as the open-source library, SITA is a founding member, for the technical framework. The Linux Foundation’s open-source Indy Hyperledger project (https: / / www.hyperledger.org / use / hyperledger-indy) provides the capabilities of a distributed ledger. The system does not rely on databases to store any Personally Identifiable Information (PH) data and as the verifiable credential is held by the traveller in their digital wallet (typically installed on an electronic device such as a smart phone) it does not contravene any GDPR requirements. The distributed ledger stores no actual data portions of the verifiable credential, instead, using DIDs (Digital IDentifiers) and cryptographic keys the data is securely exchanged between consenting parties. The overseeing authority issues the trusted traveller verifiable credential based upon a set of machine-readable governance rules. The governance rules are the basis upon which a trusted traveller verifiable credential is issued, and in the system being described, a verifiable credential which has a particular status is the defining trigger for the issuance of a trusted traveller verifiable credential. The system is flexible enough to add, modify and remove the governance rules in accordance with new or changing circumstances. In this respect, the governance framework will allow overseeing authorities to react to fluid situations. Verifiable credential revocation in real-time is supported. This may be in addition or alternate to other means of determining the validity of the verifiable credential, such as expiration date validation or positive / negative status checks.

[0223] Each of the examples illustrated in Figure 1 will now be described in more detail.

[0224] Government travel authorisation 1001 example:

[0225] Figure 2a illustrates a passenger 101 , who in this example is a passenger intending to travel and needs a travel authorisation. Initially, the passenger 101 downloads a government application in accordance with described embodiments onto their electronic device, which in this example is a mobile phone 103. Having downloaded the application, the passenger 101 scans a travel document, which in this example is a passport 105, using a camera application on the mobile device 103. The application recognises identity data from the passport 105 and conveniently stores the identity data in the form of a digital travel credential (DTC) Type 1 in the application. This may be basic identity information such as name and date of birth or may include all identity information included on the passport. The passenger 101 may additionally or alternatively input identity information into the application manually through a passenger interface of the mobile device 103.

[0226] Figure 2b illustrates the provision of a DTC verifiable credential 207. That is, the passenger 101 receives a DTC verifiable credential (VC) 207 (or certificate representative of travel document data) issued by the government agency 108 (which may be, for example, an immigration agency or department) through a secure connection based on the travel document data associated with the passenger that is stored in the application. The passenger reviews the DTC VC 107 and accepts to save it in the digital wallet app on the mobile device 103.

[0227] Figures 2c to 2e further illustrate the verification procedure in accordance with described embodiments. The passenger 101 begins the travel authorisation (TA) application through the government application on mobile device 103. The application establishes a secure connection with the wallet app on the mobile device 103 and navigates to the wallet app and requests the DTC VC 107. The passenger 101 reviews the request and provides consent to share the DTC VC 107 with the requesting entity (which here is the government 208) application. The application receives the DTC VC 107 and provides this to the government 108 for verification, taking the identity information from it in the TA application process.

[0228] As illustrated in Figure 2d, on submission of the TA application to the government 108 including the DTC VC 107 through a secure connection 205, the government 108 verifies the credential 107, and issues a TA verifiable credential 211. In Figure 2e, the passenger 101 receives the TA verifiable credential 211 issued by the government agency (immigration) 108. The passenger reviews the TA verifiable credential 211 and accepts to save it in the digital wallet app 109 on the mobile device 104.

[0229] The credential 211 may then be used for authorisation in accordance with embodiments described herein.

[0230] Airline 1003 example:

[0231] In another example, a passenger enrols for a frequent flyer loyalty program associated with an airline which includes signing in on an airline website. This process will be broadly described, and then described in more detail with respect to Figures 3a to 3d. In this process the passenger performs an eKYC customer onboarding process including providing passenger data or travel document data to receive a digital travel credential (ICAO DTC Type 1) (which may be a certificate as described herein) that is stored within a wallet on the passenger’s device. Further, the passenger provides additional information to the airlines. Having verified the certificate, the airline as the verifying entity may then issue an AirlinelD verifiable credentials that is sent and stored in the wallet.

[0232] Subsequently, the passenger associated with the travel data may be authenticated by an authenticating entity. In this example, at a flight check-in, the passenger is asked to share the AirlinelD and the DTC. In a passenger’s journey through an airport, credentials may be authenticated and additional credentials may be issued. In this example, the passenger provides consent for sharing the credentials with biometric information in response to a request from the airline. The biometric information is sent to the airline systems for verification and, upon verification that the passenger may board a flight, a boarding pass credential is issued which, in this example, also contains a passenger’s membership status with the associated airline and the DTC comprising biometric information.

[0233] The biometric information and DTC is then populated in a flight gallery which may be used for authentication. The passenger can now proceed through the departure touchpoints which may include: self-bag drop, security screening, outbound immigration, lounge access, retail and wayfinding and boarding. Where the touchpoints comprise facial recognition technology, the passenger’s face is matched against the flight gallery (which also stores the DTC) as a boarding pass. If the touchpoints at airport departure are not biometric enabled (they do not provide for facial recognition) the passenger can pass through each touchpoint scanning a QR code generated in the passenger’s mobile device. Similarly, the biometric information and DTC is also populated in an arrival gallery that is matched for in-bound immigration (eGates) to check for inadmissible / flagged passengers.

[0234] In more detail, the arrangement illustrated in Figure 3a illustrates an example related to the described airline use case. That is, Figure 3a illustrates a passenger 301, who in this example is a passenger intending to travel through an airport using an airline service which may be a SITA airline service. Initially, the passenger 301 downloads an airline application in accordance with described embodiments onto their electronic device, which in this example is a mobile phone 303. Having downloaded the application, the passenger 301 scans their passport 305 using a camera application on the mobile device 303. The application recognises identity data from the passport 305 and conveniently stores the identity data in form of a DTC Type 1 in the application. This may be basic identity information such as name and date of birth or may include all identity information included on the passport. The passenger 301 may additionally or alternatively input identity information into the application manually through a passenger interface of the mobile device 303.

[0235] Figure 3b illustrates the provision of a DTC verifiable credential 307. The passenger 101 receives a DTC verifiable credential 307 (or certificate representative of travel document data) issued by the airline 308 through a secure connection based on the travel document data associated with the passenger that is stored in the application on the mobile device 303. The passenger reviews the DTC VC 307 and accepts to save it in the mobile application on the mobile device 303.

[0236] Figures 3c and 3d further illustrate the verification procedure in accordance with described embodiments. In this example, Figure 3c illustrates a passenger 301 signing up for a frequent flyer ID account / AirlinelD. In particular, the mobile phone 303 of the passenger 301 establishes a secure connection 306 with a SITA Air website 309 of the SITA Air airline 308. The secure connection is established by the mobile phone 303 generating a QR code 304 as a unique identifier, and the SITA Air website 309 scanning and recognising the QR code 304. Establishing the secure connection also allows the SITA Air airline 308 to request for the DTC Type 1 and additional information required for creating the AirlinelD 301. The passenger 301 receives a notification to share the DTC VC 307 and upon review of the requested data fields that passenger 301 provides consent to share.

[0237] Figure 3d illustrates the DTC VC received through the secure connection 306 and verified by the SITA Air website 309. An AirlinelD verifiable credential 310 is issued by the SITA Air website 309 to the passenger 301. The Airline ID verifiable credential 310 is received by the passenger 301 on the mobile device 303 as a notification. The AirlinelD credential 310 is stored in the application on the mobile device upon review from the passenger 301.

[0238] The verified credentials may then be used in an example authentication procedure in which an authenticator (which in this example is a SITA Air airline 308) establishes an initial connection with the passenger 301. In particular, the mobile device 303 of the passenger 301 establishes a secure connection with the SITA Air airline website 309 of the airline 308. In this example, the secure connection is established by the mobile phone 303 generating another QR code as a unique identifier, and the SITA Air website 309 scanning and recognising the QR code. Establishing the secure connection also allows the airline 308 to securely request for the DTC VC and an AirlinelD to verify the passenger’s identity. The Air website 309 may then retrieve the passenger’s membership status (such as membership with an airline or airport) such that any subsequent transaction with an airline or its partners can be correctly and securely linked to the traveller’s identity.

[0239] In an example scenario, the passenger 301 is checking in for a flight. The SITA Air website 309 similarly produces a QR code and the mobile device 303 scans the QR code. Having established the secure connection, the passenger 301 provides an DTC VC and AirlinelD. The SITA Air website 309 receives the credentials and issues a further credential which is a boarding pass credential associated with the passenger 301 through the established secure connection. The boarding pass credential is linked or tied to the passenger’s identity and, in this example, provides a proof of fit-to-fly and use airport services based on the passenger’s membership status. For example, an in-app notification may appear for the passenger allowing them to accept the boarding pass credential, which is then stored in the on the mobile device 104 through the application 203. The boarding pass credential may then allow the passenger to conveniently pass through an airport.

[0240] If the airport departure is biometric-enabled (for example, provides the functionality of facial recognition) the DTC VC and biometric information is saved in a flight gallery. The passenger 301 can therefore can proceed through the departure touchpoints of an airport implementing facial recognition, conveniently allowing the passenger to use their biometric information (i.e. their face) as a boarding pass. In an alternative example, if the passenger 301 has not provided consent to share their biometric information then the passenger 301 must present the QR code in the boarding pass at the touchpoints of an airport.

[0241] In another example, the passenger’s travel authorisation status may include the passenger’s health status. However, the following described example may applied similarly to any appropriate travel authorisation status as described herein.

[0242] Figure 4a illustrates a user 401 , who in this example is a passenger intending to travel through an airport using an airline service. Figure 4a also illustrates a health data source (which in this example is a testing lab 408) establishing an initial connection with the passenger 401. In particular, the mobile phone 403 of the passenger 401 establishes a secure connection with a lab device 405 of the testing lab 408. In this example, the secure connection is established by the mobile phone 403 generating a QR as a unique identifier, and the lab device 405 scanning and recognising the QR code. Establishing the secure connection also allows the testing lab 408 to verify the passenger’s identity such that any subsequent testing can be correctly and securely linked to the traveller’s identity. The lab device 405 could similarly produce the QR code and the mobile device 403 scan the QR code.

[0243] Having established the secure connection, the traveller 401 provides a sample 407 to the testing lab 401 as illustrated in Figure 4b. This may be, for example, a PCR test 407. Figure 4c then illustrates the testing lab 408 issuing a health test record or certificate 409 representative of the health data associated with the user through the established secure connection, the health data including information such as the test result or vaccination status. The certificate 409 is tied to the traveller’s identity and, in this example, provides proof of having been tested. The passenger then awaits remote delivery of results, which are initially pending. Conveniently, the mobile application (and the certificate 409) can be updated automatically once a result such as the PCR result is confirmed. For example, an in-app notification may appear for the passenger allowing them to accept the results, which are then stored in the on the mobile device 403 through the application.

[0244] Figure 4d illustrates verification of the traveller’s certificate 409 provided by the health data source. A secure online connection 406 is established between the passenger’s device 403 and the verifier, which in this example is a government health department 410, which is the government health department 410 associated with the passenger’s destination of travel. The certificate 409 issued by the testing lab 408 is provided to the government health department 410 via the secure online connection 406. Significantly, the certificate 409 is only representative of the health data associated with the passenger 401. That is, the certificate 409 provides only the relevant information needed by the government health department 410 to be able to verify the traveller’s health data and does not necessarily include the passenger’s health data.

[0245] Having received the certificate 409, the government health department 410 is able to verify the certificate 409 and, if verified, provide a credential 411 based on the verified certificate 409 over the secure online connection 406. In this example, the verification process is automated based on a set of machine-readable governance rules forming the basis of the verification. These rules may be requirements for permitting entry into the passenger’s country of destination. For example, the rules may, for example, include determining whether one or more of: insurance has been purchased; consent has been given; a health question(s) has been completed; or health data has been verified. If the certificate 409 representative of the traveller’s health data satisfies the appropriate rules, the government health department 410 verifies the certificate 409 and issues the credential 411 via the secure online connection 406 as illustrated in Figure 4e. In this example, the credential is termed a happy traveller card 411 , signifying that the passenger is permitted to travel to their desired destination as verified by the government health department 410 of that country based on their requirements for travel. As illustrated in Figure 4f, the credential 411 is stored in the mobile device 403 in a digital wallet of the mobile device 403. The credential 411 does not comprise the user’s health data but comprises identity data of the user allowing the credential to be associated with the user. As previously explained, in some embodiments, the verifying entity may comprise or work in conjunction with an issuing agent to issue the credential 411.

[0246] Figures 5a and 5b illustrate the authentication process of a passenger or traveller attempting to gain entry to, access, or use a service of a particular entity. In this example, the traveller 401 wishes to progress through an airport to use an airline service, but the method may equally be applied to a passenger wishing to gain entry to an entertainment venue or restaurant.

[0247] Figure 5a illustrates the traveller 401 establishing a secure peer-to-peer connection 505 with the authenticator, which here is an airline 503. A secure connection 505 is established between the mobile device 403 and an authenticator device 501 associated with the airline 503. To establish the secure connection, the authenticator device 501 generates a unique identifier 507 which is recognised by the mobile device 403. In this example, this process is performed remotely over an online internet connection accessed by both the mobile device 403 and authenticator device 501, the connection between the two parties being established over TCP / IP and the data being exchanged directly. All communications are encrypted using only the DID and verification keys known to each party.

[0248] Having established the secure connection 505, the credential 411 is provided to the airline 503 for authentication. At the time of authentication, where a traveller is requested to present proof of a credential, the data is exchanged over a securely established communication channel using the Aries Hyperledger protocols and DIDComm messaging standards. The traveller cannot alter the contents of the digital wallet as the data is cryptographically signed, so that any tampering of the data will render it invalid to the authenticator. The authenticator, once they have requested and received the proof presentation (a cryptographic representation of the verifiable credential), performs a verification lookup of the distributed ledger to verify the DID and credential definition components. The result of this distributed ledger lookup is used to determine the outcome of the authentication, that is, either authenticated or not. In this way, the traveller 401 is able to conveniently perform online check-in with their airline 503.

[0249] The open-source Aries Hyperledger protocols and DIDComm messaging standards are used to provide the lower layers of the trust framework and a set of governance rules are injected into the system to provide a level of trust ensuring that only authorised issuers have provided the credentials. Cryptographically secured messages over communication channels guarantee the privacy of all data exchanges between parties.

[0250] The separation of data (the verifiable credential information) and trust (who has issued the verifiable credential) is a feature of the system that allows an authenticator to be confident that a set of verifiable credentials has been provided to adequately satisfy the governance rules put in place by an appropriate overseeing authority (usually, but not limited to, a governmental agency).

[0251] The airline 503 confirms that the credential 411 is valid and has been issued by the government health department 410. The traveller 401 is then granted access to use the airline service. For example, because of authentication, the traveller is provided with a boarding pass permitting the traveller 401 to board an aircraft.

[0252] The methods described herein use the term authentication for the process of an entity determining whether a passenger or traveller may be permitted entry, access, or use of a service. However, it will be appreciated that this may be termed verification, verifying the passenger’s health or travel status from the credential issued by, for example, the government authority. The authenticator may similarly be termed a verifier.

[0253] Figure 6 illustrates an overview of the entities which may be involved in the verification and authentication of a passenger’s travel authorisation status.

[0254] An identity holder 601 , which may be the passenger according to any of the embodiments described herein, requires an electronic verifiable credential. In this example, the credential will be provided by an issuer 603 which may be a verifying entity according to embodiments described herein.

[0255] The issuer 603 is known and trusted by the holder 601. In this example, the issuer 603 represents a government entity. The level of trust between the holder 601 and the issuer 603 may determine the level of trust which will be associated with an issued credential.

[0256] An intermediary entity 605 may be present between the holder 601 and the issuer 603, which may govern the trust of organisations or entities issuing credentials. In this example, the trust network 605 is a travel trust network such as a SITA travel trust network. Communication with the intermediary entity 605 and the issuer 603 may comprise personal data management managed by the issuer.

[0257] The holder 601 initiates a request to the issuer 603 for a credential or digital identity. In this example, the issuer 603 has some prior knowledge of the holder 601. The issuer 601 authenticates the holder’s request in the manner described herein. If the request is successful, a verifiable credential is issued to the holder 601 by the issuer 603. This process may be automated, or may require at least one manual verification step between the holder 601 and the issuer 603.

[0258] The issuer 603 records the issuance of credentials with the intermediary entity 605, and a cryptographic verifiable credential and data associated with the credential is issued to the holder 601. Keys to validate the credentials may be published to a distributed ledger 612, which may comprise a trust store 607 such as a verifiable data registry (VDR). In this example, the keys are stored by the intermediary entity hosting a node 610 of the larger VDR 607. In another example, the keys may be stored with the intermediary entity 605 and not in a distributed ledger. Communication to and from the VDR may comprise cryptographic data.

[0259] When challenged to identify themselves, for example in an airport, a restaurant, or event venue, the holder 601 exchanges the issued credential with an authenticator 609 in accordance with embodiments described herein. The holder 601 chooses the information to exchange. In this example, the signed credential includes details of the trusted intermediary entity 605. Communication between the holder 601 and the authenticator 609 or authenticating entity may comprise the provision of personally identifiable information (PH).

[0260] The credential is authenticated using the cryptographic keys stored in the node 610 of the trust store 607 hosted by the intermediary entity 605. The holder 601 is then able to use the relevant service for which their travel authorisation status has been authenticated.

[0261] Methods described herein employ a trust framework as described in the Trust Over IP Foundation’s (https: / / trustoverip.org / ) principles of digital trust. The framework embodies the use of verifiable credentials that may be held by an individual in a cryptographically secure digital wallet. The verifiable credentials can be self-asserted or issued by a trusted issuing agent and authenticated by interested parties. The digital trust framework uses a governance framework to ensure the parties involved in the issuance of the credentials to be subsequently authenticated can be trusted. Each role (verifying entity and issuing agent, passenger, and authenticator) operates independently. Governance provides the basis for trusted decisions based on legislation, policy, regulations, process, and reputation.

[0262] Privacy is preserved, and security is enhanced via open standards which enable both independence and scale. This may be provided by one or more of: private cryptographic peer to peer connections (surveillance resistant); standard cryptographic data exchange protocols between peers (impersonation resistant); the holder is in control of providing the verifier with proof of data (privacy preserving); the verifier verifies data from the holder without contacting the issuer (surveillance resistant); and the verifier determines what data they need to verify from what set of issuers (fraud resistant).

[0263] The described example embodiment comprises online authentication. A particularly advantageous feature of techniques of this disclosure is that it is possible to perform offline verification, where both the holder and verifier are not connected to the internet or network. The availability of offline verification is predicated on the fact that in order to receive a verifiable credential the traveller 201 must have at one stage, been online. It is when the traveller 101 is online that certain, crucial, records can be obtained and stored in a cache on traveller’s device 204. Similarly, the authenticator 502 must have, at one previous point in time, been online and retrieved and cached the relevant records. The records that may be cached locally are the schema definition and the credential definition, both of which are held on the distributed ledger. The traveller and authenticator can perform an authentication over a communication channel using the cached versions of the records instead of having to call out to the distributed ledger. Establishment of the communication channel is achieved using a peer-to-peer connection such as Bluetooth connectivity, rather than TCP / IP as no network is available.

[0264] The use of open-source standards, such as W3C verifiable credentials, Aries / Usra Hyperledger, DIDComm, and Trust over IP ensures a level of interoperability with other solutions built upon the same foundations. As an example, a verifiable credential issued by the system can be accepted, stored, and presented using a digital wallet provided by an enterprise other than the one created by system described. If the Aries protocols and DIDComm messaging standards are adhered to, there is no lock-in to using a specific digital wallet implementation. Embodiments of the present invention have been described. It will be appreciated that variations and modifications may be made to the described embodiments within the scope of the present invention. For example, the described embodiments are described in relation to a passenger. The embodiments described herein may be similarly applied to a user, with the passenger being used as an example of a user.

[0265] Although the above example has been described with reference to a system for use in the aviation industry, it will be clear from the foregoing explanation embodiments of the invention may advantageously be used in any environment where a health status check needs to be performed, such as a restaurant, cinema, shopping centre, or transportation hub such as rail or bus station.

Claims

CLAIMS:

1. A method of digitally authenticating a user’s health or travel status, the method comprising: sending a certificate representative of health or travel document data associated with a user to a verifying entity; the verifying entity carrying out verification on the certificate and, if the certificate is verified, providing a credential based on the verified certificate; and authenticating the user associated with the health or travel document data based on the credential.

2. The method of claim 1 wherein the credential comprises identity data associated with the user’s identity.

3. The method of claim 2 wherein the credential does not comprise the user’s health data.

4. The method of any preceding claim wherein the verification is based on one or more rules, and preferably the method further comprises updating at least one of the one or more rules in response to a change in one or more criteria, and more preferably wherein the one or more rules comprise determining whether or not one or more of: the user has purchased insurance; the user has given consent; the user has completed one or more health questions; and health data has been verified.

5. The method of claim 2 wherein the identity data comprises one or more of: biographic data associated with the user; biometric data associated with the user; and reference to a travel document.

6. The method of claim 5 wherein authenticating the user based on the credential comprises authenticating the user based on the biographic data or biometric data associated with the user.

7. The method of claim 6 wherein authenticating the user based on the biographic data or biometric data associated with the user comprises authenticating the user using facial recognition.

8. The method of any preceding claim further comprising applying a cryptographic signature to the health data to prevent alteration of the health or travel data.

9. The method of any preceding claim further comprising receiving the certificate representative of health or travel data from a data source, and preferably wherein the receiving the certificate comprises establishing a secure link between the data source and the user by a unique identifier associated with the user.

10. The method of any preceding claim further comprising, if the certificate is not verified, determining the user as non-compliant and not authenticating the user.

11. The method of any preceding claim further comprising revoking the credential if it is determined that the certificate should no longer be verified.

12. The method of any preceding claim further comprising deriving one or more additional credentials from a digital travel card, or any other travel document embedded on the credential.

13. The method of any preceding claim wherein the verifying entity is a government authority; and / or the authenticating is performed by an authenticator, and preferably the authenticator is an airline or a partner organisation associated with the airline.

14. The method of any preceding claim wherein the certificate representative of health or travel document data is a first certificate, the method further comprising: sending a second certificate representative of health or travel document data associated with the user to the verifying entity; the verifying entity carrying out verification on the second certificate and, if the second certificate is verified, providing a second credential based on the verified second certificate; and authenticating the user associated with the health or travel document data based on the second credential.

15. The method of any of claims 1 to 13 wherein the verifying entity is a first verifying entity and the certificate representative of health or travel document data is a first certificate, and the method further comprises: sending a second certificate representative of health or travel document data associated with a user to a second verifying entity; the second verifying entity carrying out verification on the second certificate and, if the second certificate is verified, providing a second credential based on the verified second certificate; andauthenticating the user associated with the health or travel document data based on the second credential.

16. The method of any preceding claim wherein the credential is a travel authorisation credential.

17. The method of any preceding claim wherein the providing the credential based on the verified certificate comprises providing an assurance level associated with the credential, the assurance level indicating a level representative of the amount of health or travel document data required for verification.

18. The method of claim 17 wherein: sending the certificate representative of health or travel document data associated with a user to the verifying entity comprises sending the certificate via an intermediary entity; providing the credential based on the verified certificate comprises providing the credential via the intermediary entity; and the assurance level is determined by the intermediary entity.

19. A system for digitally authenticating a user’s health or travel status, the system comprising: a module configured to send a certificate representative of health or travel document data associated with a user to a verifying entity; the verifying entity being configured to carry out verification on the certificate and, if the certificate is verified, providing a credential based on the verified certificate; and a further module configured to authenticate the user associated with the health or travel document data based on the credential.

20. A method of digitally authenticating a user's health or travel status, performed at a user device, the method comprising the user device: sending a certificate representative of health or travel document data associated with a user; receiving a credential based on the certificate being verified; and providing the credential for authentication.

21. A user device for digitally authenticating a user’s health or travel status, the user device comprising:a module configured to send a certificate representative of health or travel document data associated with a user; a receiving module configured to receive a credential based on the certificate being verified; and a further module configured to provide the credential for authentication.

22. A method of digitally authenticating a user’s health or travel status, performed at an authenticator, the method comprising the authenticator: receiving a credential representative of a verified certificate representing health or travel document data associated with a user; and authenticating the user associated with the health or travel data based on the credential.

23. An authenticator for digitally authenticating a user’s health or travel status, the authenticator comprising: a receiving module configured to receive a credential representative of a verified certificate representing health or travel document data associated with a user; and an authenticating module configured to authenticate the user associated with the health or travel data based on the credential.

24. A method of digitally authenticating a user’s health or travel status, performed at a verifying entity, the method comprising: receiving a certificate representative of health or travel document data associated with a user; verifying the certificate and, if the certificate is verified, providing a credential based on the verified certificate.

25. A verifying entity for digitally authenticating a user’s health or travel status, the verifying entity comprising: a receiving module configured to receive a certificate representative of health or travel document data associated with a user; and a verifying module configured to verify the certificate and, if the certificate is verified, providing a credential based on the verified certificate.

26. A computer program for carrying out the method of any of claims 1 to 18, 20, 22, and 24.

Images