OpenID4VCI-utstedelse av legitimasjon forklart: fra tilbud til akseptert legitimasjon

Hele livssyklusen til et legitimasjonstilbud

Spesifikasjonen definerer ikke navngitte tilstander, men en issuer-initiert flyt der legitimasjonen utstedes med en gang er enklest å følge, som i sekvensen under. Hvert trinn kan feile på sin egen måte, og en wallet-implementasjon må håndtere disse stiene, ikke bare den vellykkede.

2. Oppdagelse av issuerens metadata

Før wallet ber om noe som helst, henter den issuerens metadata for å finne ut hva roadworthiness_certificate inneholder og hvilke endepunkter som skal kalles. Metadataene lister ingen egen authorization server, så issueren er sin egen authorization server, og wallet leser token endpoint fra den serverens metadata.

Metadata for 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 for authorization server (utdrag), 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økkelbesittelse

Fordi metadataene lister et nonce_endpoint, henter wallet først en fersk c_nonce der. Deretter beviser den at den innehar den private nøkkelen legitimasjonen skal bindes til, ved å signere en proof-JWT over issuer-identifikatoren og denne c_nonce-en.

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

Svar

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

Wallet bygger nå proof-JWT-en fra to JSON-objekter, en header og en payload, og signerer dem med den private nøkkelen legitimasjonen skal bindes til.

Header: hva denne JWT-en er og hvilken nøkkel som signerte den

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

• typ: markerer dette som en OpenID4VCI key proof, slik at den ikke kan forveksles med noen annen type JWT
• alg: signeringsalgoritmen, en av dem issueren listet i proof_signing_alg_values_supported
• jwk: den offentlige nøkkelen legitimasjonen skal bindes til; issueren kontrollerer signaturen mot denne

Payload: hvem beviset gjelder og når det ble laget

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

• aud: issuer-identifikatoren, slik at beviset ikke kan gjenbrukes hos en annen issuer
• iat: tidspunktet beviset ble opprettet, i sekunder siden 1970
• nonce: c_nonce fra nonce endpoint, som viser at beviset er ferskt

Signert resultat

Header og payload er hver base64url-kodet og satt sammen med et punktum. Wallet signerer denne strengen med sin private nøkkel og legger til den base64url-kodede signaturen etter et andre punktum. Den resulterende strengen er proof-JWT-en wallet sender i legitimasjonsforespørselen i trinn 5.

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

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

Når legitimasjonen ikke er klar ennå: utsatt utstedelse

Eksempelet over forutsetter at kontrollresultatet allerede er endelig. Hvis kontrollorganet i stedet må eskalere et tvilsomt resultat til en seniorkontrollør, kan credential endpoint ikke returnere legitimasjonen med en gang, så den utsetter utstedelsen.

Utsatt svar fra /credential

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

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

Spørring mot /deferred til 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.

Relaterte begreper

Kilder

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