PROPOSAL: Breaking change for sec-v3-unstable

[OR13]

I propose we combine the terms from sec-1 and sec-2 and then remove all Linked Data Suite specific RDF Classes from sec-v3, such that it can be safely used with the linked data suites currently registered via w3id.org.

for example:

{
  "@context": ["https://w3id.org/security/v3-unstable", "https://w3id.org/security/suites/ed25519-2018/v1"]
}

note that Ed25519VerificationKey2018 was originally defined in https://w3id.org/security/v2.... I am asserting that nothing defined under /suites should be defined in sec-v3-unstable

This proposal would also align with the approach we took with did core:

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2018/v1"]
}

[OR13]

ping @dlongley @davidlehn @msporny @tplooker @kdenhartog @dmitrizagidulin @iherman

[dlongley]

So, I'm in support of making sec-v3 work with suite contexts. However, I don't know, at this point, if sec-v3 is even useful/needed. Why not just use the feature-specific security context(s) you need?

[msporny]

I don't know, at this point, if sec-v3 is even useful/needed. Why not just use the feature-specific security context(s) you need?

Do we need to keep sec-v3-unstable around to deal with all the security context stuff that /isn't/ in a cryptosuite? I haven't done the work to determine what's left after we move all the cryptosuites out of the security context.

Also, @kdenhartog -- is Mattr using sec-v3-unstable? I remember that being a possibility at some point in the past.

[dlongley]

Do we need to keep sec-v3-unstable around to deal with all the security context stuff that /isn't/ in a cryptosuite?

Like what? We've created separate contexts for WebKMS and zCaps as well. I think a cleaner model is to make contexts for specific features -- rather than trying to bundle everything together and hope for the best ... or bundle some of the things (which ones?) that may not appear in other contexts (what happens when we make new contexts that do have those things?).

[kdenhartog]

Also, @kdenhartog -- is Mattr using sec-v3-unstable? I remember that being a possibility at some point in the past.

At this point we've updated the BBS libraries to use the specific suite when signing, but I believe we still support verification of sec-v3-unstable for compatibility. Internally though we're still using the github.io and are likely to cut directly over to the suite here soon. So I don't think this is going to cause us issues. Additionally I'm +1 to this change for an ideal long term solution.

[OR13]

If we don't need sec-v3 at all, we should mark sec-v2 as deprecated, and ensure that it can be completely removed from VC Data Model of LD Signatures tooling in the future.

This proposal assumes that not possible, and the second best option would be to flatten terms that are required from sec-v1 and sec-v2 into sec-v3.