Schemas and Credentials

CREDEBL supports two credential families: AnonCreds (Hyperledger Indy-based) and W3C Verifiable Credentials (JSON-LD). Both share the concept of a schema that describes the structure of a credential, but they differ in how credentials are signed and presented.

Credential schemas

A credential schema defines the set of attributes (claims) a credential of that type will contain, along with a version string. Schemas are published to a ledger or referenced by a DID Document so that any party can look up and validate the credential’s structure. CREDEBL supports two schema types, defined in the SchemaType enum:

AnonCreds (Indy)
W3C JSON-LD

Schemas are published to a Hyperledger Indy ledger. Each attribute has a name; the data type is expressed separately in the credential definition and issuance payload.Supported attribute data types (IndySchemaDataType):

string
number
datetime-local
boolean

An Indy schema ID is derived from the publisher’s DID, the schema name, and the version:

<publisherDid>:2:<schemaName>:<version>

W3C schemas are associated with a JSON-LD context. CREDEBL supports both Polygon-anchored W3C schemas and ledger-less W3C schemas (using did:key or did:web).Supported attribute data types (W3CSchemaDataType):

string
number
integer
datetime-local
array
object
boolean

The JSONSchemaType enum distinguishes between polygon (Polygon W3C) and no_ledger (ledger-less) variants.

Creating a schema

Only owner and admin roles can create schemas. The endpoint supports Indy, Polygon, and W3C schemas through a single generic endpoint:

POST /orgs/:orgId/schemas
Authorization: Bearer <token>

{
  "name": "EmployeeCredential",
  "version": "1.0",
  "attributes": ["firstName", "lastName", "employeeId", "department"],
  "schemaType": "indy"
}

Schemas can be listed and retrieved per organization via GET /orgs/:orgId/schemas and GET /orgs/:orgId/schemas/:schemaId.

Credential definitions

A credential definition links a schema to an issuer’s cryptographic keys. For AnonCreds credentials, a credential definition must exist before any credentials can be issued. It publishes the issuer’s public key material to the ledger so that holders can later prove possession without revealing the credential itself (using zero-knowledge proofs). Credential definitions are retrieved by schema ID:

GET /orgs/:orgId/schemas/:schemaId/cred-defs

The CredDefSortFields enum supports sorting by createDateTime, tag, schemaLedgerId, and credentialDefinitionId.

W3C JSON-LD credentials do not use credential definitions. The issuer’s signing key is referenced directly via the DID Document verification method.

The credential issuance lifecycle

Connection-based issuance

Establish a connection

The issuer and holder establish a DIDComm connection. The connection state transitions through: start → invitation-sent → invitation-received → request-sent / request-received → response-sent / response-received → completed.

Create a credential offer

The issuer sends a credential offer to the holder over the established connection:

POST /orgs/:orgId/credentials/offer?credentialType=indy
Authorization: Bearer <token>

{
  "connectionId": "<connection-id>",
  "credentialDefinitionId": "<cred-def-id>",
  "credentialData": [
    {
      "attributes": {
        "firstName": "Alice",
        "employeeId": "EMP-001"
      }
    }
  ]
}

Supported credentialType values: indy (AnonCreds) and jsonld (W3C JSON-LD).

Holder receives and requests

The holder’s agent receives the offer. The issuance state transitions: offer-sent → offer-received → request-sent → request-received.

Credential issued

The issuer’s agent issues the signed credential. State transitions to credential-issued → credential-received → done.

The full set of issuance states (IssuanceProcessState):

State	Description
`proposal-sent` / `proposal-received`	Holder proposes a credential type
`offer-sent` / `offer-received`	Issuer has sent a credential offer
`request-sent` / `request-received`	Holder has accepted and requested the credential
`credential-issued`	Issuer has signed and sent the credential
`credential-received`	Holder’s agent has received the credential
`done`	Issuance completed successfully
`declined`	One party declined
`abandoned`	Process abandoned

Out-of-Band (OOB) issuance

OOB issuance allows credentials to be offered without a prior connection. CREDEBL supports two OOB modes: Email delivery — The issuer creates OOB credential offers and sends them directly to holder email addresses:

POST /orgs/:orgId/credentials/oob/email?credentialType=indy
Authorization: Bearer <token>

{
  "credentialOffer": [
    {
      "emailId": "alice@example.com",
      "attributes": { "firstName": "Alice", "employeeId": "EMP-001" }
    }
  ],
  "credentialDefinitionId": "<cred-def-id>"
}

URL-based offer — The issuer generates an invitation URL that the holder can scan or click:

POST /orgs/:orgId/credentials/oob/offer?credentialType=indy

