Verifiable Credentials Working Group Telco — Minutes

Date: 2023-08-16

Attendees

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

Regrets:

Guests:

Chair: Kristina Yasuda

Scribe(s): Manu Sporny, Sebastian Crane, Dave Longley

Kristina Yasuda: We have Nick Steele joining us as an IE.

Nicholas Steele: I’m at 1Password, working on WebAuthn, working on new standards, working on FIDO, working on credential import/export on passkeys, interested in VCs as well, interested in helping in any way I can.

Kristina Yasuda: any other re-introductions?

1. PRs.

Kristina Yasuda: You got through PRs and issue triaging yesterday, any updates on PRs from yesterday? Mainly spending time on issue discussion today.
… Any concerns/comments?

Brent Zundel: On the topic of PRs, status updates for different work items, needed to get reviews from TallTed.

Ted Thibodeau Jr.: Sure, I can take a look.

Kristina Yasuda: I did re-review PR 1211 – works for me, thanks.

Gabe Cohen: vc-json-schema is coming along nicely, all but a few pre-CR ones are done… open to others to have others review work and open issues if they see fit.

Manu Sporny: Just a quick heads up, Mike Prorock – there are merge conflicts on StatusList, if you could look at those and fix them we can get that PR merged.

Michael Prorock: I will attempt to get to that in the next 48 hours.

Kristina Yasuda: any updates on BBS?

Greg Bernstein: Yes, it uses an HMAC with key.

Orie Steele: as far as I’m aware, no progress on BBS work item. Last progress was ecdsa-sd updates. There was a need to blind RDF NQuads in documented manner, that has been documented and incorporated into Data Integrity more generally, more specifically ecdsa-sd test suite has that capability, at some point in future we might see BBS adopt that, or we might see BBS not make it into CR.

Kristina Yasuda: thanks, any update on vc-jose-cose PR?

Michael Jones: Merged an editorial PR.

Greg Bernstein: Some of the SD-primitives are also applicable to BBS. Reviewing these now.

Orie Steele: In general, work item needs a bunch of clean up … now that PR 88 is in, in terms of general things, normative changes that need to be made before we go into CR – need to be comfortable w/ mandatory header parameters, main risk for item – statement that says there MUST be header values, media types, multiple plus signs, etc. There might be folks concerned about multiple suffixes, normative statements addressing protected headers need the most amount of attention, probably also some cleanup / differentiation language that we want to make now that we have clear separation on work items on JSON-LD and securing JSON and registered claim names (work item at IETF) – probably some mutual citation should happen there, direct readers to appropriate place, don’t think that’s.

Manu Sporny: blocking CR, but header parameters are blocking CR.

Michael Jones: I appreciate the test suite repo being created, what’s our plan to have there be tests?

Orie Steele: I am about to open a PR with some initial test cases and structure, just got repo today, I was going to throw some strawman suggestion up for folks to look at… don’t know if W3C Process for test suites, interested in knowing if what I’m going to say is run afoul … would like to push commits straight to main, review on call, go over what we think is good enough and gather feedback from the group, if group hates it, we can make adjustments.
… I’d like to push to main in the test suite repos.

Michael Prorock: +1 to push to main.

Michael Jones: yes, +1.

Michael Prorock: I have example representations for some of core tests.

Brent Zundel: Chair hat firmly on – test suites are where folks who are willing to write code end up with a test suite that matches what they like, folks with opinions that don’t write code, while we appreciate what you want, unless you’re willing to write tests, then it’s the do-ers that get to determine what test suite is to a large extent. Fully support generating test suite as they see fit, presenting it to group for feedback.

Kristina Yasuda: concur - orie, you have the go-ahead.
… we have 33 pre-CR issues, with 2 not assigned.

2. Issues.

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

Kristina Yasuda: anyone need help w/ the issues – anyone need guidance from the WG?
… if not, let’s see if we can assign two of the issues.

Brent Zundel: reminder that no one being assigned to an issue essentially means it will not happen.

