Deprecate RsaSignature2018

[clehner]

Change stability status of proof method RsaSignature2018 from Experimental to Deprecated.

Address #5

[kdenhartog]

I'm not sure we want to deprecate this signature suite while it's still in V1 context

@msporny @dlongley @peacekeeper what's your take on this?

[msporny]

@msporny @dlongley @peacekeeper what's your take on this?

Agree, deprecate it. JsonWebSignature2020 replaces it, at the very least.

[kdenhartog]

👍 we'll wait to hear from @peacekeeper since I know he's used this a bit in the past when checking security-v3 vocab stuff, but otherwise I'm good to deprecate this since other than @peacekeeper I'm not sure this is practically in use and there's another suite that supports similar functionality which has stronger foundations to build on.

[peacekeeper]

Hmm @kdenhartog is right that I have used it from time to time for experimentation and testing, but otherwise I don't have a strong need or opinion here.

I just wonder, is the only reason to deprecate it that it's not used very much? The fact that it can be replaced by JsonWebSignature2020 doesn't seem like a sufficient reason for deprecating it, since that would apply to several other suites as well...

There was some discussion in our open-source Java implementation about this suite recently at WebOfTrustInfo/ld-signatures-java#12, so it seems to be in use at least somewhere.

We also did some analysis of DIDs in various ledgers recently, and found that the percentage of DID documents with RSA keys is extremely small.

To sum up, I don't really care one way or the other, but thanks for asking :)

[kdenhartog]

Thanks @peacekeeper I tend to agree there's a few suites that would make sense to deprecate in favor of JsonWebSignature2020 and I'd be mildly in favor of that for simplicity, but won't die on that hill (I suspect others would). Namely just about every one that's PKI based 🙃

@vitorpamplona would you object to having this marked as deprecated since it seems like you're using RsaSignature2018.

[vitorpamplona]

I am ok with the deprecation.

I just need to provide verification services for the 1.1 billion COVID QR codes out there from DIVOC using a non-compliant version of the RsaSignature2018. So, I already had to fork and modify these RsaSignature2018 implementations anyway :(

[vitorpamplona]

It begs the question... is there a better way to mark certain suites to be for verification only to discourage people from creating new credentials with it while encouraging backward compatibility of verification services?

[kdenhartog]

Yeah that's a good point that we should consider some additional statuses for this. I think it's best we don't merge this for now and leave this PR open until we can move this into the VCWG and establish what we want to do about this registry.

[peacekeeper]

Agree with the above. Quick note that the https://github.com/w3c-ccg/lds-rsa2018 repo has already been archived, so if at some point the decision is to only partially deprecated this suite for issuing but not for verifying, then maybe that repo should be un-archived and a note also added there.

[vitorpamplona]

From the experience I have had with credentials, devs will use whatever compiles and run without much thinking about it. Given that, it would be nice to enforce the new status in code. The spec could request implementations to throw an exception when the user is calling for a signature from a sign-deprecated suite (maybe offer a "--force" option?). That will make devs think about their work and redirect them to more appropriate suites.

[kdenhartog]

Seems like a reasonable enforcement mechanism. For me, I'm less concerned if a dev actually uses it or not, but I want it to be recognized as not something that should be expected to be interoperable generally and any form of interoperability is done via bespoke coordination between parties which is always the case.