Verifiable Credentials Working Group Telco — Minutes

Date: 2024-07-31

See also the Agenda and the IRC Log

Attendees

Present: Ted Thibodeau Jr., Hiroyuki Sano, Manu Sporny, David Chadwick, Gabe Cohen, Benjamin Young, Phillip Long, Sebastian Crane, Jennie Meier, Kevin Dean

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Wesley Smith

Content:

Brent Zundel: agenda for today: wrap up VCDM, discuss issues in Data Integrity.

1. VCDM Wrap Up.

Brent Zundel: first topic: VC Data Model wrap-up.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc.

Brent Zundel: last few issues open on VCDM so we get all on same page as far as what needs to be done.
… 3 open issues that need to be finished that are not marked future.

1.1. Remove at risk issue markers for property extension points. (issue vc-data-model#1437)

See github issue vc-data-model#1437.

Manu Sporny: to speak to some of these, don’t need to go into depth, 1437 remove at risk issue markers: waiting on EBSI to give us concrete examples.

1.2. Consider explicitly allowing/recommending language maps for use in internationalisation. (issue vc-data-model#1479)

See github issue vc-data-model#1479.

Manu Sporny: for next item, 1479, we need a language map example, Mahmoud raised a PR but the PR didn’t have a language map.
… is Dmitri in IRC?
… Dmitri’s contribution will take care of 1479, for next item Ivan has raised a PR.

1.3. Publish undefined-terms context URI (issue vc-data-model#1534)

See github issue vc-data-model#1534.

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

Manu Sporny: for next item Ivan has raised a PR, once those three are done, no more issues on VCDM.
… only thing waiting on then is for test suites to demonstrate multiple independent implementations for every feature in specification.

1.4. next steps.

Manu Sporny: when we hit that, ready for CR2 for VCDM.
… maybe wait until TPAC, maybe go to CR2 ASAP.
… going to make full pass through spec to cleanup editorial issues.

Brent Zundel: if we get controller document in a state to go to CR by end of month, can finish updating Data Integrity and VC-jose-cose so when we get to TPAC the rest of the documents are in a state to be ready for second CR.
… strictly speaking, don’t need test suite to be done to go into second CR for VCDM.

Benjamin Young: we have been running test suite office hours right before this call, running weekly until TPAC, come if you have implementations that you need help integrating with test suites.
… all but small handful of tests written for VCDM, those should be done by end of week.
… each MUST statement already has 2 implementations, one or two left or coming that don’t have green check marks.
… if you have an implementation and are interested in participating, next Wed at 10AM, please reach out with questions.

Brent Zundel: is there a link to results page?

Benjamin Young: https://w3c.github.io/vc-data-model-2.0-test-suite/.

Benjamin Young: yes, these run every Sunday morning, up to date as of Sunday.
… only a handful of things not passing, just skimming there is one verifiable presentation test with only one check mark, everything else >1.

Gabe Cohen: I have a template repo for the josecose test suite, have not gone through exercise of test vectors/normative statement tests.

Manu Sporny: we are dependent on SD-JWT being done to go to rec, based on cryptography review in EU digital wallet stuff, it raises questions on path forward for EUDI/SD-JWT, now discussion around modifying SD-JWT to support unlinkable ECDSA work.

Gabe Cohen: See test suite template I mentioned.

Manu Sporny: that has undetermined timeline, what is our plan w.r.t SD-JWT and VC Jose cose.
… JWT stuff safe, COSE stuff safe, SD-JWT not on predictable path.

Brent Zundel: had conversations at IETF with SD-JWT folks about this, their plan was to address the extensions to SD-JWT in a separate spec, SD-JWT going to working group last call before Nov.
… working group last call IETF equivalent of candidate rec.
… folks I talked to confident that SD-JWT itself pretty much done, working group agreed.
… that said, should we get to the point where we need to go to proposed rec with VC-jose-cose and SD-JWT not yet at working group last call, don’t know that we can keep it in the spec at that point.
… should still be possible to keep SD-JWT in VC-jose-cose if timing continues to work out.

Manu Sporny: Thanks for the update, Brent, that makes sense to me.

2. VC Data Integrity.

2.1. Multiple significant security vulnerabilities in the design of data integrity (issue vc-data-integrity#272)

See github issue vc-data-integrity#272.

Brent Zundel: Data Integrity: we have one aspect of one key issue left.
… an issue raised citing possible vulnerabilities, a solution has been presented, all aspects except one of that solution have been agreed upon.
… the folks that raised the concerns believe that it would be most appropriate to add a mechanism for demonstrating context integrity.
… other folks are concerned about the overhead of that and that it may not solve the problems.
… that is the essence of what we want to talk about right now - how would folks feel about this? what should we do/not do?

Manu Sporny: https://github.com/w3c/vc-data-integrity/issues/272#issuecomment-2230883816.

Manu Sporny: 272 has 143 comments now, been discussed extensively, Gabe made a proposal many weeks ago that had broad support for a number of the items, can follow your nose to what Gabe suggested and how those things went into PRs.
… made adjustments to @vocab mechanism, took it out of core context, put in warnings about using it and how it might work in your benefit or against you.
… proposal 0 that Gabe did, fully implemented.
… the other thing that we ended up implementing was enhancing context validation.
… didn’t spell out how to do it before.
… arguably the main issue with the security issue raise, that they weren’t checking their context values.
… we now have a normative context validation algorithm in the Data Integrity specification.
… eventually that algorithm should be pushed to the JSON-LD spec.
… and the VCDM says that you should understand context values before doing any business logic.
… we can write tests for this algorithm in the test suite to test against implementations.
… that was the second proposal, the other thing was clarifying the processing model (what’s the order of steps etc.), that is in as a PR.
… the only thing that we now need to focus on is: do we need to put mandatory context integrity protection into the digital signature in Data Integrity.
… I don’t think it addresses the issue at hand, the problem with the security disclosure is that an important check was not being done.
… we have a mechanism to do context integrity protection w/ related resource.
… tying this any deeper into the crypto layer is problematic as it prevents certain use cases.
… not possible to go to CBOR-LD in certain cases, not possible for entities receiving a message to use their own context.
… in RDFC use case it doesn’t make sense b.c. you are already signing the quads.
… there is an argument in JCS case, but could use resource integrity there.

Dave Longley: +1 to allowing issuers (if they desire) to use related resource, +1 to never forcing a particular context on holders and verifiers, they should be free to translate/recompact. +1 that the forcing wouldn’t fix the issue anyway.

Manu Sporny: all doing this tells you is that you are using the same content hash that the issuer used when they created it, this is insufficient to protect against the kind of attack in 272.
… what’s being proposed 1. doesn’t address the core issue 2. prevents important use cases 3. is redundant w.r.t an existing feature.

Dave Longley: -1 to a recommendation that would preference it.

Brent Zundel: would it be possible to add a recommendation that folks do resource integrity? would that be a means of satisfying the folks who have raised this issue?
… curious what the drawbacks of that would be.
… it’s something that we have defined, is straightforward, and maybe would do no harm.

Dave Longley: +1 to DavidC.

David Chadwick: my suggestion would be weaker, just to add a note saying that if the issuer wishes they can integrity protect the context with related resource.

Manu Sporny: +1 to DavidC’s proposal.

Gabe Cohen: +1 to DavidC’s proposal.

Brent Zundel: would anyone be opposed to adding this note? anyone want to argue that the context integrity stuff absolutely must happen?
… we have a path forward, do we have a volunteer to raise this PR.

Manu Sporny: I can raise this PR.

Brent Zundel: we raise the PR, we go into the issue and list the PRs that have been raised, we as a working group believe this addresses the issue, then close the issue - is that right?

Manu Sporny: sounds good, one thing we can always do is strengthen requirements, if you are working in an ecosystem that needs this, in their spec they can mandate that verifiers must check this, at the base layer we are saying that you can use this feature, but in another spec using this you can make it a must.

Dave Longley: +1 to profiles being allowed that can require this or anything else (not encouraging anyone to profile in any particular way though).

Manu Sporny: it’.
… it’s mostly at application layer, in a particular ecosystem verifiers must check this etc.

3. Controller Document.

Brent Zundel: that topic done, next topic is Controller Document.

Manu Sporny: just to report where we are on Data Integrity and existing crypto suites, if we can close 272, we are out of issues for Data Integrity as well, same place as VCDM: need an editorial sweep and to make sure implementations are coming in, but not required for second CR.
… we can do that for ECDSA and EDDSA as well as Data Integrity.
… not able to do that for BBS, will be out of issues for that soon, but gated by IETF doing their review of BBS which is taking a long time.

Brent Zundel: https://github.com/w3c/controller-document/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc.

Manu Sporny: trying to get other cryptographers to do a separate review, but still won’t be able to transition BBS cryptosuite at same speed as others.

Brent Zundel: 14 Controller Document issues, going to do some issue processing.
… the question to the group for each issue is: what needs to be done/changed to address it (if anything), and if something must be done, who will do it.
… if folks stay silent, likely the issue will just be closed.

3.1. What is the role of the subject when the controller property is present? (issue controller-document#33)

See github issue controller-document#33.

Brent Zundel: first issue: 33. What is the role of the subject when the controller property is present.
… first question: DavidC, was dlongley’s suggestion adequate, would this suggestion resolve your concern?

David Chadwick: Yes, this knowledge needs to be explicit in the spec.

Manu Sporny: I can write this PR.

3.2. Put publicKeyJwk on an equal footing with publicKeyMultibase (issue controller-document#5)

See github issue controller-document#5.

Brent Zundel: next #5. Mike not able to join us today.
… most examples using public key multibase not public key jwk, need both in examples.
… is anyone opposed to doing this?
… will anyone take on the task of doing this?

Manu Sporny: I can get to it eventually but not immediately.

Brent Zundel: decentralgabe you are another person well suited to address this.

Gabe Cohen: yes you can assign me.

Brent Zundel: if you want to interact with Mike and get him assigned as well that is fine.

3.3. X25519KeyAgreementKey2019 has wrong property (issue controller-document#34)

See github issue controller-document#34.

Brent Zundel: next up: issue 34.

Manu Sporny: I assigned myself, will do this one and 35.
… don’t need group feedback for these editorial PRs.

3.4. Contexts and Vocabularies inconsistencies (issue controller-document#10)

See github issue controller-document#10.

Brent Zundel: next issue #10, currently assigned to ivan.
… Ivan presented a plan, just implementing the plan that was proposed last time we talked.
… Ivan has said he will do it, it will get done.

Joe Andrieu: I had to review the issue to try and understand if my interpretation was right or not, I’m concerned people might be imagining that subject has some power, there might be a mismatch between David’s actual concern and that other issue.

Brent Zundel: Please indicate that in the comments, we can keep going and loop back if there is time.

3.5. Make Conformance Classes a top-level section (issue controller-document#7)

See github issue controller-document#7.

Brent Zundel: next up #7, make conformance classes a top level section.
… manu this is assigned to you - conversation needed for the group?

Manu Sporny: on 6/30 I reported that the group has discussed this twice, no support to make this change, following same approach as in other specs, I marked this issue pending close, Mike disagreed and removed the label, I don’t think anything has changed and we are not expecting to make this change, group should make decision so we can close the issue.
… proposal: do not make conformance classes a top level section to conform with other specs.

Ted Thibodeau Jr.: +1 manu, perhaps we should push back on Mike to change Jose-cose to conform with the rest of the specs created by this WG.

Manu Sporny: +1 to TallTed’s suggestion that VC-JOSE-COSE should follow what all the other specs do.

Brent Zundel: not hearing any pushback on Manu’s proposal, going to marked this issue closed.

Phillip Long: +1 to Manu’s request to close issue #7.

Gabe Cohen: opened https://github.com/w3c/vc-jose-cose/issues/284.

3.6. proofPurpose seems unnecessary in Controller Document spec (issue controller-document#12)

See github issue controller-document#12.

Brent Zundel: moving on to #12, proof purpose seems unnecessary in controller document spec.
… there seems to be a mismatch, what do folks think about this.

Manu Sporny: I took this, it’s ready for PR, I just need to raise the PR.

3.7. (Minor) Data model reference? (issue controller-document#21)

See github issue controller-document#21.

Brent Zundel: next up #21 raised by Ivan.
… we have an informative reference to VCDM, copy-paste artifact, proposal is to remove that.
… hopefully Ivan will act on that and move forward.

Manu Sporny: I was going through the spec, we can remove most of the references, but we have a section on binding to a physical identity that references VCDM, in content integrity we say that if you want to do content integrity read about it in VCDM, we could point to data integrity, this feels like if someone blanket removes these statements it’s an issue, probably can remove most of them.

Brent Zundel: that comment will get into the issue and hopefully be reflected in Ivan’s PR.

3.8. Add the SRI datatype? (issue controller-document#20)

See github issue controller-document#20.

Brent Zundel: next, #20, add the SRI datatype?

Manu Sporny: I prefer not to move it since we don’t use SRI in Controller Document.
… the most pure thing to do is put it in Data Integrity spec but there were objections to that before so we decided to move it to where digestSRI and digestMultibase used, that was VCDM.
… we don’t use related resource or digestMultibase in Controller Document specification.
… Controller Document does define Multibase and Multihash, but does not have relatedResource, which is the only place the SRI datatype is used.
… I think they’re in the right places.
… If we move the SRI datatype into Controller Document, we don’t talk about it anywhere else in that spec.

Brent Zundel: proposal is to close this issue with no action?

Manu Sporny: Correct.

Brent Zundel: Any opposition to marking this issue closed?
… hearing none, marked pending closed.
… next up, horizontal review tracking issues.

3.9. Security and Privacy Self-Review (issue controller-document#22)

See github issue controller-document#22.

See github issue controller-document#25.

Brent Zundel: This is an opportunity for folks to report what they know about what is happening.
… We have filled out this security/privacy review questionnaire in advance of review being done on Controller Document spec.
… I don’t know how this is going elsewhere, we have requests in place but no indication that these requests are being acted on.
… A couple days ago, pending tag removed from a request, maybe a clue that it is being worked on.
… Security request still marked pending.

Manu Sporny: I have a tracking issue set up for all of them, #25, it looks like internationalization is done, but the others need a friendly nudge.

Brent Zundel: I need to ping, security, privacy, accessibility.
… with that, we have reached the end, meaning we can talk about #33 again.

3.10. What is the role of the subject when the controller property is present? (issue controller-document#33)

See github issue controller-document#33.

Joe Andrieu: David had mentioned that if we don’t have controller, does the subject get control back? But the subject doesn’t have control, no mechanism for that, may have answered that incorrectly.

David Chadwick: controller property is optional, if it’s missing does the subject have control over setting Controller Document.

Joe Andrieu: subject may not be controller.

David Chadwick: Something needs to be said, if no controller property who has control?

Gabe Cohen: It should be explicit who the controller is, might not be subject even if no controller present, would like more detail on “depends on VDR”, would like to always see controller present.

Manu Sporny: agree with Joe that it depends on VDR, don’t think that saying that controller must always exist is a good idea, some use cases where that doesn’t make sense e.g. write only things.
… language we could add is to say that if controller not set, controller is determined by policy of the VDR.

Brent Zundel: my view is that if there is a controller that is explicit then that entity is the controller, in absence of that, the controller by default would be the holder of the credential.
… if the holder is the subject or not is moot.

Manu Sporny: ok for controller to be unknown, for use cases there it’s up to the VDR.
… -1 for saying you must specify controller in every controller document.
… saying you SHOULD is a weaker form of that mistake.
… trying to figure out when it matters to know who the controller is, typically only for updating, if not specified, the answer is “I don’t know”.
… It’s been suggested that the subject is in control of it but that’s not always true either.
… Brent, you mixed VCs in with it, and I think that’s fine in a VC interpretation, but the controller document is not really playing a part in that question in that way.
… all that to say that it’s OK for the controller to be unknown.
… SHOULD is a little dicey here.

Dave Longley: my main point is that whatever we do here should continue to allow layering DID documents on top of controller document spec.

Brent Zundel: no longer have agreement on path forward on #33 - any suggestions? what action if any should be taken?

Gabe Cohen: +1 to that we need to know who’s flying the plane.

Manu Sporny: the only thing I can think of to reach consensus is to say it’s up to the VDR to say who the controller is if it’s not specified in the document.

Brent Zundel: that’s the path we have, we will say as much as we can, ok that sometimes you might not know who is flying the plane.
… We talked about everything we wanted to talk about.

David Chadwick: re: manu, if we say the VDR says who is in control if the controller document doesn’t say that’s fine, but we need to say that if controller is present it overrides VDR.

Joe Andrieu: We can’t override VDR.

Dave Longley: the VDR allowed that controller property to exist.

Dave Longley: it’s not an “override”.

David Chadwick: this yields a contradiction when VDR and document say different things.

Manu Sporny: controller document establishes what all VDRs must do.
… the rules for VDRs. I agree, we put ourselves in weird position if we say the controller field is entirely dependent on VDR.
… I don’t know if it’s an override, as dlongley says.

Joe Andrieu: we need more time kicking this around, there are subtleties that need discussion.

Brent Zundel: thanks all, looking forward to seeing PRs.