Remove proof from v2 context

[OR13]

Related: https://github.com/w3c/vc-data-model/issues/881

proof is not a property of "Credentials" it is a property of "Verifiable Credentials" that are secured by Data Integrity.

The context defining the data integrity suite that is used to "secure a verifiable credential" should define proof, since it also needs to define the proof.type and other associated attributes.

[OR13]

What's the end goal with this PR? What is the desired outcome?

Aligning the v2 context to only terms defined normatively by the vc-data-model.

[OR13]

It's not clear what removing proof would do other than ALWAYS REQUIRING the usage of cryptosuite-specific contexts (which is something we want to get away from).

This is implied by the current context, due to there not being any cryptosuites defined in the v2 context...

IMO, the correct thing to do is to remove proof, until there is an ability to actually use it.

[selfissued]

I also support decoupling credentials from the means used to make them verifiable.

[iherman]

What's the end goal with this PR? What is the desired outcome?

Aligning the v2 context to only terms defined normatively by the vc-data-model.

I think the answer should be that the proof property must be normatively defined in one of the WG's normative specification (I presume the data integrity spec). If that is done, then there is no reason to remove this property from the v2 @context; after all, the v2 @context is, essentially, a convenience mapping of JSON terms to all the vocabulary items that are defined somewhere, not necessarily the vc-data-model vocabulary only.

[OR13]

I think the answer should be that the proof property must be normatively defined in one of the WG's normative specification (I presume the data integrity spec).

Agree, data integrity specific.... not VC Data Model specific.

If that is done, then there is no reason to remove this property from the v2 @context; after all, the v2 @context is, essentially, a convenience mapping of JSON terms to all the vocabulary items that are defined somewhere, not necessarily the vc-data-model vocabulary only.

This is likely to lead to bias towards a representation format... which contains proof.

I'm not opposed to the idea of cramming both credential and verifiable credential terms into a single context... but I would prefer for v2 to start empty and add only things which have reached consensus.

[iherman]

The issue was discussed in a meeting on 2022-09-07

• no resolutions were taken

View the transcript

