[placeholder] add trust mechanism in the future versions

[Sakurann]

currently out of scope, but agreement to add before final

[tlodderstedt]

I think the profile with key resolution and identifier authentication adds a lot in terms of interoperability. On the other hand, there are so many different technical means to manage trust, we will have a hard time to pin down THE one or two to endorse by the profile. I don't think we should delay publication due to this topic.

[peppelinux]

My only concern is that also this time new specifications are born that do not address the crucial issue of trust, in a paradigm where the citizen is at the center and consequently alone, considering that there's an important demand of the trust model, at a design level, and consequentially the demand the technical and implementation profiles for certifying trust.

Considering that profiles for attesting trust exist, it would be really important to at least reference them in this new spec (and answer simple questions, like the ones here: draft-looker-oauth-attested-key-based-client- authentication) by giving some non normative example about how to deal with these, in this new specs.

in addition to the concern, I want to remove the fear that not wanting/being able to deal with the issue of trust, consequently it will not be dealt with at all, leaving a huge design hole that would allow anyone to do it "in their own way" and with clear security risks.

[tlodderstedt]

One step after the other. Our first concern is to provide interoperability across implementations of OID4VC with SD-JWT on a global basis. And as always, interoperability means to reduce optionality. On the other hand, less optionality also reduces the number of potential implementations, since not all requirements can be covered. So we need to make sure we provide interop while having an broad enough scope for adoption. So we are not only looking for eIDAS ARF, we are also, for example, looking for small business intending to get something out onto the streets this year. In their deployments, trust might be as simple as the wallets and verifiers having a list of issuers (as a list of URLs). eIDAS ARF will certainly use other mechanisms, other deployments around the globe will perhaps use other mechanisms, too. It's their responsibility, to add their mechanism to our (global) interop profile. Modularity is the key here. For eIDAS ARF, I assume the ARF/rule books will add whatever is necessary. Perhaps ETSi will do that on the ling run.

[Sakurann]

based on few other issues (like #101), it would be very beneficial to add a section in HAIP, explaining that HAIP specifies the key resolution mechanisms, but how to establish trust in those keys (i.e., how to obtain a root cert for x.509 or know that https url can be trusted) is out of scope.

[c2bo]

We currently have this text in the out of scope section:

Trust Management, i.e. authorization of an issuer to issue certain types of credentials, authorization of the Wallet to be issued certain types of credentials, authorization of the Verifier to receive certain types of credentials.

Should we expand a bit to also include things like root certs etc?