Made DID Resolution language more relaxed

[awoie]

This PR introduces the following changes:

• fixes #186
• Made all public key validation rules conditional
• Rejecting the SD-JWT VC if public key validation cannot be done

[peacekeeper]

This harms interoperability, since some implementations will use DIDs and others will use /.well-known/jwt-issuer. A more interoperable approach would be to drop /.well-known/jwt-issuer and to always use DIDs. Those who want to use domain names and web servers can then still use did:web.

DIDs have always been designed as an abstraction layer for different types of resolvable identifiers. To build yet another layer of optionality, where DIDs are one option out of others, does not make much sense. Now you will have to deal with different metadata formats (JWT Issuer Metadata, and DID document).

Similar arguments apply to the did:jwk vs cnf discussion.

But I already know the response.. "Simple is a feature", and "DIDs have more boilerplate that is not needed", right? :)

[awoie]

This harms interoperability, since some implementations will use DIDs and others will use /.well-known/jwt-issuer. A more interoperable approach would be to drop /.well-known/jwt-issuer and to always use DIDs. Those who want to use domain names and web servers can then still use did:web.

DIDs have always been designed as an abstraction layer for different types of resolvable identifiers. To build yet another layer of optionality, where DIDs are one option out of others, does not make much sense. Now you will have to deal with different metadata formats (JWT Issuer Metadata, and DID document).

Similar arguments apply to the did:jwk vs cnf discussion.

But I already know the response.. "Simple is a feature", and "DIDs have more boilerplate that is not needed", right? :)

@peacekeeper Let's have the discussion in #186. As long as we haven't resolved the discussion I keep the DO NOT MERGE label on it.

[awoie]

This harms interoperability, since some implementations will use DIDs and others will use /.well-known/jwt-issuer. A more interoperable approach would be to drop /.well-known/jwt-issuer and to always use DIDs. Those who want to use domain names and web servers can then still use did:web. DIDs have always been designed as an abstraction layer for different types of resolvable identifiers. To build yet another layer of optionality, where DIDs are one option out of others, does not make much sense. Now you will have to deal with different metadata formats (JWT Issuer Metadata, and DID document). Similar arguments apply to the did:jwk vs cnf discussion. But I already know the response.. "Simple is a feature", and "DIDs have more boilerplate that is not needed", right? :)

@peacekeeper Let's have the discussion in #186. As long as we haven't resolved the discussion I keep the DO NOT MERGE label on it.

Let me try to update the PR.

[awoie]

This harms interoperability, since some implementations will use DIDs and others will use /.well-known/jwt-issuer. A more interoperable approach would be to drop /.well-known/jwt-issuer and to always use DIDs. Those who want to use domain names and web servers can then still use did:web. DIDs have always been designed as an abstraction layer for different types of resolvable identifiers. To build yet another layer of optionality, where DIDs are one option out of others, does not make much sense. Now you will have to deal with different metadata formats (JWT Issuer Metadata, and DID document). Similar arguments apply to the did:jwk vs cnf discussion. But I already know the response.. "Simple is a feature", and "DIDs have more boilerplate that is not needed", right? :)

@peacekeeper Let's have the discussion in #186. As long as we haven't resolved the discussion I keep the DO NOT MERGE label on it.

Let me try to update the PR.

@peacekeeper I made all rules now conditional from a verifier perspective. In this way a verifier is compliant if they don't support all rules but the SD-JWT VC would fail validation. Note, it is impossible for a verifier to support all rules that may be defined by ecosystems anyways. Are you ok with the updated language?

[peacekeeper]

Are you ok with the updated language?

As a DID maximalist, I would personally prefer DIDs to be the only mechanism that is used whenever public keys are needed, instead of allowing more static public key mechanisms like "jwt-issuer" or "cnf".

Unlike "jwt-issuer", DIDs support identifiers that are persistent, decentralized, and cryptographically verifiable.

Unlike "cnf", DIDs support key rotation and other updates.

And as I said above, with DIDs there would be only one syntax and one resolution mechanism and one metadata format, instead of multiple different ones that individual implementations may or may not support.

But I also understand that for some communities, "keeping it simple" is more important than the above properties, so yes I'm fine with the language, thanks for the effort to update it!

[paulbastian]

While I understand your points, I think some of them are not true.

DIDs may be decentralized, may support key rotations and may have other features. There are enough examples of DID methods that do not have those properties.

Making DIDs mandatory would limit optionality. But also with DIDs the optionality in my view shifts just shifts a layer further down as there are many DID methods. Indeed allowing DIDs expands optionality by 200+ did methods, so this could indeed be a counterargument.

"Cnf" isn't actually far away from DIDs, as the content can vary, there is a registry at IANA for supported methods, with different properties. In my view the cleanest approach for the keybinding would be to register a new cnf type "did" in this registry. But that's off topic in this PR.

I'm fine to keep some optionality in the specification at the beginning and then see what is actually being used

[peacekeeper]

There are enough examples of DID methods that do not have those properties.

True. :) But with "JWT Issuer Metadata" discovered from domain names you will never have the kind of decentralization, persistence, and cryptographic verifiability that DIDs can offer.

"Cnf" isn't actually far away from DIDs, [...] register a new cnf type "did" in this registry

Sounds interesting! But I agree off-topic.

But also with DIDs the optionality in my view shifts just shifts a layer further down

You can still restrict the DID methods you want to use in a specific application such as eIDAS2.

For example, if you want to support 1. domain names, 2. plain public keys, and 3. EBSI, then:

With the current approach in this specification:

• For 1. you need to support JWT Issuer Metadata (= a new format introduced by this spec).
• For 2. you need to support "cnf" and JWK (= a format that has been around for a long time).
• For 3. you need to support DID documents (= a format that has been around for a few years).

Compare that to a DID-only approach:

• For 1. you need to support did:web (= DID document format)
• For 2. you need to support did:jwk (= DID document format)
• For 3. you need to support did:ebsi (= DID document format)

You see what I mean?

Yes with a DID-only approach you would still have a layer of optionality with regard to DID methods, but you'd only have that ONE layer of optionality instead of TWO layers of optionality, and you'd have a harmonized identifiers syntax and harmonized metadata format.

But I understand there are communities that simply don't want to use DIDs, so I think this current PR is a good middle ground.