OpenID4VCI: authorization_pending in a token response
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 theinterval
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.
Comments (13)
-
reporter -
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.
-
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.
-
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
-
In my proposal, I don’t think the authorization pending error code in the credential endpoint would be needed anymore.
-
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.
-
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 anauthorization_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. -
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?
-
filed PR #488 to move
authorization_pending
to the token error response section -
- changed status to open
-
taka noted that CIBA core also uses authorization_pending
-
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
-
- changed status to resolved
PR #488 merged.
- Log in to comment
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.