[Openid-specs-ab] Issue #1719: Pre-auth flow: Credential binding of IIR and Access token for AS and RP (openid/connect)

[nklomp]

New issue 1719: Pre-auth flow: Credential binding of IIR and Access token for AS and RP
https://bitbucket.org/openid/connect/issues/1719/pre-auth-flow-credential-binding-of-iir

Niels Klomp:

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](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#format_profiles). 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 scope 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?