Remove did: based client ID's

[tplooker]

Practically speaking I don't believe DID based client ID's offer much in the way of value for the OpenID4VP protocol and instead only add complexity to implementations. The current text for did: based client ID's is generally under-defined in the sense that:

• Which DID methods implementations are suppose to support are not defined.
• Which verification method types implementations are suppose to support are not defined.
• Which key representations formats inside the verification method types is not sufficiently defined.

To that end I believe the simplest path is to remove this feature from OpenID4VP, it doesn't prevent implementations from using DID's in other places such as credential binding if they so wish.

[bc-pi]

It also adds complexity to cognitive overhead involved in just trying to comprehend the document itself.

[bc-pi]

Remove it

[Sakurann]

don't remove it.

[Sakurann]

I don't understand how it is underspecified more than others. majority of client_id_schemes need something additional to be defined, not just DID one. like verifier_attestation scheme requires it to be defined how to get the keys to validate that verifier attestation jwt. openid federation leaves a lot of things open too.

profiles are supposed to define details for did method and they do. like here: https://identity.foundation/jwt-vc-presentation-profile/

in the end of the day, did: client_id_scheme is optional, if you don't like it, don't use it.

[tplooker]

don't remove it.

Can you please elaborate on why not?

I don't understand how it is underspecified more than others. majority of client_id_schemes need something additional to be defined, not just DID one. like verifier_attestation scheme requires it to be defined how to get the keys to validate that verifier attestation jwt. openid federation leaves a lot of things open too.

I've clearly stated above how it is under-defined, even though its an optional feature it creates complexity and burden for implementers that attempt to use it and for us as editors to maintain it. The feature needs to be properly defined or removed, I'm in favour of removing.

[bj-ms]

Practically speaking I don't believe DID based client ID's offer much in the way of value for the OpenID4VP protocol and instead only add complexity to implementations. The current text for did: based client ID's is generally under-defined in the sense that:

• Which DID methods implementations are suppose to support are not defined.
• Which verification method types implementations are suppose to support are not defined.
• Which key representations formats inside the verification method types is not sufficiently defined.

To that end I believe the simplest path is to remove this feature from OpenID4VP, it doesn't prevent implementations from using DID's in other places such as credential binding if they so wish.

If did: is removed from the client_id scheme, how will verifiers with DIDs be able to authenticate themselves to the wallet?

I would argue that this option is necessary to validate a signed authorization request sent to the wallet by a verifier with a DID.

From your points above, one addition that makes sense to me is to define what type of public key encoding is supported.

[nemqe]

I always saw did: support here as an enabler for DID centric ecosystems, and then it is their business what specific DID methods they want to use, what key types they want to support, and in what format they want to present them - all of which is defined in the base DID spec and the corresponding method specs.

What is the main concern of keeping this in, do we worry about wallets needing to support things like DIDs and not knowing what to expect because the range of possible methods is big?