Verifiable Credentials Working Group Telco — Minutes

Date: 2023-09-06

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Brent Zundel, Sebastian Crane, Greg Bernstein, Manu Sporny, Juan Caballero, Ted Thibodeau Jr., Gabe Cohen, Joe Andrieu, Przemek Praszczalek, Dave Longley, Orie Steele, David Chadwick, Michael Jones, Oliver Terbu, Phillip Long, David Lehn, Kristina Yasuda, Nicholas Steele, Benjamin Young

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Juan Caballero

Content:

Sebastian Crane: brent: you have no audio?

Juan Caballero: i scribe.

1. TPAC in Sevilla.

Brent Zundel: https://docs.google.com/spreadsheets/d/1OXEEkZ-ffd4PBdGVJ2c0vjfcnqoGXeOO0RvC5eMEx7M/edit#gid=179611341.

Brent Zundel: still accepting last-minute agenda requests from the group.
… spreadsheet above to register attendance in-person and/or virtual.

2. Work Item status updates/PRs.

2.1. Status List spec.

Manu Sporny: status list work item update: would like to discuss at TPAC, hoping to iterate slightly to facilitate that.
… big question is whether to allow multiple formats/legacy format. single bitstring version versus multiple bitstring version.
… the two designs have different privacy properties and there may be usecases for each.
… so the question is whether both are optional, or one is an optional extension or legacy version of the other… tradeoff may be time to recommendation.

Brent Zundel: multiple versions sounds good, if different use-cases can be defined.

Phillip Long: pl-asu has joined #vcwg.

Michael Jones: are the two versions so different aside from length of bits?

Manu Sporny: review the PR, the differences are substantial.

Michael Jones: such as?

Manu Sporny: TTL, different privacy attack surface… i can summarize in an issue if that would help.

Michael Jones: I would object to complexity or optionality here, strong preference for minimizing the delta.

Orie Steele: Sounds like adding security considerations is probably a safe thing to do though (re status list concerns).

