[Openid-specs-ab] Issue #1826: OpenID4VCI: authorization_pending in a token response (openid/connect)

Takahiko Kawasaki issues-reply at bitbucket.org
Tue Feb 21 17:54:00 UTC 2023


New issue 1826: OpenID4VCI: authorization_pending in a token response
https://bitbucket.org/openid/connect/issues/1826/openid4vci-authorization_pending-in-a

Takahiko Kawasaki:

From Section 6.2. Successful Token Response of the draft 11 of “OpenID for Verifiable Credential Issuance”:

* `authorization_pending`: OPTIONAL. JSON Boolean. In the Pre-Authorized Code Flow, the Token Request is still pending as the Credential Issuer is waiting for the End-User interaction to complete. The client SHOULD repeat the Token Request. Before each new request, the client MUST wait at least the number of seconds specified by the `interval` response parameter. ToDo: clarify boolean.

I’m not sure that the `authorization_pending` response parameter should be added in a token response. The response parameter assumes that the “**authorization server**” \(hosting the token endpoint\) can know whether the “**credential issuer**” is ready to issue the requested credential\(s\). It does not seem a good idea that the OpenID4VCI specification requires token endpoint implementations check the readiness of credential issuers on every token request. The token endpoint should be dedicated only to issuing an access token that can be used at the credential endpoint \(and other family endpoints\) of the credential issuer.

If the idea of `authorization_pending` is needed to be introduced somewhere, it should be used in an error response from the credential endpoint \(and other family endpoints\) like below. This is what CIBA POLL/PING modes and Device Flow \(RFC 8628\) do.

```json
{
  "error": "authorization_pending"
}
```

What the client should repeat is not token requests but credential requests.



More information about the Openid-specs-ab mailing list