Verifiable Credential Linked Data Integrity work should happen in a Linked Data working group

[selfissued]

The new "Verifiable Credential Linked Data Integrity 1.0" deliverable (which was not present in the original charter), is sufficiently different from the core deliverable "Verifiable Credentials Data Model 2.0" that it should happen in its own working group. Surely the Proposed Linked Data Signatures Working Group (https://w3c.github.io/lds-wg-charter/) would be a better place for this work - likely containing more of the relevant subject matter experts.

Please remove the second proposed deliverable from the draft charter.

[selfissued]

And of course, the text "Algorithms for the expression and verification of proofs that use existing cryptographic primitives" should be moved from the Scope section to the Out of Scope section.

[iherman]

That approach has been tried, and it does not seem to be workable.

The LDS charter proposal[1] that you cite is, essentially, identical to the proposal that was put forward to the AC[2] and that was also submitted for review to the Linked Data/Semantic Web community[3]. This was followed by a fairly lively email thread as a response to [3] (and also a more modest discussion on GitHub and the AC). After many weeks' of discussions, we had to conclude that there is no hope to find a consensus for [1], and submitting it to the AC would lead to formal objections. We acknowledged that to the Linked Data community in [4], as well as to the AC[5].

The fundamental problem that came to the fore with [1] was exactly around the topic you are referring to. The community very much welcomed the possible work on RDF Dataset Canonicalization and Hash, which should become a core technology building block for Linked Data deployment. However, numerous commenters felt that the subject of the proposed work on Linked Data Integrity and Vocabulary concentrate on a very specific use case, namely Verifiable Credentials, and their generalizations to Linked Data at large would be problematic. As a consequence, inclusion of that work into a general Linked Data centric Working Group was rejected.

Hence the strict separation, which is also described in [4] and [5]: the work, originally put forward in [1] would be split:

• a working group should be set up concentrating on the problem of RDF Dataset canonicalization and hash, and only on that;
• the data integrity and vocabulary, that is based on the RDF Dataset canonicalization and hash, must be defined by Verifiable Credential experts in a different, targeted Working Group.

This has been translated into the proposal for the VC Linked Data Integrity work (note the fact that "VC" appears in the title!) in this charter.

---

1. https://w3c.github.io/lds-wg-charter/
2. https://lists.w3.org/Archives/Member/w3c-ac-members/2021AprJun/0002.html
3. https://lists.w3.org/Archives/Public/semantic-web/2021Apr/0012.html
4. https://lists.w3.org/Archives/Public/semantic-web/2021Oct/0020.html
5. https://lists.w3.org/Archives/Member/w3c-ac-forum/2021OctDec/0113.html

[iherman]

The issue was discussed in a meeting on 2021-12-01

• no resolutions were taken

View the transcript

1.3. Verifiable Credential Linked Data Integrity work should happen in a Linked Data working group (issue vc-wg-charter#21)

See github issue vc-wg-charter#21.

Brent Zundel: This might take some more time to discuss, Ivan responded laying out the history of the Linked Data Integrity and Semantic Web WG stuff -- the history/reason, so far no response from Mike..

Manu Sporny: We tried what Mike is proposing..

Phil Archer: quick comment -- manu's explained everything. the question that went through my mind; my worry is -- if we stick with those items, then MSFT will formally object to the next charter.

Manu Sporny: We got push back on Mike's proposal -- RDF Dataset Canonicalization will happen in another WG, there is broad consensus on that..
… and we should think about what we might do if that happens.
… The pushback we got was: "Do the Linked Data Integrity work in the group that's using it -- the VCWG -- that's where the implementers are, and it's a packaging format, not new crypto.".
… So, that's what we're doing because that is what removed the potential for formal objections..

Brent Zundel: any other comments on this issue?.

[iherman]

The issue was discussed in a meeting on 2021-12-08

• no resolutions were taken

View the transcript

1.2. Verifiable Credential Linked Data Integrity work should happen in a Linked Data working group (issue vc-wg-charter#21)

See github issue vc-wg-charter#21.

Brent Zundel: VC LDI work to happen. We haven't heard from Mike Jones on this in almost 2 weeks. We don't know if there's much we can do at this point but hope to hear on this..

Manu Sporny: One thing to mention here is that I think that by calling it Linked Data Integrity, we are communicating the wrong thing. The first wrong thing is that you have to use Linked Data to use the data integrity portions. Or rather, that the stuff we're working on don't require LD -- at least the data integrity portions. You can shove a JWT in somewhere and sign it..
… The "LDI" spec right now does not require you to do canonicalization based on LD, you can use non-LD canonicalization mechanisms such as JCS. You can choose not to canonicalize at all, and therefore there are variations that have nothing to do with LD. I'm wondering if we should rename the work to VC data integrity / data integrity..
… Plus all of the arguments that have been made to date. That may not be compelling to make but it's another angle we can take..

Ivan Herman: That's fine, but as far as I remember, the charter text itself refers to the RDF canonicalization work which is planned to be done, etc. It's not only the title, but the whole description that's there in the draft charter that has to be adapted, I think..

Manu Sporny: I agree, Ivan. I think the description right now is misleading. We may want to mention JCS as well, which is already an IETF RFC as another canonicalization mechanism. I'm happy to take an action to try and reword it before we have buy in from the group that this is a direction that the group is comfortable with..

David Chadwick: Obviously, I'm one of the proponents of not using LD, so I would be imposed to only working on LDI, that's too narrow a scope. Just like version 1 of the data model allowed both LD and non-LD, the work should continue in that vein and make it clear that we're doing so..
… I want VC to get world wide take up. I want the barriers to world wide take up to be as low as possible. We should support non-LD because that has a lower barrier to take up and leads to greater success of this WG overall..

Brent Zundel: Anything else on this issue?.

Ryan Grant: I also support not drawing in LD where it isn't absolutely necessary to VCs. That's all..

[brentzundel]

I believe this may be addressed by PR #32

[iherman]

The issue was discussed in a meeting on 2021-12-15

• no resolutions were taken

View the transcript

1.2. Verifiable Credential Linked Data Integrity work should happen in a Linked Data working group (issue vc-wg-charter#21)

See github issue vc-wg-charter#21.

Brent Zundel: manu I believe you have a PR open for this. Can you tell us about this?.

See github pull request vc-wg-charter#32.

Manu Sporny: yeah there's a PR open for this.
… what it's trying to do is make it clear that this next spec will be talking about data integrity for verifiable credentials in a more wholistic and normative way.
… this means JWTs/LD-Proof and any other mechanism would be in scope as well.
… including things like JCS and other things like that.
… we can't invent new crypto here but can focus on how things get packaged up.
… by calling this LD Integrity it's not accurately representing this.
… the specific reasons we're doing this is because we want to be clear that we're not just talking about Linked data integrity and making this about VC data integrity.

Brent Zundel: Assuming the JWP work gets further along would you expect we could use that in here?.

Dave Longley: My one concern with this PR is that we don't want to convey that we're only doing JWTs and want to make it clear the Linked Data proofs are in scope.

Manu Sporny: One thing we do to counteract that is to link specifically to the linked data proof spec.
… I can check in CCG about renaming but this should make it clear that we want it in scope.
… I'll add some clarifying language to explicitly list the things in scope.

Kyle Den Hartog: I was thinking about... the proof section becomes obvious, I'm not sure to what degree we wanted to scope particular suites... with JWTs you don't hit that as much, how do we want to handle scoping of that?.

Manu Sporny: I believe the way it's scoped now is that we say all of the suites are non-normative.
… one second that might not be true.
… we don't say anything about the suites themselves.
… I think the intent was to note define specific suites.
… we'd publish notes and test suites for it but not define them normatively.

Dave Longley: -1 we shouldn't constrain ourselves to not being able to define any suites.

Manu Sporny: but that might be the wrong way to go about it.

Kyle Den Hartog: I'm concerned that suites are being developed now in a way that makes it problematic..
… Like there are 2020, 2021, 2022 suites being developed, taking longer than a year to stabilize -- we need some sort of model to encompass the active work happening right now..

Dave Longley: I don't think we should constrain ourselves to not being able to address these suites.
… we may be able to develop a versioning scheme that's a bit of a middle ground where we create a few with common vocabs to describe these.
… and that might avoid some of the issues that Kyle is bringing up.
… we might be able to handle this, but my main point is that I don't think we should constrain ourselves to solve that.

Manu Sporny: There is a VC extension registry.
… I think we're probably going to end up making that in scope.
… I'd imagine doing all that to document that things are in process.
… to dlongley point I think the big question is how normative do we want to get about the suites.
… I think the idea was that we'd define a bunch of the suites as notes.
… part of the DID-Core objections are that you should have just taking things to CR and not gone further.
… so if we take that into consideration for this chartering we may follow a similar model.
… where we only take a suite to CR without saying we're going to work on all of these suites normatively.
… and stay focused on a few that we take to CR and if we have good enough interop we can ask W3C to take it to REC later.
… this would allow us to make it clear that we're not overscoping our work.
… so we need to be careful about what we say we're going to do.
… this is to say we'll change the description to say we'll describe Edwards curve, BBS+, and JWTs but not take them fully to REC.

Brent Zundel: How common is it for people to say we're only going to CR only?.

Manu Sporny: Not common it's only for CSS typically and other perma working groups.

Brent Zundel: with just my hat on I'm not sure going to only CR makes sense.

Dave Longley: +1 I think it's best to say we're going to handle only a few suites.

Kyle Den Hartog: Saying going only to PR seems like people could object to that.

Manu Sporny: I think we could do that for Edwards curve but could be trickier for BBS+.
… we'd need CFRG approval before we could reference them normatively and succeed in REC stage.

Dave Longley: if we go with something a bit more general we could describe how you use a suite without having to specifically normatively define BBS+.

Brent Zundel: There's active work at DIF and they expect to have something to submit to the CFRG first quarter next year.

Manu Sporny: Is there something we can point out?.
… even if it's an ID that intends to go to CFRG.

Brent Zundel: See current draft of BBS+.

Manu Sporny: I think the response to the JWTs handling all of this is that you can't do multiple signatures together with JWTs today.
… the other issue is that we have a parallel RDF canonicalization WG.
… and that group is expecting the ability to not have to use only JWTs only.
… and with people already using this I think we have sufficient counter arguments for these things being brought up.
… and we've documented all that stuff.
… I think we're ok, but we'll see how it goes.

Kyle Den Hartog: I think that's a sufficient argument.

Manu Sporny: I guess the question is what do we want to do for this..
… Do we want to update the description for this PR and describe focusing on Edwards and BBS+.
… and because this is a normative item we can then decide as a WG to decide how we want to split up that work.
… we'd have one description to define how to express VC integrity with a specific focus on Ed25519, BBS+, and JWTs.

David Chadwick: +1.

Dave Longley: +1 to what manu just said and to pointing to this discussion saying we meant to define LD suites.

Manu Sporny: and if there's ever a question about whether or not we meant to include Linked Data we can point back to these minutes to show we were very clear.

Brent Zundel: So what needs to change for that to happen?.

Manu Sporny: I need to change this PR to include it and I'll link to draft state input documents to cover this.

[brentzundel]

we believe this has been addressed.

[iherman]

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

• no resolutions were taken

View the transcript

2.1. Verifiable Credential Linked Data Integrity work should happen in a Linked Data working group (issue vc-wg-charter#21)

See github issue vc-wg-charter#21.

Brent Zundel: The discussion we had in this meeting, with lack of response from MikeJones who posted the issue, in my opinion this issue has been addressed and can be closed..

Manu Sporny: +1 to closing, agree with brentz's assessment..

Brent Zundel: Any disagrees?.
… Going to write a quick note and close it..