Discuss did:jwk and other did method support

[jischr]

Opened as a result of #13 These were proposed for additional supported DID methods, so should add them before the spec is "done"?

• did:jwk https://github.com/quartzjer/did-jwk/blob/main/spec.md
• did:key

[Sakurann]

I would put did:ebsi in this bucket too to consider

[peacekeeper]

I find it strange that a specification like this mandates or even has an opinion on which DID method(s) to use. This should be a completely orthogonal question. Specific use cases or profiles or ecosystems or governance frameworks may define what DID methods to use, but this specification itself should be completely agnostic with regard to DID method(s).

[Sakurann]

I disagree, for interoperability, we need to pick certain DID methods

[dtmcg]

consensus on the call was that unless a compelling use case is presented by the next meeting we wont add them. the default bias of the profile is to remove as may options as possible to make it easier to implement

[peacekeeper]

for interoperability, we need to pick certain DID methods

This is essentially one of the misguided arguments in the formal objections that were recently overruled by W3C. The idea that a limited set of "best" DID methods should be mandatory for everyone in the world is a misunderstanding of one of the main principles behind DIDs, and of the fact that the flexibility of DID methods ENABLES rather than limits interoperability.

I have to say I don't really understand the goals of this specification, but I am pretty sure it can potentially be useful in conjunction with any DID method. So why artificially restrict it to some DID methods that the authors prefer? There seems to be some hidden reason for coupling certain layers of a stack that should be independent. Defining a protocol profile that combines VC/JWT/SIOPv2/OpenIDVP in certain ways makes sense. Locking in users of this profile to a small set of DID methods does not.

Such restrictions can make sense in the context of specific industries or use cases or individual projects. E.g. a Microsoft/Ping/Workday consortium could agree that they will only use did:web and did:ion for their customers. But that should not affect all others who may want to use this specification with other DID methods.

[Sakurann]

This document makes choices of which specifications to combine and what options within those specifications should be mandated, so that any implementations that implement this profile are guaranteed to be interoperable.

If this document only says use any DID method, and implementer A implements only DID method A, but implementer A implements only DID method B, they will not be interoperable and we cannot achieve the goal.

It has nothing to do whether DID-Core specification itself is interoperable or not.

[peacekeeper]

I guess the problem I have with this is that the document has a very generic title and is written as a DIF specification, but then it makes choices about DID methods that arbitrarily prefer certain ecosystems and communities over others. Everything in this specification is generic and neutral, except for picking "we like this DID method, and we don't like the other one".

If a few companies get together and decide which DID methods they want to use in their products, that's fine, but it feels wrong for a few people to simply decide for everyone else which DID methods they think are "best". This leads back to centralization, vendor lock-in, "digital slavery", etc., all those things we already had before that made DIDs necessary in the first place.

I know this is exaggerating a bit, but.... I don't want to live in a world where DID methods have to be "Microsoft-approved".

[Sakurann]

Nothing in this document says that the chosen DID methods are better than the other - it is not even implied. the document simply says that for certain use-cases (e.g. workplace credentials), implementers are choosing certain DID methods.

btw the document makes choices not only for DIDs, but also for W3C VC formats, crypto suites and revocation methods.

If changing the title of the document will make you feel more comfortable, happy to do so - let us know if you have any suggestions - we tried in the past but could not come up with a better name.

[jischr]

I also think if we add some more detail to the abstract, audience and introduction sections, it could clarify that this is a specification profile rather than a just a specification and some of our goals or intentions for interoperability when creating this. issue #7 to track that.

[peacekeeper]

Thanks for the discussion and explanations. I agree that if the abstract and audience sections were more detailed, and the document title sounded less generic, then that would address my concerns. E.g. you could call it jwt-vc-oidc-ion-workplace-profile (okay that sounds maybe too complicated, I admit).

Taking that idea further, someone could write an automatic "interop profile generator" tool where you click a few checkboxes for things you want to support on each layer, and the tool could spit out a complete interoperability specification based on your choices, and of course that tool would also auto-generate an appropriate document title :)

[Sakurann]

noted to revisit abstract and audience sections, and the document title.

while automatic interop profile generator sounded appealing on the first thought, I am afraid it will not solve the fundamental problem that is being addressed with this work. The point of interoperability profile work is not to document all the potential ways to combine specifications - certain combinations that are technically possible, would not have a business use case, for example. The goal is to create a profile that has a buy in from multiple implementers so that it kickstarts an interoperable VC ecosystem. There is already a confusion in the market around the large number of specifications in the VC space, let's simplify that by giving a set of choices in few interop profiles, rather than exemplifying the problem by giving large number of interop profiles...