Kristina

i think the comments in this issue pre-date the decision that led to PR #392 we have discussed it extensively. and this issuer should have been closed when we merged...

wg discussion: - are there implementations that use authorization details (with format) without credential offer? - do people need more time to think? or remove format from authorization details? -...

I think this is related to issues #132 and #197.

Credential is always identified by the combination of format and type (type claims are mandatory in the credential format profiles). `proof_types_supported` is optional to enable the use-cases when issuer wants...

@jogu, it feels like multiple problems are being confused. a problem that one of the credential_configurations_supported object lacks `proofs_supported` so the wallet does not know which proof_type is supported is...

for the first problem, as I said previously, `we can make it clearer in the description that if the issuer requires key binding, the parameter must be present`. for the...

@TakahikoKawasaki there is more than one company that has ASs that have limitations that do not allow them to make changes easily or to have intermediary ASs/wrappers, etc. and as...

@paulbastian @c2bo is this addressed in #389 PR?

I think your use-case can be solved by defining credentials_configurations_supported objects with same format&type combination but different credential_configuration_id. credential_configuration_id needs to be unique per credential.

closing since this is true: > In case we have a holder that is entitled to more that one credential instances (those instance share the same credential_configuration_id, the same claim...