added format to authorization details and respective format specific additional claims

[tlodderstedt]

resolves #217.

[paulbastian]

As I stated in the WG Call, I believe that credential_configuration_id is the better choice. In general, I have trouble understanding how OpenID4VCI works well without metadata, as the Wallet needs to known:

• the credential endpoint
• supported proof types
• supported credentials and formats
• display data for the issuer and the credential

Therefore I believe in productive environment it will be very common that the Issuer has the ability to host metadata.

Moreover there are two ways to start Auth Code flow:

1. Credential Offer -> we need the credential_configuration_id anyway
2. The Wallet has implicit knowledge/is pre-configured, in this case it needs to know the credential_issuer anyway and it is not a big difference between storing format/type and configuration_id

In the end, my argument is that its less options to support, which is generally better. However I see that this is becoming very similar to scope, which is an indicator that the concept is not ideal yet and we are missing more implementation experience.

Therefore, feel free to override my request for change, I just wanted to share my opinion.

[Sakurann]

i think we need to figure out optional/must in the authorization request, but looks good otherwise.

[jogu]

As I stated in the WG Call, I believe that credential_configuration_id is the better choice. In general, I have trouble understanding how OpenID4VCI works well without metadata, as the Wallet needs to known:

• the credential endpoint
• supported proof types
• supported credentials and formats
• display data for the issuer and the credential

Therefore I believe in productive environment it will be very common that the Issuer has the ability to host metadata.

We had a fairly long conversation about this in one of last year's issues or PRs (likely the that one that first added configuration ids). As I understood it, the issue was not so much that people didn't want to have metadata at all - it was that they didn't want to be required to list every supported credential in the metadata. (There's parallels for this in OAuth, e.g. https://datatracker.ietf.org/doc/html/rfc8414#section-2 the AS isn't required to list every supported scope in scopes_supported.)

[awoie]

I'm not excited about this change. I agree with @paulbastian that metadata should be required, even if it was disseminated out-of-band. It would make things so much simpler. But I understand that people might have overlooked the implications in the previous PR that changed that assumption. I'm not blocking this PR, the content seems to be fine since it restores the previous state. I have just one suggestion below.

[c2bo]

I share some of the concerns of Paul (and the benefit of a reduction of complexity), but I agree that right now we probably have too little experience/feedback. So I guess the best approach at the current state of the draft is to keep it in and revisit later.
That being said, I do believe we should definitely revisit this sometime this year.

per Paul's written and verbal comments