Pre-auth flow: Credential binding of IIR and Access token for AS and RP

In the Pre-Authorized Code flow the IIR contains one or more credential strings or objects next to the pre-authorized code as defined below:

credentials: REQUIRED. JSON array, where every entry is a JSON Object or a JSON String. If the entry is an object, the object contains the data related to a certain credential type the Wallet MAY request. Each object MUST contain a format Claim determining the format of the credential to be requested and further parameters characterising the type of the credential to be requested as defined in Appendix E. If the entry is a string, the string value MUST be one of the id values in one of the Supported Credentials Objects in the credentials_supported Credential Issuer metadata parameter. When processing, the wallet MUST resolve this string value to the respective Supported Credentials Object.
pre-authorized_code: CONDITIONAL. The code representing the Credential Issuer's authorization for the Wallet to obtain Credentials of a certain type. This code MUST be short lived and single-use. MUST be present in a pre-authorized code flow.

‌

It might make sense to clarify the following a bit more:

The pre-authorized code resulting in the access-token should be bound to the credentials in the IIR right? Because a wallet would typically hit the well-known endpoints and might find out there are more credential types available. Since the IIR didn’t list them I doubt you would want to allow issuance of these credentials for the respective access token. If that is the case how to prevent this from an AS/RP perspective?

Comments (7)