OpenID4VCI kredencialo išdavimas paaiškintas: nuo pasiūlymo iki priimto kredencialo

Visas kredencialo pasiūlymo gyvavimo ciklas

Specifikacija neapibrėžia pavadintų būsenų, tačiau išdavėjo inicijuotą procesą, kuriame kredencialas išduodamas iš karto, lengviausia sekti taip, kaip parodyta toliau pateiktoje sekoje. Kiekvienas žingsnis gali nepavykti savaip, ir piniginės diegimas turi apdoroti tuos atvejus, ne tik sėkmingą scenarijų.

2. Išdavėjo metaduomenų paieška

Prieš pateikdama bet kokią užklausą, piniginė gauna išdavėjo metaduomenis, kad sužinotų, ką apima roadworthiness_certificate ir kokius galinius taškus reikia kviesti. Metaduomenyse nenurodyti atskiri autorizacijos serveriai, todėl išdavėjas yra pats savo autorizacijos serveris, o piniginė prieigos rakto galinį tašką nuskaito iš to serverio metaduomenų.

Kredencialo išdavėjo metaduomenys (ištrauka)

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

Autorizacijos serverio metaduomenys (ištrauka) iš /.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. Rakto turėjimo įrodymas

Kadangi metaduomenyse nurodytas nonce_endpoint, piniginė pirmiausia iš ten gauna šviežią c_nonce. Tada ji įrodo, kad turi privatų raktą, prie kurio kredencialas bus priskirtas, pasirašydama proof JWT su išdavėjo identifikatoriumi ir tuo c_nonce.

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

Atsakymas

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

Dabar piniginė sukuria proof JWT iš dviejų JSON objektų, antraštės ir naudingosios apkrovos, ir pasirašo juos privačiu raktu, prie kurio bus priskirtas kredencialas.

Antraštė: kas yra šis JWT ir kuriuo raktu jis pasirašytas

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

• typ: žymi, kad tai OpenID4VCI rakto įrodymas, todėl jo negalima supainioti su jokiu kitu JWT tipu
• alg: pasirašymo algoritmas, vienas iš tų, kuriuos išdavėjas nurodė proof_signing_alg_values_supported sąraše
• jwk: viešasis raktas, prie kurio bus priskirtas kredencialas; išdavėjas pagal jį tikrina parašą

Naudingoji apkrova: kam skirtas įrodymas ir kada jis sukurtas

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

• aud: išdavėjo identifikatorius, kad įrodymo nebūtų galima pakartotinai panaudoti pas kitą išdavėją
• iat: įrodymo sukūrimo laikas, sekundėmis nuo 1970 metų
• nonce: c_nonce iš nonce endpoint, rodantis, kad įrodymas yra šviežias

Pasirašytas rezultatas

Antraštė ir naudingoji apkrova kiekviena užkoduojama base64url formatu ir sujungiamos tašku. Piniginė pasirašo šią eilutę savo privačiu raktu ir po antro taško prideda base64url užkoduotą parašą. Gauta eilutė yra proof JWT, kurį piniginė siunčia kredencialo užklausoje 5 žingsnyje.

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

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

Kai kredencialas dar neparuoštas: atidėtas išdavimas

Aukščiau pateiktame pavyzdyje daroma prielaida, kad apžiūros rezultatas jau galutinis. Jei vietoj to apžiūros įstaigai reikia perduoti ribinį rezultatą vyresniajam apžiūrėtojui, kredencialo galinis taškas negali iš karto grąžinti kredencialo, todėl jis atideda išdavimą.

Atidėtas atsakymas iš /credential

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

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

Apklausiamas /deferred, kol jis bus paruoštas

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.

Susijusios sąvokos

Šaltiniai

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