2.1. Define Controller Documents in the Core Data Model (issue vc-data-model#1205)

See github issue vc-data-model#1205.

Kristina Yasuda: this one is about describing controller documents in core data model.

Manu Sporny: I think it’s a bad idea and we shouldn’t do it. We define controller docs in the data integrity spec and if we want to point to something we can do that.

Orie Steele: I am not a huge fan of having to point to Data Integrity to understand how to verify something that uses a DID. Problem that I see, is that if you are using JWT or SD-JWT and you are issuing from a DID and you want to talk about expectation on issuer key representation and envelopes will be – we will have to refer to Data Integrity from vc-jose-cose spec, currently we point to OID documents, we don’t talk about DIDs yet, there isn’t a way to talk about DIDs and key material and point to DID spec, in VCs, we would have to do that. because of way did spec and vc spec, vc-cose-jose should point to VC spec, not to DID spec… resolution was out of scope… how to use DIDs w/ vc-jose-cose, refer to Data Integrity spec to do that, as long as we want to do that, we can do that… if we want to cite different document for controller format, reference needs to move.

Dave Longley: +1 to its fine and close the issue.

Kristina Yasuda: is it an option to just add a summary in VCDM? and point elsewhere.

Orie Steele: That is not true.

Sebastian Crane: From my udnerstanding of ecosystem, people might need to understand vc-jose-cose and other ones in data integrity… not much of a problem either way or the other.

Orie Steele: Many people probably do not plan to implement both.

Kristina Yasuda: yeah, i would not assume everyone will understand both securing mechanisms..

Gabe Cohen: It goes beyond cleanliness, I don’t want to refer to multiple specifications, pursuing a path of being able to verify DID w/o needing to rely on DI spec would be valuable.

Dmitri Zagidulin: @Orie - for those who don’t plan to implement DI, why not talk about controllers in whatever securing JOSE spec ?

Brent Zundel: valuable enough to volunteer to be assigned?

Orie Steele: As it stands, I plan to refer to data integrity controller documents section from vc-jose-cose… since its MUCH better than referring to DID Core.

Gabe Cohen: if no one else volunteers I can try, but I will need help.

Dmitri Zagidulin: question to Orie - understand not wanting to refer to many different specs, why not say controller document/verification belongs to securing spec, just use that?

Manu Sporny: The problem with copying and pasting between two specs is that they drift over time.

Dmitri Zagidulin: They wouldn’t be exactly the same.

Kristina Yasuda: yeah, I would assume the definition of a controller doc will not have to match btw securing docs.

Orie Steele: DID core DOES NOT define how to get key material.

Orie Steele: making it mostly useless to refer to.

Manu Sporny: This feels like a worse thing. We could just refer to DID core, it does specify the controller document, but not as well as data integrity does. If we copy and paste between both, it will diverge, which will be bad.
… Now we’re talking about divergent definitions of the controller document and that would almost certainly get objections.

Orie Steele: Imo divergent definitions might be better than bad definitions… could see objections either way.

Kristina Yasuda: could we talk about key discovery mechanism? Inclusive of DIDs, but not limited to?

Michael Prorock: +1 Orie.

Orie Steele: I like dmitri’s idea, repeating controller document guidance, I would feel better doing that than citing data integrity… I think it’s ok, as long as definitions are compatible, ok for one document to take more securing mechanism focused approach, stuff specific to JOSE/COSE that Data Integrity is not going to talk about… makes sense to copy content and describe security considerations associated with controller documetns used w/ vc-jose-cose.

Dave Longley: another option would be to reference what’s in data integrity and add some additional requirements as needed vs. just copying and changing.

Michael Prorock: isn’t some divergence expected?

Orie Steele: There would probably be divergence, is the divergence substantial enough to create formal objections? I can see either side leading to problems if it’s not handled properly, duplicating content would be easier path than puttin git in core data model.

Sebastian Crane: I don’t think I understood what Dmitri said… in data model specification, when you are securing VC, you must refer to specification regarding verification, regarding vc-jose-cose, or Data Integrity, while that implies that those specs copy/paste, it does not necessitate copying/pasting.
… If there is a risk of divergent definitions, we can propose another REC-track spec.

Dmitri Zagidulin: right, so, we have two different decisions. 1) whether to summarize or specify key discovery in the core VC DM. yes or no. and 2) If no, if we rely on securing specs for key discovery, whether to copy the text, or pick one spec.

Orie Steele: I doubt we can propose another rec track document… especially since that document would look like DID Core.

Kristina Yasuda: adding another rec-track spec at this time would be difficult (chair hat on).

Sebastian Crane: I thought we were only halfway through charter… we would have another chance at REC-track documents?

Kristina Yasuda: W3C Process wise, yes, we have a year left, but we need the last year to resolve comments, administrative review, timeline wise, unfortunately, no – we can’t add another rec-track document at this time.

Brent Zundel: Everything you said was accurate, W3C Process requires wide review of REC-track documents, wide review takes time, ends up in multiple CR phases, going to PR and REC takes several months to do that… already are straining bounds of possibility on specs we have in flight.

