decoupling issuer metadata from the supported credentials metadata

[Sakurann]

bringing the conversation that started in SD-JWT VC oauth-wg/oauth-sd-jwt-vc#181 to VCI, because potentially moving credentials_supported part out of issuer metadata has implications and is related to some of the discussions in issue #82. Let's keep the conversation on this topic in SD-JWT VC issue tracker and not this one.

[Sakurann]

we probably need to add a paragraph clarifying the relationship between sd-jwt vc and VCI issuer metadata before doing 1.0 final

[Sakurann]

the agreement seems to be that

• when there is sd-jwt vc metadata, that takes precedence over VCI metadata
• when there is no sd-jwt vc metadata, VCI metadata must be used
• no alignment between the two is expected and sd-jwt vc metadata can keep evolving regardless of the vci metadata

[charsleysa]

• when there is no sd-jwt vc metadata, VCI metadata must be used

Is that for when there is no sd-jwt VC Type Metadata using any of the defined methods in sd-jwt VC? Or for when there's no Type Metadata when trying to use the vct as a HTTPS URL specifically?

See sd-jwt VC 6.3 for defined methods
https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-08.html#section-6.3

[Sakurann]

WG discussion:

• agreed with a direction in decoupling issuer metadata from the supported credentials metadata  #99 (comment)
• but make it generic and not specific to sd-jwt vc; w3c vcdm also has this metadata.
• default is VCI; credential format specific definitions (sd-jwt vc or w3c vcdm right now, can be more in the future) can overrule

[c2bo]

I started working on this and have a clarifying question:
Within credential_configurations_supported, there are currently a these paramters:

• format
• scope
• cryptographic_binding_methods_supported
• credential_signing_alg_values_supported
• proof_types_supported
• display
• claims (in the credential format specific parts, but maybe we can move that out into the generic parts? the text is always the same)

Everything but display and claims is important for the choices a wallet makes before creating the Credential Request and we would probably run into interop problems if we touch those with format specific information. The parameters that would be relevant for the overwriting rules are those that have impact after we receive a credential which currently only seems to be display and claims?

I wonder how to best scope the PR and while creating a first proposal asked myself if it wouldn't make sense to move claims and display out of the credential_configurations_supported parameter or into one dedicated display parameter inside it? That way there would be a clear separation between information that is relevant for the Credential Request and information that is relevant for dealing with the credential after receiving it (display etc).

Would people be comfortable moving display and claims into something like credential_metadata and then allow credential format specific mechanisms to overwrite this information? I know this is a breaking change but feels a lot cleaner to me.