OpenID4VCI-udstedelse af legitimation forklaret: fra tilbud til accepteret legitimation

Hele livscyklussen for et legitimationstilbud

Specifikationen definerer ikke navngivne tilstande, men et issuer-initieret flow, hvor legitimationen udstedes med det samme, er nemmest at følge, som i sekvensen nedenfor. Hvert trin kan fejle på sin egen måde, og en wallet-implementering skal håndtere disse veje, ikke kun den ideelle.

2. Opdagelse af issuerens metadata

Før wallet anmoder om noget som helst, henter den issuerens metadata for at finde ud af, hvad roadworthiness_certificate indeholder, og hvilke endpoints der skal kaldes. Metadataen lister ingen separate authorization servers, så issueren er sin egen authorization server, og wallet læser token endpoint fra den servers metadata.

Metadata for credential issuer (uddrag)

{
  "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 for authorization server (uddrag), fra /.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å nøglebesiddelse

Fordi metadataen lister en nonce_endpoint, henter wallet først en frisk c_nonce der. Den beviser derefter, at den besidder den private nøgle, som legitimationen bliver bundet til, ved at signere en proof-JWT over issuer-identifikatoren og den c_nonce.

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

Svar

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

Wallet bygger nu proof-JWT'en ud fra to JSON-objekter, en header og en payload, og signerer dem med den private nøgle, legitimationen bliver bundet til.

Header: hvad denne JWT er, og hvilken nøgle der signerede den

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

• typ: markerer dette som en OpenID4VCI key proof, så den ikke kan forveksles med nogen anden slags JWT
• alg: signeringsalgoritmen, en af dem issueren angav i proof_signing_alg_values_supported
• jwk: den offentlige nøgle, legitimationen bliver bundet til; issueren tjekker signaturen mod den

Payload: hvem beviset gælder for, og hvornår det blev lavet

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

• aud: issuer-identifikatoren, så beviset ikke kan genbruges hos en anden issuer
• iat: tidspunktet, hvor beviset blev oprettet, i sekunder siden 1970
• nonce: c_nonce fra nonce endpoint, som viser, at beviset er frisk

Signeret resultat

Header og payload bliver hver base64url-kodet og sat sammen med et punktum. Wallet signerer den streng med sin private nøgle og tilføjer den base64url-kodede signatur efter et andet punktum. Den resulterende streng er den proof-JWT, wallet sender i legitimationsanmodningen i trin 5.

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

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

Når legitimationen ikke er klar endnu: udskudt udstedelse

Eksemplet ovenfor forudsætter, at synsresultatet allerede er endeligt. Hvis synsvirksomheden i stedet skal eskalere et tvivlsomt resultat til en seniorinspektør, kan credential endpoint ikke returnere legitimationen med det samme, så den udskyder udstedelsen.

Udskudt svar fra /credential

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

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

Spørger /deferred, indtil den er 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.

Relaterede begreber

Kilder

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