Extend Credential Endpoint to support explicit holder refresh and revocation requests

The OpenID4VCI protocol currently (13 May 2025) specifies how to issue and refresh verifiable credentials, with some reference to credential revocation. However, it does not provide a standard, explicit, interoperable mechanism for wallets to request “refresh” or “revoke” lifecycle operations for a given credential. This leads to ambiguity, especially for wallet-initiated credential management.

In the current flow, refreshing relies on implicit behavior: the wallet requests a new credential using the Token Endpoint, then the Credential Endpoint. It's up to the issuer to decide what action to take (e.g., issue a new credential, refresh claims, etc.). For revocation, there is no interoperable mechanism; it is left to ad-hoc solutions by each Credential Issuer, creating challenges for wallets seeking consistent selective revocation.

Proposal

• Extend the authorization_details object (per RFC 9396/RAR) with an optional action field for type == "openid_credential" in Token Endpoint requests.
• The action field may be set to "refresh" or "revoke" to indicate explicit lifecycle operations.
• Omitting the action field (or omitting authorization_details) means regular issuance/refresh as per existing flows.
• The credential to manage is referenced by credential_identifiers or credential_configuration_id.
• If present, Credential and Authorization servers SHOULD handle the action and respond accordingly.

Example 1: Implicit Refresh (no action sent)

Token request

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=eyJ... 

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "eyJabcd...",
  "token_type": "Bearer",
  "authorization_details": [
    {
      "type": "openid_credential",
      "credential_identifiers": ["cred123"]
    }
  ]
}

Credential request

POST /credential
Authorization: Bearer eyJabcd...
Content-Type: application/json

{
  "credential_identifier": "cred123",
  "proofs": {
    "jwt": [
      "eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ"
    ]
  },
}

Example 2: Explicit revocation

Token request

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=eyJ...
&authorization_details=%5B%7B%22type%22%3A%22openid_credential%22%2C%22credential_identifiers%22%3A%5B%22cred123%22%5D%2C%22action%22%3A%22revoke%22%7D%5D

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "eyJabcd...",
  "token_type": "Bearer",
  "authorization_details": [
    {
      "type": "openid_credential",
      "credential_identifiers": ["cred123"],
      "action": "revoke"
    }
  ]
}

Credential request

POST /credential
Authorization: Bearer eyJabcd...
Content-Type: application/json

{
  "credential_identifier": "cred123",
  "action": "revoke"
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "credentials": []
}

Start by reviewing the existing /token and /credential flows alongside RFC 9396/RAR and the OpenID4VCI issuance and refresh behavior. Trace how authorization_details, credential_identifiers, and credential_configuration_id are handled, then define interoperable refresh and revoke requests and responses using the proposal's examples as acceptance criteria.