Skip to main content

Credential Pipeline

When you issue a credential in DPP Kit, it goes through a multi-step pipeline. Each step must succeed before proceeding to the next.

Pipeline Steps

┌─────────────────────┐
│ 1. Pre-flight │ UNTP Tier 2 schema validation
│ Validation │
└────────┬────────────┘

┌─────────────────────┐
│ 2. Issue Credential │ Create revocation status entry
│ Status │ via VCKit bitstring status list
└────────┬────────────┘

┌─────────────────────┐
│ 3. Sign Credential │ Sign the VC with org's DID
│ │ via VCKit /v2/credentials/issue
└────────┬────────────┘

┌─────────────────────┐
│ 4. Upload to │ Store signed credential
│ Storage │ in S3/MinIO via Storage Service
└────────┬────────────┘

┌─────────────────────┐
│ 5. Post-issuance │ Conformance validation
│ Validation │ (UNTP — planned)
└────────┬────────────┘

┌─────────────────────┐
│ 6. Register in IDR │ Map identifier to credential
│ │ URL in the Identity Resolver
└─────────────────────┘

Compensation (Rollback)

If steps 5 or 6 fail after the credential has already been uploaded to storage, the pipeline compensates by deleting the credential from storage. This prevents orphaned credentials that are stored but not resolvable.

What Happens at Each Step

1. Pre-flight Validation

Runs UNTP Tier 2 schema validation against the unsigned credential payload. This checks three things: the W3C VCDM v2 context is present, the credential conforms to its UNTP type-specific schema (e.g., DPP, DFR), and the credential conforms to the W3C Verifiable Credential Data Model schema. If validation fails, the pipeline stops and the credential is set to error status with detailed error messages.

2. Issue Credential Status

Creates an entry in VCKit's bitstring revocation list. This gives the credential a status that can later be flipped to "revoked" if needed, without modifying the original credential.

3. Sign Credential

Sends the credential to VCKit's signing endpoint. VCKit looks up the organization's private key, creates the cryptographic proof, and returns a signed W3C Verifiable Credential.

4. Upload to Storage

The signed credential (a JSON document) is uploaded to the Storage Service, which writes it to S3-compatible object storage. The resulting URL becomes the canonical location of the credential.

5. Post-issuance Validation

A conformance check on the signed credential. Currently a placeholder — planned for a future release.

6. Register in IDR

Maps the credential's GS1 identifier (GTIN-14 or GLN-13) to the storage URL in the Identity Resolver. After this step, scanning the product's identifier resolves to the credential.

After Issuance

Once a credential is issued:

  • Its status changes from draft to active
  • It cannot be edited (the signature would be invalidated)
  • It can be viewed and verified by anyone with the credential URL or product identifier
  • It can be revoked by an admin, which updates the status list but does not delete the credential