Verifiable Credentials Working Group Telco — Minutes

Date: 2024-07-17

Attendees

Present: Ivan Herman, David Chadwick, Brent Zundel, Wesley Smith, Manu Sporny, Hiroyuki Sano, Joe Andrieu, Kevin Dean, Dmitri Zagidulin, Michael Jones, Dave Longley, Jennie Meier, David Lehn, Benjamin Young, Steve McCown, Ted Thibodeau Jr., Phillip Long

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Joe Andrieu, Dave Longley

Wesley Smith: wes-smith has joined #vcwg.

Brent Zundel: agenda: TPAC, EBSI, Issue processing on VCDM and PRs, controller document.
… any suggestions?

1. Masking at TPAC.

Brent Zundel: W3C is feeling they don’t have the authority to enforce strict masking in the common spaces at TPAC.
… however, they are encouraging groups to establish masking rules for their meetings.
… We as a group have the authority to decide our own masking policy.
… The route I feel is best, but please speak up… this group would be willing to mask if there is anyone in the group attending TPAC who would be uncomfortable if people are masked.

Dmitri Zagidulin: heh do you know if they’re still asking to test at the registration desk, like they did last year? (which I’m very glad they did, it caught a bunch of covid cases).

Joe Andrieu: a/aren’t masked/aren’t masked/.

Brent Zundel: Please reach out to me or Ivan if you disagree.

Manu Sporny: +1 to be willing to mask if others feel strongly (but would prefer not to given how things have been operating) – I say this as one of the few who got COVID at W3C TPAC last year (and was the only time I’ve had it). :).

Brent Zundel: Moving forward on that hypothesis: if you are planning to attend but feel like you can only do so if people are masked in their room, please reach out to chairs.
… Chairs will take that input in confidence and make a decision. Basically, let us know and we will use actual information to set policy.

Michael Jones: I would prefer to defer to local health care rules.

Brent Zundel: I do not disagree, but this is the route the W3C has taken.

Steve McCown: +1 for deferring to local health care rules.

Ivan Herman: To make it clear, the “house rules” is that the W3C will not impose masking as it did in the last few years.
… that being said, there are groups which have members who have asked ror masking.

Brent Zundel: so W3C isn’t enforcing masking, but groups are allowed to do so, should they choose to do so.
… Our default is “no. wear a mask if you want.” but Let’s get some feedback.

2. EBSI and termsOfUse.

Brent Zundel: anyone from EBSI here?
… I thought they were going to come talk to us.
… Seems like they are not. Which is fine, but in absence of them showing up and telling us they are using Terms of Use, then we should probably keep it as a reserved term, but not an extension point.

Manu Sporny: I would be fine with that (as editor), can we send them an email asking for details that would let us include it if appropriate.

Brent Zundel: and you’re taking that action.

Manu Sporny: sure.

David Chadwick: I agree. I’m amazed. These guys replied they are using it, they do want it, and they were going to come give us a demo.
… but if they can’t be bothered…

Ivan Herman: because it is a reserved term, it is one of the terms that the new charter would give us the right to incorporate it into a spec. So, if we decide now it is reserved and do no more, that does not mean the door is closed forever.

Brent Zundel: do we still want to send an email?

Manu Sporny: sure. It’s not a big deal either way. Let’s give them a heads up.

David Chadwick: Manu’s edit removes it, which works for me, so we can likely close mine and take Manu’s.

Manu Sporny: +1 to agree with DavidC ^.

3. VCDM PR/Issue Processing.

Brent Zundel: https://github.com/w3c/vc-data-model/pulls.

Brent Zundel: Pull requests.

Manu Sporny: can we start with 1508?

