Verifiable Credentials Working Group Telco — Minutes

Date: 2024-07-03

Attendees

Present: Ivan Herman, Brent Zundel, Hiroyuki Sano, Manu Sporny, David Chadwick, Ted Thibodeau Jr., Jennie Meier, Joe Andrieu, Gabe Cohen, Dave Longley, Michael Jones, David Lehn, Benjamin Young, Phillip Long, Anil John, Dmitri Zagidulin

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Gabe Cohen, Manu Sporny

Brent Zundel: Welcome to the VCWG weekly meeting. We were going to have a conversation with EBSI about Terms of Use. We will do VCDM issue processing and look at Controller Document PRs + Issues. Anything else?

Michael Jones: I would like to review Controller Document status and next steps.

Brent Zundel: we will go into it!

1. VCDM Issue Processing.

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

Brent Zundel: let’s hope EBSI folks will join later and jump into issue processing.

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

See github issue vc-data-model#1437.

Brent Zundel: we have 10 open issues. many are addressed. #1437 - Remove at risk issue markers for property extension points.

Manu Sporny: We are waiting for the charter to up for AC vote for the PRs to go in. Waiting to hear from EBSI so that we can see their usage and cite it in the spec.

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

See github issue vc-data-model#1479.

Brent Zundel: next we have language maps. do not see Dmitri on the call today. he is working on a PR but we have not seen movement for a month. if it’s not happening we need to close it.

Manu Sporny: I can take it.

Brent Zundel: please reach out first to see his progress.

