Wallet interaction
The ability to receive credentials, hold them, and share them as proofs with verifiers is found primarily in the wallet interaction endpoints of the Core API.
When a holder scans the QR code offered by an issuer or verifier, the
/api/interaction/v1/handle-invitation endpoint takes the encoded URL and returns an
interactionId along with one of credentialIds (if the holder is connecting to an
issuer) or proofId (if the holder is connecting to a verifier's proof request).
The interactionId is then used in all responses. The following is a high-level
overview of the workflow from the perspective of the wallet.
Issuance workflow
-
Handle invitation
-
Get credential to see the offer
-
Accept the issuance OR Reject the issuance
Verification workflow
-
Handle invitation
-
Get proof request to see the request
-
Get presentation definition
-
Submit presentation of the chosen credentials OR Reject presentation
Rejection in both cases requires calling the relevant rejection endpoint with the
interactionId in the request body.
Accepting a credential issuance requires the additional specification of a local DID to which the resulting credential will be bound and optional specification of a key for cases in which a DID has multiple keys specified for authentication.
Submitting a presentation of credentials to a verifier requires a further step since
the wallet holder needs to choose exactly which credentials to share with the verifier.
Use the /api/proof-request/v1/:id/presentation-definition endpoint to filter the wallet,
returning the credentials which match the verifier's request. When submitting the
presentation, the submitCredentials object is the specification of the set of claims
being submitted to the verifier.
transport array
For mobile wallets with multiple transport protocols enabled, use the transport
array of handleInvitation to specify which transport protocol should be used.
Together with the order of transport protocols in the configuration, the array
enables dynamic protocol choice for exchange protocols.
The table below describes how the system uses the array and the configuration to determine
which transport protocol to use. The table assumes the values being passed are supported.
See the supportedTransports capability of the exchange object of the configuration
for supported transport protocols.
transport array value | System action |
|---|---|
| [] | Of available transports from the configuration, uses highest order |
| [one value] | Uses the specified transport |
| [multiple values] | Following the order from the configuration, uses first supported transport found |