3.1. Add Artificial Intelligence section to Security Considerations. (pr vc-data-model#1508)

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

Brent Zundel: add AI section. lots of approvals. One request for changes that seems editorial. And one request from Mike Jones to not include it at all.

Manu Sporny: I have applied Ted’s suggested changes.

Brent Zundel: anyone (other than Mike) on the call that would object to merging PR 1508?
… Mike you can comment too.

Michael Jones: What was the update that was going to be made?

Manu Sporny: Dave’s changes. Something like “VCs that seem like they might be only attained by humans… might be used by AI.”.

Michael Jones: Let me re-review it during the call.

Brent Zundel: pinging Mike may not have happened, so thanks Mike for looking at it.

Michael Jones: I still think this is a waste of spec space, but I’ve withdrawn my objection https://github.com/w3c/vc-data-model/pull/1508#pullrequestreview-2183294339.

3.2. Remove `@vocab` from the base context. (pr vc-data-model#1520)

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

Brent Zundel: also talking about https://github.com/w3c/vc-data-model/pull/1525 simultaneously.

Brent Zundel: 1520 and 1525 exist as a pair, really.

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

Brent Zundel: One of them 1520 takes vocab out of base context. 1525 adds optional new context with vocab in it.
… which allows people to test/develop.

Dmitri Zagidulin: quick question. about adding vocab to undefined terms context. Is that an option in addition to the examples context?
… we already have @vocab in the examples.
… I am a fan of taking it out of core.

Manu Sporny: You’re right, Dmitri. 1525 would add a separate @vocab in the undefined terms context.
… that one would be able to be used in production for those who want to use it. We recommend not to use @vocab in production unless you know what you’re doing.
… the compromise we got to was that Gabe wanted something other than the examples contexts that leverages issuer-defined terms.
… Gabe liked this approach, so it met his concerns.
… The main difference is that the examples context is not for production.
… The new one is.

Michael Jones: I take exception that the working group has decided to remove @vocab.

Brent Zundel: I did not see it that way, so I didn’t call it out as chair.
… ok. two PRs. anyone other than Mike who objects, please speak up.

Brent Zundel: as the only objector, is this is merged in, do you expect to formally object if this goes in.

Michael Jones: I hope we’ll never get there.
… We should have stability. This is destabilizing.
… The reason we put this in is so that all terms are processed as RDF. This is a security problem.

Brent Zundel: I felt there was additional information that justified reopening the discussion.
… I agree it is destabilizing, but I felt it was necessary.

Michael Jones: this is a security degradation.

Ivan Herman: +1 to dmitriz.

Manu Sporny: +1 to dmitriz.

Dmitri Zagidulin: Just taking out @vocab is destabilizing, but adding it back to undefined terms to restore stability.

Benjamin Young: +1 to dmitriz; definitely makes things clearer for everyone.

Dmitri Zagidulin: we are offering the same security options, we’re just adding a flag for it.

Michael Jones: it’s still a security degradation because its still optional.
… developers are lazy.
… deployments will occur where they forget to add the additional context.

Ivan Herman: I’m surprised by “security degradation”. But the current situation has a security problem as well.
… so the question is which of these are worse?

Manu Sporny: I also take exception to the concept that there is a security degradation.
… we are repeating things that have been discussed in the issues multiple times.
… If a term is undefined, the processor throws an error. That’s what happens. I don’t see how a processor throwing an error is a security degradation.
… This is a security enhancement.
… You seem to be arguing from a position from a year ago that we have already addressed.

Dmitri Zagidulin: +1 I like that suggestion.

Brent Zundel: I believe I have a suggestion for addressing Mike’s concern. How about “If you define terms that are not in the default context, you must use the undefined terms context”.

Joe Andrieu: The only concern I have with what you said, Brent, is that you should still be able to define terms in our own context and not use the undefined terms context.

Joe Andrieu: +1.

Brent Zundel: You must either define terms in your own context or use the undefined terms context.

Ivan Herman: +1 to brent’s option.

Dave Longley: +1 to say that you must do either of these things.

Brent Zundel: does this sound like a viable path forward?
… I’m seeing +1s.
… anyone who can’t live with this moving forward, speak now.
… This feels like consensus emerging.
… Manu, these are your PRs, will you make those mods?

Manu Sporny: yes.
… can we merge it once we do that?

Brent Zundel: Mike?

Michael Jones: I’d like to get a few people’s eyes on the new semantics before we merge it.

Brent Zundel: Manu, thanks for the willingness to make the changes. Ping me or Mike once you have the changes in.
… If those changes go in this afternoon, can you re-review by the end of the week?

Michael Jones: Yes.

Brent Zundel: So we’ll have feedback by Friday, which if cleared, means you can merge.
… one last thing on charter. We don’t need to hold off on a bunch of PRs as the charter explicitly includes the details we need.
… next up: Issues.

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

See github issue vc-data-model#1479.

Brent Zundel: Dmitri, the time has come. We need a PR or we need to pull it. How are we doing?
… Looks like we lost Dmitri.

Manu Sporny: I’ll raise a PR.

3.4. Pin down the input type of verification algorithms (issue vc-data-model#1517)

See github issue vc-data-model#1517.

Brent Zundel: Part of our edits over the last year were to refine the algorithm for verification. This is further iteration on that.
… PR 1522 is response to the issue.

Manu Sporny: it’s really just editorial.
… I just need to figure out how to do what he wants us to do.

Brent Zundel: where’s the PR that puts it somewhere else?

Manu Sporny: 1523. We merged that.
… I need to check with Jeffrey about closing.
… he raised two issues, but maybe we addressed it with 1523.

3.5. `expires` header for https://www.w3.org/2018/credentials/v1 is in the past (issue vc-data-model#1239)

See github issue vc-data-model#1239.

Brent Zundel: What is the reason we shouldn’t just do this now?
… any reason to wait?

Manu Sporny: The group decided to do it later. I don’t see why not to do it now.
… It’d be nice to close the issue.
… We also looked into it and there is some kind of caching bug problem. Ivan?

Ivan Herman: The problem is we are in an area I’m not familiar with.
… there was a caching problem I don’t fully grasp, but the original problem is that the files we are talking about may still be subject to change that would create potential problems. E.g., taking vocab out.
… so I proposed doing it after we’re stable. but not opposed to doing it now.

David Lehn: what was the propose change?
… the caching thing is a proxy issue. not sure how that gets fixed.

Ivan Herman: at some point in the future, the files we are talking about will migrant to W3C website and won’t be redirected to github.
… It seems the problem with github will go away eventually.

David Lehn: while still under development, maybe we shouldn’t move them over.

Manu Sporny: the issue is about the credentials v1 context. That should be fixed. For v2 context, that is still up in the air, we don’t have to address those at this point.
… Let’s just take care of V1 context.
… We can talk about v2 later.

Ivan Herman: I was not remembering that point, so thanks. I think what I hit as a problem is that we cannot set expiration data on a specific file. We can set it on all the files that are given to IPNET directly. I don’t remember how the system is organized.
… If they are in the same directory, we can’t set the expiry different for one than the other.

Manu Sporny: here is one way to set expires on specific URLs: https://stackoverflow.com/questions/1600831/setting-expires-header-for-a-specific-uri.

Manu Sporny: we can set expires on specific URLs in apache. Here’s how to do that.

Ivan Herman: I’m happy to look at it again either this week or next.
… I could use someone to look over my shoulder.

Manu Sporny: cc Lehn and myself and we’ll help out.

3.6. Enhance Context Validation (issue vc-data-model#1529)

See github issue vc-data-model#1529.

Brent Zundel: enhanced context validation.

Manu Sporny: Gave made a proposal that we add normative language to data integrity spec, but it might be good to put in VCDM.
… some sort of normative language to say you are checking issuers.
… Ted also suggested some detail on how you can use compaction algorithms to get rid of untrusted contexts.
… This PR is creating new normative language to doing that.
… We would be testing for that at the application layer, which we haven’t done before.
… But it seems that the group is willing to go there.
… action is to raise a PR that does that.

Brent Zundel: any concerns, speak up now.

Manu Sporny: I do have a question to the group. The specs we are creating have architectural layers, e.g., the securing layer is lower on the stack and validation is higher.
… I’m trying to figure out if it is worth using this language in the data integrity specification.
… Note that data integrity can work on things without @context.
… we describe the challenges with that.
… Would people object to duplication that language? If we put it in Data Integrity, that’s likely a layer violation.

Ivan Herman: I sort of understand the layering problem. But for me, the language seems more natural in the DI spec than VCDM. Just my instinct.

Manu Sporny: If we only put the language in the DI spec, VC-JOSE-COSE would have no language in it to ensure they understand the context.
… the layering here is that “these statements are things the application layer should be doing” they don’t have much to do with data integrity. They have more to do with VCDM.
… The root issue was ignoring contexts.
… So we had to tell people, “When you process an incoming document, you have to understand what it means”.
… One way to do that, with @context is to make sure you understand and trust the @contexts.
… That is an application-layer instruction. At the validation layer.

Dave Longley: i.e., don’t just guess what JSON keys refer to.

Manu Sporny: That’s why it would be a layer violation.

Ivan Herman: that makes sense. My first instinct then is that something needs to be added to VC-JOSE-COSE, but I will not object if it is in the VCDM. We should not spend too much time on it.

Dave Longley: the string “cats” could refer to many different things.

Joe Andrieu: The validation of the issues definitely doesn’t seem like it’s about securing, I am convinced of the layering violation.

Brent Zundel: next week’s meeting is canceled.