Receive a Credential

When to use

An issuer is offering you a credential. There are three delivery mechanisms supported on IDA:

1. In-platform — the credential is issued to your DID; you see it appear in /credentials.
2. DIDComm — the issuer sends an encrypted message to your DIDComm endpoint; you accept it from the wallet’s “Pending” list.
3. Out-of-band link — the issuer hands you a URL; clicking it opens the platform with a confirmation dialog.

Before you begin

• You have shared your DID with the issuer (in-platform: you signed in; DIDComm/OOB: you sent your DID via email or QR).
• The credential is for your DID — verify the credentialSubject.id field matches.

Steps (in-platform delivery)

1. The issuer enters your DID in their portal and clicks Issue.
2. You see a notification (bell icon) on your dashboard within seconds.
3. Open /credentials — the new VC is at the top of the list with a New badge. 4. Click the credential to open the detail page.

Steps (DIDComm delivery)

1. The issuer sends a DIDComm issue-credential message to your DID’s DIDCommMessaging endpoint.
2. The platform receives it via POST /api/v1/didcomm/receive and stores it as a pending message.
3. Open /inbox (or the wallet’s pending tab). You see “Credential offer from did:adi:0xUniv…” with the schema name.
4. Click Accept. The platform sends the response, the issuer signs and returns the VC, and it lands in your /credentials list.

Steps (Out-of-band link)

1. The issuer hands you a URL like https://adid.dev/credentials/claim?offerId=abc123.
2. Click the URL while signed in. The portal verifies the offer is for your DID and renders an accept dialog.
3. Click Accept. Same outcome as DIDComm delivery.

Verify

The credential should appear in GET /api/v1/credentials:

$
curl https://adid.dev/api/v1/credentials \
>
  -H "Authorization: Bearer $ACCESS_TOKEN"

1
{
2
  "data": [{ "id":"urn:uuid:...", "issuer":"did:adi:0xUniv...", "type":["VerifiableCredential","UniversityDegreeCredential"], "issuedAt":"..." }],
3
  "total": 1
4
}

Troubleshooting

3.2.3. Viewing & Managing Your Credentials ##### When to use

Day-to-day inspection of what you hold and where it came from.

Before you begin

• Signed in as a holder.
• At least one credential received.

Steps

1. Navigate to /credentials.
2. Filter by:
   • Issuer — type-ahead search backed by the trusted issuers list.
   • Schema — select from a dropdown of received schema types.
   • Status — active, revoked, expired, suspended.
3. Click any credential row to open the detail.
4. The detail page shows:
   • Claims — pretty-printed.
   • Issuer — DID, with click-through to Trust Explorer.
   • Status — live revocation check (calls §3.2.5 automatically).
   • Raw VC — collapsible JSON dump.
   • Actions — Create presentation, Generate ZK proof, Delete, Export.

API

$
curl "https://adid.dev/api/v1/credentials?limit=50&offset=0" \
>
  -H "Authorization: Bearer $ACCESS_TOKEN"

$
curl "https://adid.dev/api/v1/credentials/urn:uuid:c5b7e3..." \
>
  -H "Authorization: Bearer $ACCESS_TOKEN"

Verify

The list count matches the badge on the Credentials sidebar tile.

Troubleshooting

A credential that disappears from the list typically had its row deleted. Deletion is local (the chain anchor remains). If you need to restore, contact the issuer for a fresh copy.

3.2.4. Creating a Verifiable Presentation ##### When to use

A verifier has asked you for a presentation — typically by sharing a Proof Request URL/QR (see §5.2). You want to compile one or more of your VCs into a signed VP and submit it.

Before you begin

• The verifier’s Proof Request (a Presentation Definition per DIF Presentation Exchange v2).
• The VCs that satisfy the request.

Steps

1. Open the Proof Request (URL or QR scan in the wallet).
2. The portal/wallet matches the request against your held VCs and shows you which credentials would satisfy each input descriptor. 3. Approve. The portal calls POST /api/v1/presentations/create (vc.go:316).
3. The API:
   • Fetches the named VCs.
   • Constructs a VP envelope.
   • Signs the VP with your DID’s authentication key.
   • Returns the VP JSON.
4. The portal/wallet then submits the VP to the verifier (typically via POST /api/v1/presentations/verify on the verifier’s side, or a callback URL specified in the Proof Request).

API & SDK

$
curl -X POST https://adid.dev/api/v1/presentations/create \
>
  -H "Authorization: Bearer $ACCESS_TOKEN" \
>
  -H "Content-Type: application/json" \
>
  -d '{
>
    "holderDid":"did:adi:0x9a2c...",
>
    "credentialIds":["urn:uuid:c5b7e3..."],
>
    "challenge":"verifier-nonce-abc",
>
    "domain":"verifier.example.com"
>
  }'

1
const vp = await client.createPresentation({
2
  holderDid: 'did:adi:0x9a2c...',
3
  credentialIds: ['urn:uuid:c5b7e3...'],
4
  challenge: 'verifier-nonce-abc',
5
  domain: 'verifier.example.com',
6
});

Response (truncated):

1
{
2
  "verifiablePresentation": {
3
    "@context":["https://www.w3.org/ns/credentials/v2"],
4
    "type":["VerifiablePresentation"],
5
    "holder":"did:adi:0x9a2c...",
6
    "verifiableCredential":[ { ... } ],
7
    "proof":{ "type":"Ed25519Signature2020", "challenge":"verifier-nonce-abc", "domain":"verifier.example.com", "proofValue":"z3..." }
8
  }
9
}

Verify

The verifier’s portal will show “Presentation received → verifying…” and within ~1 s display the verdict. You should see a matching record in your own /presentations/history (if surfaced — currently part of §5.4 Verification History for the verifier side).

Troubleshooting

3.2.5. Checking a Credential’s Revocation Status ##### When to use

You hold a credential and want to confirm it has not been revoked. The status check is also performed automatically every time you open a credential’s detail page.

Before you begin

You have a credential ID.

Steps (manual)

$
curl https://adid.dev/api/v1/credentials/urn:uuid:c5b7e3.../status

(No auth needed — this endpoint is public, registered at router.go:68.)

Response:

1
{
2
  "credentialId":"urn:uuid:c5b7e3...",
3
  "revoked": false,
4
  "statusListId":"abcd",
5
  "statusListIndex": 42,
6
  "checkedAt":"2026-04-26T12:00:00Z"
7
}

How it works under the hood

The handler reads the bit at the credential’s statusListIndex from the RevocationRegistry contract. Bit 1 = revoked, bit 0 = active. See §4.4.3 for the bitstring encoding.

Troubleshooting