Verifiable Credentials Working Group Telco — Minutes

Date: 2023-04-19

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Brent Zundel, Paul Dietrich, Manu Sporny, Kevin Griffin, Michael Jones, Hiroyuki Sano, Dave Longley, Sebastian Elfors, Przemek Praszczalek, Orie Steele, Kevin Dean, David Chadwick, Andres Uribe, Shawn Butterfield, Chris Abernethy, Will Abramson

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Dave Longley, Manu Sporny

Content:

Brent Zundel: We intend to go through the Agenda in numerical order, sorry for any confusion in the ordering there.
… We have a proposal for StatusList2021 … and then we are going to do issue assignment triage, PR review, discussions, etc.
… Anyone joining for the first time or wants to reintroduce?.
… Ok, finally, TPAC September 11th.

Brent Zundel: TPAC.

Brent Zundel: If it is your current intention to attend TPAC please do +1 there.

Brent Zundel: +1.

Ivan Herman: +1.

Manu Sporny: +1.

Michael Jones: +1.

Ivan Herman: It is in Spain, if you are wondering.

Brent Zundel: It is in Seville, Spain and it’s lovely you should come.
… With that, we can move into our first topic.

1. Proposal for a FPWD.

Proposed resolution: Publish the Status List 2021 specification (https://w3c.github.io/vc-status-list-2021/FPWD/2023-04-27/) as a First Public Working Draft with a short name of vc-status-list with a target publication date of April 27th 2023.. (Brent Zundel)

Brent Zundel: I’m not anticipating any controversy with this proposal, it’s standard ready for FPWD.

Orie Steele: +1.

Dave Longley: +1.

Manu Sporny: +1 (noting that there has been a request to add “Verifiable Credential” to the title of the spec).

Brent Zundel: +1.

Andres Uribe: +1.

Kevin Griffin: +1.

Michael Jones: +1.

David Chadwick: +1.

Ivan Herman: +1 (the request for the change the name to the title came from me).

Ted Thibodeau Jr.: +1.

Resolution #1: Publish the Status List 2021 specification (https://w3c.github.io/vc-status-list-2021/FPWD/2023-04-27/) as a First Public Working Draft with a short name of vc-status-list with a target publication date of April 27th 2023..

Ivan Herman: Short question – for Manu, when do you intend to renew the text?.

Manu Sporny: I could do it before publication.

Ivan Herman: If you could do it today that’s even better.

Manu Sporny: Yup, will do it today.

2. Issue Triage.

Brent Zundel: See https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+no%3Aassignee+-label%3A%22pending+close%22+.

Brent Zundel: This is the list of all issues with no assignee in order of least recently updated with no pending close.
… I’m hoping we can just zip through these ~6 issues.

2.1. proof in @context and the use of @container (issue vc-data-model#881)

See github issue vc-data-model#881.

Brent Zundel: The question is whether there is someone who is willing to be assigned.
… Is there anyone who would like to be assigned?.
… Or would anyone like to propose to close it?.

Orie Steele: Some background on what it would take to close it. There’s an assumption around proof is related to the container it’s applied to. It’s use for proof sets and proof chains in Data Integrity.
… We have visuals in our spec that I think people really like that show what a proof is and how a proof goes on a VC / presentation.
… Those pictures are for after applying the context. I think it would be helpful to add some details around how the process works with the graph being a separate named graph and how that relates to the pictures.
… I think also that the proof term is not specific to Data Integrity proof, it’s an extension point and we have a single implementation so far with Data Integrity Proof.
… I think we should make the case better in the core spec, I think it’s non-normative today.
… I think that’s also not super great. All of these things are all tied together. These things are all tied together, we have these visuals that are great that people like but we need to understand what the context will do to make those pictures.

Orie Steele: Correction, proof is normative in the core spec, but there are no normative “types” for it today..

Brent Zundel: Who would be willing to be assigned to the issue to help move it forward?.
… Not hearing any volunteers – issues without someone assigned to them are much less likely to see progress.

2.2. Address controller ambiguity (issue vc-data-model#915)

See github issue vc-data-model#915.

Brent Zundel: This one is marked ready for PR. I think the last time we talked about it. A bit of a brief conversation.
… Also raised by Orie … is someone willing to be assigned?.

Manu Sporny: I feel like this is important – I can’t remember if Data Integrity addresses this partially.
… I’m not volunteering but will definitely take a look at it. If it’s marked ready for PR, I imagine one of the editors will pick it up.

Orie Steele: Anyone who likes DIDs could pick this up.

Orie Steele: and be a hero.

2.3. more clarity around the id field in the VC data model (issue vc-data-model#973)

See github issue vc-data-model#973.

Orie Steele: This is also related to those pictures, the graphical representations of what a credential looks like and whether a proof is related to it.
… I think this is another case where pictures could help a lot. It means something to have a credential that has an ID – and it means a lot when you’re joining a graph with other graphs which is a thing you do when you process the core data model.
… When you don’t give it an ID, you make it basically impossible to do a join on that property. That makes visualizing what you’re trying to do difficult and getting an identifier for that kind of thing in an application specific way – all of that difficult. This all impacts app developers, data analysis, a number of things, it’s important.

Orie Steele: +1 to graph visualization.

Manu Sporny: Thinking about what Orie said in the other issue and here. We have these tabs in the different types of securing mechanisms – if we added another tab for graphical visualization I imagine that might address some of the concerns you’re raising.

Orie Steele: I can provide some code for that if there is desire.

Manu Sporny: The fall back to that would be to hand create some examples and put them in the appendix. For visualizing the graphs and mental models, etc. I’m struggling to understand what we can concretely do to address the issues to just put into the minutes and given enough spare time people can work on creating those things. They will require a decent bit of time to get into a form that communicates what we want.

Ivan Herman: I must admit that whenever I work with RDF I am thinking about graphs and visuals myself, very much a +1 to what Manu says. The little problem that relates to the previous issue is that the tools that are around to create more proper visualization of these RDF graphs, to the best of my knowledge, are pretty poor. They certainly cannot handle data sets but only graphs.
… That additionally visual glue that is necessary is missing, usually and that’s of course a problem.
… That means that I’m afraid that they will have to be made by hand using Google Draw or whatever.
… It’s a small red flag in the direction of what Manu is saying – maybe not systematically but maybe for some of the bigger examples doing it.
… One other comment – this issue went in a lot of different directions, we might want to close it because it’s a conversation anyway, but close with the additional agreement that we will do something with visualization or something.

Manu Sporny: +1 to Ivan’s suggested path forward..

Brent Zundel: So raising an issue to add visualizations as a concrete way to solve this and close it.
… Can anyone open the new issue and link it to this one?.

Orie Steele: I can do that.

Brent Zundel: I’m going to mark this one pending close.
… Thank you.
… I’m going to resist the temptation to keep talking about issues even though I really want to be I really want to because we’re past the time that was allotted for that.
… So, moving onto work item status and PRs.

3. Work Item status updates/PRs.

Manu Sporny: I count 27 open PRs right now across all of our specs.
… Things are moving forward, but we have a number of them kind of stuck that we may need special topic calls for.

Manu Sporny: See https://github.com/w3c/vc-data-model/pulls.

Manu Sporny: In general, areas … we need people to come in and comment on this PRs mostly in the VC data model. General classes of commentary that would help right now is around the table of reserved properties in the specification.
… We had a good discussion about that yesterday in a special topic call, not all resolved there but progress. We will make updates to that PR to see if we can get it merged.

Brent Zundel: Reserved properties PR: https://github.com/w3c/vc-data-model/pull/1082.

Manu Sporny: A group of discussions happening around the examples in the specifications. What should we do about it – should we have an example context or not have it, should we depend on the base vocabulary, should we use real world examples. We could use input on that.
… We are starting to raise PRs to remove sections from the spec that have had very little to no implementation after years of being the specification. This was a general request by some WG members to remove those and migrate those to the implementer guide. There’s discussion happening there.
… Those are the main categories of discussion right there please jump in and comment on what you feel is important.

Brent Zundel: Is there a PR you’d like to look at more closely today?.

Orie Steele: +1 to discussing that PR.

Manu Sporny: The table of reserved properties would unblock like seven PRs, I’d pick that one.

Brent Zundel: Would you like to jump into that?.

3.1. Add “Media Type Extensions” category. (pr vc-specs-dir#14)

See github pull request vc-specs-dir#14.

Manu Sporny: Sure, the others are moving along, aren’t super important. There’s one – let me call that out. There’s a media types extension.
… The VC specs dir has this media types category based on the resolution from the F2F and there’s discussion on this PR and issues linked to it. There’s discussion on the transformation rules, what they should be, where they are specified, how are they testable, should we use JSON schema, etc. lots of discussion happening there.
… If you care about different media types that can be translated into the base media type you should look at that.

Orie Steele: I think it would be nice to specify normative guidance all registrations in the vc specs dir, in the core data model TR, and that guidance would be relevant to the reserved property table and the media types debate.

Manu Sporny: That’s the only one that really jumps out at me.
… Then the thing that mentions me – the VC-JWT spec and taking a look at it before it goes out to FPWD in a non-blocking way.
… It’s on its way but people should take a look at it.

3.2. Add table of reserved properties (pr vc-data-model#1082)

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

Brent Zundel: I’ll time box it and see how it’s going at 5 minutes and stop it at 10 so we have time for the other work items.
… We had a good conversation about this yesterday and the impression I got is that there were changes suggested and if a number of those get committed to the PR then the resulting text would be acceptable, I believe, to the three people who have formally requested changes.
… I think we’re in a pretty good state.

Manu Sporny: Agree with that.
… I was going to try and highlight the specific changes to try to apply that will hopefully result in the PR going in. I think Brent want a table of reserved “something or others” in the document. So that section should exist. I believe the changes that a number of people want … are we should tell people what they should expect and implementers need to do something with what’s in there.
… So that section should be normative.
… There is some language that Brent proposed that should go in there with normative statements. That will go in there.
… I think David Chadwick said we should have to say whether “type” is expected or not – make it mandatory – I think that’s a safe thing to say. You also wanted to say something else I’d like to handle in another PR.
… Orie mentioned context and vocab values – and I think we should handle that in a separate PR.
… Mike Prorock expected a table with values and with my editor hat off I agree but I don’t think people were ready for that in this PR yet.
… I think that’s the delta to be made to this PR to merge it in – the question to the group is if those changes were made would anyone object?.

Orie Steele: That matches my understanding.

Brent Zundel: That matches my understanding.

Orie Steele: There are a bunch of things you could try and include in your revised PR that might snag it again. The current terms in the core data model or current terms in the core context – if there isn’t consensus to how to handle those you shouldn’t put those in your PR.

Manu Sporny: yes “+1 to we are going to make a table and we’re going to figure it out”.

Orie Steele: Specific URLs same thing. The types piece … if you register a type for an extension property then you must provide a spec.
… Specifics will snag the PR.

Manu Sporny: yes “+1 to saying you have to specify a type, but not specify specific types”.

Orie Steele: I think it’s worth moving normative processing should be moved to another PR.
… If you’re careful to revise the text and careful not to pull things in related to those items I think it will sail through, fingers crossed.

Manu Sporny: yes “+1 to not pulling in relationships to @context and Vocabulary URLs, etc.”.

David Chadwick: I wanted to bring clarity – we want to talk about the property names and types and we need both. All our extension points have a type – and if you have a subtype of the extension point.
… I know Ivan came back and said he didn’t know what the extension point was and people need some clarity perhaps on simple properties and extension point types.

Orie Steele: this is where increased knowledge of @type and @container… would be helpful to the group… and hence the need to understand the context..

David Chadwick: My understanding is that an extension point is like “termsOfUse” or whatever and then there’s a type for the value that is registered with that and you need a subtype for it.
… I dont’ think we’re going to change those – we may tweak those, we aren’t going to change for example an “evidence” might contain a “revocation list” or the status extension point will contain “terms of use”.
… We may have to tweak them in a minor way but that’s really it, those were my comments.

Manu Sporny: I broadly agree with what David said – I think we’re going to have a table and I don’t think anything we put in there will change in a drastic way.
… Going back to David’s initial question, when we say extension point … this PR is just going to say the extension point is going to have a type. That puts things that don’t have a type in limbo. In the RDF world those are just literal values. If we wanted to specify something that’s always a text string we won’t be able to do that with this next PR.
… Then we have to have a discussion around whether we want the table to include those things.

Orie Steele: I note the utility of what Manu said regarding, in RDF we call these a “literal value”… and our core data model in JSON-LD, which compels implementers to understand this..

Manu Sporny: Ivan, tell me if I’m wrong here, but I think you were saying this is an RDF property that can point to anything, a literal value like a text string, or another object out there – if we don’t give it a very specific range of values it can be. That’s the default.
… With the “issuee” thing, I think… you’re concerned … I would argue with that, that can be something that points to something with a “type”. We should have that discussion in an issue in a different PR.
… I think we should just say in this PR that these extension points have types associated with them and define that in a future PR.

Brent Zundel: The things we are concerned with reserving, to my understanding, and one of the reasons for this table is so that we have a place to put extension points. Because those are the things that are sort of normatively there and yet we anticipate that will get us into trouble in v2.0 of the spec.

Orie Steele: +1 brent.

Manu Sporny: +1 brent.

Brent Zundel: We want to include things that don’t have a way of normatively specifying what they are … but we reserve them is the purpose of this.
… Because of the nature of the things we’re reserving is that they are unspecified which necessarily means they might change.

Ivan Herman: I’m still looking for something that I understand, my mind seems to be narrow minded. I think in terms of RDF here. Which has classes and properties.
… My understanding is that we are here defining placeholders for classes and properties that are there and we leave them open and any one of those can play a role as an “extension point” if I take it as an English term.
… I don’t know how that term “extension point” can be explained in RDF because from my perspective at the end of the day this has to be reflected in a vocabulary. We don’t have to do that now, we can do that later.
… We should clarify what extension points are later in a separate PR.

Brent Zundel: I believe Orie has some things that he might want discussed here so I wanted to give you time here.
… To go over PRs.

3.3. BBS.

Orie Steele: See https://github.com/w3c/vc-di-bbs.

Orie Steele: For context, we have adopted this vc-di-bbs work item. I have this problem from the old version regarding the ordering of RDF N-Quads.
… For background, we had for selective disclosure mechanism for dealing with RDF ordering because the order couldn’t be known based on RDF canonicalization.
… This BBS item will use, we assume, using the CFRG representation for signatures.
… I know another company is making an implementation.

Brent Zundel: Gen is also planning to update our BBS data integrity implementation based on the CFRG work.

Orie Steele: Manu had also added an item to align the BBS spec to the latest Data Integrity spec.
… The cryptosuite property is bbs-2023 or something like that and uses the new Data Integrity properties.
… As I went to update my implementation to use cryptosuite, I realized I had to use multibase and I don’t like that.
… If it’s possible to not do that, I’d like to avoid it – and the current spec requires me to do that. The spec requires it.
… The current rules in vc-di-bbs states (see https://w3c.github.io/vc-di-bbs/#add-proof-bbs-2023)).
… They state somewhere in here that you need to add a multibase base58btc-encoded proof value. That means you need to know and understand the multibase spec to implement this proof type. I think as a general comment for Data Integrity proof spec says you must understand multibase encodings and you must use those.
… I think that’s fine.
… If that’s truly the statement we’d have to implement that here in BBS but as an implementer I don’t think that makes this proof suite great, it just makes it look like other proof suites.
… That may be a design goal but we should discuss it.
… We will encounter these things and if it looks like you’re going to have to add a dependency for the encoding we should talk about that. It’s a potential attack vector and a dependency for other things. It implies that encoding mechanism is stable and reliable.
… I don’t know how we will refer to that, the process is starting at IETF, and there are encoding issues around that. Before I can finish an implementation of this first draft I need to know more.

Manu Sporny: Just to kind of respond to some of that, Orie. The intention in the Data Integrity spec is not to say that every single cryptosuite must use base58btc. The cryptosuites do need to decide how to encode the proof value using some base but they must encode as multibase.
… The multibase spec will happen at IETF as a mini-WG or the informative spec track.
… We will not build that dependency in but we can happily reference it when it’s ready.
… So that should be a non-issue.
… DB will also be doing an implementation.
… So that should ensure a minimum number of implementations.
… Our expectation is that BBS will use base64url to encode the proof value and all that needs to happen for that reality – it just needs to start with the lower case ‘u’.

Orie Steele: ahh, ok… u +.

Manu Sporny: That’s all the spec has to say.
… If it doesn’t start with the letter ‘u’, it’s an invalid proof value. And then the rest of it is whatever the BBS serialization of the signature is.
… That’s not settled what that thing will look like – we’re working on that too.
… It’s not settled for mandatory disclosure field, it’s not settled how to encode the nonce, and so on.
… All of that is up in the air.
… Orie, to your point, I think there’s a clear answer: “No, there is one thing, it starts with ‘u’ and that’s it, you throw an error if it doesn’t start with that.” No downref multiformats/multibase at this time.
… Orie, does that address your concerns?.

Orie Steele: Yes, in part. I’m glad to hear what you said, I think we’ve got a lot of work to do on the spec.
… Hearing what you’ve said and hearing that you plan to implement, I think we can start to craft revisions to the spec that are implementable under the consensus of those who want to implement.
… I’d like to hear about others who would like to also implement and hear what they think about these changes to the spec.
… My original point was to start building a test suite. And I was thinking about how multibase would have to be in the tests.

Orie Steele: its never too early to start tests, because you don’t even know how the implementation will work… without tests :).

Orie Steele: ( I mean local implementation tests, not “TR” tests ).

Ivan Herman: Total outsider – what I hear at this point raises red flags in my mind. I’m looking at the calendar and the way the WG will evolve. Are we really sure that we can deliver a recommendation in time if the implementations are still so unclear on what should be in the spec?.
… I’m asking a disagreeable question here but am beginning to worry as a staff contact….

Orie Steele: part of why I am trying to push this along, is that bbs is very obviously at risk.

Manu Sporny: BBS is at-risk. We’re trying as hard as we can, it’s not one of the four core or whatever that number was to get out, it may not make it, we’ll work as hard as we can but no guarantee we’ll make it. There’s a clear technical path, there’s nothing scary that still needs to be solved, no deep computer science issue or anything.
… Just need to put the primitives together and sync up on it.
… There are no problems as far as I can see, it’s doable, but there are decisions to be made that haven’t been made yet that will prevent a finalized test suite – that we all need to agree on so we can implement.

Brent Zundel: Ok, thanks to our scribe today and there are a few other issues that need assignees. Thanks and a pleasure!.

4. Resolutions