Resolve issue with conflicting 'MUST' & 'SHOULD' for key attestations

[jogu]

The 'MUST' for the proof types supported was not intended to be a MUST given we now have only a 'SHOULD' in the following section for supporting the key attestations format defined in OID4VCI.

closes #270

[paulbastian]

Does this mean if you use other key attestations then you may also use other proof_types?

[jogu]

Does this mean if you use other key attestations then you may also use other proof_types?

@paulbastian Hrrm. Good question. That was certainly where I was going.

I think this breaks down into two parts:

1. attestation proof type - as defined, I don't think this is usable with other formats of key attestations, so by definition you can't support that proof type I believe.
2. jwt proof type - I believe you can't put other formats of key attestations into the key_attestation header (according to the current text), but I believe you could define a new field that contains an attestation in a different format.

Does that sound correct? If so I'm not sure where that leaves us. Do you have a suggestion on what we should say?

[Sakurann]

WG discussion.

• update the text so that it is clearer that for non annex D key attestations, especially those that are not JWTs, additional proof types would need to be defined most likely.
• and point out that even for non-JWT key attestations, jwt proof type can be used (but not attestation proof type)

[jogu]

Updated based on WG discussion, please re-review @paulbastian

[Sakurann]

reads really good!