OpenID4VCI credential-uitgifte uitgelegd: van aanbod tot geaccepteerde credential

De volledige levenscyclus van een credential-aanbod

De specificatie definieert geen benoemde states, maar een door de uitgever geïnitieerde flow waarbij de credential direct wordt uitgegeven, is het makkelijkst te volgen zoals hieronder weergegeven. Elke stap kan op zijn eigen manier mislukken, en een wallet-implementatie moet die paden afhandelen, niet alleen het gunstige scenario.

2. Ontdekking van uitgeversmetadata

Voordat er iets wordt aangevraagd, haalt de wallet de metadata van de uitgever op om te achterhalen wat roadworthiness_certificate bevat en welke endpoints moeten worden aangeroepen. De metadata vermeldt geen aparte autorisatieservers, dus is de uitgever zijn eigen autorisatieserver, en leest de wallet het token endpoint uit de metadata van die server.

Metadata van de credential-uitgever (uittreksel)

{
  "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"] }
        ]
      }
    }
  }
}

Metadata van de autorisatieserver (uittreksel), van /.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. Bewijs van bezit

Omdat de metadata een nonce_endpoint vermeldt, haalt de wallet daar eerst een verse c_nonce op. Vervolgens bewijst de wallet dat het de private key bezit waaraan de credential wordt gebonden, door een proof JWT te ondertekenen over de identifier van de uitgever en die c_nonce.

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

Response

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

De wallet bouwt nu de proof JWT op uit twee JSON-objecten, een header en een payload, en ondertekent deze met de private key waaraan de credential wordt gebonden.

Header: wat deze JWT is en welke sleutel heeft ondertekend

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

• typ: markeert dit als een OpenID4VCI key proof, zodat het niet wordt aangezien voor een ander soort JWT
• alg: het ondertekeningsalgoritme, een van de algoritmen die de uitgever vermeldde in proof_signing_alg_values_supported
• jwk: de publieke sleutel waaraan de credential wordt gebonden; de uitgever controleert de handtekening ertegen

Payload: voor wie de proof is en wanneer die is gemaakt

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

• aud: de identifier van de uitgever, zodat de proof niet bij een andere uitgever kan worden hergebruikt
• iat: het tijdstip waarop de proof werd gemaakt, in seconden sinds 1970
• nonce: de c_nonce van het nonce endpoint, die aantoont dat de proof vers is

Ondertekend resultaat

Header en payload worden elk base64url-gecodeerd en met een punt samengevoegd. De wallet ondertekent die string met de private key en voegt na een tweede punt de base64url-gecodeerde handtekening toe. De resulterende string is de proof JWT die de wallet in stap 5 meestuurt in het credentialverzoek.

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

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

Wanneer de credential nog niet klaar is: uitgestelde uitgifte

Het voorbeeld hierboven gaat ervan uit dat het keuringsresultaat al definitief is. Als de keuringsinstantie in plaats daarvan een grensgeval moet voorleggen aan een senior keurmeester, kan het credential endpoint de credential niet meteen teruggeven en stelt het de uitgifte uit.

Uitgestelde response van /credential

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

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

Bevragen van /deferred tot deze klaar is

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.

Gerelateerde termen

Bronnen

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