Define the capabilities needed for exchanging VCs
The following subsection is to guide you to outline all of the needed capabilities of each step of your user journey. The goal is to identify each functional step and its capabilities in the user journey.
Now it is time to define the capabilities required for exchanging Verifiable Credentials. The following functional scenarios describe an example of the capabilities required to exchange VCs between trusted issuers, holders, and verifiers, and are described as sequences of actions that the user takes to achieve their goal.
Functional Scenarios Examples
How a Natural Person downloads and sets up their digital wallet
- The user downloads and installs a digital wallet.
- The user sets up and secures their wallet.
- The user creates DIDs, and private and public keys.
How a Natural Person requests a Verifiable Attestation from a Trusted Issuer
- The user visits the official website of the Trusted Issuer.
- The user authenticates with the Trusted Issuer.
- The user requests a Verifiable Attestation.
- The user scans a QR code with their phone's camera to claim the Verifiable Attestation with their wallet.
- The user unlocks their wallet.
- The user authorises the issuance of the Verifiable Attestation.
- The issuer authenticates the user (in a pre-authorised flow, this step is omitted)
- The user reviews and approves the storage of the Verifiable Attestation.
How a Natural Person presents one or more Verifiable Attestations to a Verifier
- The user visits the official website of a Verifier and selects the service.
- The Verifier requests to present one or more verifiable credentials.
- The user scans a QR code with their phone's camera to start the Verifiable Attestation presentation process on their wallet.
- The user unlocks their wallet.
- The user reviews and authorises the sharing of their Verifiable Credentials.
- The Verifier verifies the VP (signature, trusted issuer and accreditation validity)
- The Verifier grants the user access to the service.
Hands on!
Next Steps to define your Verifiable Credential functional capabilities
- Please check the functional scenarios you defined for your user stories Section 1 Template #3.
- For each user story, define the target component and the capability needed with the help of the Section 2 Template #13
- Check the specifications referenced in the Section 2 Template #13 for each capability and quickly assess the implementation effort.
Please use the table in Section 2 Template #13 below to guide you:
Section 2 Template #13
How as a Natural Person I download and setup my digital wallet
| Functional scenarios | Scenario Description | Holder Wallet Components | Actions |
|---|---|---|---|
| 1 | To set up my digital wallet, as a Natural Person, I download and install a digital wallet. | Download and install a digital wallet | Visit the App Store |
| 1 | Select a Wallet | ||
| 1 | Download and install a wallet | ||
| 2 | To start using my wallet, as a Natural Person, I set up and secure my wallet | Wallet UI | Enter information (name, etc.) |
| 2 | Wallet UI | Secure wallet (pin/password/face id/...) | |
| 2 | Wallet Key manager | Create DIDs, private and public keys | |
| 2 | Wallet Secure Enclave | Store DIDs, private and public keys |
As a Natural Person, I request a Verifiable Attestation from a Trusted Issuer
| Functional scenarios | Scenario Description | Issuer Components | Holder Wallet Components | Capability |
|---|---|---|---|---|
| 1 | In order to request an attestation from a Legal Entity, as a Natural Person, I can visit the official website of the Trusted Issuer. | Website | Serve the Trusted Issuer Website | |
| 2 | In order to get access to my profile, as a Natural Person, I can authenticate with the Trusted Issuer. | Website | Display supported authentication options | |
| 2 | Authentication Service | Authenticate the user | ||
| 2 | Authentication Service | Create user session | ||
| 3 | To get a Verifiable Attestation from a Legal Entity that attests my claims, as a Natural Person, I can request a Verifiable Attestation. | Website | Display an option to issue the credential in a Verifiable Credential format | |
| 3 | VC Issuance service | Create Credential Offer for the requested Verifiable Credential | ||
| 3 | Website | Case A: Render the Credential Offer into a QR code | ||
| 3 | Website | Case B: Redirect the user to her wallet | ||
| 4 | To claim the Verifiable Attestation with my wallet that is on a different device than the browser I'm using for the Trusted Issuer website, as a Natural Person I scan the QR code with my phone's camera. | QR code scanner | Scan the QR code | |
| 5 | To start the Verifiable Attestation issuance process on my wallet, as a Natural Person, I'm redirected to my digital wallet. | VC manager | Fetch the Credential Offer | |
| 6 | To get access to my wallet, as a Natural Person, I unlock my wallet. | UI | Ask the user to unlock the wallet | |
| 7 | To ensure that the issuer is trusted and that the issuance request is valid, as a Natural Person, I authorise the issuance request. | VC manager | Validate the credential offer | |
| 7 | VC manager | Fetch issuer metadata | ||
| 7 | TIR manager | Check whether the issuer is Trusted | ||
| 7 | TIR manager | Check whether the issuer is accredited to issue the Verifiable Attestation | ||
| 7 | TIR manager | Check the Accreditations validity | ||
| 7 | UI | Ask the user to authorise the VC issuance | ||
| 7 | VC manager | Send an authorsation request to the /authorisaiton endpoint | ||
| 7 | UI | Display the authorisation screen (if authentication is required) | ||
| 8 | To learn about the identity of the user, as an Issuer, I authenticate the user. Note: in a pre-authorised flow, this step is omitted. | Authentication service | Authenticate the user | |
| 8 | Authentication service | Create user session | ||
| 8 | Authentication service | Return an Authorisation Response (user is returned to the wallet) | ||
| 8.1 | Optional: The Issuer may request to present one or more Verifiable Presentations. For details see the How do I present Verifiable Credentials? user journey . | |||
| 9 | To bind the Verifiable Attestation to my DID, as a Natural Person, I request the VC and prove ownership of my DID. | VC manager | Process the Authorisation Response | |
| 9 | VC manager | Request access token via the /token endpoint | ||
| 9 | Secure enclave | Create a proof of DID ownership | ||
| 9 | VC manager | Send a Credential request (incl DID ownership proof) | ||
| A1 | Case A: In-time VC issuance To issue the Verifiable Attestation, as an Issuer, I verify the request and construct and e-seal the Verifiable Attestation. | VC issuance service | Verify the DID ownership proof | |
| A1 | VC issuance service | Fetch user information from the database | ||
| A1 | VC issuance service | Construct a Verifiable Credential | ||
| A1 | E-sealing service | E-seal the Verifiable Credential | ||
| A1 | VC issuance service | Return a Verifiable Credential | ||
| A2 | To store my Verifiable Attestation, as a Natural Person, I receive and verify the Verifiable Attestation. | VC manager | Receive a Verifiable Credential | |
| A2 | Signer | Verify the signature of the issuer in the issuance request | ||
| A2 | VC manager | Check whether the issuer is in the TIR | ||
| A2 | VC manager | Check the issuer's accreditations in the TIR | ||
| A2 | VC manager | Check the Accreditations status via EBSI | ||
| A2 | UI | Ask the user to store the V. Attestation | ||
| A2 | VC manager | Store the V. Attestation | ||
| B1 | Case B: Deferred Verifiable Attestation issuance To evaluate the Verifiable Attestation issuance request, as an Issuer, I notify the back office to review and authorise the issuance. | VC issuance service | Verify the DID ownership proof | |
| B1 | Notification service | Notify the back office about a pending VC issuance request | ||
| B1 | VC issuance service | Return a Credential Response with an acceptance token | ||
| B2 | To inform that issuance requires authorisation, as a Natural Person, I receive a notification that my request is being processed. | VC manager | Receive a Credential Response with an acceptance token | |
| B2 | UI | Notify the user that the VC issuance is pending authorisation | ||
| B3 | To issue the Verifiable Attestation, as an Issuer, I fill in the information, e-seal the Verifiable Attestation, and notify the user. | Back office UI | Authorise the VC issuance | |
| B3 | VC issuance service | Fetch user information from the data base or fill in a form | ||
| B3 | VC issuance service | Construct a Verifiable Credential | ||
| B3 | E-sealing service | E-seal the Verifiable Credential | ||
| B3 | Notification Service | Notify the user that the Verifiable Attestation has been issued | ||
| B4 | To receive the Verifiable Attestation, as a Natural Person, I open the notification that opens my digital wallet. | VC manager | Send a Deferred Credential Request | |
| B4 | VC manager | Receive a Verifiable Credential | ||
| B4 | Signer | Verify the signature of the issuer in the issuance request | ||
| B4 | VC manager | Check whether the issuer is in the TIR | ||
| B4 | VC manager | Check the issuer's accreditations in the TIR | ||
| B4 | VC manager | Check the Accreditations status via EBSI | ||
| 10 | To store the received Verifiable Attestation, as a Natural Person, I review and approve the storage of the Verifiable Attestation. | UI | Notify the user about the received credential | |
| 10 | VC manager | Store the Verifiable Credential |
As a Natural Person, I present one or more Verifiable Attestations to a Verifier
| Functional scenarios | Scenario Description | Verifier Components | Holder Wallet Components | Capability |
|---|---|---|---|---|
| 1 | To use a service, as a Natural Person, I can visit the official website of a Verifier and select the service. | Website | Serve the Trusted Issuer Website | |
| 2 | To serve the user, as a Verifier, I can request to present one or more verifiable credentials. | VP service | Create Verifiable Presentation request | |
| 2 | Website | Case A: Render the Credential Offer into a QR code | ||
| 2 | Website | Case B: Redirect the user to her wallet | ||
| 3 | To be able to share my Verifiable Credentials using my digital wallet, as a Natural Person, I scan the QR code with my phone's camera. | QR code scanner | Scan the QR code | |
| 4 | To start the Verifiable Attestation presentation process on my wallet, as a Natural Person, I'm redirected to my digital wallet. | VP manager | Fetch the VP Token Request | |
| 5 | To get access to my wallet, as a Natural Person, I unlock my wallet. | UI | Ask the user to unlock the wallet | |
| 6 | Optional: To ensure that the verifier is trusted and that the presentation request is valid, as a Natural Person, I am notified about the validity of the presentation request. | VP manager | Validate the VP Request | |
| 6 | VP manager | Fetch Verifier metadata | ||
| 6 | UI | Display the use information about the Verifier | ||
| 7 | To share my Verifiable Credentials, as a Natural Person, I review and authorise sharing of my Verifiable Credentials | UI | Display the requested Verifiable Credentials and ask the user to authorise the sharing | |
| 7 | VP manager | Prepare a Verifiable Presentation | ||
| 7 | Signer | Sign the Verifiable Presentation | ||
| 7 | VP manager | Submit the Verifiable Presentation | ||
| 8 | To make a decision about offering the service, as a Verifier, I verify the Verifiable Presentation. | VP manger | Verify the Verifiable Presentation signature | |
| 8 | Signer | Verify the Verifiable Credential signature | ||
| 8 | VP manger | Check whether the issuer is Trusted | ||
| 8 | VP manger | Check whether the issuer is accredited to issue the Verifiable Attestation | ||
| 8 | VP manger | Check the Accreditations validity | ||
| 8 | VP manger | Check the validity of the Verifiable Credential | ||
| 8 | VP manager | Case A: Return an access token | ||
| 8 | Website | Case B: Load the service in the browser. | ||
| 9 | To use the service, I get access to the service. | VP manager | Case A: Redirect the user to the website. |
Once you have filled in Section 2 Template #13, please move on to Plan for implementation & Integration.