1.3. Add Security Considerations related to advances in Artificial Intelligence (issue vc-data-model#1507)

See github issue vc-data-model#1507.

Brent Zundel: let’s talk about AI! 1507 Add Security Considerations related to advances in Artificial Intelligence.
… there are vendors concerned about AI and interactions with VCs. we talked and said it could in validation/verification, or security considerations. getting some pushback from Mike – let’s see if we can find some consensus.

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

Manu Sporny: I moved to the validation section as Gabe requested. I know Ted pushed back a bit. It’s not out of place in either section. Pulled in all the WG’s requests for changes.

Michael Jones: I have expressed in GitHub. as editors we need to make judgment calls on what is useful/actionable vs what makes the spec longer. This doesn’t improve implementations. I don’t want stuff in it that I’m embarrassed to see. Should we also have security considerations around cloud computing? I’m puzzled.

Ted Thibodeau Jr.: Didn’t get the joke. There’s a difference between cloud computing and an ‘active agent’ - we know it’s an independent actor that can be put to use now in new ways. I think it is a relevant caution. We should say ‘be aware of this new thing, a moving target’.
… could be decades until things settle down. let’s put in a brief warning and move on.

Gabe Cohen: What would make this more real to you, Mike? Is there language we could change?
… Concerns around AI and data legitimacy are real. If we could improve the text that would be good.

Manu Sporny: I appreciate your opinion Mike. At this point just about everybody is disagreeing with your point. There are people working on some of the largest AI companies in the world working on research around AI and Verifiable Credentials. It quotes the work we’re doing here directly.
… it is possible for AI to pass tests today that were thought to only be passed by humans before (GRE, high school diploma, etc.). If people are building systems, and the security is built on VCs identifying certain capabilities and proof of personhood…we need to warn that may not be good enough anymore. Security researchers need to take that into accoutn.
… captcha is broken now. AIs can solve it better than humans. it would be strange for us to not say something about this.

Dave Longley: “VCs that seem like like they might only be acquirable by human persons might also become acquirable by artificial intelligence systems, be aware of this when validating / making decisions”.

Manu Sporny: see no reason to not put this into the spec.

Michael Jones: Gabe used the word that is key. Is the guidance ‘actionable’. Are there things we’re recommending? Are there actions that can be taken? If there are actions – cool. If I get overruled I would rather this be a security consideration. If there is not a validation consideration then it doesn’t belong there.

Dave Longley: Text should say something like ‘VCs that seem like they may only be acquired by humans today may be acquired by AI systems’ - don’t assume only a human can do it.

Manu Sporny: the philosophy that a spec should only contain normative actionable statements that end up in impls is a philosophy I do not believe we have ever - or should - employ. we have plenty of statements like this today, e.g. describing the ecosystem so implementers can make better decisions. -1 to a notion that everything we write needs to be actionable.
… implementers need to be able to take guidance and apply it to their specific use case.

Joe Andrieu: we do need to write something since people are asking this question and using this technology. 2 differences. 1 - confidence method is part of how we’re trying to solve this problem; not figured out yet (still a reserved property). the text does have actionable advice, though we can improve it. need to say something.

Michael Jones: I like what Dave Longley said - since it is actionable. Verifiers should not assume tests heretofore that were only passable by human beings are not achievable by machines at this point. don’t make an assumption that passing a turing test = party is a human being.

Brent Zundel: thanks Mike. seems like we have a path forward. language in chat.

Manu Sporny: the language is already in the PR. I would like to stop playing ‘go fetch a rock’ with this PR. I will integrate Dave’s changes.

Michael Jones: I will re-review after that, please ping me.

1.4. update updated media types to `application/vc-ld` and `application/vp-ld` (issue vc-data-model#1509)

See github issue vc-data-model#1509.

Brent Zundel: updated media types - 1509. don’t want a big discussion. we are trying to register application/vc and /vp - we are still on that path. if it gets accepted we’re done. if not, we will revisit and talk about other options. at this stage I do not think it is a fruitful topic to have a conversation about.

1.5. Re-evaluate support for `@vocab` in base VCDM v2 context (issue vc-data-model#1514)

See github issue vc-data-model#1514.

Brent Zundel: now we get to talk about 1514. Re-evaluate support for @vocab in base VCDM v2 context. coming out of a conversation in the Data Integrity spec. Some folks are suggesting there is a critical vulnerability. This could be a mitigation.

See github issue vc-data-integrity#272.

Manu Sporny: the discussion in the DI spec asserts a number of things…one is a realization that some people do not understand how @vocab works. because of that it has been misinterpreted and misused in that security disclosure. this discussion has led some to change their position on adding @vocab to the base context.
… the issue asserts we should remove @vocab from the base context. still up to us to decide how it could be used, if at all. the spec doesn’t say ‘don’t use it in production’ - folks in the thread think it must not be used in production (MUST vs SHOULD). how do we enforce that? should we? there are legitimate uses of @vocab/@base in production.
… there is enough here to raise a PR after we discuss this a bit more on the call today.

Ivan Herman: if @vocab must not be used that would require all participant parties to check that. that means off-the-shelf LD checkers cannot do this, since it is valid LD.

Dave Longley: +1 that we consider some language changes but not add a MUST NOT; any verifier must understand the contexts it consumes information from anyway, and they can only allow list contexts that don’t include @vocab (so long as @vocab is removed from the core context).

Manu Sporny: you are right. there are some LD processors considering putting in a feature around this. I don’t know if there is support for pulling this into our spec. There are legitimate uses of @vocab in production. Example: if the last @vocab in a context array, and your application knows that, … it could be fine to use @vocab if you order it properly and there are other similar scenarios.
… feels like we’re closing off a bunch of use cases for no real reason. the current security disclosure specifically did not do checks that we highlight in the spec. do not think we’ll get consensus. most we’ll see is a ‘should not’ or strongly discourage it unless you know what you’re doing.

Dave Longley: I tend to agree. a MUST NOT is a bridge too far. I do think removing @vocab from the base context is a good idea. any context should be vetted, verifiers do not need to accept with @vocab if they vet the core context (and we remove it).

Michael Jones: I was talking with Orie about this. The statements he made…he has a slight preference for always getting to RDF even if as a result of @vocab terms. If it is removed, then removal should mean terms are interpreted as JSON not RDF.

Ivan Herman: trying to make clear what I understand the proposal to be. 1 - remove from the core context. in parallel 2 - reinforce text to say ‘don’t use that if you can avoid it’. I agree with both proposals.

Manu Sporny: yes, your understanding of the proposal is correct, Ivan.

Ivan Herman: to Mike - I do not understand everything Orie is stating. I know he has this opinion that everything should be done on RDF only. I do not want to get into this, and not the right person to discuss this (RDF bias). His statement that we should treat it as JSON…I do not understand what he means.

Dave Longley: we decided a while ago that VC 2.0 uses LD compacted form. That requires that you understand the @context field. Not something you can just ignore. That makes things simple. We can clarify more if we need to do so. When you understand that…it prevents these problems from being raised.

Gabe Cohen: My main concern was to reduce the complexity on implementers that are more LD-averse, and I’m afraid that removing vocab increases the burden on implementers. I can see the arguments for using LD and understanding what its doing, but like the convenience for @vocab provided for those that wanted the feature. Is there a middle ground here?

Michael Jones: I understand what Orie is saying – we get a mapping for all terms that do not appear in context entries. This is why we added it. As an engineering mechanism I still think it’s valuable. I am prone to leaving it alone.

Ivan Herman: +1 to selfissued, I understand now what Orie meant. Thx.

Manu Sporny: We cannot leave it alone anymore - there is no support from the WG. We can figure out what to do about it. Gabe you asked - is there middle ground here? Yes - I think that’s what’s being proposed. The section we had said ‘don’t worry, just use the base context’ - that section can be updated to say - use these two contexts: the base and examples context since it has @vocab. Can work until they’re ready for ‘production’.
… IF they really want to use @vocab we can provide a template with an @vocab file..that is not a big ask.

Dave Longley: +1 to that plan, but none of that changes the fact that everyone must check the @context field, you can’t ignore it (and the spec already says this).

Manu Sporny: LD-averse people can continue to use the mechanism, we can continue to strongly recommend they don’t do that. one of the negotiations around vocab … we were concerned that people that were LD-averse would split the group and start competitive work at IETF and negatively impact both communities…that happened. So, that weakens the argument to have @vocab at all.
… we have said you do not need to use an LD processor, use a simplified set of rules, said just check the context array and make sure you’re OK with the contents, … but there’s only so much we can do. if developers are not going to use the spec since publishing a single context with an @vocab definition is too difficult, then I don’t know we need to cater to those developers anymore.

Brent Zundel: it sounds like we have a proposed path forward. remove @vocab from the core context. create an example/experimental context with @vocab for test purposes. did not hear anyone say no. a possible 3rd step - if you want to keep using undefined terms, then you can publish your own @vocab context.
… let’s spend one more minute and then move on to controller document.

Anil John: as someone implementing using DI and JOSE, using LD v2 using compact form is a credential for us. there will be no undefined terms in how we are creating credentials. all credentials we create will have clearly defined terms in the context..and can verify that the terms are coming from us.
… I am sympathetic that @vocab provides value. I disagree with having it in the base context. Developers become blind to it. The position that splits the difference (@vocab is bad vs @vocab adds value), we can add a secondary context that developers can add to note there are undefined terms.

Dave Longley: +1 to Anil, @vocab is useful in a closed setting like development, but it creates conflicts and problems in the general ecosystem.

Anil John: we support removing @vocab from the base context. support in a 2nd context for development purposes…so developers have to be aware of it…that’s fine.

Michael Jones: is it the case now that conforming JSON-LD implementations will throw an error if there are undefined terms?

Manu Sporny: yes…not all of them but we can force them to.

Dave Longley: conforming implementations will throw an error, yes.

Michael Jones: thanks that is good data. responding to Brent’s summary that no one has spoken against removal. I have spoken against removal. I would like to have this go out to some people - like Tobias - who are in different time zones, before making a decision.
… I would like more discussion before deciding on this call.

Dmitri Zagidulin: Responding to Manu’s point about not worrying about LD-averse implementers. Not quite the case…I know of multiple implementers that are new to LD. any removal of friction, such as including an @vocab (though I understand the concern) – let’s not discount that audience.

Manu Sporny: Agree that we want to remove as much friction as possible for people that are new to LD (and even people that regularly use LD).

Dave Longley: +1 to not discount, but to move @vocab to examples and new developer space.

Dave Longley: +1 to Manu.

Dmitri Zagidulin: we want to remove friction. we could recommend an inline @vocab, which is an option.

Ivan Herman: +1 to fall back on inline @vocab.

Gabe Cohen: +1 if we can inline @vocab I’m less opposed..

Brent Zundel: I open to reaching out to MATTR and others. Not sure how much they should dictate group direction.

Dave Longley: yeah, i don’t see why we can’t inline it – verifiers in production would reject it if they haven’t allowlisted it.

Phillip Long: +1 to in-line @vocab - which sounds like a good compromise.

2. Controller Document.

Brent Zundel: Let’s talk about controller document. We have 1 open pull request. we have 16 open issues.

Manu Sporny: I was able to open a PR on the Data Integrity spec. Removed every duplicated section, pointed to the Controller Document. Fairly minor surgery!
… some issues we need to address, but going well, we are on a good trajectory to go to CR.

Ivan Herman: can I update the security vocabulary? all terms need to point to the controller document.

Manu Sporny: in theory…yes…there may be some that fail and we can fix them.

Ivan Herman: I will start the practical part.

Michael Jones: I will say, as an editor, I did page in all the issues a day or two ago. I agree it’s in decent shape. As a VC JOSE COSE editor, I believe I should do the exercise Manu did with DI and see what it’s like to remove the Controller Document stuff from VC JOSE COSE.
… one thing in the VC JOSE COSE profile is restrictions on syntaxes to be used. That work is on me (and then Gabe and the WG to validate).

Gabe Cohen: I agree.

Brent Zundel: only a couple of those bigg(er) issues we’re trying to work through. shaping up to be in a good place. looking forward to seeing those changes and reviewing them.
… fantastic working with you all!