Explain RsaSignature2018 about did-core HOT 15 CLOSED

If all signature methods are out of scope, we should still have examples in the document. All examples need to have concrete references and clear pointers to the required bits to understand things. In particular, RsaSignature2018 needs references to JWS, JWS detached, and a few others. These can be informative if it's not a normative example.

An aside, normative statements still need to be in the document for where the signatures interact with the document itself.

from did-core.

@OR13 wrote:

I think both RSASignature2018 and RS256 / JOSE are external references

Yes, they're both external references, but of very different kinds. One is to an ad-hoc registry administered by a community group that will eventually dissolve. The other is to an IANA registry backed by stable standards (mostly RFC). We should excise external references of the first kind, due to the instability of the reference target. We should embrace external reference of the latter kind, to reuse existing standards and implementations.

from did-core.

As described in #9 , using existing JSON based signature methods would reduce the footprint of new standards that we would have to create to build a functioning DID and DID method ecosystem.

from did-core.

The specification should clearly state that proof mechanisms are outside of the scope of the specification. I'd argue that the specification should probably remove the proof property as well. If people want to use JSON-LD + Linked Data Security mechanisms they can do that... if folks want to use JWS, they can do that too, but protecting DID Documents using either mechanisms shouldn't be mandated or prevented by the spec.

from did-core.

This will need to be discussed in the group. We had previously (at the 2019 DID WG meeting at W3C TPAC) agreed that we were not going to put normative statements like this into the specification as how a DID Document is secured was out of scope.

from did-core.

I believe this is blocked by the discussion of the registries. I tend to agree with concern of external dependencies, being a risk... separate from the discussion of the defintion of a signature suite and where that would happen. I think both RSASignature2018 and RS256 / JOSE are external references.... so this does seem like a tricky topic, worth tackling after we have better registry conversation.

from did-core.

Normative functionality used by the specification should either be in final specifications, such as W3C recommendations or IETF RFCs, or defined by the specification itself. This is closely related to issue #169, where RsaSignature2018 is an example of functionality not currently normatively defined in this manner.

This is also closely releated to the decision to establish registries for use by the specification.

from did-core.

@selfissued I mostly agree with your position on this. I'm worried about external dependencies that will become stale / difficult to update.

from did-core.

We have made progress in not pointing to external dependencies, we have stuff in our registry now to half-solve this issue:

https://w3c.github.io/did-core-registries/#publickey

from did-core.

We need to decide what Signature Suites and Verification Keys are in DID Core, and what go in extensions.

from did-core.

The other part of this issue is if the spec should say anything about signature formats. My assertion is that it shouldn't and leave that to other specs to define. However, doing things like key representations should be in scope.

from did-core.

The original issue was about RsaSignature2018 and RsaVerificationKey2018. PR #307 replaces these examples. The rest of the discussion in this issue - about defining things that are mentioned in the spec - I think is covered in #272, and by ongoing work on the Registries (so, propose closing?).

from did-core.

I recommend we close this for the same reasons expressed in #9 for closing.

from did-core.

The RSA Verification Key examples have been changed to Ed25519 ones. There is a different issue opened for updating the JWK examples, see #171.

That means that this issue can be closed now.

from did-core.

No comments since marked pending close, closing.

from did-core.