Émission de credentials OpenID4VCI expliquée : de l'offre au credential accepté

Le cycle de vie complet d'une offre de credential

La spécification ne définit pas d'états nommés, mais un flux initié par l'émetteur où le credential est émis immédiatement est le plus simple à suivre, comme dans la séquence ci-dessous. Chaque étape peut échouer à sa manière, et une implémentation de wallet doit gérer ces chemins, pas seulement le scénario favorable.

2. Découverte des métadonnées de l'émetteur

Avant de demander quoi que ce soit, le wallet récupère les métadonnées de l'émetteur pour savoir ce que contient roadworthiness_certificate et quels endpoints appeler. Les métadonnées ne listent pas de serveur d'autorisation séparé, donc l'émetteur est son propre serveur d'autorisation, et le wallet lit le token endpoint dans les métadonnées de ce serveur.

Métadonnées de l'émetteur de credentials (extrait)

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

Métadonnées du serveur d'autorisation (extrait), depuis /.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. Preuve de possession

Comme les métadonnées listent un nonce_endpoint, le wallet y récupère d'abord un c_nonce récent. Il prouve ensuite qu'il détient la clé privée à laquelle le credential sera lié, en signant un proof JWT sur l'identifiant de l'émetteur et ce c_nonce.

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

Réponse

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

Le wallet construit maintenant le proof JWT à partir de deux objets JSON, un header et un payload, et les signe avec la clé privée à laquelle le credential sera lié.

Header : ce qu'est ce JWT et quelle clé l'a signé

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

• typ: marque ceci comme une key proof OpenID4VCI, afin qu'elle ne soit pas confondue avec un autre type de JWT
• alg: l'algorithme de signature, l'un de ceux que l'émetteur a listés dans proof_signing_alg_values_supported
• jwk: la clé publique à laquelle le credential sera lié ; l'émetteur vérifie la signature avec celle-ci

Payload : pour qui est la proof et quand elle a été créée

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

• aud: l'identifiant de l'émetteur, afin que la proof ne puisse pas être rejouée chez un autre émetteur
• iat: le moment où la proof a été créée, en secondes depuis 1970
• nonce: le c_nonce provenant du nonce endpoint, qui montre que la proof est récente

Résultat signé

Le header et le payload sont chacun encodés en base64url puis reliés par un point. Le wallet signe cette chaîne avec sa clé privée et ajoute la signature encodée en base64url après un second point. La chaîne résultante est le proof JWT que le wallet envoie dans la requête de credential à l'étape 5.

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

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

Quand le credential n'est pas encore prêt : l'émission différée

L'exemple ci-dessus suppose que le résultat du contrôle est déjà définitif. Si l'organisme de contrôle doit au contraire faire remonter un résultat limite à un inspecteur senior, le credential endpoint ne peut pas renvoyer le credential immédiatement, il diffère donc l'émission.

Réponse différée de /credential

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

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

Interrogation de /deferred jusqu'à ce qu'il soit prêt

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.

Termes associés

Sources

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