Verifiable Credentials Working Group Telco — Minutes

Date: 2023-10-04

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Hiroyuki Sano, Paul Dietrich, David Chadwick, Orie Steele, Kristina Yasuda, Brent Zundel, Manu Sporny, Dave Longley, Sebastian Crane, Shigeya Suzuki, Will Abramson, Ted Thibodeau Jr., Michael Jones, Benjamin Young, Greg Bernstein, Chris Abernethy, Andres Uribe, Gabe Cohen, Joe Andrieu, Phillip Long, Dmitri Zagidulin, Nicholas Steele

Regrets:

Guests:

Chair: Kristina Yasuda

Scribe(s): Benjamin Young, Manu Sporny

Content:

• 1. PR status updates.
  • 1.1. Explain JSON-LD further. (pr vc-data-model#1270)
  • 1.2. Update to Terms of Use description (pr vc-data-model#1295)
  • 1.3. Remove normative dependency on Multibase and Multihash. (pr vc-data-integrity#196)

1. PR status updates.

Kristina Yasuda: I expect us to spend a good bit of time on PRs today.
… many things are blocked.
… they should be labeled, but some may not be, so we may consult others if time.
… manu raised Data Integrity PR reviews as needing to be addressed.
… anyone want to start with a PR or status update?
… DavidC are you queued to talk about ToS topics?

Manu Sporny: do you want these in oldest to newest order?

Kristina Yasuda: probably skip 1271.

1.1. Explain JSON-LD further. (pr vc-data-model#1270)

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

Manu Sporny: so, 1270 has multiple requests for changes.
… selfissued is blocking. Orie is blocking.
… what changes need to be made?

Orie Steele: we have this section about JSON processing…which I don’t really like.
… I’d believed we would/should add a JSON-LD section to explain applying @context more completely.
… and these two things differ substantially when you just process JSON.
… I think the text in the JSON processing section is dangerous and misleading.
… that text is mostly information that doesn’t help implementers.

Dave Longley: -1 to what Orie is saying :) … the information is the same, JSON-LD is a syntax that expresses graph information.

Orie Steele: and doesn’t help people use RDF or JSON-LD.
… so the changes I want to see are to remove these differences.
… bigbluehat’s comments are excellent.
… he says there dangers of doing just JSON processing.
… it’s a huge mistake for us to be vague.
… and this will harm interop if these things differ too much.
… the JSON-LD processing section needs to talk more about RDF data model.
… @id, @list, etc.
… basically the stuff that’s in the @context that only an advanced processor would use.
… I strongly disagree with the position that dlongley stated.
… that we should avoid the JSON-LD feature to keep it compatible with JSON processing.
… bigbluehat’s PR has some of this, but not enough which is why I’m requesting changes.

Kristina Yasuda: +1 to json processing is not compatible with JSON-LD processing (without additional checks on top co json processing).

Michael Jones: this PR kind of runs at the mouth.
… it says a lot of things that aren’t useful to implementers.
… we don’t need to be an evangelist mouth piece for JSON-LD.
… I will not approve this until it’s down to a sentence or a paragraph.

Orie Steele: I would encourage better direct references to the JSON-LD spec, for example: https://www.w3.org/TR/json-ld11/#relationship-to-rdf.

Dave Longley: trying to figure out where to start.
… there are many competing requests.
… many from Orie requesting explanation of the advantages of JSON-LD.

Kristina Yasuda: chairs hat on, i don’t think the request was “json-ld advantage” it was about “json-ld processing guide”.

Orie Steele: I disagree that the PR captures the advantages on JSON-LD, but I agree that is an objective… and I think citing the JSON-LD spec, would better accomplish the mission.

Dave Longley: new comers are often confused by the ability to process JSON-LD further with libraries.
… but they miss that JSON-LD is a syntax.
… if you understand the @context, then you can move ahead.
… if you don’t understand what’s in `@context, then you do need to process that and understand it.
… so this section is really talking about that difference.
… JSON is really just a syntax.
… and if you want to do anything with JSON, you need a spec to read and implement.
… whereas JSON-LD is an object-oriented graph model that defines how to be processed.
… JSON-LD imposes additional constraints.
… so you don’t have this problem of missing out on this extensibility and data model.

Orie Steele: I agree with what dave is saying, that JSON-LD and JSON claims can’t be merged, without understanding RDF… that is the security issue that the group is being unclear regarding.

Dave Longley: the JSON processing model section basically says that if you know it’s using these @context definitions that the spec specifies, then you can just process this in JSON–because you trust it implemented the spec.
… on top of that Orie has been asking on elaborating on the additional value of JSON-LD.

Orie Steele: We don’t have the section, we have draft text, which I don’t feel is acceptable yet… the mission is still ongoing.

Dave Longley: but now we have the counter request to remove all of this–both JSON-LD values that were requested and the JSON processing section.
… many of the new comers have missed the history here.
… that this context ability was chosen on purpose.
… that it provides the clarity of what the data is about referenced from that data.

Orie Steele: Agree with what dave is saying about JSON-LD providing value to W3C Verifiable Credentials, hence the need to communicate the value of JSON-LD and RDF processing as opposed to “JSON Processing”, which does not require reading the JSON-LD spec, to do safely.

Orie Steele: +1 to landing the PR, after revising it.

Dave Longley: it’s valuable to explain this value and how it helps and has helped this community since the beginning.

Kristina Yasuda: I don’t think we don’t want to have this section.
… it feels like there’s more discussion needed for this PR.
… it’s not like this needs huge conversation.
… so lets entertain the queue.
… but keep it sort and sweet to exactly what you want to see here.
… not debate the values of JSON-LD etc.

Ted Thibodeau Jr.: I started off being extremely frustrated by two voices in this conversation.
… both are asking for vague changes with no specific changes.

Orie Steele: If the working group agrees, I am happy to author an alternative PR.

Ted Thibodeau Jr.: I kinda want to lock Orie and selfissued in a room and let you hash it out.
… but I don’t think that’s going to be useful.
… and others should support you if they agree.
… Orie’s been asking for this for months.
… but without any actual contribution to the conversation.

Orie Steele: IMO its better to refer to a spec, than it is to mischaracterize the benefits of a spec, without references.

Ted Thibodeau Jr.: he hasn’t put the concrete suggestion forth.
… and selfissued if you want this down to a sentence, then write that sentence.
… otherwise you’re just blocking to block.

Kristina Yasuda: this is an inclusive environment.

Ted Thibodeau Jr.: you’re spending more time on this than anyone.
… let’s move onto the queue.

The minutes do not fully capture the interaction between Ted and Kristina. The chairs felt that Ted’s behavior was not acceptable and asked him to leave the call.

Kristina Yasuda: please leave the call TallTed.

Brent Zundel: ivan please remove TallTed from the call.

Orie Steele: My offer to author an alternative is sincere, we may find that merging 2 different PRs is an effective path forward.

Manu Sporny: yes, please write something Orie ^.

Orie Steele: will do.

Michael Jones: strangely related to what TallTed was saying.
… I do have a specific action.
… put this in a note, and reference the note.

Ivan Herman: clarification. you mean a separate WG note document, correct?

Michael Jones: yes.

Kristina Yasuda: there is a separate JSON-LD spec…so I’m not sure a separate note gets us much.
… please offer concrete PRs with concrete suggestions Orie.
… and we can move from there.
… Orie is that OK?

Orie Steele: IMO, its worth highlighting the parts of the JSON-LD spec that can provide the most value to Verifiable Credentials.

Orie Steele: yes, i will do a PR.

Dave Longley: +1 to see something from Orie … but also note, Orie, I think there may be more benefits to VCs than you’re thinking of (including all of the ones in the PR of that subtopic).

1.2. Update to Terms of Use description (pr vc-data-model#1295)

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

David Chadwick: no one had implemented this on the v1 data model, but there have been some now.
… to the best of our knowledge there are several now.
… the problem now is that the original term was generic.
… and my original PR was to improve it to make it more encompassing.
… the v1 had generic text, but talked about mandatory things to do…which was not equally generic.
… so this PR makes the actions also be generic.
… then the comments came to provide examples.
… so I did that with real URIs, etc.
… but then the feedback came about the URI’s and that they may not be around as long as the spec.
… so now I think the data model should have the generic text.
… and we should point to an extension space for these.
… so my proposal is that if we want the EBSI example to be the example, then we’d have to explain it all.
… or we could make it a generic example…but then it wouldn’t be a good example.

Kristina Yasuda: so the question I have is proving that there are two implementations in the example–is that what we want to see?
… how the use of the ToS seems underspecified.
… so how can that be improved –that’s the question I want addressed.

Orie Steele: I want to thank DavidC.
… he’s been good about addressing feedback.
… there’s some v1 stuff that still needs removed, but overall this seems ready for tests to be written for.
… once there’s two tests we can merge this.

Manu Sporny: the examples in the spec are non-normative, so the URL’s in them shouldn’t matter.
… DavidC has proved that there are multiple implementations.
… there is v1 cleanup.
… but I am confused about testing the extensions.
… feel like goal posts are being moved unless we’re being very clear about what needs testing.
… multiple people are using it.
… there is a separate test suite.
… and I think that tests that it’s being used.
… so not sure we need to take on the interop tests.

David Chadwick: I accept that it’s v1 because it’s based on their existing work.
… I can upgrade it to v2.
… I realized it takes more than swapping out the contexts.
… and that an additional EBSI context needs to be defined now.
… to work with the v2 data model.
… however, I don’t think I should be describing how EBSI works.
… maybe I can just say, this is implemented according to the EBSI spec and link there.

Orie Steele: this is about testing.
… my request is about removing that “at risk” flag.
… to do that we need 2 supporting implementations that past tests.
… if the only normative requirement that it use an RDF type, then having an example should pass that test.
… I don’t think there are additional tests to write.
… just share examples that can survive issuance and validation.

Manu Sporny: so Orie if I’m understanding you.
… then a test that says, “uses issuer defined type”.
… and as long as that issues and verifies, would that meet your expectation of the testing requirement?
… can we use an example in the type in the terms of use?

Orie Steele: as far as I’m concerned we just need to prove that two implementations can handle these examples.

Manu Sporny: so if 2 implementations do not choke on these examples then we’re fine?
… and you do not believe they need to understand the Terms of Use terms?

Orie Steele: I hope not.

Manu Sporny: k. then as long as issuance and verification don’t choke across two implementations, then I agree that we’re good.

David Chadwick: this is great, thank you.

Ivan Herman: to clarify, if DavidC goes through what was just discussed, then we remove the at-risk flag? correct?

Kristina Yasuda: yes.

David Chadwick: do I remove them now?

Orie Steele: I left a comment similar to what ivan said on the PR.

Kristina Yasuda: no, we need them tested first.
… and an issue to track.

1.3. Remove normative dependency on Multibase and Multihash. (pr vc-data-integrity#196)

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

Manu Sporny: this is a base PR for many other things.
… selfissued has made many requests.
… and I want to get through them on the call.

Manu Sporny: See https://github.com/w3c/vc-data-integrity/pull/196#pullrequestreview-1657894864.

Manu Sporny: ‘cause this is dragging out.
… selfissued, you are asking for more normative definitions where there are just examples.
… so the normative references you want are in other specs.

Manu Sporny: https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/196.html#multibase-0.

Manu Sporny: this preview ^ shows these definitions have been in there for awhile.
… it’s normatively defined in the specification.
… the other thing is asking about the header format and how they’re used.
… they’re headers, they’re doing what they’ve been defined to do.
… these are examples, so they are not normative.

Manu Sporny: https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/196.html#resource-integrity.

Manu Sporny: same thing is true for the others also.
… this stuff is defined in there.
… I can go and respond to each one, but they are all already normatively defined.

Michael Jones: I am reading the specification.
… the text that you’re talking about does not normatively define how to translate the alphabet to string or binary.
… in all cases where we’re using data structures, we need to define in sufficient detail, so implementers can build implementations.
… I’m still doing a review, but there’s similar incomplete definitions in EDSA as well.
… counting on tribal knowledge isn’t acceptable when we’re normatively referencing something.

Manu Sporny: base encoding something is something no ones had a problem with since forever.
… no other spec has to define this.

Michael Jones: no. you must define it in the spec.

Orie Steele: @manu, you can paste in this example: https://github.com/cryptocoinjs/base-x/blob/master/src/index.js. lol.

Manu Sporny: then if I define base encoding, will you let us merge this?

Michael Jones: yes.

Manu Sporny: so you want all these things redefined directly in this spec?

Michael Jones: yes.
… there’s a term, multibase prefix…and that’s not defined.
… when I review stuff, I like to pretend I’m an implementer.
… and imagine whether I can build code with that of others.
… and if I can’t, then I raise issues.

Manu Sporny: Here is the normative definition: https://pr-preview.s3.amazonaws.com/w3c/vc-di-eddsa/pull/63.html#multikey.

Manu Sporny: Here is the other normative definition: https://pr-preview.s3.amazonaws.com/w3c/vc-di-ecdsa/pull/42.html#multikey.

Manu Sporny: I have pointed directly to the normatively to the definitions.
… and they tell you how to build the format front to back.
… I can make these changes, selfissued.
… but every time I make a change, you request new ones.

Michael Jones: I’m sorry that’s the way it feels.
… but the intent is to have each of these specs completely define everything implementers need to do to implement everything.

Dave Longley: would referencing RFC 4648 and say that the bases used are 58, 64, and the alphabets are base58-btc and base64-no-pad?

Dave Longley: would that help?

Dave Longley: https://datatracker.ietf.org/doc/html/rfc4648.

Manu Sporny: can you read what dlongley just shared.

Michael Jones: maybe. I’d have to look.

Orie Steele: ref’ing that RFC seems like a good move.

Manu Sporny: I can address all the comments.

Kristina Yasuda: sorry we can’t pick a date.
… we’ll continue to believe there’s good intent here.
… but please address these concerns selfissued.

Sebastian Crane: it seems selfissued’s main concern is anything multibase/multikey.
… it seems our charter includes defining these things.

Orie Steele: +1 to potentially publishing multibase as a w3c document.

Sebastian Crane: so, if selfissued, you take issue with these not being defined at the IETF, then a probably solution is to take these multibase/multikey stuff through the W3C process within this group.

Kristina Yasuda: we can talk about multibase.
… but I do not think it is realistic within the lifetime of the WG.
… in the meantime if selfissued and manu can work through the PR that would help.
… next week is IIW, but we will cancel the special topic call.
… but keep the main call.
… I think the special topic call will be about accessibility.
… so seabass if you could send stuff out about it, that’d be great.

Sebastian Crane: I will be absent for part of the coming weeks.

Ivan Herman: next week, WG is at a EU unfriendly time.
… and I want to be part of the timing discussions.
… so you’re welcome to meet and provide a time…but I may have to disapprove it after I see it.

Kristina Yasuda: yeah, lets discuss offline.
… thx all.
… thx for scribing bigbluehat.