Verifiable Credentials Working Group Telco — Minutes

Date: 2025-01-22

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Hiroyuki Sano, Mahmoud Alkhraishi, Kevin Dean, Benjamin Young, Rene Leveille, Mandy Venables, Manu Sporny, Michael Jones, Dave Longley, Ted Thibodeau Jr., Will Abramson, Joe Andrieu, Phillip Long, Jennie Meier

Regrets: Brent Zundel

Guests:

Chair: Ivan Herman

Scribe(s): Benjamin Young

Content:

1. agenda review, introductions.

Rene Leveille: Hi, Rene from 1Password, recently joined W3C and been sitting in a few WGs. Been involved in FIDO for past few years.

Ivan Herman: anything we need to add to the agenda?

2. pending issues.

Ivan Herman: there are a few “to be discussed” issues.

2.1. Structuring the security considerations section (issue vc-data-model#1583)

See github issue vc-data-model#1583.

Ivan Herman: this is about structuring the security considerations section.

Manu Sporny: if folks remember for the VCDM, the new security group did a review on it.
… and mentioned there were no blocking issues.
… but said they may raise non-blocking issues.
… we have asked for a final horizontal review.
… we made that request a few weeks ago.
… just last week we heard from the security group and they requested we match a new structure.
… which is planned for all W3C specs.
… The vibration API and the Digital Credentials API groups would also be using this sort of structure.
… we said we’d be happy to participate over time, but I don’t think we said we would restructure all our documents at this stage.
… if you look through what was provided, there are a number of ways we could restructure this section.
… some of these suggestions require massive amounts of editorial work.
… we’re trying to figure out what amount of this is reasonable at this stage.

Ivan Herman: I agree with brent, this is simply too late.
… we’re planning to go to PR in February.

Dave Longley: +1 it’s too late in the process, it can be something we do in 2.1/x.1 specs going forward that clean up and revise the spec editorially.

Dave Longley: +1 to do it for maintenance.

Ivan Herman: I’d propose that we put on record that we’re happy to do this as maintenance work that we are already chartered to do so post recommendation stage.
… so the issue would stay open.
… and we’d just label it for maintenance phase work.

Phillip Long: +1 for doing the security work as maintenance.

Manu Sporny: we do have a label ‘future’.
… so we could mark it for that.
… the stuff they’re requesting is interesting, but it also is early stage ideas, so this approach would give the security group more time to test out this approach.
… it would be good for us to do this and we have done this in the past–as seen in our current security considerations section.
… but it would be best to take our time and do it right in the maintenance stage.

Dave Longley: do we need a proposal for this one?

Ivan Herman: if manu can add this info to issue, I think we will be fine.

Ted Thibodeau Jr.: +1 push this section revision to 2.1.

Benjamin Young: +1.

Manu Sporny: I’m writing that now.
… the group decided doing this work would be good in time, but doing this much editorial work this close to recommendation would be disruptive especially.
… the group agreed to mark this as editorial and address as future work during maintenance mode work cycles.

Ivan Herman: that’s the only issue brent identified for the data model.

2.2. Authentication of a CID (issue cid#141)

See github issue cid#141.

Ivan Herman: the next is on CID.
… manu, this is probably another one for you.

Manu Sporny: this issue is related to fediverse and ActivityPub use.
… JoeAndrieu you added something about base identifier and canonical identifier.
… when you get a CID value back it has an id value. That is supposed to match the URL you got the document from.
… we say that if that is not the case, then the document should be treated as invalid.
… the request is to make that a MUST.
… we did not do that earlier because there may be cases where it is valid for them not to match.
… such as the document being retrieved from cache even when the document is gone.
… or if query parameters, etc.
… so we avoided MUST language and used SHOULD language.
… so a further suggestion was to describe those cases.
… for the group: do we want to make this a MUST?
… if not, do we want to describe cases where these may not match?

Michael Jones: this is a security validation feature, so those should be MUSTs.
… we could informatively describe where that MUST would not be enforced.
… or we could say MUST…UNLESS…

Dave Longley: I think that MUST…UNLESS… construct is what is in there now, actually…just with different words.
… it is conditional.
… in the unless case we say you should treat it as invalid.

Michael Jones: that sounds like it’s already addressed then.

Manu Sporny: I agree, this is already addressed.
… do we want to describe the scenarios where it might be OK for them not to match?
… like trusting a cache?

Ivan Herman: is it a major amount of work?

Manu Sporny: it’s about a paragraph.

Ivan Herman: well in that case!!

Manu Sporny: I’ll raise that PR.

Ivan Herman: and everyone will be absolutely happy.

2.3. Data Integrity -> external resources (issue vc-data-integrity#323)

See github issue vc-data-integrity#323.

Ivan Herman: this one is on data integrity.

Manu Sporny: this issue was about what happens when URLs which are linked to which later disappear.
… the concern is mostly about archival systems.
… there are specifications that define how you fully encapsulate things for archival.
… and I think the hope is that we deal with some of those scenarios in our spec vs. downstream in archival specs.
… there are scenarios like extensions or the loss of the document being linked to from all systems.
… such as an issuer shutting down and no archives being made for the issuers documents.
… if there is nothing anywhere that one could get the context, then what do archives need to do?

Dave Longley: -1 to make any of our specs create and provide a process that everyone has to follow to fetch and cache URLs.

Manu Sporny: one idea is to expand it inline for archival.
… or they could download it into the archival record.
… there are several ways to address it.
… do we want to explain that in the spec? or do we want to differ that to other specs?

Dave Longley: I’d not be opposed to stating you could store any URL and it’s value for archival purposes, etc.
… this would apply to any URL, so we’d also need to update JOSE/COSE to reflect that.

Ivan Herman: is there anything here that is VC specific?
… this is a 404 problem which happens all the time.

Dave Longley: +1 to Ivan, if you are fetching URLs and you want to be able to “replay what happened” you need to do this.

Michael Jones: it’s not useful to describe something informatively if that text could result in normative changes.

Dave Longley: +1 to selfissued that we don’t need to say anything here.

Manu Sporny: agreed with selfissued. I don’t think there’s much more to say here beyond what we already say.
… we could perhaps add something to the long term security considerations section.
… maybe we just ask for language this person would like to see.
… and then consider that.

Dave Longley: “if your system fetches URLs at time X, you’ll want to save that content from that time if you want to replay exactly what happened.”.

Ivan Herman: sounds good. can someone help manu with that?

2.4. Call into JSON-LD via its WebIDL API instead of calling algorithms directly (issue vc-di-eddsa#100)

See github issue vc-di-eddsa#100.

Ivan Herman: this one is on EDDSA.
… but is likely beyond just that spec.

Manu Sporny: this issue came up because Jeffrey Yaskin was doing a review on behalf of the TAG.
… he’d spoken to Gregg Kellogg who’d suggested the use of the JSON-LD API and options.
… that’s Gregg’s preference.
… it would technically be a normative change if we changed the reference.
… the reality is that we didn’t have this reference previously, and we have 20 or so implementers.
… there’s also a request to use WebIDL which only browsers care about.
… and we should reference that implementer feedback has shown this is implementable as described.

Dave Longley: I’d also add that the WebIDL stuff in the JSON-LD API spec is optional.
… so at most we might say you could do it the way we describe or the way that was requested.

Ivan Herman: if we describe something in WebIDL it may present a false requirement that browsers MUST implement it.
… this has caused confusion in past groups.
… that’s a danger we should avoid.

Manu Sporny: yeah. true. If you invoke WebIDL, that can result in opposition and certainly causes confusion.
… I think the response here is that we discussed it, that it lacked support from the group, because we do not want to mandate WebIDL even though that’s fine.
… and we did not want to suggest we intended to force browser implementers to implement the described WebIDL.

Phillip Long: If 20 implementers are fine without this clarification there’s nothing that really must be done at this time sounds good.

Dave Longley: and we have plenty of implementations already, +1.

Ivan Herman: great. please then mark it as closed.

3. DI PRs.

Ivan Herman: DI PRs: https://github.com/w3c/vc-data-integrity/pulls.

Ivan Herman: there are 2 PRs which are pending.
… one of these is probably a left over.

Manu Sporny: yes, that one can be merged.

3.1. Add security considerations section on safer abstractions. (pr vc-data-integrity#330)

See github pull request vc-data-integrity#330.

Ivan Herman: does this one need discussion?

Manu Sporny: I think the PR is clear.

Ivan Herman: so there is nothing really to discuss here. 5 more days to review on GitHub.

4. VCDM PRs.

Ivan Herman: https://github.com/w3c/vc-data-model/pulls.

Ivan Herman: VCDM has a few more PRs.
… manu, which ones of these would you like to discuss.

Manu Sporny: let’s do the abstract one–1560.

4.1. Making Abstract abstract, instead of introduction (pr vc-data-model#1560)

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

Ivan Herman: this has been dragging on since September (!).

Manu Sporny: during last call, I agreed to try to use David’s language or propose alternate language that would get closer to getting consensus.
… DavidC did a rewrite and then I did another revision, ivan and dlongley gave feedback.
… I think we have consensus and I was waiting on TallTed.

Dave Longley: https://github.com/w3c/vc-data-model/pull/1560#discussion_r1923432170 <– just one more editorial change from DavidC and I think we’re good.

Manu Sporny: and DavidC had one more change request.

Ted Thibodeau Jr.: I just haven’t had a chance to look at it yet. I’ll do that today.

Manu Sporny: ok. then based on that review, we can hopefully get it merged.

4.2. 2nd attempt at finalizing list of Editors, Authors, and Acknowledgements. (pr vc-data-model#1585)

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

Ivan Herman: can we try to resolve the editors list?

Manu Sporny: DavidC said he preferred the other one, but with no details.
… and it’s showing that he did not approve.
… so, some context, we had a discussion about this last week.
… we merged it.
… brent reviewed the merge and noted that we said we would use data to add editors to the list.
… it had not say we would remove editors.
… so brent reverted the changes.
… and this new PR puts the editor list back.
… so now the question is is the group OK with that.
… practically that means, if you volunteered to do work but did not make sufficient changes, you would stay on the list.
… this differs from how we’ve handled this in the past.
… there’s also a question around GitHub handles in the Acknowledgements section.
… and how to alphabetize those.

Dave Longley: +1 seems fine to include GitHub handles that way.

Michael Jones: you didn’t mention that I put in a change request to add Gabe.
… I cited two examples of authoring and obtaining consensus for the Miami resolution which gave us a big tent scenario for awhile.
… he also worked out getting our media types straightened out.
… so I think both of those merit.
… I see an editors job as leaders not editors.
… so I don’t think doing the editorial work should be required to be an editor.

Ivan Herman: to be more precise, as described, we do not take people off the list based on data, but do take them off if they request it.
… the another comment on GitHub handles in other groups they just use the GitHub handles.
… it allows for privacy for the GitHub contributors.

Dave Longley: i think future iterations of the group should be more clear upfront on editor responsibilities and expectations so that everyone in the group is on the same page and what attribution will be based on, etc.

Manu Sporny: I’m also OK adding Gabe, but the question then is where does he appear in the list.
… we currently sort by the amount of contributions.
… so these contributions would put him on the bottom of the list.

Joe Andrieu: +1.

Dave Longley: +1 to adding Gabe.

Mahmoud Alkhraishi: I was going to suggest the same thing.

Michael Jones: manu and I discussed the GitHub acknowledgement and we say we sort it by first name.
… but these aren’t first names.
… so i want to see a separate list.
… and prefer we sort by last name.
… and then for extra credit we could link to their GitHub handles.
… I shouldn’t have to guess how things are sorted.

Manu Sporny: I don’t want tow separate lists.
… but we can explain how things are sorted.

Ivan Herman: +1 to manu on keep one list.

Manu Sporny: and that we’re using GitHub handles.
… we do normally do last name.
… but brent has done a great deal of work and brent’s last name starts with a Z.
… also many cultures don’t have last names.
… really we just need to decide.

Dave Longley: first name is fine to be kind to those people who are often listed last.

Ivan Herman: also just a reminder that “first” and “last” names are culturally subjective.
… e.g., Hungarian it is reversed from English, so are a number of names in Asia.

Michael Jones: ivan I have a question for people contributing without personal identification.
… the W3C has IPR requirements, how does that fit with a world where people have contributed but were not identified?

Ivan Herman: it depends on the contribution.
… non-substantial changes do not require IPR’s to be signed.

Ted Thibodeau Jr.: “given name”, “family name”, “patronymic”, etc. For discussion of some of these, see https://github.com/kdeldycke/awesome-falsehood?tab=readme-ov-file#human-identity.

Ivan Herman: if there are substantive changes, then they would be required to sign an IPR.

Michael Jones: then why are we acknowledging these people?

Ivan Herman: because non-substantive changes are still valuable.

Michael Jones: that’s a fine answer. thank you.

Ivan Herman: anything else?

Manu Sporny: we have to sort out if DavidC is opposed to this change or not.

4.3. Removed the “MUST” for error conditions to be in sync with CID and DI (pr vc-data-model#1587)

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

Ivan Herman: ok. we have time for one more.

Manu Sporny: we have a section on error conditions.
… it’s optional to implement.
… but if they do implement it, we have some strong requirements around how they implement those errors.
… this change would not effect our current test suites since these aren’t tested now because they are optional.
… so, if we reduce this from a MUST to a SHOULD to match the upstream RFC, this would not effect any implementers currently passing the test suite.

Ivan Herman: so…apparently we have a mixed approach across the specifications that use this text.

Dave Longley: +1 for consistency.

Ivan Herman: so this PR actually makes things sync up.
… whatever else we do, we need to be consistent.

Phillip Long: +1 for this PR.

Ivan Herman: comment on the PR if you’d like.
… any final comments?
… ok. I think we can close the meeting.
… brent should be back next time.
… bye all.