decouple credential metadata

[c2bo]

Closes #99

This is a bit different from what we discussed at last WG, thus marking it as draft for the time being.

[c2bo]

TODO: change all the examples

[Sakurann]

WG discussion:

• direction seems to make sense.

[sloops77]

@c2bo I'm not a fan of adding a credential_metadata claim. It's too generic sounding and makes me wonder why many other credential configuration isnt in there

Some options to consider:

1. rename the property to display_metadata, display_descriptor. Is there any purpose for this property than for wallet display?
2. type_metadata is an alternative to the above and shows alignment with sd-jwt-vc type metadata
3. nest claims inside of display, and update the sd-jwt-vc spec

[c2bo]

@c2bo I'm not a fan of adding a credential_metadata claim. It's too generic sounding and makes me wonder why many other credential configuration isnt in there

Some options to consider:

1. rename the property to display_metadata, display_descriptor. Is there any purpose for this property than for wallet display?
2. type_metadata is an alternative to the above and shows alignment with sd-jwt-vc type metadata
3. nest claims inside of display, and update the sd-jwt-vc spec

I thought about different names as well, but the main thing I wanted to make sure was that from the name it is clear that the "other" metadata is necessary before the Credential Request, whereas this is relevant during the lifetime of the credential. Right now we have mainly display information but there could be other metadata with the same lifecylce -> a more generic name made sense to me. More opinions on that topic?

[paulbastian]

Does it make sense to separate the other display then into an issuer_metadata object?

[Sakurann]

WG discussion:

• current structure of the issuer metadata makes sense. also to enable a use-case of sending this object in the credential response
• no concerns with credential_metadata parameter
• merge once @leecam and @lchacha 's review is in

[sloops77]

I have two related concerns:

• this change feels quite sd-jwt specific, and I don't think it is clear why properties of the credential configuration such as format and credential_definition are defined outside of a property called credential_metadata, but display and claims are in there unless one is familiar with the sd-jwt spec.

• I think defining override mechanisms is really worthwhile, but it could encompass more than this credential_metadata. Our ecosystem uses w3c VCs and has a multitude of issuers all whom would benfit from delegating a default set of credential configurations to an ecosystem endpoint, and allow issuers to optionally override these default settings. This kind of override would be perhaps accepting a particular proof type or using a particular signing algs, or it could even be a whole credential configuration unique to the issuer.

[c2bo]

• this change feels quite sd-jwt specific, and I don't think it is clear why properties of the credential configuration such as format and credential_definition are defined outside of a property called credential_metadata, but display and claims are in there unless one is familiar with the sd-jwt spec.

My rationale was that things like format and credential_definition are necessary for choices the wallet makes during the issuance process/flow, whereas everything in credential_metadata is about longterm information about the credential, mainly for display purposes right now.

It would imho also be a clear path forward for #421 to allow for another display override via the credential response (which would then also be scoped on this object).

• I think defining override mechanisms is really worthwhile, but it could encompass more than this credential_metadata. Our ecosystem uses w3c VCs and has a multitude of issuers all whom would benfit from delegating a default set of credential configurations to an ecosystem endpoint, and allow issuers to optionally override these default settings. This kind of override would be perhaps accepting a particular proof type or using a particular signing algs, or it could even be a whole credential configuration unique to the issuer.

The idea was to initially define the override for information that is not critical to the issuance process itself (like format, signing algs etc.), but information like display that in itself does not create an interop problem and the wallet could always fall back to the "default" information in the metadata.

An override mechanism that modifies the issuance flow would have a lot more implications and we need to be really careful to not create interop issues here.

[jogu]

As agreed at last week's WG call ( https://github.com/openid/OpenID4VCI/pull/500#issuecomment-2967331167 ) - we now have @leecam & @lchacha 's reviews/approvals, and have discussed this mechanism at a few WG calls, and all comments seem to have been addressed, so we're good to merge - thank you. If people have further improvements to wordings or parameter names feel free to open an issue with suggestions ASAP :)