OpenID4VCI credential issuance explained: from offer to accepted credential

The full lifecycle of a credential offer

The specification does not define named states, but an issuer-initiated flow where the credential is issued straight away is easiest to follow as the sequence below. Each step can fail in its own way, and a wallet implementation has to handle those paths, not only the happy one.

2. Issuer metadata discovery

Before requesting anything, the wallet fetches the issuer’s metadata to learn what roadworthiness_certificate contains and which endpoints to call. The metadata lists no separate authorization servers, so the issuer is its own authorization server, and the wallet reads the token endpoint from that server’s metadata.

Credential issuer metadata (excerpt)

{
  "credential_issuer": "https://issuer.fleetinspect.example",
  "nonce_endpoint": "https://issuer.fleetinspect.example/nonce",
  "credential_endpoint": "https://issuer.fleetinspect.example/credential",
  "deferred_credential_endpoint": "https://issuer.fleetinspect.example/deferred",
  "notification_endpoint": "https://issuer.fleetinspect.example/notify",
  "credential_configurations_supported": {
    "roadworthiness_certificate": {
      "format": "dc+sd-jwt",
      "vct": "https://fleetinspect.example/vct/roadworthiness",
      "cryptographic_binding_methods_supported": ["jwk"],
      "credential_signing_alg_values_supported": ["ES256"],
      "proof_types_supported": {
        "jwt": { "proof_signing_alg_values_supported": ["ES256"] }
      },
      "credential_metadata": {
        "claims": [
          { "path": ["vehicle_registration"] },
          { "path": ["inspection_result"] },
          { "path": ["valid_until"] }
        ]
      }
    }
  }
}

Authorization server metadata (excerpt), from /.well-known/oauth-authorization-server

{
  "issuer": "https://issuer.fleetinspect.example",
  "token_endpoint": "https://issuer.fleetinspect.example/token",
  "pre-authorized_grant_anonymous_access_supported": true
}

4. Proof of possession

Because the metadata lists a nonce_endpoint, the wallet first fetches a fresh c_nonce there. It then proves it holds the private key the credential will be bound to, by signing a proof JWT over the issuer identifier and that c_nonce.

POST /nonce HTTP/1.1
Host: issuer.fleetinspect.example

Response

{
  "c_nonce": "fi-nonce-77aa"
}

The wallet now builds the proof JWT from two JSON objects, a header and a payload, and signs them with the private key the credential will be bound to.

Header: what this JWT is and which key signed it

{
  "typ": "openid4vci-proof+jwt",
  "alg": "ES256",
  "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
}

• typ: marks this as an OpenID4VCI key proof, so it cannot be mistaken for any other kind of JWT
• alg: the signing algorithm, one the issuer listed in proof_signing_alg_values_supported
• jwk: the public key the credential will be bound to; the issuer checks the signature against it

Payload: who the proof is for and when it was made

{
  "aud": "https://issuer.fleetinspect.example",
  "iat": 1789376400,
  "nonce": "fi-nonce-77aa"
}

• aud: the issuer identifier, so the proof cannot be replayed at a different issuer
• iat: the time the proof was created, in seconds since 1970
• nonce: the c_nonce from the nonce endpoint, which shows the proof is fresh

Signed result

Header and payload are each base64url-encoded and joined with a dot. The wallet signs that string with its private key and appends the base64url-encoded signature after a second dot. The resulting string is the proof JWT the wallet sends in the credential request in step 5.

base64url(header) . base64url(payload) . base64url(signature)

eyJ0eXAiOiJvcGVuaWQ0dmNpLXByb29mK2p3dCIs...
  .eyJhdWQiOiJodHRwczovL2lzc3Vlci5mbGVldGluc3BlY3QuZXhhbXBsZSIs...
  .<ES256 signature>

When the credential is not ready yet: deferred issuance

The example above assumes the inspection result is already final. If the inspection body instead needs to escalate a borderline result to a senior inspector, the credential endpoint cannot return the credential straight away, so it defers issuance.

Deferred response from /credential

HTTP/1.1 202 Accepted
Content-Type: application/json

{
  "transaction_id": "fi-tx-55c2",
  "interval": 900
}

Polling /deferred until it is ready

POST /deferred HTTP/1.1
Host: issuer.fleetinspect.example
Content-Type: application/json
Authorization: Bearer fi-at-3d91e0

{ "transaction_id": "fi-tx-55c2" }

// While the review is open: 202 with the same transaction_id and interval.
// Once approved: 200 with the credentials, optionally with a notification_id.
// If the review rejects the result: a credential_request_denied error.

Related terms

Sources

1. OpenID for Verifiable Credential Issuance 1.0
2. OpenID4VC High Assurance Interoperability Profile 1.0
3. EUDI Wallet Architecture and Reference Framework