14:37:15 RRSAgent has joined #vcwg 14:37:20 logging to https://www.w3.org/2023/04/19-vcwg-irc 14:37:20 RRSAgent, make logs Public 14:37:21 please title this meeting ("meeting: ..."), ivan 14:37:25 Meeting: Verifiable Credentials Working Group Telco 14:37:25 Date: 2023-04-19 14:37:25 Agenda: https://www.w3.org/events/meetings/3094a419-a55e-4608-aac1-6144804c5201/20230419T110000 14:37:25 chair: brent 14:37:25 ivan has changed the topic to: Meeting Agenda 2023-04-19: https://www.w3.org/events/meetings/3094a419-a55e-4608-aac1-6144804c5201/20230419T110000 14:51:48 brent_ has joined #vcwg 14:57:07 present+ 14:57:51 present+ brent 14:58:42 present+ pauld 14:58:52 kgriffin has joined #vcwg 14:59:52 TallTed has joined #vcwg 14:59:57 hsano has joined #vcwg 15:00:22 hsano_ has joined #vcwg 15:00:26 present+ manu 15:00:41 present+ kgriffin 15:01:45 present+ selfissued 15:01:52 present+ 15:02:07 present+ hsano 15:02:11 present+ 15:02:25 present+ elfors 15:03:05 present+ Przemek 15:03:13 I think he (Lucas) was 3 in that picture, he's all grown up at 5 now :) 15:03:28 selfissued has joined #vcwg 15:03:32 przemek has joined #vcwg 15:03:44 Orie has joined #vcwg 15:03:51 present+ 15:03:55 KevinDeanGS1 has joined #vcwg 15:03:58 present+ 15:04:07 sebastian has joined #vcwg 15:04:12 s/I think he (Lucas) was 3 in that picture, he's all grown up at 5 now :// 15:04:15 present+ davidc 15:04:31 DavidC has joined #vcwg 15:04:36 present+ 15:04:41 scribe+ 15:05:13 brentz: We intend to go through the Agenda in numerical order, sorry for any confusion in the ordering there. 15:05:42 brentz: We have a proposal for StatusList2021 ... and then we are going to do issue assignment triage, PR review, discussions, etc. 15:06:03 present+ 15:06:08 brentz: Anyone joining for the first time or wants to reintroduce? 15:06:23 present+ andres 15:06:33 brentz: Ok, finally, TPAC September 11th... 15:07:06 TPAC 15:07:09 +1 15:07:11 +1 15:07:12 brentz: If it is your current intention to attend TPAC please do +1 there. 15:07:14 +1 15:07:16 +1 15:07:37 ivan: It is in Spain, if you are wondering. 15:07:45 andres has joined #vcwg 15:07:49 brentz: It is in Seville, Spain and it's lovely you should come. 15:08:17 brentz: With that, we can move into our first topic. 15:08:18 Topic: Proposal 15:09:02 PROPOSAL: 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. 15:09:05 brentz: I'm not anticipating any controversy with this proposal, it's standard ready for FPWD. 15:09:08 +1 15:09:11 dlongley: +1 15:09:21 +1 (noting that there has been a request to add "Verifiable Credential" to the title of the spec) 15:09:21 +1 15:09:24 +1 15:09:29 +1 15:09:35 +1 15:09:42 +1 15:09:43 +1 (the request for the change the name to the title came from me) 15:09:43 +1 15:10:24 RESOLVED: 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. 15:10:40 ivan: Short question -- for Manu, when do you intend to renew the text? 15:10:47 manu: I could do it before publication. 15:10:53 ivan: If you could do it today that's even better. 15:10:56 manu: Yup, will do it today. 15:10:58 Topic: Issue Triage 15:11:04 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+no%3Aassignee+ 15:11:30 https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+no%3Aassignee+-label%3A%22pending+close%22+ 15:11:36 present+ shawn 15:11:39 cabernet has joined #vcwg 15:11:52 present+ 15:11:59 brentz: This is the list of all issues with no assignee in order of least recently updated with no pending close. 15:12:08 brentz: I'm hoping we can just zip through these ~6 issues. 15:12:13 subtopic: https://github.com/w3c/vc-data-model/issues/881 15:12:18 brentz: The question is whether there is someone who is willing to be assigned. 15:12:33 brentz: Is there anyone who would like to be assigned? 15:12:42 brentz: Or would anyone like to propose to close it? 15:13:19 Orie: 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. 15:13:43 Orie: 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. 15:14:06 Orie: 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. 15:14:35 Orie: 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. 15:14:45 Orie: I think we should make the case better in the core spec, I think it's non-normative today. 15:15:21 Orie: 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. 15:15:52 Correction, proof is normative in the core spec, but there are no normative "types" for it today. 15:15:54 brentz: Who would be willing to be assigned to the issue to help move it forward? 15:16:07 brentz: Not hearing any volunteers -- issues without someone assigned to them are much less likely to see progress. 15:16:19 subtopic: https://github.com/w3c/vc-data-model/issues/915 15:16:39 brentz: This one is marked ready for PR. I think the last time we talked about it. A bit of a brief conversation. 15:16:52 brentz: Also raised by Orie ... is someone willing to be assigned? 15:17:48 manu: I feel like this is important -- I can't remember if Data Integrity addresses this partially. 15:18:10 manu: 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. 15:18:18 Anyone who likes DIDs could pick this up 15:18:19 and be a hero 15:18:27 subtopic: https://github.com/w3c/vc-data-model/issues/973 15:19:15 q+ 15:19:36 ack Orie 15:19:54 Orie: This is also related to those pictures, the graphical representations of what a credential looks like and whether a proof is related to it. 15:20:17 Orie: 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. 15:20:57 q+ to wonder out loud about a solution 15:21:03 ack manu 15:21:03 manu, you wanted to wonder out loud about a solution 15:21:08 Orie: 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. 15:21:31 +1 to graph visualization 15:21:39 manu: 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. 15:21:42 I can provide some code for that if there is desire 15:21:53 q+ 15:22:25 ack ivan 15:22:30 manu: 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. 15:23:16 ivan: 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. 15:23:28 ivan: That additionally visual glue that is necessary is missing, usually and that's of course a problem. 15:23:44 ivan: That means that I'm afraid that they will have to be made by hand using Google Draw or whatever. 15:24:12 ivan: 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. 15:25:06 ivan: 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. 15:25:22 +1 to Ivan's suggested path forward. 15:25:23 brentz: So raising an issue to add visualizations as a concrete way to solve this and close it. 15:25:47 brentz: Can anyone open the new issue and link it to this one? 15:25:49 Orie: I can do that. 15:25:53 brentz: I'm going to mark this one pending close. 15:25:56 brentz: Thank you. 15:26:15 q+ on PR summaries. 15:26:19 brentz: 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. 15:26:26 brentz: So, moving onto work item status and PRs. 15:26:30 Topic: Work Item status updates/PRs 15:26:37 ack manu 15:26:37 manu, you wanted to comment on PR summaries. 15:26:47 manu: I count 27 open PRs right now across all of our specs. 15:26:58 manu: Things are moving forward, but we have a number of them kind of stuck that we may need special topic calls for. 15:26:59 https://github.com/w3c/vc-data-model/pulls 15:27:01 andres has joined #vcwg 15:27:26 manu: 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. 15:27:48 manu: 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. 15:27:58 Reserved properties PR https://github.com/w3c/vc-data-model/pull/1082 15:28:16 manu: 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. 15:28:44 manu: 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. 15:29:02 manu: Those are the main categories of discussion right there please jump in and comment on what you feel is important 15:29:15 brentz: Is there a PR you'd like to look at more closely today? 15:29:20 Will has joined #vcwg 15:29:23 +1 to discussing that PR 15:29:26 present+ 15:29:29 manu: The table of reserved properties would unblock like seven PRs, I'd pick that one. 15:29:37 brentz: Would you like to jump into that? 15:29:54 subtopic: https://github.com/w3c/vc-specs-dir/pull/14 15:29:58 manu: Sure, the others are moving along, aren't super important. There's one -- let me call that out. There's a media types extension. 15:30:43 manu: 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. 15:30:55 manu: If you care about different media types that can be translated into the base media type you should look at that. 15:30:57 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 15:31:00 manu: That's the only one that really jumps out at me. 15:31:16 manu: 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. 15:31:27 manu: It's on its way but people should take a look at it. 15:31:44 subtopic: https://github.com/w3c/vc-data-model/pull/1082 15:31:49 brentz: 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. 15:32:00 q+ to provide commentary on expected changes. 15:32:33 brentz: 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. 15:32:36 ack manu 15:32:37 manu, you wanted to provide commentary on expected changes. 15:32:37 brentz: I think we're in a pretty good state. 15:32:40 manu: Agree with that. 15:33:21 manu: 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. 15:33:26 manu: So that section should be normative. 15:33:40 manu: There is some language that Brent proposed that should go in there with normative statements. That will go in there. 15:33:48 q+ 15:34:00 q+ 15:34:14 manu: 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. 15:34:25 manu: Orie mentioned context and vocab values -- and I think we should handle that in a separate PR. 15:34:46 manu: 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. 15:35:01 ack Orie 15:35:02 manu: 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? 15:35:06 present+ will 15:35:07 Orie: That matches my understanding. 15:35:10 brentz: That matches my understanding. 15:35:41 Orie: 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. 15:35:57 yes "+1 to we are going to make a table and we're going to figure it out" 15:36:08 Orie: Specific URLs same thing. The types piece ... if you register a type for an extension property then you must provide a spec. 15:36:13 Orie: Specifics will snag the PR. 15:36:25 yes "+1 to saying you have to specify a type, but not specify specific types" 15:36:29 Orie: I think it's worth moving normative processing should be moved to another PR. 15:36:39 ack DavidC 15:36:48 Orie: 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. 15:36:48 yes "+1 to not pulling in relationships to @context and Vocabulary URLs, etc." 15:36:59 q+ 15:37:12 q+ to offer "extension points w/ types" for now... 15:37:18 DavidC: 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. 15:37:38 DavidC: 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. 15:37:56 this is where increased knowledge of @type and @container... would be helpful to the group... and hence the need to *understand* the context. 15:38:10 DavidC: 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. 15:38:38 q+ to say that the things we are concerned with reserving are all extension points 15:38:42 DavidC: 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". 15:38:56 ack manu 15:38:56 manu, you wanted to offer "extension points w/ types" for now... 15:38:58 DavidC: We may have to tweak them in a minor way but that's really it, those were my comments. 15:39:22 manu: 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. 15:40:03 manu: 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. 15:40:14 manu: Then we have to have a discussion around whether we want the table to include those things. 15:40:16 q? 15:40:46 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. 15:40:52 manu: 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. 15:41:16 manu: 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. 15:41:21 q+ 15:41:28 ack brentz 15:41:28 brentz, you wanted to say that the things we are concerned with reserving are all extension points 15:41:33 manu: 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. 15:42:08 brentz: 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. 15:42:13 +1 brent 15:42:17 +1 brent 15:42:48 brentz: 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. 15:42:48 brentz: Because of the nature of the things we're reserving is that they are unspecified which necessarily means they might change. 15:42:54 ack ivan 15:42:56 brentz: Note that after Ivan we will move on. 15:43:15 ivan: 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. 15:43:45 ivan: 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. 15:44:13 ivan: 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. 15:44:33 ivan: We should clarify what extension points are later in a separate PR. 15:45:01 brentz: I believe Orie has some things that he might want discussed here so I wanted to give you time here. 15:45:05 brentz: To go over PRs. 15:45:19 subtopic: BBS 15:45:28 https://github.com/w3c/vc-di-bbs 15:46:13 Orie: 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. 15:46:29 scribe+ 15:46:56 Orie: For background, we had for selective disclosure mechanism for dealing with RDF ordering because the order couldn't be known based on RDF canonicalization. 15:47:11 Orie: This BBS item will use, we assume, using the CFRG representation for signatures. 15:47:30 Orie: I know another company is making an implementation. 15:47:51 Gen is also planning to update our BBS data integrity implementation based on the CFRG work 15:47:53 Orie: Manu had also added an item to align the BBS spec to the latest Data Integrity spec. 15:48:09 Orie: The cryptosuite property is bbs-2023 or something like that and uses the new Data Integrity properties. 15:48:29 Orie: As I went to update my implementation to use `cryptosuite`, I realized I had to use multibase and I don't like that. 15:48:52 Orie: 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. 15:49:00 Orie: The current rules in vc-di-bbs state ... 15:49:06 https://w3c.github.io/vc-di-bbs/#add-proof-bbs-2023 15:49:35 q+ to clarify what that language is intending to do. 15:49:52 Orie: 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. 15:49:52 Orie: I think that's fine. 15:50:13 Orie: 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. 15:50:25 Orie: That may be a design goal but we should discuss it. 15:50:56 Orie: 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. 15:51:31 Orie: 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. 15:51:38 ack manu 15:51:38 manu, you wanted to clarify what that language is intending to do. 15:52:18 manu: 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. 15:52:33 manu: The multibase spec will happen at IETF as a mini-WG or the informative spec track. 15:52:57 manu: We will not build that dependency in but we can happily reference it when it's ready. 15:53:04 manu: So that should be a non-issue. 15:53:08 manu: DB will also be doing an implementation. 15:53:18 manu: So that should ensure a minimum number of implementations. 15:53:34 ahh, ok... `u` + 15:53:43 kgriffin_ has joined #vcwg 15:53:43 manu: 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'. 15:53:47 manu: That's all the spec has to say. 15:54:04 manu: 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. 15:54:13 manu: That's not settled what that thing will look like -- we're working on that too. 15:54:29 manu: It's not settled for mandatory disclosure field, it's not settled how to encode the nonce, and so on. 15:54:33 manu: All of that is up in the air. 15:55:04 manu: 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. 15:55:09 manu: Orie, does that address your concerns? 15:55:27 Orie: 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. 15:55:40 q? 15:55:48 Orie: 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. 15:56:06 Orie: I'd like to hear about others who would like to also implement and hear what they think about these changes to the spec. 15:56:14 q+ 15:56:18 q+ to note test suite is probably premature :( -- because there are unanswered questions. 15:56:20 Orie: My original point was to start building a test suite. And I was thinking about how multibase would have to be in the tests. 15:56:25 ack ivan 15:56:46 its never too early to start tests, because you don't even know how the implementation will work... without tests :) 15:57:00 ivan: 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? 15:57:12 ack manu 15:57:12 manu, you wanted to note test suite is probably premature :( -- because there are unanswered questions. 15:57:14 ivan: I'm asking a disagreeable question here but am beginning to worry as a staff contact? 15:57:22 ( I mean local implementation tests, not "TR" tests ) 15:57:43 part of why I am trying to push this along, is that bbs is very obviously at risk 15:57:57 manu: 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. 15:58:07 gkellogg has joined #vcwg 15:58:08 manu: Just need to put the primitives together and sync up on it. 15:58:45 manu: 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. 15:59:01 brentz: Ok, thanks to our scribe today and there are a few other issues that need assignees. Thanks and a pleasure! 15:59:19 rrsagent, draft minutes 15:59:20 I have made the request to generate https://www.w3.org/2023/04/19-vcwg-minutes.html ivan 16:00:07 zakim, end meeting 16:00:07 As of this point the attendees have been ivan, brent, pauld, manu, kgriffin, selfissued, hsano, dlongley, elfors, Przemek, Orie, KevinDeanGS, davidc, andres, shawn, cabernet, Will 16:00:09 RRSAgent, please draft minutes 16:00:10 I have made the request to generate https://www.w3.org/2023/04/19-vcwg-minutes.html Zakim 16:00:16 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:00:16 rrsagent, bye 16:00:16 I see no action items 16:00:16 Zakim has left #vcwg