Meeting minutes
brent: agenda for today: wrap up VCDM, discuss issues in Data Integrity
VCDM Wrap Up
brent: first topic: VC Data Model wrap-up
brent: 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
<DavidC> I cannot hear anything. Is anyone else having problems with Zoom?
w3c/vc-data-model#1437
manu: 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
w3c/vc-data-model#1479
manu: 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?
manu: Dmitri's contribution will take care of 1479, for next item Ivan has raised a PR
… once those three are done, no more issues on VCDM
w3c/vc-data-model#1534
manu: only thing waiting on then is for test suites to demonstrate multiple independent implementations for every feature in specification
… 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
<Zakim> brent, you wanted to talk timing
brent: 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
<Zakim> bigbluehat, you wanted to give a quick test suite update
bigbluehat: 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: is there a link to results page?
<bigbluehat> https://
bigbluehat: 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
decentralgabe: I have a template repo for the josecose test suite, have not gone through exercise of test vectors/normative statement tests
manu: 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
<decentralgabe> test suite template I mentinoed decentralgabe/
manu: 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
<Zakim> brent, you wanted to talk sd-jwt timing
brent: 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> Thanks for the update, Brent, that makes sense to me.
VC Data Integrity
<brent> w3c/
Brent: Data Integrity: we have one aspect of one key issue left
Brent: 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> w3c/
manu: 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
<dlongley> +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: 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
<dlongley> -1 to a recommendation that would preference it
Brent: 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
<dlongley> +1 to DavidC
DavidC: 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> +1 to DavidC's proposal
<Zakim> decentralgabe, you wanted to ask about resource integrity
decentralgabe: +1 to DavidC's proposal
brent: would anyone be opposed to adding this note? anyone want to argue that the context integrity stuff absolutely must happen?
brent: we have a path forward, do we have a volunteer to raise this PR
manu: I can raise this PR
brent: 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: 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
<dlongley> +1 to profiles being allowed that can require this or anything else (not encouraging anyone to profile in any particular way though)
manu: it'
… it's mostly at application layer, in a particular ecosystem verifiers must check this etc
Controller Document
brent: that topic done, next topic is Controller Document
manu: 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> https://
manu: 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: 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
w3c/controller-document#33
brent: 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?
DavidC: Yes, this knowledge needs to be explicit in the spec
manu: I can write this PR
w3c/controller-document#5
brent: 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: I can get to it eventually but not immediately.
brent: decentralgabe you are another person well suited to address this.
decentralgabe: yes you can assign me.
brent: if you want to interact with Mike and get him assigned as well that is fine.
w3c/controller-document#34
brent: next up: issue 34
manu: I assigned myself, will do this one and 35
w3c/controller-document#10
manu: don't need group feedback for these editorial PRs
brent: 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.
<Zakim> JoeAndrieu, you wanted to talk about the prior issue (#33) if/when appropriate
JoeAndrieu: 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: Please indicate that in the comments, we can keep going and loop back if there is time
w3c/controller-document#7
brent: next up #7, make conformance classes a top level section
… manu this is assigned to you - conversation needed for the group?
manu: 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
TallTed: +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> +1 to TallTed's suggestion that VC-JOSE-COSE should follow what all the other specs do.
brent: not hearing any pushback on Manu's proposal, going to marked this issue closed
<PL-ASU> +1 to Manu's request to close issue #7
w3c/controller-document#12
brent: 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: I took this, it's ready for PR, I just need to raise the PR
<decentralgabe> opened w3c/
w3c/controller-document#21
brent: 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: 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
w3c/controller-document#20
brent: that comment will get into the issue and hopefully be reflected in Ivan's PR
… next, #20, add the SRI datatype?
manu: 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: proposal is to close this issue with no action?
manu: Correct.
brent: Any opposition to marking this issue closed?
… hearing none, marked pending closed.
… next up, horizontal review tracking issues.
w3c/controller-document#22
brent: 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> w3c/
manu: 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: I need to ping, security, privacy, accessibility.
… with that, we have reached the end, meaning we can talk about #33 again.
w3c/controller-document#33
JoeAndrieu: 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.
DavidC: controller property is optional, if it's missing does the subject have control over setting Controller Document.
JoeAndrieu: subject may not be controller.
DavidC: Something needs to be said, if no controller property who has control?
decentralgabe: 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: 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: 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.
<Zakim> JoeAndrieu, you wanted to suggest a SHOULD
<Zakim> manu, you wanted to note that it's ok for the controller to be "unknown"
manu: 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.
<Zakim> dlongley, you wanted to say we should make sure that what we do continues to work with layering DID docs on top of the controller doc spec
dlongley: my main point is that whatever we do here should continue to allow layering DID documents on top of controller document spec.
brent: no longer have agreement on path forward on #33 - any suggestions? what action if any should be taken?
<decentralgabe> +1 to that we need to know who's flying the plane
manu: 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: 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.
DavidC: 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
JoeAndrieu: We can't override VDR
<dlongley> the VDR allowed that controller property to exist
<dlongley> it's not an "override"
DavidC: this yields a contradiction when VDR and document say different things
manu: 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
<Zakim> JoeAndrieu, you wanted to say what controller property is, is not VDR specific
JoeAndrieu: we need more time kicking this around, there are subtleties that need discussion.
brent: thanks all, looking forward to seeing PRs.