Verification of Identities in Distribution Chain
Overview
Leveraging organizational digital identity (public/private key cryptography and electronic certificates issued by recognized industry bodies) participants of the distribution chain can generate the necessary tokens to be authenticated in EASD messages even when these have been relayed by intermediaries before reaching the intended recipient.
The industry bodies responsible for issuing IDs and their respective Verifiable Credentials (VCs) will define the processes supporting the lifecycle of the VCs. They will also be responsible for making available the necessary material to verify the VCs and their revocation status.
Definitions
Identifier - a combination of characters alpha and/or numeric used to identify an organization (e.g Passenger Agency IATA code).
Credential - an electronic certificate used in the process of proving ownership of an identifier (e.g. W3C Verifiable Credential).Â
Signature - cryptographic operation used in the process of proving ownership of an identifier and participation in a given transaction.Â
Intermediary - means distribution chain participant between the buyer and the retailer, e.g. sellers and distributors (including consolidator or aggregator).
Participant roles
Seller (as defined in (Distribution Chain )
Intermediary
Carrier (as defined in (Distribution Chain )
Preconditions
This applies only to system-to-system interaction (i.e. no graphical interfaces)
Each participant of the distribution chain is equipped with:
An identifier (e.g. IATA accreditation code, TIDS - Travel Identity Designator Service, TTC - Travel Tech Coding, Airline Designator or bilaterally agreed codes).
A W3C compliant DID (Decentralized ID) and DID document - except the participant directly connected to the Carrier which does not need to include verifiable presentation (see https://www.w3.org/TR/did-core/ for details).
A W3C compliant VC (Verifiable Credential) issued by recognized industry bodies containing the identifier to be used in the transaction - except the participant directly connected to the Carrier which does not need to include verifiable presentation (see for details).
Identifiers:
"96546752"
DID:
did:web:bpa-api.demo.adaptivespace.io
DID Document:
{
"@context": [
"https://www.w3.org/ns/did/v1"
],
"id": "did:web:bpa-api.demo.adaptivespace.io",
"verificationMethod": [
{
"id": "did:web:bpa-api.demo.adaptivespace.io#key-1",
"type": "Ed25519VerificationKey2018",
"controller": "did:web:bpa-api.demo.adaptivespace.io",
"publicKeyBase58": "6gD8jcLxXEjbVGFqabJ8Sd2dGEJVxbjSU5YAU6yWtw3x"
}
],
"authentication": [
"did:web:bpa-api.demo.adaptivespace.io#key-1"
],
"assertionMethod": [
"did:web:bpa-api.demo.adaptivespace.io#key-1"
],
"service": [
{
"id": "did:web:bpa-api.demo.adaptivespace.io#did-communication",
"type": "did-communication",
"serviceEndpoint": "https://cloud-wallet.demo.adaptivespace.io/aries-agent-aca-py/didcomm",
"recipientKeys": [
"did:web:bpa-api.demo.adaptivespace.io#key-1"
]
},
{
"id": "did:web:bpa-api.demo.adaptivespace.io#profile",
"type": "profile",
"serviceEndpoint": "http://bpa-api.demo.adaptivespace.io/profile.jsonld"
}
]
}
Verifiable Credential:
Business Process
Each participant (except the participant directly connected to the Carrier) should generate a Verifiable Presentation and send it to the next participant in the chain.
Intermediaries need to relay all the Verifiable Presentations they have received from previous participants in the chain.
The Carrier receives all Verifiable Presentations and can thus verify them.
Verifiable Presentation
 The below Verifiable Presentation is built following the W3C Verifiable Credential data model including:
The participant’s Verifiable Credential, including the identifier used by the participant included in the distribution chain.
A unique transaction identifier (line 4).
The creation timestamp (line 44).
The Verifiable Presentation is signed using the private key associated with the public key included in the DID document.
Each Verifiable Presentation may have a different transaction identifier and creation timestamp.
Verifiable Presentation:
Â
Each Verifiable Presentation transmitted to the Carrier needs to be placed in the relevant instance of DistributionChainLink
in the VerifiablePresentation
element shown below:
Â
Postconditions
Carrier is in a position to verify that, for each participant:
The Verifiable Credential is authentic.
The Verifiable Credential is valid (not expired and not revoked).
Airline needs to decide on the frequency to retrieve the revocation list published by issuer.Â
The participant’s identifier used in the EASD message matches the identifier in the Verifiable Credential.
The Verifiable Credential is presented by its owner.
The Verifiable Credential presented for this particular transaction.