Clarification on authorization_details for Pre-Authorized Code Flow

[hesusruiz]

I think it would be clarifying to mention explicitly that the Token Request, when using the Pre-Authorized Code Flow, can include an authorization_details object of type openid_credential with a credential_configuration_id.

The current text:

When the Pre-Authorized Grant Type is used, it is RECOMMENDED that the Credential Issuer issues an Access Token valid only for the Credentials indicated in the Credential Offer.

does not mention explicitly that the Token Request can indicate the specific credential being requested, via one of the credential_configuration_id described in the Credential Offer.

This explicit mention could help clear any potential confusion that the reader may have with this text in the Token Response:

authorization_details: REQUIRED when authorization_details parameter is used to request issuance of a certain Credential type as defined in [Section 5.1.1]

Because Section 5.1.1 is inside the Authorization Request section and the reader may understand that it can only be used in that context.

[babisRoutis]

Indeed this is confusing for me as well.

Reading just the token response requirement

authorization_details: REQUIRED when authorization_details parameter is used to request issuance of a certain Credential type as defined in [Section 5.1.1](https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#authorization-details). It MUST NOT be used otherwise.

I get the impression that authorization_details must not be included in token response in case of pre-authorized grant.

I think thought that this is not the case. Otherwise there is no way, i think, that AS can convey to the wallet credential_identifiers in case of pre-authorized code.

I agree with @hesusruiz proposal to specify that authorization_details can also be used in case of pre-authorized grant

[Sakurann]

looks like there are several points...?

• for the authorization code grant, it is true that authorization_details can be used in token request. but it is not a pre-requisite for authorization_details to be included in the token response because authorization details was already included in the authorization request.
• the bigger question is whether for the authorization_details is required in the token request in the pre-auth code flow to use authorization_details in the token response, because there is no authorization request, and I think the answer should be yes? @tlodderstedt

[tlodderstedt]

good question. OAuth allows to request an access token without any scope or authorization details object. In case of a pre authz grant, I would assume a token request without authorization details will request an access token for all credentials authorized by the pre authz code. The wallet can specify authorization details, which makes especially sense if only a sub set of the authorized credentials shall be requested.

[jogu]

• the bigger question is whether for the authorization_details is required in the token request in the pre-auth code flow to use authorization_details in the token response, because there is no authorization request, and I think the answer should be yes?

I think the AS could return authorization_details for the pre-auth code even when authorization_details is not in the token request.

Essentially as far as I can see we don't specify any details about how that pre-auth code was created, and the issuer would be free to have asked the AS to generate the authz code on the basis of a nominal authorization request that included a 'scope', or on the basis of a nominal authorization request that included an 'authorization_details'

[hesusruiz]

good question. OAuth allows to request an access token without any scope or authorization details object. In case of a pre authz grant, I would assume a token request without authorization details will request an access token for all credentials authorized by the pre authz code. The wallet can specify authorization details, which makes especially sense if only a sub set of the authorized credentials shall be requested.

In my use case (an employee credential with delegated powers from the legal representative of the employer organisation), I feel like I want to return authorization_details from the Token response even in the case where the Token Request does not include authorization_details. My reasoning is the following:

• We use Pre-Auth code flow to authorise only one credential (extracting employee data from the HR DB).
• The credential is signed with the eIDAS certificate owned by the legal representative (a natural person).
• After the Token Response, the Wallet can suspend the flow until the employee receives a notification that the legal representative has signed the credential (from minutes to days). There is no need for polling the (Deferred) Credential endpoint until the Credential is ready, given the timing.
• Once the employee receives the notification, she can restart the flow by using the UI of the Wallet to select the suspended Token Response and activate it.

I would like to have the credential_configuration_id explicitly associated to the Token Response, so the Wallet can display to the user the proper information for restart. Of course, it is not strictly required, because the Wallet can derive the credential_configuration_id from the Credential Offer, but I think putting it also in the Token Response makes the flow more "self-documented" and less prone to errors.

[Sakurann]

@hesusruiz putting pending-close and closing in a week unless objections, since i believe what you have been asking for has been enabled in #392.
Please take a look at https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-3.3.4 too

[Sakurann]

closing #279 (comment) conditional to "including in the spec the clarification of #242. As a clarification I consider your #242 (comment)"

[hesusruiz]

@hesusruiz putting pending-close and closing in a week unless objections, since i believe what you have been asking for has been enabled in #392. Please take a look at https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-3.3.4 too

Looks good to me.