You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

This page documents the Issue-credential technical flow (as described in the spec here) between two Aries agents: Agent A (the Issuer) and Agent B (the Holder).

There are three alternate flows. We will be focusing on the "holder begins with a request" flow here because it's the most interesting use case. The other two flows are essentially just subsets of this flow. Below is a technical flow diagram for the "holder begins with a request" flow, made with the following assumptions:

  1. We're taking the "happy path" - no errors.
  2. An ack for the receipt of the credential was not requested.


High Level Design 

  1. CreateOffer : creates offer creates the ICoffer 
    1. Input: Credential Defination ID (from ledger), Connection ID (from didComm Protocol), comment/label
    2. Output: Issue Creditial Offer with credential View embedded inside
  2. HandleOffer: Sends the IC offers from one agent to another who have established a didComm connection 
    1. Output: Creates the Credential Exchange Record
    2. Update state to offer_sent
  3. CreateCredentialRequest : creates the CR in response to  credential_exchange_id
    1. Input: credential_exchange_id
  4. HandleCredentialRequest : 
    1. Creates the credential. 
    2. Update state to received 
  5. HandleIssueCredential : 
    1. Stores the credential
    2. Update the state credential_issued

      5. CreateCredentialRequestWithoutOffer : creates the CR without any prelimary offer. How ? TBD 


Note: This interface is based on the python implementation.

Screen Shot 2019-11-17 at 11.08.03 AM.png

Additional details

Layer responsibilities

Business logic: Initiates the protocol and ultimately determines whether to accept/refuse going to the next step.

Client: The first step in sending a message to another agent happens here. The business logic/controller does not call the underlying service directly. Note that there can be different clients depending on the need (e.g. Go client, REST client, etc)

Service: Last step in the chain for sending messages and also the first step in the chain for receiving messages. Responsible for tracking state and saving messages to the local store.

Other Details

The issuer and holder are assumed to have already established a connection previously via DID Exchange.

Unknowns - Clarification Needed!

The spec generally seems to be assuming that Indy is being used. There are some parts of the spec that, in the absence of Indy, are unclear:

The propose-credential message has schema_id and cred_def_id fields. In the ACA-Py demo they are used to identify the credential format, which is stored in the ledger. What should we do here?

The offer-credential message has an "offers~attach" field. It says that it's supposed to be an "array of attachments that further define the credential being offered". The specific example it provides describing what this looks like is for Indy. What do we do?

The request-credential message has a "requests~attach" field. Similar to the "offers~attach" field from offer-credential, it is supposed to define the requested formats for the credential. In the absence of Indy, what does this look like?

  • No labels