2.2. Add support for DIDs (pr vc-jose-cose#144)

See github pull request vc-jose-cose#144.

Michael Jones: I would like to close the PR adding multibase to Jose/Cose.
… jose and cose already have native key formats, I don’t see why other key formats should be allowed.

Orie Steele: https://w3c.github.io/vc-jose-cose/#key-discovery.

Orie Steele: provide clarity for vc-jose-cose#144 - intention was to close as many red issues quickly.
… as possible (see link).
… discovery of keys is a topic that covers many of these, in particular around controller documents.
… as we have been discussing this, a normative reference to the data integrity spec was rejected, so we opted to paste in some relevant text from there.
… I opened this PR because I feel that minimizing external concepts and being as silent as possible on DIDs leaves a gap in the implementability around key discovery.
… In the interest of timeliness, I would like to know as soon as possible what is acceptable to the group.

Michael Jones: I believe that nothing involving multibase will be acceptable to the group.

Brent Zundel: Orie has requested that this PR be moved forward with concrete suggestions, re: multibase and/or otherwise.

3. Issue Triage.

3.1. Encourage the use of OHTTP (issue vc-data-model#1267)

See github issue vc-data-model#1267.

Brent Zundel: oliver, can you walk us through #1267 and why it should be pre- or post-CR.

awoie: This issue resulted from ping group review, and a clarification or addition to security considerations would probably cover it, I believe.
… I can’t think of any normative changes that this would necessitate, and I don’t have strong opinion on pre- versus post.

Brent Zundel: if non-normative, post- should be fine.

Sebastian Crane: OHTTP hasn’t cleared IETF yet, so even if we wanted to add a normative reference we can’t yet.

Kristina Yasuda: ohttp has not been published by ietf yet!?

Manu Sporny: https://w3c.github.io/vc-data-integrity/#fingerprinting-network-requests.

Sebastian Crane: OHTTP === ‘oblivious’ HTTP.

Oliver Terbu: +1 manu.

Manu Sporny: the precedent is in the link i’ve just shared.

Dave Longley: https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/10/.

Sebastian Crane: I can take this issue and add a note post-CR.

3.2. are domain and range correct for all properties in data model? (issue vc-data-model#1263)

See github issue vc-data-model#1263.

Orie Steele: The vocab does not perfectly reflect the spec for abstract classes and domain and ranges… thats part of the challenge.

Ivan Herman: I would argue this issue (1263) should be pre-CR.
… diagram and vocabulary should reflect what’s in the normative spec text; nowhere in the spec does it specify that these can be used in VPs.
… if there is a desire to include these in the vocabulary or the diagram, we can do that, but only if the relevant spec text changes pre-CR.

Ted Thibodeau Jr.: I understand the normative text is upstream of the diagram, but the diagram is consequential and without it I would not have noticed this VC/VP delta.

Sebastian Crane: +1 TallTed (IRC) to importance of diagram to be correct and available.

Orie Steele: +1 TallTed.

Ted Thibodeau Jr.: I think these discrepancies deserve attention.

Orie Steele: There is another example where vocab, diagram and text seem misaligned: abstract classes.
… abstract class for CredentialSchema types are, for example, very important in the work items around JSONSchema.
… so I support clarifying this and making it more explicit pre-CR.

Ivan Herman: I volunteer to be assigned this issue.
… and as a sidenote, I want to briefly summarize what Orie means by abstract classes.
… abstract classes allow properties to be inherited by subtypes, this is a powerful tool.
… (scribe struggles to summarize).

Orie Steele: if you don’t like RDF just think of the abstract classes and Interfaces in TypeScript : ).

Orie Steele: FWIW, I think the classes should be in the spec, or removed from the vocab, since its confusing if they only appear in vocab.

Dave Longley: +1 yes, the VCDM just uses a simple object / class-based modeling constraint to express information as opposed to “anything goes”.

Dave Longley: which happens to map cleanly to RDF statements of subject -> property -> value.

Manu Sporny: We should have a section in the specification that defines the abstract classes for those that care about RDF, that’ll close that loop, I’m not hearing any objections to that path.

4. Issue Discussion.

4.1. Section title and contents mismatch on “Complex Language Markup” (issue vc-data-model#1254)

See github issue vc-data-model#1254.

Sebastian Crane: this one is going well and almost done, maybe today, will move on to the other issue assigned to me soon.

Manu Sporny: my one thought on 1254 is that internationalization guidance (w3c-wide) is being updated lately, and i don’t know if you want that in your PR or in a separate one.

Sebastian Crane: actually I think the PR was only mentioning @language in reference to security of LD documents.

Manu Sporny: Great, that sounds like it’s not an issue then, Sebastian! :).

Sebastian Crane: so not related I don’t think.

4.2. Recommend that authors don’t use @language in @context (issue vc-data-model#1264)

See github issue vc-data-model#1264.

Manu Sporny: in w3c i18n review, github user aphillips who is in this issue has been trying to align our spec with recent w3c i18n guidance.
… specifically around @language annotations in credentials and documents.
… which I don’t think many implementers have been following, at great peril for i18nal machine-readability.
… I don’t think there’s a standard way to use this feature in standard-tooling JSON, and I don’t think many implementers are using it in JSON-LD.
… so the concern here is that cross-processing as outlined in the spec (reading JSON-LD as JSON) could be hindered with little tradeoff if no one’s using it.
… so my questions are 1.) would the group object to describing this as a recommended way of doing i18n.
… and also 2.) would the group object to that description warning implementers about the base64 footgun this presents to cross-processing.

Orie Steele: thanks for that explanation. do i understand correctly that this is being removed in v2?
… i would prefer we took a strong position that we are discouraging it if no one implemented it after we recommended it in v1.
… i think it’s worth mentioning that it was in v1 and not in v2, if not also an explanation of why.
… ideally something that makes the recommendation simple, because too much detail can overwhelm confused implementers.

Sebastian Crane: I would actually argue that i18n is very important here, and I think putting the @language inline might confuse JSON parsers less than annotating from @Context.

Orie Steele: +1 to being clear… lets not give many options, lets give a single clear recommendation.

Manu Sporny: that is an option, but Orie’s point on a clear and rationale default recommendation should be taken seriously here.
… and I wouldn’t characterize this as having recommended A in v1 and recommending not-A now, it’s more like I think we have insufficient feedback from implementers.
… and I would appreciate feedback.
… since I feel like the v1 text was a compromise solution without a clear enough recommendation or rationale.
… which would take some time to create in v2, i.e. writing up multiple options and considering their pros and cons.

Orie Steele: wrong ~= we recommended something that people are not using.

Ted Thibodeau Jr.: 1. record erratum (really, bug) on v1; 2. explain in v2 why changed from v1, why NOT to do that thing we thought was a good idea before we had experience to date; 3. push I18n WG to produce some kind of whitepaper for all SDOs to refer to (because it seems like non-W3C orgs may not be doing such a great job with I18n, and everybody needs every SDO to do better with I18n).

Orie Steele: i’d be ok outlining many paths forward, and then picking one.

Orie Steele: we should say UTS-46 / WHATWG URL for i18n.

Sebastian Crane: I am more bullish on timeline because I do not think we have that many options to weigh or people defending each.
… would consensus on this call be possible?

Brent Zundel: sebastian has a resolution proposal.
… call for refinements or changes before they go into the minutes?

Joe Andrieu: I would change support to specify or include – an additional/supplemental context file should be able to include it or apply it.

Sebastian Crane: +1 that is.

Ivan Herman: nit: not just language but language directionality was mentioned in the issue, and not here in the proposal.

Joe Andrieu: +1 to that advice from Orie.

Manu Sporny: yes, +1 to what Orie is saying.

Sebastian Crane: +1.

Orie Steele: I would have expected the recommendation to be bipartite: not in core context, and how/if/whether to use in additional contexts.

Manu Sporny: @language is a sledgehammer that shouldn’t be used for VCs.

Manu Sporny: (when expressed in the base context).

Orie Steele: or, as I thought i heard, that the recommendation was not to use it in either.

Sebastian Crane: +1.

Brent Zundel: dlongley and orie have variations in the irc.

Juan Caballero: .. that overlap considerably.

Manu Sporny: https://w3c.github.io/vc-data-model/#language-and-base-direction.

Ted Thibodeau Jr.: this is so dangerous to decide without LOTS of evidence. see https://www.w3.org/International/articles/strings-and-bidi/.

Manu Sporny: I think we need more time, there is already guidance in the link i just shared, and what orie is calling the second part is what’s missing.

Orie Steele: I’d be good with dlongley’s proposal.

Manu Sporny: and i worry that even that would not fulfill the i18n peoples’ request.

Orie Steele: its an improvement over what we have now, its not sufficient.

Manu Sporny: yes ^.

Dave Longley: notes we could also require all encoded values use type multibase to enable language in the context, but that is very unlikely to get consensus.

Ted Thibodeau Jr.: also see https://www.w3.org/TR/string-meta/.

Joe Andrieu: I think it might be reductive to say it should never be used in @contexts, there are places even in VC were it might make sense.

4.3. Address normative concept of VerifiableCredentialGraph (issue vc-data-model#1240)

See github issue vc-data-model#1240.

Manu Sporny: I am on the hook for this PR.

Orie Steele: +1 Manu, its also related to the vocab vs spec.

Manu Sporny: yep ^.

Manu Sporny: which I am ready to work on, given the prior discussion about vocab vs spec.

4.4. Addressing Verifier Stored Data Vulnerabilities and Legal Compliance (issue vc-data-model#1247)

See github issue vc-data-model#1247.

Sebastian Crane: status update: I am going to work on it in the next few days.

4.5. Conformance requirements for normative context (issue vc-data-model#1185)

See github issue vc-data-model#1185.

Manu Sporny: oops new comments in the thread, will PR soon.

Orie Steele: related to your last comment on processing the data model in JSON-LD, I think a quick sentence or two would be enough. i’ll propose inthread.

Ted Thibodeau Jr.: also see https://www.w3.org/TR/string-meta/.

Joe Andrieu: I think it might be reductive to say it should never be used in @contexts, there are places even in VC were it might make sense.