Paul Bastian

Doesn't this belong into attestation based client authentication draft?

we may adapt this to terminology WTE and WIA

HAIP currently says in Section 7: "https://openid.github.io/oid4vc-haip-sd-jwt-vc/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-wg-draft.html#section-7-5.3"

HAIP currently says: "x.509 certificates: the SD-JWT VC contains the issuer's certificate along with a trust chain in the x5c JOSE header. In this case, the iss value MUST be...

So my analysis is: - we want Issuers to support both web-based and x509 keys at the same time - almost all x509 certificates today use dNSName SAN - SD-JWT...

This would likely be countered by client attestation, however client attestation is probably not required but recommended?

I totally agree that the requirements in the credential logo are not precise enough, I also like svg. However I think this is an issue that should be addressed for...

Related to #120 Also related #1, probably reusing the key attestations that we introduced in OpenID4VCI

I would define a very limited number of crypto suites that shall be used, obviously ES256 but not so much else

I agree using iss field for x509 as well. It has the advantage of having a common identifier for both mechanisms. EV and QWAC work the same way