This returns an invitation URL and QR code payload the holder can use to accept the credential without an existing connection.

Bulk issuance via CSV

CREDEBL supports issuing credentials to many holders simultaneously using a CSV file.

Download the CSV template

Download a pre-formatted template that matches the schema’s attributes:

POST /orgs/:orgId/credentials/bulk/template

The template includes column headers matching the credential schema attributes. The email_identifier column (TemplateIdentifier.EMAIL_COLUMN) is used to identify each recipient.

Fill and upload the CSV

Upload the completed CSV file:

POST /orgs/:orgId/bulk/upload?schemaType=indy
Content-Type: multipart/form-data

This returns a requestId used to track the batch.

Preview the data

Review the parsed data before issuing:

GET /orgs/:orgId/:requestId/preview

Start bulk issuance

Trigger issuance for all rows in the file:

POST /orgs/:orgId/:requestId/bulk

Monitor progress

Check the status of uploaded files and retry failed rows if needed:

GET /orgs/:orgId/bulk/files
POST /orgs/:orgId/:fileId/retry/bulk

The verification flow

Send a proof request

The verifier sends a proof request to a holder’s connection. CREDEBL supports two proof request types (ProofRequestType): indy (AnonCreds) and presentationExchange (DIF Presentation Exchange).

POST /orgs/:orgId/proofs?requestType=indy
Authorization: Bearer <token>

{
  "connectionId": "<connection-id>",
  "proofFormats": {
    "indy": {
      "attributes": [
        { "attributeName": "firstName", "credDefId": "<cred-def-id>" }
      ]
    }
  }
}

For connectionless scenarios, use POST /orgs/:orgId/proofs/oob.

Holder presents proof

The holder’s agent receives the proof request and sends a presentation. The verification state transitions: request-sent → request-received → presentation-sent → presentation-received.

Verifier verifies the presentation

The verifier calls the verify endpoint to cryptographically check the presentation:

POST /orgs/:orgId/proofs/:proofId/verify

Retrieve verified proof details

Retrieve the verified attributes from the presentation:

GET /orgs/:orgId/verified-proofs/:proofId

The full set of verification states (VerificationProcessState):

State	Description
`proposal-sent` / `proposal-received`	Holder proposes a proof type
`request-sent` / `request-received`	Verifier has sent a proof request
`presentation-sent` / `presentation-received`	Holder has sent a presentation
`done`	Verification completed successfully
`declined`	One party declined
`abandoned`	Process abandoned

Credential revocation

AnonCreds credentials support revocation. A revocation registry is created alongside a credential definition, and the issuer can revoke specific credentials without revealing which credential was revoked or the holder’s identity. The verifier requests a non-revocation proof as part of the proof request.

OID4VC and OID4VP protocols

CREDEBL supports OpenID for Verifiable Credentials issuance (OID4VC) and OpenID for Verifiable Presentations (OID4VP). The OpenId4VcIssuanceSessionState enum tracks OID4VC issuance sessions:

State	Description
`OfferCreated`	Credential offer has been created
`OfferUriRetrieved`	The offer URI has been fetched by the wallet
`AuthorizationInitiated`	Authorization flow has started
`AuthorizationGranted`	Authorization has been granted
`AccessTokenRequested`	Wallet has requested an access token
`AccessTokenCreated`	Access token has been issued
`CredentialRequestReceived`	Wallet has sent a credential request
`CredentialsPartiallyIssued`	Some credentials in a batch have been issued
`Completed`	All credentials have been issued
`Error`	An error occurred during the session

OID4VP supports indy and presentationExchange request types, mirroring the connection-based verification flow. The response modes direct_post, direct_post.jwt, dc_api, and dc_api.jwt are defined in the ResponseMode enum.

Get Started

Configuration

Deployment

Core Concepts

Credential schemas

Creating a schema

Credential definitions

The credential issuance lifecycle

Connection-based issuance

Out-of-Band (OOB) issuance

Bulk issuance via CSV

The verification flow

Credential revocation

OID4VC and OID4VP protocols

Build docs developers (and LLMs) love

Get Started

Configuration

Deployment

Core Concepts

​Credential schemas

​Creating a schema

​Credential definitions

​The credential issuance lifecycle

​Connection-based issuance

​Out-of-Band (OOB) issuance

​Bulk issuance via CSV

​The verification flow

​Credential revocation

​OID4VC and OID4VP protocols

Build docs developers (and LLMs) love

Credential schemas

Creating a schema

Credential definitions

The credential issuance lifecycle

Connection-based issuance

Out-of-Band (OOB) issuance

Bulk issuance via CSV

The verification flow

Credential revocation

OID4VC and OID4VP protocols