Accepting New Credentials
Accept and store incoming verifiable credentials from Issuers, and manage credentials mid-issuance.
After establishing an end-to-end encrypted connection with peers, the agent is ready to begin negotiating and receiving credentials from credential issuers they are connected with. The CredentialExchangeModule
provides the functionality needed to easily walk through the Decentralized Identity protocol flow for accepting and storing a W3C or Anoncreds credential.
The functionality of the CredentialExchangeModule
is accessed via the agent
's field agent.credentials.exchange
. The functionality provided is described below.
Receive a Credential Offer
A CredentialExchange
(a pending credential) is created in the agent's wallet once a credential offer is received. The agent receives these offers as encrypted messages, either through the receiveMessage
API, or via the the MessageSource
of the agent's run loop. The credential offer must come from an established connection, and the CredentialExchange
will contain information about which connection the offer came from.
Additionally, a CredentialExchange
will show the metadata of what credential is being exchanged, and what the attributes/values of that credential are. These attributes/values can be reviewed by consumers before accepting the offer.
After an offer is decrypted and processed by the agent, a CredentialExchange
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 (see here), a new CredentialExchange
will invoke a credential update event.
Credential Exchange Formats
The Edge Agent supports multiple formats of credential exchanges (see Standards and Protocols). To represent this, the CredentialExchange
contains a formatData
field. This field is a CredentialExchangeFormatData
data structure which has variants for the different types of supported exchange formats. Currently these format variants include:
.Indy
: contains the details of a credential exchange being performed with Aries Indy Attachments. The data format is used to exchange Anoncreds credentials..AriesLdProof
: contains the details of a credential exchange being performed with Aries LD Proof Attachments. The data format is used to exchange W3C VCs (LD Proof) credentials.
Accepting a Credential Offer
With a CredentialExchange
in the OFFER
state, the agent can "accept" that offer, which will send off a credential request reply to the Issuer in accordance with Aries protocols.
Note that after calling the acceptOffer
API, the credential has not yet been issued nor stored. The Issuer will still have to approve the request and respond again with the issued credential data. The status updates of the issuance process can be tracked via agent events.
The acceptOffer
API takes the identifier of the CredentialExchange
to accept, and a configuration
for how the agent should behave after accepting.
The AcceptCredentialOfferConfiguration
data object allows the following behaviour to be adjusted:
autoStoreCredential
- a flag for whether the credential should be automatically stored in the wallet once the Issuer responds with the issued credential. If false, then the consumer is responsible for calling the Store Credential API once theCredentialExchange
receives the "issued" state.storeCredentialConfiguration
- a configuration for how the credential should be auto-stored (ifautoStoreCredential
is configured as true). Allows for custom behaviour, such as automatically applying certaintags
to the storedCredential
.formatSpecificConfiguration
- configuration which is specific to the credential exchange format (#credential-formats). This configuration has variants for the different formats which maps to theCredentialExchange
'sformatData
. These variants include:.AriesLdProofVc
- configuration which can be applied when the credential exchange format is an Aries LD Proof
Accepting an Anoncred Credential
To accept an Anoncred credential offer using the .Indy
credential exchange format, no additional formatSpecificConfiguration
is required. The following can be done:
Accept a W3C Credential
To accept a W3C credential offer using the .AriesLdProof
credential exchange format, the formatSpecificConfiguration
field can be provided with additional configuration. This additional configuration includes:
overrideCredentialSubjectId
- if provided, request that the issuer uses this string as the Credential Subject ID of the W3C VC. This mechanism can be used to inform the issuer of the holder DID the Edge Agent wants to VC to be bound to. See Manage DIDs.
To accept a W3C and request that the Edge Agent's DID be bound to the credential, the following can be done:
In order to prove holder ownership of a W3C credential (i.e. when presenting proof), it must be bound to one of the Edge Agent's DIDs. Hence the importance of this configuration.
Store a Credential
When a CredentialExchange
reaches the ISSUED
state, and has not been configured to auto-store, then the agent must call the storeCredential
API before the Credential
is stored in the wallet, completing the Aries protocol.
The API takes the identifier of the CredentialExchange
to store the credential of, and a configuration
for how the agent should behave when storing the credential.
The StoreCredentialConfiguration
data object can be used to overwrite tags
that the Credential
will be stored with. It could also be left as null
to leave the tags
as their default.
The API will also return the new Credential
that was stored as a result of the API call. This new credential will also now be available in the agent's Credential management module.
There is no need to call this API if the agent is configured to auto-store credentials.
Get a Pending Credential by ID
As mentioned above, a credential pending issuance is represented by CredentialExchange
objects. To retrieve the current state of a specific CredentialExchange
in the agent's wallet, the getById
API can be used. If a credential exchange cannot be found by the given identifier, then null
is returned:
Delete a Pending Credential by ID
Similarly, a CredentialExchange
in the wallet can be easily deleted via the deleteById
API:
Updating the Metadata of a Pending Credential
CredentialExchange
objects contain some metadata that can be controlled by SDK consumers, allowing custom information to be attached to each CredentialExchange
, and allowing custom listing functionality to be leveraged.
Each CredentialExchange
contains a list of RecordTag
(CredentialExchange.tags
) attached to it, where a RecordTag
is simply a name-value pair stored with the record. By default, some tags are attached to a new CredentialExchange
, this includes:
tag-name:
~started_timestamp
, tag-value: The UNIX epoch seconds which this credential began exchange
The tags on a CredentialExchange
can be replaced or updated by using the updateCredentialExchange
API, and providing a new set to update. This will replace whatever the current set of tags is:
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 (see below).
Listing Pending Credentials
To list all pending credentials in the agent's wallet, the listAll
API can be used:
Filtered Listing
More complicated CredentialExchange
list queries can also be achieved by utilizing the ListCredentialExchangeFilters
.
These filters allow for a list of CredentialExchange
to be filtered by their state
, tags
, or both together.
Filtering by state
can be achieved as follows.
To filter by tags
applied to the CredentialExchange
(i.e. applied via the update API), the tagFilter
field of ListCredentialExchangeFilters
should be used. This field takes a String
in compliance with a Wallet Query Language (WQL) Query.
Continuing from the example in the Update API section:
Last updated