Define key resolution mechanisms for verifier attestation, wallet attestation, and status list issuers

[tlodderstedt]

The module drafts for client attestation (used for wallet attestation), verifier attestation (OID4VP) and status list define the schemas of the different assertions but do leave flexibility regarding the way keys are represented and resolved. The Interoperability profile will defines the concrete mechanisms to be used to achieve interoperability in the context of the profile.

Current idea is to support the same mechanisms currently used for SD-JWT VCs, web based key lookup and x.509 certificates. We could add one section with key resolution mechanisms and state where those are used.

[Sakurann]

related to #65, #119, #39

[tlodderstedt]

the spec now has text for client / wallet attestation and

• SD-JWT VCs: web-based key resolution and x.509
• wallet attestation: web-based key resolution
• verifier attestation: web-based key resolution
• status list: no requirement

I suggest to change the text to require both options for all credentials/attestations except mdoc based credentials, where only x.509 is supported. For status list also see #65 .

[Sakurann]

from ISO's perspective, I believe only x509_san_dns can be mandatory for mdoc over the browser API in HAIP

[Sakurann]

WG discussion:

• for verifier attestation: mandate x509_hash for both: The Client Identifier Scheme as introduced in Section 5.10 of [OIDF.OID4VP] MUST be x509_hash for both the wallet and the verifier.
• for sd-jwt vc issuer key resolution: mandate x509 for both issuer and the wallet and the verifier. mention web-based key resolution as an option.
• for wallet attestation, keeping the currect text: "The public key, and optionally a trust chain, used to validate the signature on the Wallet Attestation MUST be included in the x5c JOSE header".
• for status list, "The public key used to validate the signature on the Status List token MUST be included in the x5c JOSE header".

ecosystem free to extend, these are mandatory to implement but do not have to be used in each transaction.