1.3. Remove proof from v2 context (pr vc-data-model#924)

See github pull request vc-data-model#924.

Brent Zundel: 924 Orie has suggested removing proof from the VC context.
… I suggest waiting until after TPAC.

[jandrieu]

I agree that proof is not a property of VCs - it's a property of how they are secured.

This I disagree with. A credential need not have a proof, but a Verifiable Credential does need to have a proof, otherwise it isn't verifiable.

That said, this distinction has never gotten much traction beyond its own academic debate. I'm not sure the best way to handle this in terms of JSON-LD contexts, but I am not surprised that we appear to have some inconsistencies.

[decentralgabe]

I also support decoupling credentials from the means used to make them verifiable.

+1 here. Even with the excellent cryptosuite work that's going on I do not see a reason to couple the concept of a credential with its integrity mechanism. There are already multiple options: LD proofs and JWTs. Why favor one in the context, but not another?

If we were to keep the proof in the context, I'd advocate for making it a required field, and removing support for JWTs entirely. If we are not willing to take a hard stance, then we must continue to enable optionality.

[msporny]

Even with the excellent cryptosuite work that's going on I do not see a reason to couple the concept of a credential with its integrity mechanism. There are already multiple options: LD proofs and JWTs. Why favor one in the context, but not another?

Please explain how specifying proof in the base context favors one integrity mechanism over the other? The other integrity mechanisms are not built on JSON-LD and thus have nothing to do with the JSON-LD Context.

What defining these properties in the base v2 context is doing is attempting to make things easier on developers. The argument to separate them will make things harder on developers because they will have to (unnecessarily) pull in a separate JSON-LD Context when we could make it so that they don't have to do that.

There is an argument that NOT including proof favors non-DI based approaches since it makes it so you have to do something extra if you're doing DI, but you don't have to do anything extra for the VC-JWT stuff. Therefore, removing proof disenfranchises the DI-based solutions.

If we were to keep the proof in the context, I'd advocate for making it a required field, and removing support for JWTs entirely. If we are not willing to take a hard stance, then we must continue to enable optionality.

There is no need to take an extreme stance, there is a middle ground here that's workable.

Please explain how including proof in the JSON-LD Context favors one data integrity mechanism over another?

[decentralgabe]

@msporny my understanding is that proof can be added with a Data Integrity context, should a Verifiable Credential choose to be constructed with a Data Integrity Proof.

If an effort for VCDMv2 is to decouple 'integrity' from the core data model, doesn't this change follow? Proof certainly is an 'optional' field, and one that is not core to the data model, but is core to Data Integrity, which can be layered in with additional contexts.

Please correct my understanding if I am off.

[OR13]

What defining these properties in the base v2 context is doing is attempting to make things easier on developers.

I am supportive of this objective, I believe its best accomplished by removing the existing proof definition, and aligning as a group on how do to this... Also, note language of text from v1.1

Search for "proof" here:

https://github.com/w3c/vc-data-model/blob/5f62aed1de235611cac006e5bc7163aeb8891ef9/index.html

[iherman]

The issue was discussed in a meeting on 2022-10-05

• no resolutions were taken

View the transcript

1.3. Data Model

Manu Sporny: https://github.com/w3c/vc-data-model/pulls.

See github pull request vc-data-model#924.

Manu Sporny: VCDM spec, scripts for vocabulary generation as PR, PR. #924 has a fair bit of discussion, quite a number of issues, encouraged to create PRs for issues.

[msporny]

@decentralgabe wrote:

@msporny my understanding is that proof can be added with a Data Integrity context, should a Verifiable Credential choose to be constructed with a Data Integrity Proof.

Yes, noting that doing that is more work that's easily avoided. What we're talking about here is doing this:

{
  "@context": [
    "https://www.w3.org/2022/credentials/v2",
    "https://www.w3.org/2022/credentials/examples/v2"
  ],
  // rest of VC goes below here

vs. asking developers to do this:

{
  "@context": [
    "https://www.w3.org/2022/credentials/v2",
    "https://www.w3.org/2022/credentials/examples/v2",
    "https://w3id.org/security/data-integrity/v1" // <-- note, doing this can be avoided
  ],
  // rest of VC goes below here

If an effort for VCDMv2 is to decouple 'integrity' from the core data model, doesn't this change follow?

No, it doesn't follow :). You can conceptually decouple the core data model from integrity protection, sure... but then carrying that through to the JSON-LD Context will make lives measurably worse for developers. JSON-LD Contexts are designed to mix vocabularies from different areas together into something that's application specific... they're meant to optimize the developer experience and make things easier (when defining global semantics). Being academically pure about aligning conceptual separation with implementation harms developer experience in this case, namely it makes life more difficult for developers using JSON-LD.

Please correct my understanding if I am off.

Hope the above helps clarify the rationale.

[msporny]

@OR13 wrote:

I am supportive of this objective, I believe its best accomplished by removing the existing proof definition, and aligning as a group on how do to this.

Why don't we just skip forward to getting alignment as a group on how to do this? Here's the base proposal:

https://docs.google.com/presentation/d/16J9TcFc6fX18Cun_Rhj3xqNlnhkCs6MnPkGBlRL3YKg/edit

Here is the entirety of what we'd need to include in the vc/v2 context:

https://w3id.org/security/data-integrity/v1

Here's an open source library that implements it (with a README explaining how to use it):

https://github.com/digitalbazaar/eddsa-2022-cryptosuite

Here's a draft interoperability test suite demonstrating its implementability (for eddsa-2022):

https://w3c-ccg.github.io/di-eddsa-2022-test-suite/#conformance

[OR13]

@msporny the correct way to "skip forward" is not in external repositories, its in a context for the suites, or the v2 context...

Either proof is defined in that suite context, or proof is defined in the core context.

If you are trying to keep proof in the v2 context, let's open PRs to add suites to the core context... or lets remove proof.

[msporny]

@msporny the correct way to "skip forward" is not in external repositories, its in a context for the suites, or the v2 context...

Fair enough, I was waiting until we could talk about this as a WG, but I can also just raise the PRs since we have all the content we need now. The danger there is a knee-jerk -1'ing reaction to things that haven't been discussed yet.

If you are trying to keep proof in the v2 context, let's open PRs to add suites to the core context... or lets remove proof.

Ok, I'll raise a PR.

[peacekeeper]

I understand the argument that a data model should be separated from ways of securing it, but still I find it strange when people say that "proofs are not part of the core data model".

I know there's a difference between a Credential and a Verifiable Credential. I have seen many Verifiable Credentials in different forms. I don't think I have ever seen a (non-Verifiable) Credential without a proof. The specification is called "Verifiable Credential Data Model", and proofs are definitely part of that data model, even if their details are defined in other documents (Data Integrity, JWT, etc.).

So I think "proof" should remain in the context.

[msporny]

Ok, I'll raise a PR.

PR #943, which retains proof and adds DataIntegrityProof in order to make developers lives easier, has been raised as an alternative to this PR.

[OR13]

@peacekeeper

"proofs are not part of the core data model".

They are not defined normatively... they are referred to informatively, as "internal" (Data Integrity) or "external" (JWT)

I'm ok, defining proofs normatively in v2, and then including a context definition that matches up.

[David-Chadwick]

If we can cast our minds back to when this issue was originally being discussed prior to DMv1 being published, I argued that we should have defined a fixed proof for JWT-proofed VCs, so that all VCs would have a proof property, rather than having externally and internally proofed VCs, but this viewpoint was rejected. If we are to include proof in the v2 @context then I would like to raise again the issue of having a fixed proof value to signal in the credential that the type of proof is JWT. Then all verifiable credentials will have a proof property.

[OR13]

Prefer https://github.com/w3c/vc-data-model/pull/943

[iherman]

The issue was discussed in a meeting on 2022-10-12

• no resolutions were taken

View the transcript

5. Remove proof from v2 context (pr vc-data-model#924)

See github pull request vc-data-model#924.

Kristina Yasuda: manu has briefly mentioned it.
… brief overview -- Orie did a PR removing 'proof' from the VC @context.
… there is another PR that's a counter-proposal (to keep the proof).
… anyone who would like to speak to move this forward?.

Orie Steele: so, in the conversation on that open issue, Manu and I talked about how to move the item forward, and he's implemented a path forward for adding a 'proof' definition for Data Integrity to the VC context.

Orie Steele: this is a valid path forward, and I'm happy to close my PR..
… I asked for a counter-proposal, and it was given. so unless anyone objects I'll close my PR.

Manu Sporny: does everyone understand the ask?.
… Orie, not everyone on the call may understand what's being proposed in the PRs.
… we can ask if anyone has objections, but I'm just concerned people are unclear.

Shawn Butterfield: I'll sheepishly admit that I don't fully understand - I'm about 60% of the way there..

Kristina Yasuda: that's a fair point.
… Orie would you like to comment?.

Orie Steele: I invite people to look through the comments / conversation in the issues.

Manu Sporny: ok, let me see if I can explain.
… so, fundamentally, the question is -- to what lengths should we go to, to make people's lives easier, when they're developing VCs (using JSON-LD)?.
… for those developers, do we want to give them an easy way of covering 80% of the types of proofs that might be attached to a VC.
… so the whole question is -- do we want to create a base format for a Data Integrity proof, that's batteries included.
… meaning, when somebody includes the VC v2 context, for most use cases, they can just attach a DI proof.
… that's what my PR does.
… basically says - for devs using the v2 context, they don't have to painstakingly look through a registry of proofs, and copy and paste the context for that proof type, they can just use it.
… the counter-argument was -- 'you're favoring DI stuff', to which the reply is -- if you don't care about JSON-LD, then this doesn't affect you.
… this whole thing does not hurt or affect JWT VCs.
… it just makes JSON-LD dev experience easier; cuts down on too many cryptosuite contexts from being created.
… so, it offers upsides for DI users, while not dis-enfranchising JWT users.

Shawn Butterfield: just wanted to say thank you, Manu, that was helpful, and I see the connection between the PRs. I think this is great.

Phillip Long: +1 to the explanation and support closing 924, as well..

Kristina Yasuda: so, what's on the table is closing #924.
… any objections?.

Manu Sporny: +1 to close #924.

Dmitri Zagidulin: +1 to close.

Dave Longley: +1 to close #924.

Logan Porter: +1 to close.

Shawn Butterfield: +1.

Orie Steele: I opened it, I closed it..

Orie Steele: :).

Markus Sabadello: +1.

Kristina Yasuda: I see multiple +1s in the chat, let's give it a moment. Oh, I see Orie closed it (since he's the one who opened the PR).
… ok, the counter-PR was opened 3 days ago, let's give people a few more days to comment on it.
… ok, let's move to issues discussion.