feat: adds 2020 v1 VC context and v3 security context

[kdenhartog]

This is a first attempt to try and get consensus on a new VC context which removes the conflicting link data proof suites and rather brings them in by reference from the V3 security suite. This means that all suites defined in the v3 security vocab are usable with the VC context without any additional changes or conflicts.

Additionally, this adds name and description as properties to the context to go along with #752

While I very much doubt it's going to be merged right away, the intent of this is rather to start the discussion with a concrete proposal for us to start moving on.

---

Preview | Diff

[OR13]

I would love to see this happen... forcing term redefinition is an act of strategic sabotage :)

Developers who first encounter linked data will spend years trying to figure out why we didn't start with this approach, only to learn, the reason was it was blocked by people who don't like linked data.

However, the counter point is that the spec and its context should be 100% self contained... its a bad argument, since many specs rely on other specs... but in this case, the fact that the sec vocab is CCG will inevitably be raised as a major reason it can't be linked to / included.

I would point out that the current VC Data Model is going a worse job of maintaining human vocabulary... compare:

https://www.w3.org/2018/credentials#VerifiableCredential

https://w3id.org/security/#ethereumAddress

[iherman]

I think we've hit a point where at least @iherman, @OR13, @kdenhartog, @dlongley, @tplooker, @burnburn, @vsnt, @wyc, and @msporny need to get on a call and sort out how we're going to manage the updates to the VC spec.

Agreed. Let us wait for @burn to be back in town to do that.

[OR13]

+1 for a call, this is blocking a number of thing I care deeply about :)

[kdenhartog]

I would love to see this happen... forcing term redefinition is an act of strategic sabotage :)

Developers who first encounter linked data will spend years trying to figure out why we didn't start with this approach, only to learn, the reason was it was blocked by people who don't like linked data. However, the counter point is that the spec and its context should be 100% self contained... its a bad argument, since many specs rely on other specs... but in this case, the fact that the sec vocab is CCG will inevitably be raised as a major reason it can't be linked to / included.

Yeah I'm fine with removing the security suites reference and then they have to be included directly within the VCs. In my subjective opinion that's most cleanly separation of concerns between the different vocabularies.

I would point out that the current VC Data Model is going a worse job of maintaining human vocabulary... compare:

https://www.w3.org/2018/credentials#VerifiableCredential

https://w3id.org/security/#ethereumAddress

Yeah, I was going to update that in this context as well, but thought it was going to cause a breaking change so opted to not do that. I'd like to link to definitions if possible, but would prefer we don't break the contexts.

[kdenhartog]

Thank you for continuing to do this long overlooked and needed work, @kdenhartog ... much appreciated.

I don't understand what's going on in this PR:

1. We have yet another naming scheme for JSON-LD contexts YYYYVV instead of v2-unstable.

Happy to switch to that, I wasn't certain of the convention used here, but good to know we want to stick with the same thing throughout all of them.

2. We are now including the v3 security context in the vc-data-model repo, which will lead to divergence... one thing that's bitten us time and time again over the years is having the same context file in multiple different places.

Agree that it doesn't make sense for it to be in here and should rather be referenced externally where it's kept. Only reason I included was because I was using terms from it and it looked like the precedent is that the security context should be included if it's referenced / shares terms.

I'll add to this that there is uncertainty around how the CCG maintenance process and the W3C REC update process are going to interact.

I think we've hit a point where at least @iherman, @OR13, @kdenhartog, @dlongley, @tplooker, @burnburn, @vsnt, @wyc, and @msporny need to get on a call and sort out how we're going to manage the updates to the VC spec.

I agree, this is valuable for us to address to stabilize things and hopefully will get us to a stable direction so I can go through and get the last few things updated. For the sake of completeness too, @rhiaro has done work to move the DID context forward and @peacekeeper has been a huge help on the security context side of things. I'll leave it up to them if they'd like to join, but definitely want them to be aware that this is going on.

[brentzundel]

I think we've hit a point where at least @iherman, @OR13, @kdenhartog, @dlongley, @tplooker, @burnburn, @vsnt, @wyc, and @msporny need to get on a call and sort out how we're going to manage the updates to the VC spec.

Agreed. Let us wait for @burn to be back in town to do that.

I'd also like to be involved.

[msporny]

I have cleaned up all old stale branches and setup the current branch structure for the repo:

• main - this is where changes to the next non-breaking release goes (bug fixes, errata, etc) -- the next target release is v1.1
• v2 - this is where major breaking changes/additions go (new terms, contexts, features, etc.) -- the next target release is v2.0

This PR has been marked as a v2 feature and the target branch has been changed to v2. This enables the current repo to be used for both v1.1 and v2 work.

NOTE: None of this has any immediate effect on anything -- it's merely a bookkeeping measure for the Editors until the VC Maintenance WG can meet and decide if this structure is appropriate.

[brentzundel]

I think it may be better to hold off moving on this PR until the Data Integrity and JWT bits get taken out, before then it may be hard to have a productive conversation.

[msporny]

I think it may be better to hold off moving on this PR until the Data Integrity and JWT bits get taken out, before then it may be hard to have a productive conversation.

Agreed. This PR is probably going to be "overtaken by events". The new design for the Data Integrity Signature suites removes the need for the group to fight about "which cryptosuites get included in the core VC context", largely removes cryptosuite proliferation, and simplifies the usage on the Data Integrity side of things.

I'm working on a presentation deck to introduce the concept to the VCWG in the coming weeks (for those that are interested in the Data Integrity portions).

