Define how credential metadata "layers" override each other

[fkj]

There are currently multiple ways to get credential metadata for a credential. #721 adds another one.

We should explicitly define the rules for how these sources override each other.

@c2bo posted a comment in #721 with his view:

They way I'd see metadata is in sort of a hierarchy:

• Issuer metadata: most general form level of metadata
• Optional format-specific metadata
• Metadata returned in Credential response

Where Issuer metadata is the default, gets overwritten by format-specific metadata if it exists (only for the values it contains), gets overwritten by credential response (only values that exist in the credential response)

From an implementation perspective:

• Take everything from the issuer metadata
• Check for format-specific metadata and for each value found, overwrite your current metadata construct
• Check Credential Response and for each value found, overwrite your current metadata construct

There was a session partially covering this at IIW. We came to the following conclusions (though feel free to debate):

• It makes sense to allow adding new keys in the metadata
• It probably does not make sense to allow deleting keys in the metadata
• We need to define rules for how/when to recursively go through keys to allow partial overrides
• We need to define rules for how to override arrays

[Wicpar]

It would be nice to know which level of metadata security the credential expects, and ignore lower security metadata according to that in addition to this hierarchy.

[fkj]

It would be nice to know which level of metadata security the credential expects, and ignore lower security metadata according to that in addition to this hierarchy.

You mean something like not allowing unsigned metadata to override signed metadata?

[Wicpar]

Yes exactly