Why does the Data Model context file define a DataIntegrityProof RDF class?

[brentzundel]

Now that Data Integrity is it's own specification, the DataIntegrityProof RDF class in the base data model context should be moved to the Data Integrity context

[OR13]

Here are some related contexts we have historically used for data integrity:

• https://w3id.org/security/v2
• https://w3id.org/security/v1

Here is the vocab term definitions for data integrity RDF Class:

• https://w3id.org/security#DataIntegrityProof

Here is the complete security vocabulary:

• https://w3id.org/security

IMO the vc-data-model core context should be restricted to things you MUST understand to implement the spec.

However, currently the URL is normative: https://www.w3.org/ns/credentials/v2

While its contents (resolved content) is not.

Here are a few things that are sorta "implied to be normative" because of this:

• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L51
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L95
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L149

Additionally, "data integrity proofs" can be used without "w3c verifiable credentials" to secure arbitrary JSON... so it makes sense that there should a some other context out there that includes https://w3id.org/security#DataIntegrityProof but does not include https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L9 .

It seems like it might be easier for us to move some of the "proof" related stuff to data integrity and refer to it from the core data model, as opposed to defining it in the core data model normatively... and then actually maintaining it in data integrity and related vocabs:

Conformance to this specification does not depend on the details of a particular proof mechanism; it requires clearly identifying the mechanism a verifiable credential uses.

https://w3c.github.io/vc-data-model/#conformance

This is sorta not true, if the v2 context is normatively required:

https://w3c.github.io/vc-data-model/#contexts

AND It resolves to a non-normative JSON-LD context object that directly includes:

• https://w3id.org/security#proof
• https://w3id.org/security#DataIntegrityProof

It would be better to use a second context to add support for "data integrity proofs" to a VC.

This second context would also be useful for applying data integrity proofs to JSON-LD that is not a VC.

This second context can of course be built at any point in the future, so we have no need to bundle these data integrity proof specific terms in the current core data model v2 context.

Perhaps the following URL would be natural for a data integrity proof context that was not related to W3C Verifiable Credentials:

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

[msporny]

It would be better to use a second context to add support for "data integrity proofs" to a VC.

The whole argument behind @vocab was so that people didn't need to pull in a second context. If we are going to go back on that decision, then we should re-open the debate on @vocab.

The reason proof and DataIntegrity exist is for convenience. Multiple implementers (17+ of them) have demonstrated that they are using proof when issuing VCs. This is a strong signal that this is a useful property. Additionally, implementers have also signaled that they'd like to avoid pulling in cryptosuite contexts if possible, reducing the number of contexts required to sign a Data Integrity protected VC from 3 (base + market vertical + data integrity) down to 2 (base + market vertical).

For both of those reasons, proof should stay, and there is a broad expectation that we will have multiple implementations for DataIntegrity as well. The base context is supposed to make developer's lives easier by reducing the number of contexts that they have to pull in for a functioning example.

[brentzundel]

I agree that proof should stay, it is a defined property of the data model.

I am sorry, I still don't understand why DataIntegrity is part of the core spec @context as well as the Data Integrity spec @context.
I hear that it makes things easier for those who use VCs with Data Integrity, but if the Data Integrity terms are already included in the Data Integrity spec @context, isn't having them here redundant? As an implementer I find that very confusing.

The goal of the @vocab decision was to ease JSON-LD complications for those who want to use VCs without LD. One of the ways that was accomplished was by removing the need for those users to pull in additional contexts.
If users are using Data Integrity to secure VCs, then they are already using JSON-LD, so pulling in a context for Data Integrity doesn't seem like it would be much of an additional burden for them.

As an implementer of Data Integrity for VCs, I find the lack of explicit guidance for proper @context usage to be deeply confusing.
It is my opinion (chair hat off) that having terms from another specification mapped both there and in this specification without any language about how to use them decreases the potential successful uptake of both VCs and Data Integrity.

[dlongley]

@brentzundel,

There are two contexts that people can use when working with Data Integrity, EITHER:

1. The core VC context (v2).
2. The core DI context.

You don't use both. If you're working with VCs, you simply use 1. If you're not working with VCs, you simply use 2. We should make this explicit in text so that guidance is clear to implementers.

[brentzundel]

Okay, that helps a bit. Some guidance to that effect would help a lot.
What I wonder now is why Data Integrity designers would want that confusion for their implementers. Why set things up so that in order to use Data Integrity you have to do it differently when you use a VC?

[dlongley]

@brentzundel,

Why set things up so that in order to use Data Integrity you have to do it differently when you use a VC?

Because there are very different kinds of users in the linked data space. However, overall, people do tend to fall into two different groups in DI usage: developers working with VCs and developers working with generalized graph data that needs to be secured.

