OpenID4VCI-Credential-Ausstellung erklärt: vom Angebot zum akzeptierten Credential

Der vollständige Lebenszyklus eines Credential-Angebots

Die Spezifikation definiert keine benannten Zustände, aber ein vom Aussteller initiierter Ablauf, bei dem das Credential sofort ausgestellt wird, lässt sich am leichtesten wie in der folgenden Abfolge nachvollziehen. Jeder Schritt kann auf seine eigene Weise fehlschlagen, und eine Wallet-Implementierung muss diese Pfade behandeln, nicht nur den erfolgreichen.

2. Entdeckung der Aussteller-Metadaten

Bevor sie etwas anfordert, ruft die Wallet die Metadaten des Ausstellers ab, um zu erfahren, was roadworthiness_certificate enthält und welche Endpunkte aufzurufen sind. Die Metadaten listen keine separaten Autorisierungsserver auf, daher ist der Aussteller sein eigener Autorisierungsserver, und die Wallet liest den Token-Endpunkt aus den Metadaten dieses Servers.

Metadaten des Credential-Ausstellers (Auszug)

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

Metadaten des Autorisierungsservers (Auszug), von /.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. Besitznachweis

Da die Metadaten einen nonce_endpoint auflisten, ruft die Wallet dort zunächst einen frischen c_nonce ab. Anschließend beweist sie, dass sie den privaten Schlüssel besitzt, an den das Credential gebunden wird, indem sie ein Proof-JWT über die Kennung des Ausstellers und diesen c_nonce signiert.

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

Antwort

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

Die Wallet erstellt das Proof-JWT nun aus zwei JSON-Objekten, einem Header und einem Payload, und signiert sie mit dem privaten Schlüssel, an den das Credential gebunden wird.

Header: was dieses JWT ist und welcher Schlüssel es signiert hat

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

• typ: kennzeichnet dies als OpenID4VCI-Key-Proof, damit es nicht mit einer anderen Art von JWT verwechselt wird
• alg: der Signaturalgorithmus, einer der vom Aussteller in proof_signing_alg_values_supported aufgeführten
• jwk: der öffentliche Schlüssel, an den das Credential gebunden wird; der Aussteller prüft die Signatur dagegen

Payload: für wen der Proof bestimmt ist und wann er erstellt wurde

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

• aud: die Kennung des Ausstellers, damit der Proof nicht bei einem anderen Aussteller wiederverwendet werden kann
• iat: der Zeitpunkt, zu dem der Proof erstellt wurde, in Sekunden seit 1970
• nonce: der c_nonce vom Nonce-Endpunkt, der zeigt, dass der Proof frisch ist

Signiertes Ergebnis

Header und Payload werden jeweils base64url-codiert und mit einem Punkt verbunden. Die Wallet signiert diese Zeichenkette mit ihrem privaten Schlüssel und hängt die base64url-codierte Signatur nach einem zweiten Punkt an. Die entstehende Zeichenkette ist das Proof-JWT, das die Wallet in Schritt 5 in der Credential-Anfrage sendet.

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

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

Wenn das Credential noch nicht bereit ist: aufgeschobene Ausstellung

Das obige Beispiel geht davon aus, dass das Prüfergebnis bereits endgültig ist. Muss die Prüfstelle stattdessen ein Grenzfallergebnis an einen leitenden Prüfer eskalieren, kann der Credential-Endpunkt das Credential nicht sofort zurückgeben und schiebt die Ausstellung auf.

Aufgeschobene Antwort von /credential

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

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

Abfragen von /deferred, bis es bereit ist

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.

Verwandte Begriffe

Quellen

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