OpenID4VCI: authorization_pending in a token response

[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.

{
  "error": "authorization_pending"
}

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

[Takahiko Kawasaki]

One more thing to mention is that the current specification results in requiring the credential issuer to get ready before the short-lived pre-authorized code expires. It’s because it is only while the pre-authorized code is alive that the client can repeat token requests with the pre-authorized code. The lifetime of the pre-authorized code and the time needed for the credential issuer to get ready should be decoupled.

[Torsten Lodderstedt]

Excellent point (again). We introduced this feature when AS and Credential Issuer were considered the same entity. I agree with your proposal.

Before we change the text, we should revisited whether we need this feature altogether.

[Arjen van Veen]

Thanks for raising this Takahiko. We are currently implementing and found the same issues you have. I like the feature and I think it’s valuable for it to be there. If we do make it an error type on the credential endpoint we should make it distinct from the authorization_pending error type for replay attack prevention.

[Oliver Terbu]

In our use case, it would be actually quite nice if the token endpoint doesn’t issue the access token unless the authorization has been done → not pending anymore.

However, it would be great if the token endpoint would return an error instead of an access token in that case, so the credential endpoint cannot be confused by issuing the credential because a valid access token was presented although authorization was still pending.

This means that we could also discuss the option where:

• /token endpoint returns an authorization_pending error, with no access token

‌

[Oliver Terbu]

In my proposal, I don’t think the authorization pending error code in the credential endpoint would be needed anymore.

[Brian Campbell]

I’d tend to agree w/ Taka. And this might be naive but “pre-authorized” very much suggests that authorization has already happened. Regardless, if something like a waiting feature is needed, it should probably be a status or error response and not some extra stuff on a token response like it is now.

‌

‌

[Kristina Yasuda]

authorization_pending was intended to be in the token error response, so the current spec text that is is in the token response is wrong. That’s why Section 11.3.1 says “the Credential Issuer returns an authorization_pending error code to the Wallet”. The same section also explains the rationale behind authorization_pending - it was intended to be a security feature for cross-device flows.

[Kristina Yasuda]

the current specification results in requiring the credential issuer to get ready before the short-lived pre-authorized code expires

Per Section 11.3.1, when authorization_pening error code in the token error response is used to give time to get the user consent to proceed on the originating device, on which QR code with credential_offer was displayed in a cross-device flow, Credential Issuer does not have to be ready when the Wallet retrieves Access Token using pre-auth code. Credential Issuer can return acceptance_token if it is not ready. what am I missing?

‌

[Torsten Lodderstedt]

filed PR #488 to move authorization_pending to the token error response section

[Kristina Yasuda]

taka noted that CIBA core also uses authorization_pending

[Torsten Lodderstedt]

just updated PR #488 to align with CIBA and RFC 8628, also clarified the mechanism works with pre-authz code and cde - please review and approve

[Kristina Yasuda]

PR #488 merged.