[Openid-specs-digital-credentials-protocols] openid/oid4vc-haip-sd-jwt-vc: Comment created on issue 101

[github at oidf.org]

openid/oid4vc-haip-sd-jwt-vc event

Issue Comment created on issue 101
Issue Title: How does a credential issuer trust the wallet attestation issuer's public key?
https://github.com/openid/oid4vc-haip-sd-jwt-vc/issues/101

Comment: Thank you for response! As you wrote in your comment a trust model and a trust mechanism needs to be built on top HAIP. How easy that is depends partly on the foundations that HAIP and other underlying specfications lay out. The underlying specifications do have opinions regarding the trust mechanisms, at least indirectly. For example, let's consider the OAuth 2.0 Attestation-Based Client Authentication specification. It goes into quite a lot of detail in describing how trust in the wallet's public key is established. There are not that many ways one can build a trust mechanism on top of that specification. I think it's OK for the underlying specifications to have opinions regarding trust mechanisms. However, the specification should consider how easy or feasible it is to build a trust mechanism on top of the specification's foundations. > As you have written, JWT VC Issuer Metadata is a mechanism to retrieve a public key, not a trust mechanism. But so is x5c header as well in the ISO example? X5c header can indeed be considered a key delivery mechanism but it also provides a framework for a trust mechanism. In other words, it's easy to imagine and design a trust mechanism on top of a wallet attestation that has a `x5c` header. I think it's less easy to work out a trust mechanism on top of a key delivery mechanism that is based on downloading unsigned JSON documents. That is the problem I am facing as a HAIP implementer. I want to follow the specification but I do not know how to solve the trust issue in an interoperable way with the building blocks the spec gives me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240507/f3b5b1c2/attachment.html>