Allow issuers to specify proof type preference

Some issuers have raised the question of how they could specify their preference for the key proof types through the standard.

Today, the Credential Issuer that requires key binding defines in its Credential Issuer Metadata proof_types_supported the key proof(s) it supports. The proof_types_supported is an object keyed by different proof types. Therefore, there's no semantics for ordering / preference. When the wallet supports and matches multiple proof types, it is up to the wallet to pick one to use.

"proof_types_supported": {
    "jwt": {...},
    "attestation": {...},
    "android-key-attestation": {...}
}

Meanwhile, issuers may want to specify their own preference out of their own security and performance consideration. For example, we are proposing an extension type android-key-attestation that allows key proofs through Android attestation generated directly from the device secure hardware. An issuer may want to prefer this proof type whenever it's viable for the added security.

Some options to allow proof type ordering are, and not limited to:

• Update the standard to support proof type ordering
  If the proof_types_supported object were an array, then we could have used it to convey ordering. However, changing the type is probably breaking at this point. To do this in a non-breaking way, we could add a new issuer metadata parameter called proof_types_preference that ranks the keys in the proof_types_supported object, or something on that line.
• Rely on certification to specify the ordering
  Can only work if the certification process can define an ordering that applies uniformly to its use case. Unsure whether the certification process can get to this level of details.
• Out-of-band agreement with each wallet.
  This can already be done today. It can be a baseline option. However, if we only rely on this option, there is a gap for use cases where issuers are willing to issue into any certified wallets. It also makes updating the ordering hard to maintain.

Open to more ideas and options!

No repository files or tests are named. Start by reviewing the Credential Issuer Metadata section for proof_types_supported and the stated ordering options; done requires an agreed, non-breaking way for issuers to express proof-type preference in the standard.