[kdenhartog]

The new design for the Data Integrity Signature suites removes the need for the group to fight about "which cryptosuites get included in the core VC context", largely removes cryptosuite proliferation, and simplifies the usage on the Data Integrity side of things.

That would be awesome! removing suites from the core context makes this much easier to deal with so that only properties defined within the VC data model are defined within the VC context. Everything else can be normatively defined by the data integrity crypto suites I'd think for stronger conformance when needed, but removed when not (e.g. JWT suites won't require MUSTs for the the proof suite terms defined)

[msporny]

That would be awesome! removing suites from the core context makes this much easier to deal with so that only properties defined within the VC data model are defined within the VC context.

The current plan is slightly different from removing all suites... it's defining a single extensible suite called "DataIntegritySignature", that can be used like so:

{
  "type": "DataIntegritySignature",
  "cryptosuite": "ecdsa-2022",
  "created": "2022-11-29T20:35:38Z",
  "verificationMethod": "did:example:123456789abcdefghi#keys-1",
  "proofPurpose": "assertionMethod",
  "proofValue": "z2rb7doJxczUF...VugUpoj"
}

Note the new "cryptosuite" property, which is associated with a pure string value. That allows us to keep the same form, but use cryptosuites like: eddsa-2022, nist-ecdsa-2022, koblitz-ecdsa-2022, rsa-2022, pgp-2022, bbs-2022, eascdsa-2022, ibsa-2022, and jws-2022.

This means, we don't need to define JSON-LD types for Ed25519Signature2020, JwsSignature2020, etc. anymore. People just include the VC2 context and they're done:

{
  // Note: 1) the new v2 contexts, and 2) we don't require a cryptosuite context anymore
  "@context": [
    "https://www.w3.org/2022/credentials/v2", 
    "https://www.w3.org/2022/credentials/examples/v2"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "DataIntegritySignature",
    "cryptosuite": "ecdsa-2022",
    "created": "2022-11-29T20:35:38Z",
    "verificationMethod": "did:example:123456789abcdefghi#keys-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z2rb7doJxczUFBTd...KVugUpoj"
  }
}

The only downside that we can see here is that, when doing semantic compression (like for CBOR-LD), we pay a penalty for the string value in the cryptosuite... instead of being 1-2 bytes, it's now 10 bytes or so... not great, but not terrible... and the trade-off seems worth it in order to largely mitigate cryptosuite context proliferation.

[kdenhartog]

Ok, that seems like a good way to handle this. Another bonus of this is that people only need to add terms to their suite if they actually need them which means the one off terms for unique suites need to be defined in the suite spec. I like where this has landed.

[msporny]

Another bonus of this is that people only need to add terms to their suite if they actually need them which means the one off terms for unique suites need to be defined in the suite spec.

Yep, exactly. Ideally, they don't even need a suite spec (this should be true for most modern digital signature algorithms).

I like where this has landed.

Great! Now on to the easy part... convincing the WG that this is a good direction to take! :P

[iherman]

I have cleaned up all old stale branches and setup the current branch structure for the repo:

• main - this is where changes to the next non-breaking release goes (bug fixes, errata, etc) -- the next target release is v1.1
• v2 - this is where major breaking changes/additions go (new terms, contexts, features, etc.) -- the next target release is v2.0

This PR has been marked as a v2 feature and the target branch has been changed to v2. This enables the current repo to be used for both v1.1 and v2 work.

NOTE: None of this has any immediate effect on anything -- it's merely a bookkeeping measure for the Editors until the VC Maintenance WG can meet and decide if this structure is appropriate.

I do not really understand where you are going with this.

• There is no such thing as a VC Maintenance WG anymore. This WG is the VC maintainer.
• The way I read your comment is as if you intend to re-issue 1.1 updates time to time. I don't think this is ok per our charter which only talks about 2.0. There is no such work item as 1.1 maintenance.
• Eventually, 2.0 will supersede 1.1; if there are "maintenance" like issues in 1.1, they should be handled within the framework of 2.0 (knowing that some issues may become moot as 2.0 evolves).

As far as I am concerned, the current 1.1 version should be considered as frozen. It is as it is, if there are bugs, they should be handled by the VC 2.0 work.

B.t.w., I see that the github pages has been re-assigned to the v2.0 branch, which is the right thing to do. But, in view of what I said, it bothers me that the 'main' branch is for 1.1, which is misleading, because it suggests that the central work item for the WG is 1.1. In my view, the right set up is to keep the v1.1 branch to secure history (and that branch should be 'frozen', as far as the WG is concerned), and the main branch should be on 2.0.

But I may misunderstand what you intend to do, in which case sorry...

[iherman]

Oops!!! I realized that I reacted on a comment from last February!!! I just looked at the last comments, and looked at the previous comments and did not realize that I was looking at a very old thing!!!

I am careless, no doubt about that. But maybe it is worth opening new issue/PR when circumstances have changed that much.

Sorry about the noise.

[msporny]

maybe it is worth opening new issue/PR when circumstances have changed that much.

Yes, agreed. I'm working on a presentation deck to organize a set of changes around the Data Integrity work. I don't expect we'll ever publish a "v3 security context", nor a "2020 v1 VC context".

At this point, we're probably going to integrate the necessary Data Integrity terms into the VC v2 context, and probably publish a Data Integrity / Security Vocabulary... IOW, this PR should probably be closed because it's not aligned with where we're probably headed.

I'm going to mark this is pending close, please disagree if there are objections.

[brentzundel]

No comments since makred pending close, closing.