Wystawianie poświadczeń OpenID4VCI wyjaśnione: od oferty do zaakceptowanego poświadczenia

Pełny cykl życia oferty poświadczenia

Specyfikacja nie definiuje nazwanych stanów, ale przepływ zainicjowany przez wystawcę, w którym poświadczenie jest wystawiane od razu, najłatwiej śledzić jako sekwencję poniżej. Każdy krok może zawieść na swój sposób, a implementacja portfela musi obsłużyć te ścieżki, a nie tylko tę pomyślną.

2. Odkrycie metadanych wystawcy

Zanim o cokolwiek poprosi, portfel pobiera metadane wystawcy, aby dowiedzieć się, co zawiera roadworthiness_certificate oraz jakie punkty końcowe wywoływać. Metadane nie wymieniają osobnych serwerów autoryzacji, więc wystawca jest jednocześnie swoim własnym serwerem autoryzacji, a portfel odczytuje punkt końcowy tokenu z metadanych tego serwera.

Metadane wystawcy poświadczeń (fragment)

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

Metadane serwera autoryzacji (fragment), z /.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. Dowód posiadania

Ponieważ metadane wymieniają nonce_endpoint, portfel najpierw pobiera stamtąd świeży c_nonce. Następnie udowadnia, że posiada klucz prywatny, z którym poświadczenie zostanie powiązane, podpisując proof JWT nad identyfikatorem wystawcy i tym c_nonce.

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

Odpowiedź

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

Portfel buduje teraz proof JWT z dwóch obiektów JSON, nagłówka i ładunku, i podpisuje je kluczem prywatnym, z którym poświadczenie zostanie powiązane.

Nagłówek: czym jest ten JWT i jaki klucz go podpisał

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

• typ: oznacza to jako dowód klucza OpenID4VCI, więc nie można go pomylić z żadnym innym rodzajem JWT
• alg: algorytm podpisu, jeden z tych, które wystawca wymienił w proof_signing_alg_values_supported
• jwk: klucz publiczny, z którym poświadczenie zostanie powiązane; wystawca sprawdza podpis względem niego

Ładunek: dla kogo jest dowód i kiedy powstał

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

• aud: identyfikator wystawcy, dzięki czemu dowodu nie można odtworzyć u innego wystawcy
• iat: czas utworzenia dowodu, w sekundach od 1970 roku
• nonce: c_nonce z punktu końcowego nonce, który pokazuje, że dowód jest świeży

Wynik podpisany

Nagłówek i ładunek są każdy kodowane w base64url i łączone kropką. Portfel podpisuje ten ciąg swoim kluczem prywatnym i dołącza zakodowany w base64url podpis po drugiej kropce. Powstały ciąg to proof JWT, który portfel wysyła w żądaniu poświadczenia w kroku 5.

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

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

Gdy poświadczenie nie jest jeszcze gotowe: wystawienie odroczone

Powyższy przykład zakłada, że wynik kontroli jest już ostateczny. Jeśli stacja kontroli musi zamiast tego przekazać wynik graniczny starszemu inspektorowi, punkt końcowy poświadczeń nie może od razu zwrócić poświadczenia, więc odracza wystawienie.

Odroczona odpowiedź z /credential

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

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

Odpytywanie /deferred, aż będzie gotowe

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.

Powiązane pojęcia

Źródła

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