Issue a Verifiable Credential
Issue a JSON-LD Verifiable Credential, signed by a did:cheqd Decentralized Identifier (DID), using the ACA-Py API endpoints.
Using the /issue-credential-2.0 API endpoints, it is possible to issue Verifiable Credentials, signed by a cheqd DID, in a few clicks or lines of code. By following the following steps, you can effectively issue verifiable credentials using ACA-Py integrated with the cheqd ecosystem.
Pre-requisite
For JSON-LD Credential Issuance, the Issuer DID must have assertionMethod set to the verificationMethod.id . If your DID does not have assertionMethod, execute POST /did/cheqd/update API call to add new assertion method matching the verificationMethod.id.
Step 1: Create a Connection with Holder
Use any supported method to create a connection with the Holder of the credential. Automated out-of-band protocol is recommended.
1a: Issuer Creates Connection Invite
The Issuer agent will create a new connection invite for the Holder. This is needed to securely communicate between the Issuer and the Holder agents.
Auto-accept connection (defaults to configuration)
Create unique DID for this invitation (default false)
Create invitation for multiple use (default false)
List of mime type in order of preference that should be use in responding to the message
["didcomm/aip1","didcomm/aip2;env=rfc19"]Alias for connection
BarryA self-attested string that the receiver may want to display to the user about the context-specific goal of the out-of-band message
To issue a Faber College Graduate credentialA self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the out-of-band message
issue-vcHandshake protocol to specify in invitation
Identifier for active mediation record to be used
3fa85f64-5717-4562-b3fc-2c963f66afa6Pattern: [a-fA-F0-9]{8}-[a-fA-F0-9]{4}-4[a-fA-F0-9]{3}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}Optional metadata to attach to the connection created with the invitation
Label for connection invitation
Invitation to BarryOOB protocol version
1.1DID to use in invitation
did:example:123DID method to use in invitation
did:peer:2Possible values: Whether to use public DID in invitation
Parameters and Request Body
For automated acceptance, pass the following parameters:
A simple request body is below:
1b: Holder receives invitation
The above request will have an invitation in the response. Holder will have to copy that invitation and pass in the body of the following API call.
Alias for connection
{"value":"Barry"}Auto-accept connection (defaults to configuration)
Identifier for active mediation record to be used
{"value":"3fa85f64-5717-4562-b3fc-2c963f66afa6"}Use an existing connection, if possible
Message identifier
3fa85f64-5717-4562-b3fc-2c963f66afa6Message type
https://didcomm.org/my-family/1.0/my-message-typeList of mime type in order of preference
["didcomm/aip1","didcomm/aip2;env=rfc19"]A self-attested string that the receiver may want to display to the user about the context-specific goal of the out-of-band message
To issue a Faber College Graduate credentialA self-attested code the receiver may want to display to the user or use in automatically deciding what to do with the out-of-band message
issue-vcHandshake protocol
Optional image URL for out-of-band invitation
http://192.168.56.101/img/logo.jpgOptional label
BobParameters and Request Body
The request body should be the invitation value from the /create-invitation call by the Issuer.
Step 2: Holder creates local DID
For JSON-LD Credentials, the verification needs a Holder did as well. The Holder DID can be created locally by using the following API Call.
Method for the requested DID.Supported methods are 'key', 'sov', and any other registered method.
sovOptional seed to use for DID, Must be enabled in configuration before use.
000000000000000000000000Trustee1Request Body
You can use the following request body to create the local did. Ensure the key_type matches the Issuer DID Key Type.
Step 3: Request Credential from Issuer
For this example, the Credential is requested from the Holder to the Issuer using the /issue-credential-2.0/send-request API. This request is sent to the Issuer, informing them about the credential request and its attributes in a JSON format.
Send issuer a credential request not bound to an existing thread. Indy credentials cannot start at a request
Whether to remove the credential exchange record on completion (overrides --preserve-exchange-records configuration setting)
Human-readable comment
Connection identifier
3fa85f64-5717-4562-b3fc-2c963f66afa6Holder DID to substitute for the credentialSubject.id
did:key:ahsdkjahsdkjhaskjdhakjshdkajhsdkjahsWhether to trace event (default false)
Request Body
The following request is a sample for creating a Citizenship credential.
Step 4: Issuer accepts and issues credential
After the Issuer received and validated the request, they can issue the credential using the /issue-credential-2.0/records/<credential-exchange-id>/issue API endpoint. The credential-exchange-id can be retrieved by calling GET /issue-credential-2.0/records?state=request-received API.
Step 5: Holder stores Credential
The Holder has to store the issued credential into their wallet using the following API. The cred_ex_id can be retrieved by running API GET /issue-credential-2.0/records?state=credential-received on the Holder side.
Step 6: Check the received Credential
As this is a JSON-LD Credential, Holder must use POST /credentials/w3c API to check the credential.
Maximum number to retrieve
{"value":"1"}Start index
{"value":"0"}(JSON) WQL query
{"value":"{\"attr::name::value\": \"Alex\"}"}Credential context to match
Given credential id to match
Credential issuer identifier to match
Maximum number of results to return
Signature suite used for proof
Schema identifiers, all of which to match
Subject identifiers, all of which to match
Credential type to match
Request Body
For our citizenship credential example, the following request can be used
Last updated
Was this helpful?