Page 32 - FIGI: e-KYC use cases in digital financial services

Presentations d) Verifiable credential request by Holder/User
Holders/Users can generate presentations and share
them with verifiers to prove they possess verifiable • The Holder should make the request to an
credentials with certain characteristics. Both creden- Issuer using a secure off-chain channel with
tials and presentations can be rapidly transmitted, mutual DID proof of possession.
making them more convenient than their physical
counterparts when establishing trust at a distance. e) Issuance to Holder.
When a Holder wants to access a digital finance
service, the Verifier could need some information • Issuers should create Credentials only as a
about the Holder, prior to accept providing the ser- response to a request from the Holder.
vice. The specific required information is requested • All the information defined in W3C recom-
using a presentation request, specifying the purpose mendation "Verifiable Credentials Data
and the minimum required information with respect Model 1.0"
to that service. • should be complied with by the Issuer.
The Holder then sends a verifiable reply with the • After being created, the verifiable credential,
appropriate Credentials from the ones stored in should be sent to the Holder using a
their wallet (not the distributed ledger). The Hold- • secure off-chain channel with mutual DID
er may need to register information related to the proof of possession.
presentation process on a distributed ledger. Anoth- • Verifiable credentials shall not be shared
er information of the reception may be registered directly to any other entities by the Issuer.
independently by the Verifier in the same distributed • The issuance event must be registered on the
ledger. distributed ledger, by the Issuer.
• The delivery event must be registered on the
7�2 Verifiable credential requirements distributed ledger, by the Issuer.
The following requirements are proposed for Verifi- • The verifiable credential shall not be directly
able Credentials (request, issue, delivery, and receipt): recorded on the distributed ledger.

a) The content should conform to W3C recommen- f) Receipt of verifiable credential
dation "Verifiable Credentials Data Model 1.0".
b) The verifiable credentials should support exis- • Verifiable credential digital signature shall be
tent and future attribute naming schemas such validated upon reception.
as X.520, schema.org, ISO 20022 or industry • The Verifiable credential may be accepted, or
specific standards. not, by the Holder/User.
c) The verifiable credential would include the fol- • The Verifiable credential shall be stored in a
lowing information: digital wallet under the sole control of the
Holder, in the original format without any
• General information about the purpose for modification to the content.
use; • The receipt of the verifiable credential may
• Verifiable Credential identifier; be registered on the distributed ledger, upon
• Holder information, including the list of Hold- acceptance, by the Holder.
er's attributes, as per request, and the Hold-
er's DID;
• The Issuer information, including the Issuer's 7�3 Decentralized Identifier (DID)
DID; The Decentralized Identifier (DID) specifications are
• Date verifiable credential was issued; being created to establish a cryptographically verifi-
• Metadata about the digital identity manage- able, globally addressable identifier namespace for
ment system used which could be for distributed ledger and blockchain systems. Decen-
instance the level of assurance of the Holder tralized Identifiers are the addressing scheme used
attributes; for Verifiable Credentials.
• Issuer's digital signature; and The DID design goals should include the following
• Expiry date of Verifiable Credential if appli- principles:
cable.

30 e-KYC use cases in digital financial services