Network Credential Registry

The Network Credential Registry is iDen2's platform service for credential lifecycle state — issuance, suspension, revocation, and expiry. It implements W3C Bitstring Status List v1.0 so verifiers can check whether a credential is still valid without contacting the issuer on every presentation.

Preview — platform API

The registry is available at crs.stg.iden2.app (staging). Issuer-facing write APIs require OAuth Bearer tokens. Public status-list reads require no token. Contact the iDen2 platform team for access and scopes.

Why it exists

When a holder presents a credential, Verification Gateway checks more than the signature:

1. Is the issuer trusted in your trust network?
2. Is the credential revoked or suspended?
3. Has the credential expired?

The registry answers (2). During verification you see the outcome as verificationResult.revocationStatus (not_revoked, revoked, or unknown) and a revocation entry in verificationResult.checks[] with mechanism BitstringStatusList.

Your backend should always verify revocationStatus !== "revoked" before granting access — even when status === "completed".

Lifecycle states

Status	Meaning
issued	Credential recorded at issuance
active	Valid and presentable
suspended	Temporarily blocked (may include suspensionExpiresAt)
revoked	Permanently invalid
expired	Past credential expiry
archived	Retained for audit; not presentable

Reason codes (e.g. key_compromise, holder_request, fraud_detected) are recorded on status transitions for audit.

How issuers interact

At issuance (Credential Factory)

When Credential Factory completes OID4VCI issuance, the platform registers the credential in the registry automatically. Your integration does not call the registry directly for normal offers.

Revocation (Issuer API)

Issuers with revocation permission can call:

curl -X POST "https://iaas.stg.iden2.app/api/v1/issuer/credentials/{credentialId}/revoke" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"action": "revoke", "reason": "holder_request"}'

The action field is required (reason is an optional free-text note). This call needs a token with the issuance.credential.revoke scope.

After revocation, Verification Gateway rejects later presentations of that credential with failureReason: "revoked_credential" or verificationResult.revocationStatus: "revoked".

Direct registry access (advanced)

Platform integrators with direct registry credentials can manage status directly:

Method	Path	Auth	Purpose
GET	/v1/status-lists/{statusListId}	Public	Fetch BitstringStatusList credential
POST	/v1/credential-status	OAuth	Register new credential status
GET	/v1/credential-status/{memberId}/{credentialId}	OAuth	Read current status
PUT	/v1/credential-status/{memberId}/{credentialId}	OAuth	Transition status
GET	/v1/credential-status/{memberId}/{credentialId}/history	OAuth	Audit history

Base path: /v1 on crs.stg.iden2.app (staging).

StatusList2021 in credentials

Issued SD-JWT credentials embed a status list reference pointing at a registry-hosted status list URL:

{baseURL}/v1/status-lists/{statusListId}

Verification Gateway resolves this reference during verification. Wallets and verifiers do not need to call the registry directly for standard OpenID4VP flows — Verification Gateway performs the check and surfaces the result.

Verification flow

Environments

Environment	Host
Staging	crs.stg.iden2.app
Development	crs.dev.iden2.app
Production	crs.iden2.app (confirm with platform team)

Next steps

• Credential Registry — the concept and its role in issuance and verification
• Credential Registry Architecture — how it is wired into Credential Factory and Verification Gateway
• Verification Integration Guide — interpret verificationResult
• Issuance Integration Guide — offer lifecycle
• Trust Network API — issuer membership vs credential status