Developers that work with VCs essentially assume a VC-centric ecosystem and write and work with software differently. They often aren't exposed to linked data in the same way that other users are, instead only consuming it as if it were JSON and just using libraries or services to handle the DI parts invisibly. Many of these people don't think about it more deeply than that -- and many do not think about their data as a graph. A significant number of them are, however, aware of the benefits of LD that underlie the data they are working with -- but they just want to use a simple "JSON interface" into the data in all of their applications. VCs solve most of their use cases ... and they approach their use cases as using "VCs" to solve them. This group sees "VCs as the front door".

Other developers are solving their use cases using LD -- and they need it to be secured. This is a different mindset and approach. It's natural for them to understand their data as a graph of information and to care significantly less about its concrete serialization. They expect significant LD transformation flexibility. This group sees "LD as the front door".

In short, the things you said earlier around @vocab and "using VC without LD" aren't as clean cut as stated, I think. There's a whole other group of people that don't necessarily care about @vocab (or even don't want it), do care about LD and use / rely upon its benefits, but still want a simpler interface into it for most of their application work ... and VCs solve all this for them.

Given this natural, general bifurcation of the user base, it makes a lot of sense to cater to both groups.

[brentzundel]

That explanation satisfies me.
I am marking this issue as pending close and will close it in a week if there are no objections.

[OR13]

I don't feel there has been sufficient discussion, and I don't agree with the proposal to include data integrity terms in the vc data model core context.

It is true, PR's attempting to remove certain terms from the v2 context did not gain consensus and were marked pending close:

• Remove refreshService #1094
• Remove termsOfUse from v2 context #1093
• Remove evidence #1092

We should probably wait til this PR is closed / addressed before labeling this issue as pending close:

• Remove DataIntegrityProof from v2 context #1091

[mprorock]

happy to take this on if we can pull these items out of core context

[mprorock]

also ref #1103

[mprorock]

Question for the group while building a (some) PR(s) out on this...
core data model is a json-ld data model that requires a context? <- this is my understanding, is this correct?

[OR13]

Yes, in particular we have reached higher degree of clarity than we had in v1 or v1.1

The following are now true:

1. Core Data Model is JSON-LD
2. application/vc+ld+json is Compact JSON-LD
3. @context is required member of both VerifiableCredential and VerifiablePresentation which are both RDF Classes referenced in the context, and defined in the vocabulary.

• https://www.w3.org/2018/credentials/#VerifiableCredential
• https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L10
• https://www.w3.org/2018/credentials/#VerifiablePresentation
  https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L68

Currently all IRIs in the context that are not explicitly normative in the TR... are.... not normative ... meaning you don't need to understand them... which means you can ignore the @context.... which is used to produce them.

[iherman]

The issue was discussed in a meeting on 2023-05-17

• no resolutions were taken

View the transcript

2.3. Why does the Data Model context file define a DataIntegrityProof RDF class? (issue vc-data-model#1089)

See github issue vc-data-model#1089.

Brent Zundel: I raised this. I'm satisfied, but others are not.

Orie Steele: same conversation about separate graphs.
… if the graph is separate, why do we bundle data integrity proofs.
… I think it biases how to secure to DI.
… I still don't see why the context file include DI terms if you don't need that to understand core data model.
… either the document should be normative and we should include these definitions.
… or they should just appear in the DI context.

Manu Sporny: nothing weird going on here.
… we are trying to make it easier on developers that make it easier for them.

Dave Longley: +1 these are not political concerns, they are technical and we've explained them many times ... making something easier isn't weird.

Manu Sporny: For example, how languages include things by default that lots of developers use.

Dave Longley: +1 to mark this pending close.

Manu Sporny: We can discuss this more, but the reason is not going to change.

Manu Sporny: +1 to mark pending close.

Brent Zundel: my inclination is to mark pending close unless someone is willing to be assigned.

Michael Prorock: I think the problem is there isn't consensus.

Orie Steele: +1 mprorock.

Michael Prorock: I'd prefer that there is a context that just has VCDM terms.

Dave Longley: -1 ... it is like "let's remove @vocab because it helps JWTs".

Michael Prorock: I'm willing to be assigned if we can yank this out.

Orie Steele: I prefer to see the data integrity terms come from a data integrity context.

Brent Zundel: reminder we are looking to assign.

Orie Steele: I don't think this makes things easier for developers... I am a developer.

Dave Longley: Just to mention some things that make things easier for developers. Not doing those things in hope of avoiding bias just makes it harder for developers.

Dmitri Zagidulin: I think it's worth remembering that JWT community doesn't really care what's in the @context or not. So, anything we do with the context to make developers lives easier, doesn't affect JWT community in any way.

Ivan Herman: mike, you made a mistake. I commented in IRC. this may be a source of misunderstandings.

Manu Sporny: yes that ^.

Ivan Herman: the context doesn't not define the vocabulary.
… Data Integrity proof is not defined in the vocabulary for VCDM.
… Context is there to also include for example, terms from schema.org.

Orie Steele: I am a vc-jwt implementer, and I care about what is in the context.

Dmitri Zagidulin: @Orie - you are literally the only one.

Manu Sporny: haha, true :).

Orie Steele: ^ why do we have a charter if that is the case?

