18:55:36 <RRSAgent> RRSAgent has joined #vcwg
18:55:40 <RRSAgent> logging to https://www.w3.org/2023/06/07-vcwg-irc
18:56:12 <brent> zakim, start the meeting
18:56:12 <Zakim> RRSAgent, make logs Public
18:56:13 <Zakim> please title this meeting ("meeting: ..."), brent
18:56:21 <brent> meeting: VCWG Weekly Telecon
18:56:27 <brent> chair: Brent Zundel
18:56:32 <brent> present+
18:59:23 <andres> andres has joined #vcwg
19:00:41 <DavidC> DavidC has joined #vcwg
19:00:45 <dmitriz> dmitriz has joined #vcwg
19:01:01 <gkellogg> gkellogg has joined #vcwg
19:03:09 <cabernet> cabernet has joined #vcwg
19:03:13 <cabernet> present+
19:03:14 <PhilF> PhilF has joined #vcwg
19:03:56 <andres> present+
19:04:03 <Orie> Orie has joined #vcwg
19:04:05 <Orie> present+
19:04:06 <JoeAndrieu> JoeAndrieu has joined #vcwg
19:04:11 <dlongley> present+
19:04:19 <JoeAndrieu> present+
19:04:51 <gkellogg_> gkellogg_ has joined #vcwg
19:04:52 <DavidC> present+
19:04:57 <shigeya> present+
19:04:58 <PhilF> present+
19:05:04 <PhilF> scribe+
19:06:29 <PhilF> brent: Agenda today: Work item status updates, PRs, Triage issues
19:06:49 <PhilF> ... Categorize items as before or after CR or closed
19:07:23 <brent> Topic: Work Item status updates/PRs
19:07:33 <brent> https://github.com/w3c/vc-data-model/pulls?q=is%3Apr+is%3Aopen+label%3Adiscuss
19:07:35 <dmitriz> present+
19:08:16 <TallTed> present+
19:08:18 <PhilF> brent: Question for the group, do we feel that consensus is possible here?
19:08:31 <PhilF> ... on issues 1100 and 1101
19:08:53 <dlongley> q+
19:09:02 <brent> ack dlongley
19:09:20 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1100
19:09:25 <PhilF> dlongley: We are missing key players to discuss today.  Probably should not discuss today.
19:09:40 <Orie> +1 people are not here.
19:10:11 <PhilF> brent: Agreed we are missing key players, moving on
19:10:49 <PhilF> ... beginning the HR process.  Preparing documents to engage other groups.
19:11:36 <Orie> https://github.com/w3c/vc-jwt/pull/103
19:11:43 <TallTed> I don't know why those key players are absent today, but I might suggest including mention of these PRs in the next agenda, so there's advance warning that they will be discussed (and so encouraging those folks to prioritize attendance)?
19:11:52 <Orie> https://github.com/w3c/vc-jwt/pull/104
19:11:57 <PhilF> Orie: There are 2 new PRs on VC-JWT, 103 and 104
19:12:26 <Orie> https://github.com/w3c/vc-data-model/pull/1144
19:12:49 <PhilF> ... PRs up in the core data model 1144
19:13:29 <JoeAndrieu> q+
19:13:34 <pdl-ASU> pdl-ASU has joined #vcwg
19:13:36 <brent> ack JoeAndrieu
19:14:08 <PhilF> JoeAndrieu: Added a comment to 103.  Would it be useful to reuse the pattern for VCs.  A base media type plus securing?
19:14:17 <dlongley> q+
19:14:22 <brent> ack dlongley
19:14:25 <PhilF> ... both securing mechanisms will need a payload with a common basis
19:14:25 <dmitriz> +1 Joe, I was wondering about that as well
19:14:34 <Orie> correct, that is what it is doing.
19:14:40 <PhilF> dlongley: agrees it is following the same pattern
19:15:16 <gkellogg> gkellogg has joined #vcwg
19:16:01 <PhilF> Orie: talking about confidence method in registry
19:16:01 <dlongley> +1 to adding confidence method to the reserved terms table + v2 context, sounds good.
19:16:40 <PhilF> brent: 9 open PRs, please review and look thru them
19:16:47 <TallTed> q+
19:16:54 <brent> ack TallTed
19:16:54 <PhilF> ... moving on to final topic, issues
19:17:21 <PhilF> TallTed: suggest that we call out specific issues and PRs in agenda ahead of time.
19:17:49 <Orie> There are also several open PRs here: https://github.com/w3c/vc-status-list-2021/pulls which can be discussed.
19:18:30 <brent> Topic: Issue Triage
19:18:34 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
19:18:53 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1019
19:18:56 <PhilF> brent: Discuss issue 1019
19:19:28 <DavidC> q+
19:19:30 <andres> q+
19:19:38 <Orie> q?
19:19:44 <gkellogg_> gkellogg_ has joined #vcwg
19:19:58 <PhilF> JoeAndrieu: Thinks it would be hard to discuss this without Kristina's input
19:20:02 <brent> ack DavidC
19:20:18 <andres> q-
19:20:47 <Orie> +1 to closing the issue, it's being resolved elsewhere.
19:21:09 <PhilF> DavidC: Has this been superseded by Oliver's email requesting this has been moved to a work item with some positive replies on the working group.
19:22:07 <PhilF> brent: talking into mute
19:22:33 <andres> +1 to close as well
19:22:39 <PhilF> ... agreement that this needs to be done but not here.  So should be pending close as its being done elsewhere
19:22:49 <PhilF> DavidC: I'm happy with it being pending closed
19:22:50 <pdl-ASU> +1 to mark it pending closed
19:22:51 <JoeAndrieu> +1 to close
19:22:51 <Orie> +1 David
19:23:00 <PhilF> brent: Marking issue as pending closed.
19:23:10 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/908
19:23:21 <DavidC> Please add a reference to Oliver's proposed work item
19:23:47 <PhilF> brent: Issue raised by Sebastian, current assigned to Kristina.  Is this work that should be done before we go into CR?
19:23:48 <Orie> Suggest this issue be closed, that work is happening in other working groups.
19:24:06 <JoeAndrieu> q+ to suggest the directory
19:24:15 <brent> ack JoeAndrieu
19:24:15 <Zakim> JoeAndrieu, you wanted to suggest the directory
19:24:42 <PhilF> JoeAndrieu: since the W3C isn't doing this work, we should move this into the directory of related work and mark pending close
19:25:16 <PhilF> brent: Going to mark issue pending close
19:25:39 <PhilF> JoeAndrieu: Someone has to move it, right.  Have to capture that task
19:25:42 <Orie> nobody needs to add it though... people can list their work there... if they want to.
19:26:20 <JoeAndrieu> agreed, Orie. Just seemed like the right resolution of the issue.
19:26:32 <DavidC> q+
19:26:34 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/938
19:26:42 <brent> ack DavidC
19:26:46 <PhilF> brent: Issue 938 raised by and assigned to DavidC
19:27:36 <PhilF> DavidC: what are people wanting here?
19:27:56 <PhilF> ... what i want is some way to indicate to the recipient that the VCs are actually encrypted and maybe how
19:28:06 <Orie> encryption is out of scope for this working group.
19:28:09 <PhilF> ... helpful hint
19:28:14 <Orie> or has been... to date.
19:28:18 <JoeAndrieu> q+ to say it seems like a credential design issue
19:28:25 <brent> ack JoeAndrieu
19:28:25 <Zakim> JoeAndrieu, you wanted to say it seems like a credential design issue
19:29:04 <PhilF> JoeAndrieu: there are many different ways to do this.  That makes it a claim design issue.  Either claim by claim or entire VC
19:29:05 <andres> Also having the entire VP encrypted
19:29:14 <PhilF> DavidC: This is for the entire VC being encrypted.
19:29:18 <Orie> In JWTs, you check the header for that information.
19:29:46 <PhilF> ... talking about app to app encryption.  We should define one recognized best way to do this.
19:30:20 <JoeAndrieu> q+
19:30:22 <Orie> q+
19:30:24 <PhilF> brent: sounds like interest in pursuing this.  May require some normative guidance.  Mark this as before CR
19:30:31 <brent> ack JoeAndrieu
19:30:34 <Orie> q-
19:31:02 <PhilF> JoeAndrieu: Want to suggest quick fix.  What if we add a pattern that has a "encryptedCredential" property and define that in the context.
19:31:03 <Orie> suggest not doing anything with this... we don't need to add more JSON-LD terms.
19:31:12 <PhilF> ... But that's not a valid VC, nevermind
19:31:18 <dlongley> q+
19:31:48 <brent> ack dlongley
19:31:52 <Orie> encrypting a presentation is different than encrypting a credential.
19:31:53 <PhilF> DavidC: any VC in your wallet may be encrypted.  When you send it to the verifier that it is encrypted and be able to present in the Presentation
19:32:12 <JoeAndrieu> +1 to that approach
19:32:19 <PhilF> dlongley: Add a property that indicates an encrypted VC referencing JWE.  Expected payload would be JWEs
19:32:33 <PhilF> ... Add a PR to add that property
19:32:35 <DavidC> q+
19:32:46 <PhilF> brent: Mark as before CR and move on
19:32:53 <PhilF> ... looking at 959
19:33:30 <PhilF> DavidC: asking to talk about 1102 which is now marked pending close
19:33:41 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1102
19:33:57 <PhilF> brent: now talking about 1102.  Was discussed and no one liked the idea so it was marked pending close
19:34:05 <brent> ack DavidC
19:34:39 <PhilF> DavidC: Each of the extension points only get in if there are implementations but that the definitions could change
19:34:51 <brent> q+ to note recorded opposition
19:34:54 <PhilF> ... we already have a class of extension which have impls and have a unique URI
19:35:35 <PhilF> ... if we have the concept of a single extension point and all others have their own URI but be under the single extension point.
19:35:37 <Orie> We kinda already do have the concept of a single extension point... its called @context, and nobody understands it, and its values are not normative.
19:35:45 <PhilF> ... don't need the outer wrapper.
19:36:23 <PhilF> ... if you have vague extensions that don't fit specific items like "TermsOfUse" you don't know where to put it.
19:36:38 <Orie> David, we've made this easy for developers by bundling everything into the JSON-LD context.
19:36:42 <PhilF> ... a single pot makes it easier for developers to propose future extensions
19:36:57 <brent> ack brent
19:36:57 <Zakim> brent, you wanted to note recorded opposition
19:37:01 <Orie> You just need to learn how to use JSON-LD to write conformant extensions, which is super easy.
19:37:31 <PhilF> brent: chair hat off, I would be be in favor of this change.  It is not less confusing.  Implementers have a small set of extension points that are well define is the better option.
19:37:48 <dlongley> s/be be/not be/
19:37:56 <JoeAndrieu> q+ to say that it is useful constrain the meaning of the extension points and use @context for open ended
19:38:08 <PhilF> ... chair hat on, we have recorded that several members have said they would not be in favor of the change.  Likely no consensus.
19:38:11 <brent> ack JoeAndrieu
19:38:11 <Zakim> JoeAndrieu, you wanted to say that it is useful constrain the meaning of the extension points and use @context for open ended
19:38:16 <DavidC> q+
19:38:35 <PhilF> JoeAndrieu: +1 to all that, would also be opposed.  Open ended extension mechanism exists in @context
19:38:50 <brent> q+ to ask about FO
19:38:54 <brent> ack DavidC
19:39:00 <PhilF> ... agree with Mike Jones it feels more complicated having them all in one bucket
19:39:27 <PhilF> DavidC: looking for technical reasons and haven't heard any.
19:39:33 <PhilF> ... just that people don't like it.
19:39:34 <JoeAndrieu> q+ the technical argument is we already have it
19:39:41 <brent> ack JoeAndrieu
19:39:41 <JoeAndrieu> q+ to say the technical argument is we already have it
19:39:43 <Orie> technical reason, we already have an open ended json-ld way to do this, adding another makes our spec even harder for people to understand or use.
19:39:51 <Orie> +1 joe.
19:39:58 <PhilF> JoeAndrieu: one of the technical arguments is that this mechanism already exists in @context
19:40:17 <brent> ack brent
19:40:17 <Zakim> brent, you wanted to ask about FO
19:40:24 <Orie> the fact that its not obvious that json-ld solves this, is shocking to me, given our entire data model assumes we are experts at JSON-LD.
19:40:26 <JoeAndrieu> q-
19:40:54 <PhilF> brent: it is clear, there is no path to consensus.  Question to DavidC:  do you plan to formally object is we close the issue?
19:40:58 <PhilF> DavidC: No I would not
19:41:11 <PhilF> ... would appreciate more technical arguments.
19:41:59 <dlongley> q+
19:42:10 <brent> ack dlongley
19:42:35 <PhilF> dlongley: If you want some incubation for your idea, create an extension in the @context that is a generic extension
19:42:44 <PhilF> DavidC: Thank you Dave, that is a good idea
19:43:09 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1102
19:43:10 <PhilF> brent: Issue 959 back on the table
19:43:16 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/959
19:43:35 <PhilF> ... current assigned to Orie
19:43:41 <Orie> q+
19:43:44 <PhilF> ... it is marked ready for PR, Orie what is the status?
19:43:46 <brent> ack Orie
19:44:16 <PhilF> Orie: Joe pointed out that we already have this in a section in the spec.  Willing to compare current section with this issue.  Should be current CR work.
19:44:36 <PhilF> brent: Adding before CR label to issue
19:44:55 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1009
19:44:59 <PhilF> ... moving to issue 1009, assigned to Manu, DavidC and Kristina.
19:45:16 <Orie> Suggest closing this, the group has essentially resovled there is no difference
19:45:31 <PhilF> ... wonder if this has been overtaken by events.  How should we mark before or post CR?
19:45:45 <DavidC> q+
19:45:47 <JoeAndrieu> q+
19:45:51 <brent> ack DavidC
19:46:00 <Orie> There is not spec legal way to distinguish between credential and verifiable credential.
19:46:33 <PhilF> DavidC: this needs someone to carefully go through current version and ensure use of credential or verifiable credential are proper and submit editorial change.
19:46:37 <Orie> q+
19:46:38 <brent> ack JoeAndrieu
19:47:10 <Orie> indeed, the base media type explains that you never know.
19:47:17 <PhilF> JoeAndrieu: Appreciate the clarification.  Agrees the language in the spec is confusing.
19:47:18 <brent> ack Orie
19:47:43 <PhilF> Orie: +1 to what Joe said.  Base media type does not talk about securing mechanism.
19:48:01 <PhilF> brent: suggests to make this as post CR
19:48:08 <Orie> q+
19:48:15 <brent> ack Orie
19:48:35 <PhilF> Orie: this may effect normative statements.  esp the definition of what a proof is.  Must be addressed before CR
19:48:42 <PhilF> brent: adding before CR label
19:48:53 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/981
19:49:20 <PhilF> ... moving on to 981, assigned to Manu, marked as ready for PR
19:49:29 <Orie> I tried fixing this, Manu need to fix : /
19:49:42 <dlongley> +1 for Manu to fix
19:50:06 <PhilF> ... will leave it for Manu to fix.  Editorial so can add post CR label
19:50:16 <PhilF> ... marking issue as post CR
19:50:29 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/991
19:50:44 <Orie> q+
19:50:45 <PhilF> ... next issue 991, to discuss label. raised by and assigned to DavidC
19:50:50 <brent> ack Orie
19:51:17 <kristina> kristina has joined #vcwg
19:51:23 <PhilF> Orie: We have a separate work item for credential status.  This issue seems overtaken by events with open PRs.  Close this PR and go over to that work item
19:51:40 <Orie> I suggest closing this issue
19:51:49 <PhilF> brent: suggestion is to move this item to status list repo
19:51:50 <Orie> and instead reviewing the open PRs on that work item
19:52:01 <DavidC> q+
19:52:11 <Orie> (you don't)
19:52:11 <PhilF> JoeAndrieu: that is not correct.  Does seem to be about a specific status mechanism.
19:52:15 <brent> ack DavidC
19:52:37 <Orie> there are not 2 objects, we spent over month on this.
19:52:46 <dlongley> +1 just one object
19:52:50 <PhilF> DavidC: There are 2 objects, credential and verifiable credential and now talking about the status is "mixed up" as well.
19:52:51 <brent> +1 just one object
19:53:09 <JoeAndrieu> +1 just one object, but this is the layering problem
19:53:12 <dlongley> q+ to say key revocation is a security layer problem
19:53:19 <Orie> It seems http range 14 is yet again, disrupting our ability to communicate.
19:53:20 <PhilF> ... one could be valid while the other is invalid and vice versa.
19:53:26 <brent> ack dlongley
19:53:26 <Zakim> dlongley, you wanted to say key revocation is a security layer problem
19:53:56 <PhilF> dlongley: key revocation at the crypto layer is different than at the credential layer.
19:54:06 <JoeAndrieu> q+
19:54:11 <brent> q+ to note that there is one object
19:54:12 <brent> ack JoeAndrieu
19:54:16 <PhilF> ... key revocation and credential revocation are different things.
19:54:23 <brent> q-
19:54:43 <DavidC> q+
19:54:49 <PhilF> JoeAndrieu: We don't have separate items in our work.  We have just one digital thing
19:54:53 <brent> ack DavidC
19:54:55 <Orie> joe is correct, and the digital thing, may or may not have any integrity protection.
19:55:28 <PhilF> DavidC: Driver's license is my credential (and I've been driving for a long time).
19:56:02 <PhilF> JoeAndrieu: There are three layers here.  Different between having driven, the physical license and a digital thing.
19:56:24 <PhilF> ... we don't have good language differentiating these three things.
19:56:32 <PhilF> DavidC: Yes it is difficult to talk about
19:57:21 <brent> zakim, who is here?
19:57:21 <Zakim> Present: brent, cabernet, andres, Orie, dlongley, JoeAndrieu, DavidC, shigeya, PhilF, dmitriz, TallTed
19:57:24 <Zakim> On IRC I see kristina, gkellogg_, JoeAndrieu, Orie, PhilF, dmitriz, DavidC, RRSAgent, Zakim, brent, TallTed, shigeya, rhiaro, cel[h], ounfacdo, bumblefudge1, dlongley, stonematt,
19:57:24 <Zakim> ... dlehn, cel, bigbluehat, hadleybeeman, Dongwoo, stenr, csarven, bumblefudge, MojGraph, cel[m], w3c_modbot, saysaywhat, npd, Github
19:57:30 <dlongley> there can a validity period on a proof (expressed via internal / external proof securing mechanism), a validity period on the VC, and a validity period expressed in a claim about a license that someone possesses ... all different things
19:57:34 <dlongley> all works with 1 VC object.
19:57:45 <brent> present+ kristina
19:58:09 <brent> zakim, end the meeting
19:58:09 <Zakim> As of this point the attendees have been brent, cabernet, andres, Orie, dlongley, JoeAndrieu, DavidC, shigeya, PhilF, dmitriz, TallTed, kristina
19:58:11 <Zakim> RRSAgent, please draft minutes
19:58:13 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/07-vcwg-minutes.html Zakim
19:58:20 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
19:58:20 <Zakim> Zakim has left #vcwg
19:58:24 <brent> rrsagent, bye
19:58:24 <RRSAgent> I see no action items