OpenID4VCI-utfärdande av legitimation förklarat: från erbjudande till accepterad legitimation

Hela livscykeln för ett legitimationserbjudande

Specifikationen definierar inga namngivna tillstånd, men ett issuer-initierat flöde där legitimationen utfärdas direkt är enklast att följa, som i sekvensen nedan. Varje steg kan misslyckas på sitt eget sätt, och en wallet-implementation måste hantera de vägarna, inte bara den lyckade.

2. Upptäckt av issuerns metadata

Innan wallet begär något alls hämtar den issuerns metadata för att ta reda på vad roadworthiness_certificate innehåller och vilka endpoints som ska anropas. Metadatan listar inga separata authorization servers, så issuern är sin egen authorization server, och wallet läser token endpoint från den serverns metadata.

Metadata för credential issuer (utdrag)

{
  "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 för authorization server (utdrag), från /.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. Bevis på nyckelinnehav

Eftersom metadatan listar en nonce_endpoint hämtar wallet först en färsk c_nonce därifrån. Den bevisar sedan att den innehar den privata nyckel som legitimationen ska bindas till, genom att signera en proof-JWT över issuer-identifieraren och den c_nonce:n.

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

Svar

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

Wallet bygger nu proof-JWT:n av två JSON-objekt, en header och en payload, och signerar dem med den privata nyckel legitimationen ska bindas till.

Header: vad den här JWT:n är och vilken nyckel som signerade den

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

• typ: markerar detta som en OpenID4VCI key proof, så att den inte kan misstas för någon annan typ av JWT
• alg: signeringsalgoritmen, en av dem issuern listade i proof_signing_alg_values_supported
• jwk: den publika nyckel legitimationen ska bindas till; issuern kontrollerar signaturen mot den

Payload: vem beviset gäller och när det skapades

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

• aud: issuer-identifieraren, så att beviset inte kan återanvändas hos en annan issuer
• iat: tidpunkten då beviset skapades, i sekunder sedan 1970
• nonce: c_nonce från nonce endpoint, vilket visar att beviset är färskt

Signerat resultat

Header och payload base64url-kodas var för sig och länkas samman med en punkt. Wallet signerar den strängen med sin privata nyckel och lägger till den base64url-kodade signaturen efter en andra punkt. Den resulterande strängen är den proof-JWT som wallet skickar i legitimationsbegäran i steg 5.

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

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

När legitimationen inte är klar än: uppskjutet utfärdande

Exemplet ovan förutsätter att besiktningsresultatet redan är slutgiltigt. Om besiktningsorganet i stället behöver eskalera ett tveksamt resultat till en senior inspektör kan credential endpoint inte returnera legitimationen direkt, och den skjuter då upp utfärdandet.

Uppskjutet svar från /credential

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

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

Frågar /deferred tills den är klar

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.

Relaterade begrepp

Källor

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