Emisión de credenciales OpenID4VCI explicada: de la oferta a la credencial aceptada

El ciclo de vida completo de una oferta de credencial

La especificación no define estados con nombre, pero un flujo iniciado por el emisor en el que la credencial se emite de inmediato es el más fácil de seguir, como en la secuencia siguiente. Cada paso puede fallar a su manera, y una implementación de wallet debe gestionar esas rutas, no solo la favorable.

2. Descubrimiento de metadatos del emisor

Antes de solicitar nada, la wallet obtiene los metadatos del emisor para saber qué contiene roadworthiness_certificate y qué endpoints llamar. Los metadatos no listan servidores de autorización separados, por lo que el emisor es su propio servidor de autorización, y la wallet lee el endpoint de token de los metadatos de ese servidor.

Metadatos del emisor de credenciales (extracto)

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

Metadatos del servidor de autorización (extracto), de /.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. Prueba de posesión

Como los metadatos listan un nonce_endpoint, la wallet primero obtiene allí un c_nonce reciente. A continuación demuestra que posee la clave privada a la que se vinculará la credencial, firmando un proof JWT sobre el identificador del emisor y ese c_nonce.

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

Respuesta

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

La wallet construye ahora el proof JWT a partir de dos objetos JSON, una cabecera y un payload, y los firma con la clave privada a la que se vinculará la credencial.

Cabecera: qué es este JWT y qué clave lo firmó

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

• typ: marca esto como una key proof de OpenID4VCI, para que no se confunda con otro tipo de JWT
• alg: el algoritmo de firma, uno de los que el emisor listó en proof_signing_alg_values_supported
• jwk: la clave pública a la que se vinculará la credencial; el emisor comprueba la firma contra ella

Payload: para quién es la proof y cuándo se hizo

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

• aud: el identificador del emisor, para que la proof no pueda reutilizarse ante otro emisor
• iat: el momento en que se creó la proof, en segundos desde 1970
• nonce: el c_nonce del nonce endpoint, que muestra que la proof es reciente

Resultado firmado

La cabecera y el payload se codifican cada uno en base64url y se unen con un punto. La wallet firma esa cadena con su clave privada y añade la firma codificada en base64url tras un segundo punto. La cadena resultante es el proof JWT que la wallet envía en la solicitud de credencial del paso 5.

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

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

Cuando la credencial aún no está lista: emisión diferida

El ejemplo anterior supone que el resultado de la inspección ya es definitivo. Si en cambio el organismo de inspección necesita escalar un resultado límite a un inspector superior, el endpoint de credencial no puede devolver la credencial de inmediato, así que difiere la emisión.

Respuesta diferida de /credential

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

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

Consultando /deferred hasta que esté lista

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.

Términos relacionados

Fuentes

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