Credential Issuer

What Are W3C Verifiable Credentials?

A Verifiable Credential (VC) is a tamper-evident digital claim issued by one party (the issuer) about another party (the subject) and held by the subject for later presentation to verifiers. The W3C Verifiable Credentials Data Model defines a standard format for these credentials so that issuers, holders, and verifiers — operating independently — can interoperate without prior arrangement.

Three roles exist in every VC interaction:

The key property is cryptographic verifiability: a verifier can confirm who issued the credential and that the claims were not modified, without contacting the issuer at presentation time.

The Issuance Lifecycle in Auris

The Auris Credential Issuer follows a four-step lifecycle: template definition, request submission, manual review, and credential issuance.

Template  -->  Request  -->  Review  -->  Credential
(schema)       (subject      (approve/    (issuedVcId
               DID + data)   reject)       assigned)

Step 1: Define a Credential Template

A Credential Template describes the structure of credentials your tenant can issue. It defines:

• A human-readable name and optional description
• A type label (e.g., VerifiableId, ProfessionalCertificate, AccessProof)
• A schemaFields array that specifies the data fields the credential carries

Each schema field has four properties:

Templates are reusable. Once a template is defined, operators can issue many credentials from it without redefining the schema for each one. Templates can be deactivated to prevent new requests without deleting historical records.

Step 2: Submit a Credential Request

A Credential Request captures the intent to issue a specific credential to a specific subject. It includes:

• templateId: which template to issue from
• subjectDid: the subject’s Decentralized Identifier (DID)
• subjectData: the field values for the credential, conforming to the template’s schemaFields

Requests enter the PENDING state on creation. No credential is issued immediately — the request waits for a reviewer to examine the submitted data.

Step 3: Manual Review

An operator with the manage:credential-issuer permission reviews each request. The review action is binary:

• Approve — transitions the request to APPROVED, allowing issuance to proceed
• Reject — transitions the request to REJECTED with an optional rejectionNote explaining why

The reviewer’s identity (sub claim from the access token) is recorded in reviewedBy alongside a reviewedAt timestamp. This creates an auditable record of who approved or rejected each credential claim.

Step 4: Issue the Credential

Once a request is APPROVED, an operator calls the issue endpoint. The service:

1. Confirms the request is in APPROVED state (rejects PENDING, REJECTED, and already ISSUED requests with INVALID_STATE)
2. Generates a unique issuedVcId UUID that identifies the resulting credential
3. Transitions the request to the ISSUED terminal state

The issuedVcId is the reference identifier for the credential in downstream systems. The actual credential payload (signing, encoding) is handled by the VC signing integration configured for the tenant.

Request Status Transitions

PENDING  -->  APPROVED  -->  ISSUED
   |
   +-------->  REJECTED

Once a request reaches REJECTED or ISSUED, it cannot be transitioned further.

Verification Challenges

The Credential Issuer includes a selective disclosure verification mechanism based on challenge codes. When a verifier (such as a web portal or a service gate) wants to verify a credential, it creates a challenge that specifies:

• verifierName: the display name of the verifying party
• credentialType: the type of credential expected
• requestedFields: the specific fields the verifier needs to see (enabling selective disclosure — the holder reveals only what is asked)
• ttlSeconds: how long the challenge is valid (default 300 seconds)

The challenge generates a unique QR URL at {AURIS_URL}/api/credential-issuer/verify/{challenge}. The holder scans this URL or follows the link to present their credential. Once presented, the challenge transitions to VERIFIED with the holderDid, disclosedFields, and verifiedAt recorded.

If the holder does not respond before expiresAt, the challenge auto-expires to EXPIRED on the next status check.

Challenge Status Transitions

PENDING  -->  VERIFIED
   |
   +-------->  EXPIRED  (auto, on next GET after expiresAt)

All verification events are recorded in the verification history, providing a durable log for compliance and auditing.

Credential Format

The Auris Credential Issuer is format-agnostic at the storage layer. The CredentialRequest model stores the subject DID and claim data as structured JSON. The VC encoding and signing (e.g., JSON-LD with Linked Data Proofs, SD-JWT) is handled by the tenant’s configured signing integration, which consumes the issuedVcId reference. This separation means the issuance workflow and audit trail are independent of the chosen credential format or cryptographic suite.

Use Cases

Digital Identity Cards

Government agencies, universities, and regulated industries can issue digital identity credentials (name, date of birth, nationality, student ID number) to users who present them as proof of identity at online services — without the verifier needing to call back to the issuer.

Professional Certificates

Training providers, certification bodies, and employers can issue credentials attesting to completed certifications, licenses, or professional qualifications. Because the credential is signed by the issuer, a verifier can confirm its authenticity years after issuance without the issuer being online.

Access Proofs

A SaaS platform can issue credentials confirming subscription tier, active entitlements, or organizational membership. Partner services or API gateways can verify these credentials at the edge without a round-trip to the issuing platform’s authorization server.

Compliance Attestations

Compliance officers can issue credentials attesting that an organization passed a specific audit, holds an ISO certification, or completed a regulatory review as of a given date — creating a verifiable, portable compliance record that can be shared with auditors, partners, and regulators.

Data Model

The Credential Issuer is backed by three Prisma models scoped to the tenant:

All records are tenant-scoped (tenantId foreign key) and cascade-deleted when a tenant is removed. CredentialRequest records reference their template with a Restrict delete — a template cannot be deleted while active requests exist against it.

Permissions

All Credential Issuer operations require the manage:credential-issuer permission. There is no separate read-only permission at the API layer — the console enforces role-appropriate access through the standard Auris RBAC model.

Related Concepts

• Multi-Tenancy — How tenant isolation applies to credential data
• Roles & Permissions — Assigning the manage:credential-issuer permission to operators
• Fine-Grained Authorization — Combining FGA with VC-based access proofs
• Credential Issuer API — Complete REST API reference