Present Credentials for Verification
Use the agent's stored credentials to present a cryptographic proof to a Verifier
Last updated
Use the agent's stored credentials to present a cryptographic proof to a Verifier
Last updated
The ProofExchangeModule
provides the functionality needed to easily walk through the Decentralized Identity protocol flow for handling credential presentation requests and responding with the desired credentials & proofs. This module contains support for both Aries/DIDComm-based proof exchanges (e.g., after ), and for OpenID4VC-based proof exchanges.
The functionality of the ProofExchangeModule
is accessed via the agent
's fields: agent.proofs.exchange
. The functionality provided is described below.
A ProofExchange
(a pending presentation / proof in exchange) is created in the agent's wallet once a presentation request is received. Like CredentialExchange
(see Accepting New Credentials), a ProofExchange
can represent either an Aries or OpenID4VC protocol, this distinction is made via the variant of the ProofExchange
(ProofExchange.Aries
or ProofExchange.OpenId4Vc
). Each of these variants contain further data specific to the protocol being used.
How a ProofExchange
is initially received by the Edge Agent depends on the protocol being used (see below).
However regardless of the protocol, after a request is processed by the agent, a ProofExchange
is created in the agent's wallet and can be accessed and used by the APIs mentioned below. If the agent is subscribed to agent events (), a new ProofExchange
will invoke a proof update event.
The agent receives as encrypted DIDComm messages, either through the receiveMessage
, or via the MessageSource
of the agent's . The presentation request must come from an , and the ProofExchange.Aries
will contain information about which connection the request came from.
Similar to , the ProofExchange.Aries
object can represent different Aries proof exchange formats (see Standards and Protocols). ProofExchange.Aries
contains a formatData
field, which is a AriesProofExchangeFormatData
data structure with variants for the different supported formats. Currently these format variants include:
.Anoncred
: contains the details of an Aries presentation exchange being performed with Aries or. This format is used to exchange Anoncreds presentation requests & presentations. When the Edge Agent receives a ProofExchange request of this format, the SDK can select and present it's AnoncredV1 Credential
s in response.
.Dif
: contains the details of an Aries presentation exchange being performed with a . When the Edge Agent receives a ProofExchange request of this format, the SDK can select and present it's suitable Credential
s in response.
The inner contents of these formatData objects particularly contains important details about what presentation items (requirements) which are being requested. In the case of Anoncreds, this may include groups of attributes and/or predicates that the verifier wishes to be presented (each with their own requirements). Or in the case of DIF, it will be a , including several Input Descriptors that the verifier wishes to be presented (each with their own requirements).
In all cases, the inner data is structured in line with the relevant specifications. SDK consumers should make themselves familiar with these standard formats to understand how the presentation request data should be processed and/or displayed to the end application user.
Check out our for a reference on how these data formats can be processed in an application.
After receiving a ProofExchange
in the REQUEST
state, the consumer should query the agent to discover which credentials the agent has that will satisfy each item.
The retrieveCredentialsForProofRequest
API, can be used for this. This API returns a RetrievedPresentationCredentials
data structure to represent this.
RetrievedPresentationCredentials
has variants depending on the ProofExchange
presentation format that is being requested (DIF or Anoncred/Indy). Generally, the inner data of each variant maps the identifiers of the requested items to the IDs of Credential
s that are suitable for presenting the requested item.
Aries
Anoncred
Anoncred
Aries
DIF (v1)
DIF
OpenID4VC
DIF (v2)
DIF
When the retrieveCredentialsForProofRequest
API is used on an .Anoncred
formatted ProofExchange.Aries
, it will return a RetrievedPresentationCredentials.Anoncred
data object. This object contains:
credentialsForRequestedAttributes
: a map of requested attribute group referents/IDs, to the list of Credential
IDs which may be used for presenting the attribute group. Attribute group IDs correspond to the referents in the AnoncredProofRequestInfo
object of formatData
.
credentialsForRequestedPredicates
: similar to above, this contains a map of requested predicate referents/IDs, to the list of Credential
IDs which may be used for presenting the predicate.
selfAttestableAttributes
: a list of attribute referents/IDs which were requested for self-attestation. Unlike credentialsForRequestedAttributes
, these requested attributes are to be self-attested by the agent; meaning any string value can be presented for these attributes. Attribute IDs correspond to the referents in the AnoncredProofRequestInfo
object of formatData
.
When the retrieveCredentialsForProofRequest
API is used on any ProofExchange.OpenId4Vc
or on a .Dif
formatted ProofExchange.Aries
, it will return a RetrievedPresentationCredentials.Dif
data object. This object contains:
However, as before, the PresentationCredentials
object has variants depending on the presentation exchange format being presented. The chosen variant should match the RetrievedPresentationCredentials
variant.
Like other APIs, if presenting an Anoncreds presentation, then the .Anoncred
variant should be used. In this case, a PresentationCredentials.Anoncred
data object should be constructed with the following data:
credentialsForRequestedAttributes
: a map of requested attribute group referents/IDs, to an AnoncredPresentationAttributeGroup
object. This object contains the credentialId
of the credential to present for the attribute group, and a revealed
boolean flag. "revealed" is an Anoncreds zero-knowledge-proof feature: if revealed
is set to false, the Verifier will receive proof of the Credential, without seeing any of the credential's attribute values.
credentialsForRequestedPredicates
: a map of requested predicate referents/IDs, to an AnoncredPresentationPredicate
object. This object simply contains the credentialId
of the credential to present for this predicate.
selfAttestedAttributes
: a map of self-attestable attribute referents/IDs, to a chosen string value (self attested value).
Like other APIs, if presenting a DIF presentation, then the .Dif
variant should be used. In this case, a PresentationCredentials.Dif
data object should be constructed with the following data:
credentialsForDescriptors
: a map of requested input descriptor IDs, to the ID of the Credential
that should present the descriptor.
If possible, the Edge Agent SDK will automatically attempt to derive a selectively disclosed credential if the credential format and data allows (using BBS+ or SD-JWT). Meaning the agent will not present more data then necessary to the verifier; similar to Anoncreds.
As mentioned above, a pending presentation is represented by ProofExchange
objects. To retrieve the current state of a specific ProofExchange
in the agent's wallet, the getById
API can be used. If a proof exchange cannot be found by the given ID, then null
is returned:
Similarly, a ProofExchange
in the wallet can be easily deleted via the deleteById
API:
Each ProofExchange
contains a list of RecordTag
(ProofExchange.tags
) attached to it, where a RecordTag
is simply a name-value pair stored with the record. By default, some tags are attached to new ProofExchange
s, this includes:
tag-name: ~started_timestamp
, tag-value: The UNIX epoch seconds which this presentation began exchange
The tags on a ProofExchange
can be replaced or updated by using the updateProofExchange
API, and providing a new set to update. This will replace whatever the current set of tags is:
To list all pending presentations in the agent's wallet, the listAll
API can be used:
More complicated ProofExchange
list queries can also be achieved by utilizing the ListProofExchangeFilters
.
These filters allow for lists of ProofExchange
to be filtered by; their state
, by their tags
, or filtered by both together.
Filtering by state
can be achieved like so:
The agent is capable of receiving via the openid://
and openid4vp://
URL scheme through the receiveUrl
. The ProofExchange.OpenId4Vc
will importantly contain details of; the verifier's ID (e.g. their DID), and the presentationRequest
.
The presentationRequest
contains the full describing the details of what the verifier wishes to be presented. This request very closely matches the Aries .Dif
format variant discussed , however OpenID4VP uses DIF Presentation Exchange V2 instead of V1, which contains a few minor breaking changes.
credentialsForRequestedDescriptors
: a map of requested IDs, to the list of Credential
IDs which may be used for presenting the input descriptor. Descriptor IDs correspond to the InputDescriptor
s within formatData
.
After identifying credentials that are appropriate for presenting a proof exchange (), the consumer must select a Credential
to use for each requested presentation item. This selection is done by constructing a PresentationCredentials
data object before passing it to the presentProof
API where credential proofs will then be created and sent to the Verifier.
For simplicity, this example assumes that there is at least 1 suitable credential for each attribute group and predicate. Additionally this example implements "auto-select", apps may wish to let their users manually select credentials. See our for a reference.
See and Standards and Protocols.
For simplicity, this example assumes that there is at least 1 suitable credential for each input descriptor. Additionally this example implements "auto-select", apps may wish to let their users manually select credentials. See our for a reference.
ProofExchange
objects contain some metadata that can be controlled by SDK consumers, allowing custom information to be attached to each ProofExchange
, and allowing custom to be leveraged.
Like most data in the wallet, RecordTag
will be stored encrypted. Unless, the tag name is prefixed with ~
, then the tag value will be stored unencrypted. Storing a tag value as unencrypted will allow some additional listing queries to be performed ().
To filter by tags
applied to the ProofExchange
(i.e. applied via the ), the tagFilter
field of ListProofExchangeFilters
should be used. This field takes a String
in compliance with a Query.
Continuing from the example in the :