18:57:19 <RRSAgent> RRSAgent has joined #vcwg
18:57:23 <RRSAgent> logging to https://www.w3.org/2023/04/26-vcwg-irc
18:58:36 <kevingriffin> kevingriffin has joined #vcwg
18:58:41 <Phil_ASU> Phil_ASU has joined #vcwg
18:58:53 <Phil_ASU> Present+
18:59:25 <brent> brent has changed the topic to: Meeting Agenda 2023-04-26: https://www.w3.org/events/meetings/c5abcc63-337b-4ebb-97af-7cc2fb63de11/20230426T150000
18:59:31 <brent> zakim, start the meeting
18:59:31 <Zakim> RRSAgent, make logs Public
18:59:33 <Zakim> please title this meeting ("meeting: ..."), brent
18:59:34 <stenr> present+
18:59:36 <shigeya> present+
18:59:41 <brent> meeting: VCWG Teleconference
18:59:49 <brent> chair: Kristina Yasuda
19:00:13 <brent> present+
19:01:23 <kristina> kristina has joined #vcwg
19:01:27 <kristina> present+
19:01:32 <DavidC> DavidC has joined #vcwg
19:01:42 <DavidC> present+
19:03:06 <decentralgabe> decentralgabe has joined #vcwg
19:03:06 <decentralgabe> present+
19:03:35 <dlongley> present+
19:03:51 <JoeAndrieu> JoeAndrieu has joined #vcwg
19:05:06 <cabernet> cabernet has joined #vcwg
19:05:08 <manu> present+
19:05:11 <kevingriffin> present+
19:05:12 <cabernet> present+
19:06:04 <dwaite> dwaite has joined #vcwg
19:06:13 <dwaite> present+
19:07:28 <cabernet> kristina: bolo for new zoom url email
19:08:02 <cabernet> kristina: agenda is intros, proposal, then prs
19:08:04 <kristina> q?
19:08:37 <dlehn> present+
19:08:41 <cabernet> topic: proposals
19:08:55 <kristina> q?
19:09:02 <manu> q+
19:09:09 <kristina> ack manu
19:09:27 <TallTed> s/bolo/be on the lookout/
19:09:28 <Orie> Orie has joined #vcwg
19:09:34 <cabernet> manu: we need to generate proposals for test suites, not necessarily now, but thoughts on when right time?
19:09:47 <cabernet> ... do chairs have expectations regarding time frame for that?
19:09:51 <Orie> I'd love a repo for managing vc-jwt test suite
19:10:04 <manu> Same for the data integrity ones...
19:10:16 <cabernet> kristina: perhaps next weeks vcwg or a special topic call in a few weeks?
19:10:26 <cabernet> brent: agree, either way works
19:10:34 <cabernet> manu: I'm travelling for the next two weeks
19:10:46 <cabernet> kristina: may 9th special topic call focus on test suites
19:11:11 <cabernet> manu: to clarify, I'm traveling and will be available starting the 15th
19:11:46 <cabernet> kristina: 16th of may meeting for test suites
19:12:02 <manu> q+
19:12:06 <cabernet> topic: work item status updates
19:12:39 <kristina> ack manu
19:13:15 <cabernet> manu: 18 open prs on vc-data-model, many stuck while we determine what to do about reserved properties table (#1097)
19:13:33 <cabernet> ... we had special topic call regarding some of these PRs yesterday, please review call notes
19:13:45 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1087
19:14:06 <brent> q+
19:14:40 <TallTed> q+
19:14:42 <cabernet> manu: initial PR was to remove section entirely, after pushback new suggestion is to leave title with link to specification
19:14:45 <kristina> ack brent
19:14:59 <Orie> +1 Brent
19:15:02 <manu> q+ I will do that.
19:15:04 <kristina> ack TallTed
19:15:06 <cabernet> brent: we can remove as long as changelog reflects
19:15:10 <manu> q+ to say I will do that in the PR.
19:15:33 <kristina> ack manu
19:15:33 <Zakim> manu, you wanted to say I will do that in the PR.
19:15:34 <cabernet> TallTed: concerned that we are removing for lack of implementation, but there should have been independent implementations
19:15:38 <cabernet> manu: that was all on-normative
19:15:57 <cabernet> manu: will change PR to remove section and put that in the changelog - will merge if no objections
19:16:04 <dlongley> s/on-normative/non-normative/
19:16:20 <cabernet> (no objections were  voiced)
19:17:05 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1097
19:17:07 <cabernet> manu: some new PRs were added recently, suggest we deep dive on #1097
19:17:08 <brent> q?
19:17:38 <cabernet> brent: agree we should, 5-10 minutes (ish), as there are other PRs and work items to look at - this would be time well spent
19:18:17 <cabernet> manu: #1100 is potentially important for the group, but I have not had time to review yet
19:18:26 <kristina> subtopic: https://github.com/w3c/vc-data-model/pull/1097
19:18:51 <cabernet> manu: bg regarding having merged reserved properties table.
19:19:08 <cabernet> ... #1097 is language from Mike Prorock regarding what this table should contain.
19:19:37 <cabernet> ... There are several ways to decide what this table means
19:20:11 <cabernet> ... 1. we need a mechanism for extension point definitions
19:20:28 <cabernet> ... what happens to existing sections in specs, e.g., 'Evidence', that is also now in this table as a reserved property?
19:20:48 <cabernet> ... one proposal is that anything in the table is removed from the spec UNTIL it is demonstrated to the WG that there are two independent
19:21:02 <cabernet> ... implementations for a property at which time it would go back in the spec.
19:21:09 <Orie> q+ to comment on existing terms, vs new ones and IRIs
19:21:19 <cabernet> ... 3. reserving json terms here, not vocab, what is happening here?
19:22:06 <cabernet> ... one suggestion is that wer are putting a term in the table and also urls for the vocab terms in here.
19:22:24 <kristina> q?
19:22:28 <cabernet> ... e.g., evidence has an entry in the vocab (long url for credential namespace hashed evidence). we would define both here to specify it is reserved
19:22:36 <cabernet> ... it would show up in the vocab as reserved as well.
19:22:42 <kristina> ack Orie
19:22:42 <Zakim> Orie, you wanted to comment on existing terms, vs new ones and IRIs
19:22:43 <DavidC> q+
19:23:03 <cabernet> Orie: I'm in favor of getting this into the place where it can be merged. it is doing too muchj now
19:23:15 <cabernet> ... reserving new terms, addressing previous terms not having implementationg
19:23:33 <cabernet> ... we should focus on the latter "terms of use", "refresh service", "evidence"
19:23:51 <cabernet> ... all we need in the table is the json member and the URL, and only for terms shipped in v1 or v1.1 in the PR
19:23:53 <manu> q+ to note ok, update PR to JSON, URL, and only for v1.1.
19:24:15 <cabernet> ... this should get rid of objections, which are primarily about new terms being added, "confirmation method", "resentations schema", "render Method"
19:24:25 <kristina> ack DavidC
19:24:26 <cabernet> ... splitting gets easier to get consensus
19:24:35 <brent> +1 to breaking this up into different PRs
19:24:51 <cabernet> DavidC: regarding conformance test, the three already in 1.1 already have conformance tests since the are MUST fields
19:25:01 <cabernet> ... our implementation implemented both [sic] of them
19:25:04 <manu> q+ to speak to the interop tests for v1.0 and v1.1
19:25:28 <cabernet> ... only two tests are needed, one is that you send to a SUT, here is a cred with a type, if you accept that is proven that it works
19:25:47 <cabernet> ... second test is to send terms or evidence without a type, and implementation should reject it
19:26:00 <cabernet> ... these should be sufficient to say we have multiple independent implementations to prove these work
19:26:16 <cabernet> ... then people can test types from registry.
19:26:35 <kristina> ack many
19:26:40 <kristina> ack manu
19:26:40 <Zakim> manu, you wanted to note ok, update PR to JSON, URL, and only for v1.1. and to speak to the interop tests for v1.0 and v1.1
19:27:12 <cabernet> manu: going with Orie's suggestion, the concrete change request is "lets just deal with the things in the spec right now", and then define URLs for that.
19:27:25 <cabernet> ... I don't know if I agree, becuase something has to have the normative definition for the vocab as it stands today
19:27:43 <cabernet> ... we might still need description in the URL because we are going to remove from the core spec and that is supposed to be normative
19:28:27 <cabernet> ... DavidC to your point, v11 and 1.0 did absolutely test that, and we are raising the bar - we need to see real usage and deployment of
19:28:43 <cabernet> ... this extension point. If we don't have that it doesn't belong in the core specificcation
19:28:47 <kristina> +1 manu
19:28:50 <cabernet> s/v11/v1.1/
19:28:59 <DavidC> q+
19:29:07 <kristina> ack DavidC
19:29:47 <brent> q+
19:29:49 <cabernet> DavidC: if you are going down to the type level, you are going to cut the group up into small groups, each of which may have implmeented
19:29:57 <brent> q+ to talk about raising the bar
19:30:05 <cabernet> ... one of the types - that seems unfair, as the rest of the datamodel is for everyone
19:30:33 <cabernet> ... it is going to be muych harder to get multiple implementations of any particular type
19:30:35 <kristina> ack brent
19:30:35 <Zakim> brent, you wanted to talk about raising the bar
19:31:06 <cabernet> brent: it was made clear when drafting the charter that the expectation was any normative statements would have an implementation
19:31:33 <manu> q+ to ask about dangers at exiting CR and running a proposal.
19:31:35 <cabernet> ... extensions from round 1 are moving to a table of reserved properties, until and unless ther are normatively defined statements for the types
19:31:50 <cabernet> ... it will be problematic if there are terms in the data model that don't point to a normatively defined type
19:32:06 <dlongley> +1 to ensure we enable innovation somehow (objectors should not be able to block it)
19:32:28 <DavidC> q+
19:32:32 <kristina> ack manu
19:32:32 <Zakim> manu, you wanted to ask about dangers at exiting CR and running a proposal.
19:32:34 <cabernet> ... the bar needs to be raised for v2
19:32:52 <JoeAndrieu> present+
19:32:58 <cabernet> manu: +1 to brent, if we don't do something about this we will see formal objections when we try to exit to CR
19:33:36 <Orie> even keeping the table of reserved terms is suspect, if you can't use them without types, and we have no normative types... but it seems a good path forward, from where we are today.
19:34:01 <cabernet> ... chairs should as if anyone would formally object if we went down this path (primarily a question for DavidC).
19:34:27 <cabernet> ... I will update the PR to reflect what I heard in the call today, and my expectation is that we need to merge or figure out which set of formal objections we are going to be happy with
19:34:43 <kristina> ack DavidC
19:35:07 <cabernet> DavidC: brent said he wants the types to be formally standardized, and this worries me. That will be very difficult.
19:35:19 <manu> q+
19:35:29 <cabernet> ... two orgs might agree and implement, and that would meet the two implementation bar
19:35:57 <manu> q+ to note that the bar is not "formally standardized"... it's "a spec published somewhere and at least two interoperable implementations of that spec"
19:36:06 <Phil_ASU> q+
19:36:09 <cabernet> ... going back to X509, that introduce the first extension point
19:36:13 <Orie> We have types for `credentialSchema` and `credentialStatus`, and `proof`, we have reserved predicates for the ones we don't have as work items.
19:36:26 <brent> q+ to note that JSON-LD is the standard way to do extensions
19:36:30 <cabernet> ... standardizing the way to do extensions is the way to go, so people can experiment and some results will be come standards
19:36:39 <kristina> zakim, close the queue
19:36:39 <Zakim> ok, kristina, the speaker queue is closed
19:36:53 <kristina> ack manu
19:36:53 <Zakim> manu, you wanted to note that the bar is not "formally standardized"... it's "a spec published somewhere and at least two interoperable implementations of that spec"
19:37:11 <cabernet> manu: we are not saying you have to formally standardize things at these extension points
19:37:23 <cabernet> ... only that something has to exist on the web at a URL and there have to be two interoperable implementations
19:37:30 <cabernet> ... That is the bar for anything we do in the WG
19:38:06 <kristina> ack Phil_ASU
19:38:16 <cabernet> Phil_ASU: manu just cleared up my concern
19:38:37 <cabernet> ... I was worried we were eliminating opportunities to experiment and try out, as for termsOfUse for example
19:38:55 <cabernet> ... as long as the bar is set as Manu described, I'm ok with that
19:39:20 <kristina> ack brent
19:39:20 <Zakim> brent, you wanted to note that JSON-LD is the standard way to do extensions
19:39:23 <manu> yes, Phil, that's the bar that's suggested.
19:39:42 <cabernet> brent: responding to DavidC, from my point of view we have a standardized method of extending the datamodel - JSON-LD
19:40:10 <cabernet> ... we are allowing for certain named properties to be reserved so that the experimentation can be guided somewhat, but there is nothing
19:40:19 <cabernet> ... blocking people from experimenting as they want to.
19:40:40 <cabernet> ... I could come to accept Manu's bar, but fear that it is too low - we reallly need high standards for our standard
19:41:01 <cabernet> ... we need to be as interoperable as possible while also encouraging experimentation and growth
19:41:24 <Phil_ASU> I don't think a bar that supports experiments around reserved properties is too low. It's actually crucial to the evolution of the standard.
19:41:25 <manu> q+ to move on to other PRs :)
19:41:27 <cabernet> kristina: direction we are going is splitting PR in two as discussed
19:41:29 <kristina> splitting the PR into two; still need to agree on the bar that is needed to "get back in" to the core DM
19:41:33 <kristina> zakim, open the queue
19:41:33 <Zakim> ok, kristina, the speaker queue is open
19:41:41 <manu> q+ to move on to other PRs :)
19:43:17 <cabernet> short discussion of fpwd for vc-jwt
19:43:24 <manu> q+ about vc-jwt
19:43:27 <manu> q- about
19:43:29 <manu> q- vc-jwt
19:43:31 <kristina> ack manu
19:43:31 <Zakim> manu, you wanted to move on to other PRs :)
19:43:58 <cabernet> manu: question - we said Orie was going to make his changes and wg was going to review... did anyone review?
19:44:23 <cabernet> Orie: we didn't make any changes, I sent email about this to the list. We were intending to make changes and met as editors and decided we didn't need to make any changes
19:44:26 <manu> q+
19:44:30 <kristina> ack manu
19:45:15 <manu> q+
19:45:20 <kristina> ack manu
19:45:35 <cabernet> manu: Next up is data integrity, couple of stuck PRs here
19:45:58 <Orie> q+
19:45:59 <cabernet> ... orie, I think you wanted group to be aware of multikey class added to vocab (vc-data-integrity #93)
19:46:02 <kristina> subtopic: https://github.com/w3c/vc-data-integrity/pull/93
19:46:16 <kristina> ack Orie
19:46:47 <cabernet> Orie: my question was, for context, there are references from new vc-di-bbs work item to this, so I'm trying to understand from an ormative standpoint, can I reference
19:46:53 <cabernet> ... multikey from vc-di-bbs?
19:47:08 <manu> q+
19:47:24 <cabernet> ... wasn't sure if group has decided to create normative key format.
19:47:36 <kristina> would encourage the WG to review 1101 and 1100 before the next call
19:47:39 <kristina> ack amnu
19:47:42 <kristina> ack manu
19:47:55 <cabernet> manu: I think the reference is fine, but agree we need to make a decision as a WG as to where the reference goes
19:48:09 <cabernet> ... multikey is the key format used in did:key, which has lots of implmenetations
19:48:18 <Orie> Here is the todo, in vc-di-bbs that points to Multikey: https://w3c.github.io/vc-di-bbs/#multikey
19:48:23 <cabernet> ... eddsa, ecdsa, maybe now bbs
19:48:55 <cabernet> ... we have been creating normative version of this in the cryptosuites themselves, e.g., here are th ekey formats this suite supports...
19:49:25 <cabernet> ... I think the proposal right now is for each suite to keep defining sub-parts of multikey spec, and instead of spreading them around like that why don't we put them
19:49:46 <cabernet> ... into the data integrity specification (normatively) so that all suites can point to one place?
19:49:53 <Orie> +1 to everything Manu is saying, it feels like we have made improvements for key formats that align with how we now have DataIntegrityProof once, and we don't define a new type for each new suite, multikey seems in that spirit
19:49:55 <dlongley> +1 to just put Multikey definition in the Data Integrity Proof spec as a key format that cryptosuites can use
19:50:05 <cabernet> ... Can a cryptosuite decide to define its own multikey identifier (probably have to do this in bbs)
19:50:42 <Orie> +1 to (keeping) Multikey in data integrity, and citing it from vc-di-bbs (and others)
19:50:52 <Orie> +1 to allowing suites to not use Multikey.
19:50:53 <dlongley> +1 to one place (data integrity spec)
19:51:08 <cabernet> manu: any objections to putting multikey into data integrity spec?
19:51:11 <kristina> q?
19:51:18 <Phil_ASU> +1 to allow Multikey in the data integrity spec
19:51:24 <cabernet> (no objections voiced)
19:51:34 <cabernet> manu: we will do that, and put def into data integrity spec
19:52:03 <cabernet> manu: should cryptosuites be able to define key formats that they support? e.g., we support multi-key, but only "this subset". Would anyone object to this?
19:52:08 <Phil_ASU> +1 to allowing cryptosuites to define public keys they support
19:52:11 <dlongley> +1 to allow cryptosuites to define key types they support
19:52:16 <Orie> +1 to allow cryptosuites to define key types they support
19:52:23 <cabernet> (no objections voiced)
19:52:36 <cabernet> manu: Orie does that address your concerns
19:52:38 <cabernet> Orie: yes
19:54:11 <cabernet> Orie: talking about clarification of @context
19:54:35 <cabernet> kristina: encourage folks to keep reviewing PRs, 1100 and 1101 appear to be crucial
19:54:58 <kristina> q?
19:55:03 <cabernet> end call
19:55:23 <brent> zakim, who is here?
19:55:23 <Zakim> Present: Phil_ASU, stenr, shigeya, brent, kristina, DavidC, decentralgabe, dlongley, manu, kevingriffin, cabernet, dwaite, dlehn, JoeAndrieu
19:55:26 <Zakim> On IRC I see Orie, dwaite, JoeAndrieu, kristina, kevingriffin, RRSAgent, Zakim, brent, tzviya, gonzu_15, manu, Jem, TallTed, csarven, dlehn, w3c_modbot, ounfacdo, saysaywhat, npd,
19:55:26 <Zakim> ... cel[h], bumblefudge1, cel[m], Github, bumblefudge, cel, dlongley, rhiaro, stenr, shigeya, stonematt, Dongwoo, bigbluehat, hadleybeeman
19:55:41 <brent> present+ TallTed
19:56:04 <brent> zakim, end the meeting
19:56:04 <Zakim> As of this point the attendees have been Phil_ASU, stenr, shigeya, brent, kristina, DavidC, decentralgabe, dlongley, manu, kevingriffin, cabernet, dwaite, dlehn, JoeAndrieu,
19:56:07 <Zakim> ... TallTed
19:56:07 <Zakim> RRSAgent, please draft minutes
19:56:08 <RRSAgent> I have made the request to generate https://www.w3.org/2023/04/26-vcwg-minutes.html Zakim
19:56:15 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
19:56:15 <Zakim> Zakim has left #vcwg
19:56:17 <brent> rrsagent, bye
19:56:17 <RRSAgent> I see no action items