Manu Sporny: in an attempt to help mike write something that survives consensus. Remember that we had consensus to add name and description.
… those are defined not in VCDM, but rather schema.org.
… So if only things in VCDM can show up in context, then that's a specific notion that probably won't achieve consensus.

Orie Steele: name and description need to be covered in the TR though right?

Dave Longley: nothing that uses @vocab is defined in the VCDM either... so we can put that in another context too.

Michael Prorock: +1 orie.

Orie Steele: otherwise how do you know how to use them?

Dave Longley: ^just leads to all kinds of problems here.

Orie Steele: also the IRIs are normative, but they only get defined in the context.... it feels like people are not really aware of how this works.

Brent Zundel: Manu and Mike are wiling to be assigned.

Manu Sporny: not me.

Michael Prorock: I'm willing to take the assignment, with help from Manu.
… Orie noticed this in the chat. It would seem reasonable to get the vocab as normative as possible.
… That probably means instead of chucking name & description, we put it in the vocab.

Dave Longley: "the context does not match 'a vocab'" <-- no, a big misunderstanding.

Dave Longley: json-ld contexts bring vocabularies together.
… Hearing this, it sounds like a massive misunderstanding of what context is for.
… I don't see us getting consensus.

Orie Steele: Its really odd, that JSON-LD authors say use 2 contexts for examples, but they want to bundle data integrity definitions into the core context at the same time... it feels like its not, consistent... and does not help developers, because it does not establish convention.

Brent Zundel: closing the conversation on this issue.

Ivan Herman: I'm ashamed I can't find the # of my own issue that I raised. Mike, you might want to combine the two.

Brent Zundel: 1103.

Ivan Herman: I think that the sense of the discussion should be there. There's some editorial work to be done.
… to try to get this general issue out of the way, cleaning up context and vocab definitions.

Michael Prorock: +1 ivan.

Ivan Herman: The same issues with come with the DI spec.
… We are mixing up concepts.

Dave Longley: Orie: you're looking for consistency in the wrong place, it's not about the number of contexts alone.

Brent Zundel: I'll leave it up to mprorock_.

[OR13]

Related to #1149

[iherman]

The issue was discussed in a meeting on 2023-06-28

• no resolutions were taken

View the transcript

2.7. Why does the Data Model context file define a DataIntegrityProof RDF class? (issue vc-data-model#1089)

See github issue vc-data-model#1089.

Brent Zundel: #1089 - why does context define a DataIntegrityProof RDF class?

Orie Steele: see #1149.

Orie Steele: can't be closed because we need to define additional terms in VC context. Another open PR#1149, similar set of issues. What are we making normative with hashed approach is similar.

Brent Zundel: Before CR label most appropriate and so labelled.
… Mike Prorock assigned to it.

[iherman]

The issue was discussed in a meeting on 2023-07-26

• no resolutions were taken

View the transcript

3.2. Why does the Data Model context file define a DataIntegrityProof RDF class? (issue vc-data-model#1089)

See github issue vc-data-model#1089.

Manu Sporny: I think we need to keep this issue open as there is no other tracking issue.

Brent Zundel: We already have a marker to indicate that the content might change with CR. Do we therefore need a before-CR label?

Manu Sporny: Yes, I believe so. I think we should have a before-CR label for implementation requirements.

Brent Zundel: I believe the consensus now is to have a 'kitchen sink' model with everything defined centrally.

Manu Sporny: +1 to brent, that's my understanding as well.

Dave Longley: +1 to brent's characterization.

---

[brentzundel]

Based on the conversation during the call today, I will close this as soon as the minutes have been added.

[iherman]

The issue was discussed in a meeting on 2023-08-16

• no resolutions were taken

View the transcript

2.4. Why does the Data Model context file define a DataIntegrityProof RDF class? (issue vc-data-model#1089)

See github issue vc-data-model#1089.

Michael Prorock: +1 brent.

Brent Zundel: I think this issue can be closed.

Manu Sporny: +1 to close.

Dave Longley: +1 to close.

Manu Sporny: +1 to close.

Orie Steele: +1 to close.

Brent Zundel: context has lots of stuff in it.

Orie Steele: we are bundling everything into v2 context now.

Orie Steele: not just data integrity proofs.

[iherman]

Based on the conversation during the call today, I will close this as soon as the minutes have been added.

The minutes have been added, closing.

[iherman]

The issue was discussed in a meeting on 2023-08-16

• no resolutions were taken

View the transcript

2.4. Why does the Data Model context file define a DataIntegrityProof RDF class? (issue vc-data-model#1089)

See github issue vc-data-model#1089.

Michael Prorock: +1 brent.

Brent Zundel: I think this issue can be closed.

Manu Sporny: +1 to close.

Dave Longley: +1 to close.

Manu Sporny: +1 to close.

Orie Steele: +1 to close.

Brent Zundel: context has lots of stuff in it.

Orie Steele: we are bundling everything into v2 context now.

Orie Steele: not just data integrity proofs.