Pre-Authorized Code Flow: When wallet must include authorization_details to the Token Request?

[babisRoutis]

In paragraph 6.1.1
there is the following text

Credential Issuers MAY support requesting authorization to issue a Credential using the authorization_details parameter. This is particularly useful, if the Credential Issuer offered multiple Credential Configurations in the Credential Offer of a Pre-Authorized Code Flow.

From a wallet perspective, it is not clear, IMHO, when authorization_details MUST be included to the token request in Pre-Authorized Code Flow.
From the Issuer perspective, it is also not clear how will can the wallet be informed that it MUST use authorization_details in Pre-Authorized Code Flow.

For instance, taking the example from 6.2 and assuming there was a credential offer with a Pre-Authorized Code Flow

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ",
  "token_type": "bearer",
  "expires_in": 86400,
  "c_nonce": "tZignsnFbp",
  "c_nonce_expires_in": 86400,
  "authorization_details": [
    {
      "type": "openid_credential",
      "credential_configuration_id": "UniversityDegreeCredential",
      "credential_identifiers": [ "CivilEngineeringDegree-2023", "ElectricalEngineeringDegree-2023" ]
    }
  ]
}

• How wallet would know that it should include authorization_details to the token request (to receive such a response)?
• The same question can be put also from the Issuer side: In which way issuer conveys to the wallet that it must use authorization_details for a specific credential_configuration_id?

PS: In the authorization code flow, the absence/presence of a scope in the credential_configuration_id meta-data could be used as a hint. If scope is missing probably authorization_details should be used.

[jogu]

My take:

There should never be a requirement from an issuer for the wallet to include authorization_details. The spec text intends to indicate it's up to the wallet whether it does it or not.

The case where the wallet would do it is when it has a specific integration with that issuer and is aware it can usefully do something by including authorization_details (which in this context would most likely be requesting the issuance of fewer credentials than the full set the pre-authorised code is authorised for). i.e. this is pretty similar to how scopes work in normal OAuth - the wallet has to have some out-of-band knowledge of what scopes to use to achieve what it wants to achieve.

The default position is that the pre-authorised code alone is sufficient and will result in the wallet receiving all the credentials the issuer intends to issue.

[babisRoutis]

Dear @jogu thank you for your comment.

I think that there are issuance use-cases which cannot be implemented without authorizations_details. Those are the cases were credential_identifiers are needed, for a given credential_configuration_id
To my understanding, this was one of the reasons for which authorization_details support was added to d14.

Not having a way to communicate this requirement to the wallet, leaves as the only option what you call "specific integration", in your comment.

I think, though, that this need for a "special integration" limits, to some extend, the interoperability wallet/issuer .

An anticipated, feature was added to d14 (to use authorization_details in Pre-Authorized Code), yet I miss a way to allow the Issuer to convey the above requirement to the wallet.

[jogu]

Ah, so there is an issue open to potentially clarify things in the spec here: #242

I think there's an assumption above that an authorization_details in the response can only be provided if an authorization details is provided in the request?

I believe that an authorization_details can be provided in the token endpoint response for the pre-authorised code even when an authorization_details is not in the request. Would making that clear in the specification resolve your concern?

[babisRoutis]

Hi @jogu

Yes. I think that at the end of the day what is creating confusion is the phrase:

authorization_details: REQUIRED when the authorization_details parameter is used to request issuance of a certain Credential Configuration as defined in Section 5.1.1. It MUST NOT be used otherwise.

This clearly describes that token response can have authorization_details only if authorization_details was included to authorization request and probably implies the same for token request.

What you suggest for Pre-authorized Code flow, that is authorization_details can be included to token response even without using authorization_details in the token request, makes totally sense.

In Pre-Authorized Code, an implied "authorization" has already happened and token endpoint just returns the authorization details and the access token for this.