JSON credentials remote verification journey pattern
This journey pattern is used to verify a JSON credential presented remotely (online).
Overview
- Issuance channel: Remote, Uponsupervised
- Device/s: Cross-device
- Formats: JSON
- Information assurance level: High
- Identity assurance level: Medium
Journey flow
Online credential request
Samantha wants to access a service that requires her to present some verified information about herself from a credential in her wallet.
The information requested is in a credential that also has information she doesn’t need or wish to share with the verifier.
Scanning a QR code
A QR code is presented on the screen for Samantha to scan with her device to initiate the process of sharing the information.
Sharing a credential
Upon scanning the QR code, Samantha is presented with a request to share information from a credential within her wallet, that was automatically selected based on the request criteria.
When one of the matching credentials support selective disclosure, Samantha can only share the required information and nothing else.
Verifying the credential presentation
Once Samantha consents to sharing the information, the wallet bundles it as a verifiable presentation response, signs it and returns it to the verifier.
The derived presentation still carries the same assurance levels as the original, enabling its verification.
Verification successful
The Verifier receives the presentation response and verifies it, allowing Samantha to access the service.
Architecture
Reviewing the presentation request
Once Samantha asks to access the service, the Verifier application (1) uses MATTR Pi Verifier SDK (2) capabilities to generate a request for the holder to present a set of claims.
The verification request contains all the information needed for the holder’s digital wallet or holding device to understand:
- What information is being requested
- Who is asking for it
- Where the wallet should respond to
- Required assurance levels.
This request is rendered as a QR code, which is presented to the user.
Reviewing the presentation request
The user uses their digital wallet (2) to scan the QR code and display the presentation request details. As part of this process, checks are made to ensure the request is genuine and was initiated by the verifier in the context under which the user initiated the flow.
Once verified, the wallet will identify one or more credentials that match the information specified in the request and present them to the holder, indicating what information is requested by the verifier.
If any of the matching credentials support selective disclosure, the holder can share only the required information and nothing extra. This is an optional capability that increases the privacy-preserving features of this workflow.
The wallet can also check the verifier against the Digital Trust Service (4) to ensure they are allowed to ask for this type of information in the context of the current trust network. This is an optional capability that enables network operators to add another layer of trust to interactions in their network.
Sharing the information
The holder consents to share the information, which is then bundled by the wallet as a verifiable presentation, cryptographically signed, and sent to the verifier as a presentation response.
Verifying the information
The verifier’s app (2), which can be the MATTR GO Verifier or any application utilizing an inbuilt MATTR Pi Verifier SDK (3) function, verifies the credential:
- The digital signature is valid, indicating the content of the credential hasn’t been tampered with.
- It hasn’t been revoked by the issuer.
- The credential is currently valid and hasn’t expired yet (based on valid from and valid until values included in the credential).
- It has been issued by an issuer that is trusted to issue this type of credential according to the current ecosystem issuer’s policy.
The only reliance the verification has on the issuer is calling an online revocation list (if the credential has revocation properties), which the credential issuer may host, to check the status of the credential being presented.
No information relating to the verifier or the context in which the holder is utilizing the credential is shared or available to the issuer.
Verification can also be achieved by extracting the credential payload and passing it through to the MATTR VII tenant for verification.