Michael Prorock: +1.

Dave Longley: Another suggestion was vc-jose-cose references what’s in Data Integrity and additional requirements.

Michael Prorock: -1.

Michael Prorock: I will firmly object in every way shape or form for referencing from vc-jose-cose, those two documents need to be 100% separated, not willing to budge on that.

Gabe Cohen: +1 to separation.

Michael Jones: +1 to keeping the securing documents separate.

Orie Steele: +1 to moving the issue.

Kristina Yasuda: We don’t have agreement to add to core data model, don’t agree on divergence is a risk or not, and this is decision of vc-jose-cose authors – can we move issue to vc-jose-cose and PR would be opened… that’s the option I heard the least objections on.
… ok, I’ll move issue to vc-jose-cose.
… going back to issues…

2.2. Allowing expanded `type` values in conforming documents (issue vc-data-model#1206)

See github issue vc-data-model#1206.

Kristina Yasuda: we discussed 3 weeks ago, there didn’t seem to be agreement to add this to VCDM.

Orie Steele: Our current language says document has to be compact, don’t know if you can use URL in compact JSON document, I expect people have done that in v1 of spec, expect them to keep doing that.
… We should expect to see people mix compact type w/ expanded tpes, or just put URLs in there… that can create logical/validation issues… if you process as JSON-LD and RDF and doesn’t expect to not have them, libraries can explode.
… This is in the category of not addressing this particular piece, make it clear to implementers that it’s not ok to do, might see this in the wild, we should providde some guidance.

Orie Steele: A JSON processor has not problem with arrays of strings.

Manu Sporny: The problem isn’t with JSON-LD processing, a JSON-LD processor will be fine. Doing vanilla JSON processing will have to look out for the long and short forms. The reason we made the rule is so that vanilla JSON processors could just use the shortened form.

Orie Steele: JSON Processors don’t understand “compact form”… thats a JSON-LD concept.

Manu Sporny: If the JSON processors put that logic in – that would work just fine. I agree we should put in guidance to say “don’t do that, if there’s a shortened form, use that, not the full URL”.

Sebastian Crane: JSON processors don’t understand anything - semantic meaning is always added by the scheme, like an OWL document in the case of JSON-LD.

Brent Zundel: who is willing to be assigned?

Manu Sporny: As Orie said, there are some ecosystems might expect that. If we didn’t use JSON-LD (only vanilla JSON) people would still need to pay attention to it. So some guidance that says you might experience it in the wild, and the ecosystem you’re operating in might use long URLs when they could have used short ones, but in general, use the short form for everything when you can.

Kristina Yasuda: anyone willing to be assigned?

Sebastian Crane: I just want to say that URIs and IRIs are difficult to work with, JSON-LD is about dealing w/ that, but in general, this is an advantage that when processing pure JSON, you don’t have to parse actual keys themselves… “a” and value, then “x” and value, you don’t have to parse string value – parsing becomes a lot more difficult, if it is feasible, we should enforce short names and that will be a tangible help for those not going full JSON-LD route.

Orie Steele: IMO that guidance would be fine…

Manu Sporny: If I’m going to do a PR for this, it would say that you should use short form URLs, not long ones, but if you use long ones it’s ok, just don’t expect interop.

Sebastian Crane: When we’re talking about using long or short forms, we are talking about official and VC context, not other context.

Orie Steele: I would say we are talking about all contexts.

Manu Sporny: Compact form means every single context that’s applied.

Sebastian Crane: So fragmentation is an issue?

Manu Sporny: No, that’s not what’s being said. For a given document, if you’re using a set of contexts, you are expected to use the short form for everything that’s defined in those contexts.
… The comment you made on fragmentation I didn’t follow, because not every VC will use the same context. A VC for a permanent resident card will use one set of contexts and one for a university degree, a different set of contexts will be used. The guidance will be to use the short form with each respective context used.
… If there’s a short form version of the thing, don’t use the long form. It doesn’t mean you can’t use URLs anywhere, you can of course do that. But when using the specific vocab and context you’re using, use the short form.

Sebastian Crane: When people create contexts for use for anyone issuing and consuming VCs, people should use shortened forms for those and that helps with interop at a second order.
… I’m for that.

Kristina Yasuda: ok, thanks for clarification.
we have 12 minutes, let’s go through before CR that don’t have “ready for PR”.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc+-label%3A%22pr+exists%22+-label%3A%22ready+for+PR%22.

2.3. Protected term errors when supporting v1 and v2 (issue vc-data-model#1150)

See github issue vc-data-model#1150.

Kristina Yasuda: protected term errors when doing v1 and v2, dave has pointed to multiple PRs in his latest comment, what’s plan here?

Dave Longley: I don’t plan to do PR unless it’s done as a final pass before CR over all of the other issues we have – we have a number of things that will need tomake changes to v2 context (other specs, etc) – we need to make pass at context at the end, tagged this item and others to make sure we get everything in there.

Kristina Yasuda: waiting for v2 context to be “final final”.

Dave Longley: Not “final final”, just right before we go to CR.

2.4. Why does the Data Model context file define a DataIntegrityProof RDF class? (issue vc-data-model#1089)

See github issue vc-data-model#1089.

Michael Prorock: +1 brent.

Brent Zundel: I think this issue can be closed.

Manu Sporny: +1 to close.

Dave Longley: +1 to close.

Manu Sporny: +1 to close.

Orie Steele: +1 to close.

Brent Zundel: context has lots of stuff in it.

Orie Steele: we are bundling everything into v2 context now.

Orie Steele: not just data integrity proofs.

2.5. Spec does not contain “name” and “description” terms in the context (issue vc-data-model#1214)

See github issue vc-data-model#1214.

Manu Sporny: We have talked about using name and description in VCs and put it in the context, this is about adding spec text for those things.

Orie Steele: I think the current v2 context plans to use schema.org definitions for these, when you consider entire VC vocabulary, you’d expect to see schema.org term definitions – theoretically, we could have added name registered claim name from jose registry, there would be contention about which registry defines name – wanted to surface that thing… I have been doing so many PRs for registered claim names, I expect that particular URL would never be surfaced and name would be protected, name would throw an error eventually, probably more information than people care about, wanted to put it in context.

Sebastian Crane: From other spec efforts, although you can’t stop people from doing stupid things, if you provide name/description, careful to say that “this shouldn’t be used for” and list cases where it would be more useful to extend it rather than dumping human readable information into those fields.

Orie Steele: He is right… expect people to put HL7 in the description field.

Kristina Yasuda: I’m not sure Orie or Sebastian agreed w/ Manu’s suggestion on what to put in the text.

Michael Jones: The issue points out name and description are in the context and not in the spec.

Manu Sporny: That’s what this issue is about, aligning those two things, making sure that we define them in the spec as well.

Orie Steele: We will define name as forever being https://schema.org/name.
And never being https://www.iana.org/assignments/jwt#name.

Sebastian Crane: Why can’t we delete them entirely?

Dave Longley: re: why not delete them… because they are very commonly used and helpful in the ecosystem.

Kristina Yasuda: again, Manu said one thing… orie mentioned schema.org, do we have agreement on the direction.

Orie Steele: I think we have a path forward, we add sections of text to name/description and we make it reflect what’s in the context today, would expect text on name/description on schema.org – we mean same thing as in context today.

Dave Longley: we could recommend a length for them (something “short”).

Sebastian Crane: Yes, but are they supposed to be displayed, say, in a wallet application? That makes it so much more important than a random human-readable helper for developers.

Dave Longley: seabass: yes, they are expected to be displayed in wallets.
that’s a common use case in the ecosystem now.

Dave Longley: +1 to clear up that entity includes abstract concepts.

Sebastian Crane: thanks for explaining - let’s make sure that’s an explicit suggestion in the specification though - in a previous specification I worked on, the ‘name’ field was used by everyone but never for the same thing!!

Dave Longley: seabass: +1 to being explicit that name is expected to be used, for example, to display information in wallets.

2.6. Revert language change on the definition of Subject (issue vc-data-model#1235)

See github issue vc-data-model#1235.

Joe Andrieu: I think references to entity implied that subject had to be something that physicaly exists, in RDF world, it can be a concept (doesn’t need to “physically exist”) – we should clear up “entity” to include “abstract concepts”.

Orie Steele: +1 to ready for PR.

Manu Sporny: +1 entity includes abstract concepts –.

Ted Thibodeau Jr.: +1.

Joe Andrieu: I think what Ted said makes sense… say entity can be abstract.

Phillip Long: +1.

Benjamin Young: +1.

Dmitri Zagidulin: +1.

3. end of call.

Kristina Yasuda: We’re at time, thanks for joining, see you next week at special topic call… we have two weeks, four more calls until TPAC, making good progress, let’s keep it up.

Brent Zundel: only 10 before-CR issues that aren’t yet ready for PR!