18:47:16 <RRSAgent> RRSAgent has joined #vcwg
18:47:20 <RRSAgent> logging to https://www.w3.org/2023/05/10-vcwg-irc
18:48:10 <brent> brent has changed the topic to: Meeting Agenda 2023-05-10: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20230510T150000
18:53:20 <brent> zakim, start the meeting
18:53:20 <Zakim> RRSAgent, make logs Public
18:53:22 <Zakim> please title this meeting ("meeting: ..."), brent
18:53:40 <brent> meeting: Verifiable Credentials Weekly Teleconference
18:53:47 <brent> chair: Brent Zundel
18:55:39 <mprorock> mprorock has joined #vcwg
18:58:03 <TallTed> TallTed has joined #vcwg
19:00:45 <TallTed> RRSAgent, pointer?
19:00:45 <RRSAgent> See https://www.w3.org/2023/05/10-vcwg-irc#T19-00-45
19:01:17 <TallTed> present+
19:01:27 <decentralgabe> decentralgabe has joined #vcwg
19:01:47 <cabernet> cabernet has joined #vcwg
19:02:05 <PhilF> PhilF has joined #vcwg
19:02:35 <kevingriffin-gleif> kevingriffin-gleif has joined #vcwg
19:03:24 <decentralgabe> present+
19:03:31 <andres> andres has joined #vcwg
19:03:36 <andres> present+
19:03:47 <PDL-ASU> PDL-ASU has joined #vcwg
19:04:20 <kevingriffin-gleif> present+
19:04:33 <brent> present+
19:04:34 <dlongley> present+
19:04:39 <cabernet> present+
19:04:41 <PDL-ASU> present+
19:04:44 <PhilF> present+
19:04:45 <mprorock> present+
19:05:06 <awhitehead> awhitehead has joined #vcwg
19:05:24 <PDL-ASU> scribe+
19:05:40 <manu> present+
19:06:11 <PDL-ASU> Brent: begin with Agenda review, work item status updates and PRs primarily in the VC data model, others if there is time etc.
19:06:28 <PDL-ASU> Brent: proposed agenda changes?
19:06:39 <Orie> Orie has joined #vcwg
19:06:47 <Orie> present+
19:06:53 <PDL-ASU> Brent: can handle changes to the JWT PR in the first agenda item.
19:07:10 <PDL-ASU> Brent: Intros?
19:07:49 <dwaite> dwaite has joined #vcwg
19:07:53 <dwaite> present+
19:08:00 <PDL-ASU> Greg Bernstein working getting signature suites test vectors together including BBS
19:08:21 <GregB> GregB has joined #vcwg
19:08:23 <brent> q?
19:08:29 <PDL-ASU> Brent: Greg recently joined as an invited expert and warmly welcomed.
19:08:35 <manu> q+
19:08:37 <brent> Topic: https://irc.w3.org/?channels=vcwg
19:08:43 <brent> ack manu
19:09:16 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1054
19:09:34 <Orie> q+
19:09:36 <PDL-ASU> Manu: Confidence method PR - there seemed to be consensus to merge last week but Orie had some objections. Wondering what we're doing with it?
19:09:41 <brent> ack Orie
19:10:03 <PDL-ASU> PR: is #1054
19:11:00 <PDL-ASU> Orie: concerned with this PR - calling it confidence methods is confusing and invites degraded security characteristics but doesn't work across industries. There aren't yet two independent implementations yet.
19:11:45 <PDL-ASU> ... tangled up into the table registry at this point which add a bunch of defs to the core spec. It's a valuable thing to look at but not helpful to focus on right now.
19:11:49 <manu> q+
19:11:51 <PDL-ASU> Brent: other comments?
19:11:54 <brent> ack manu
19:12:53 <PDL-ASU> Manu: To untangle things, one reason to put reserved property in the spec is to acknowledge important work.  While Orie is the -1 in the voting but these objections need to be addressed.
19:13:29 <PDL-ASU> ... we're listing everything that doesnt have 2 independent implementations, but we don't tell people how to implement the feature -no normative language etc..
19:14:00 <Orie> +1 the approach being taken for render method, that seems to be making progress.
19:14:01 <mprorock> q+
19:14:19 <PDL-ASU> ... in the render method spec made it its own specification and defined the normative property of render method in that separate text. Could follow that path for this confidence method mechanism, without txt in the core spec
19:14:33 <Orie> lets use the ccg to do incubation work, not the W3C TR.
19:15:16 <PDL-ASU> ... what specific things will break if we put this into the specification?  Need more details beyond concerns to understand how to respond.
19:15:34 <brent> ack mprorock
19:15:42 <PDL-ASU> ... if we get 2 independent implementations we could move that text into the spec in the CR phase
19:16:25 <PDL-ASU> Mprorock:  likes manu's approach to create an independent spec. This gets it out of the core spec, do the work in CCG, and bring it back when it's ready.
19:16:34 <Orie> Also folks should beware to of the english language issue with "confidence"... https://en.wikipedia.org/wiki/Confidence_man
19:16:36 <dlongley> q+ to say -1 to confirmationMethod, we moved through that in a previous call, it's clearly not got consensus
19:16:44 <brent> ack dlongley
19:16:44 <Zakim> dlongley, you wanted to say -1 to confirmationMethod, we moved through that in a previous call, it's clearly not got consensus
19:16:54 <PDL-ASU> Brent: concerned that we sounded like agreement last week and now we sound differently.
19:17:06 <Orie> I objected, outside of the call time.
19:17:14 <Orie> sorry I could not make the call.
19:18:05 <PDL-ASU> dlongley: fine with the approach manu has suggested making it a separate spec. The new argument is combining it with confidence associated with "man"  but we should proceed with Manu's plan.
19:18:15 <Orie> I am supportive of reserving terms, and then not working on them in the working group.
19:18:17 <PDL-ASU> Brent: clarifying which plan?
19:18:52 <mprorock> I would note, as i noted on the last call, i am likewise not a fan of confidenceMethod vs confirmationMethod for the technical reason of alignment with cnf and other existing use of this concept
19:18:55 <Orie> +1 to most of what dlongley said
19:18:58 <PDL-ASU> dlongley: add property to reserve table and can add it to the main spec later. If the group doesn't want that at risk text in the spec he could live with it as well.
19:19:06 <mprorock> but lets keep work moving
19:19:08 <Orie> I am supportive of the text being developed in ccg
19:19:25 <manu> q+ to ask for a poll to move the work out of the group vs. at risk?
19:19:35 <brent> ack manu
19:19:35 <Zakim> manu, you wanted to ask for a poll to move the work out of the group vs. at risk?
19:19:37 <PDL-ASU> Brent: "At risk"  has a specific meaning. It's not common to use "at risk" in specifcations at this stage.
19:19:41 <Orie> +1 to brents comment regarding adding "at risk" to things that are not yet developed pass the ccg draft phase.
19:20:06 <mprorock> q+
19:20:24 <PDL-ASU> Manu: based on the minutes from the last call we had agreement to bring the defs into the spec.  We could poll to see if preference is to include in the spec as "at risk" or move it out to an external thing.
19:20:26 <TallTed> q+
19:20:40 <PDL-ASU> ... Manu not sure if polling is useful at this point.
19:20:56 <brent> ack mprorock
19:21:36 <brent> ack TallTed
19:21:39 <PDL-ASU> mprorock: Mprorock not a fan of this at this point.  But he's not going to block this at this stage. Strong preference to do the work elsewhere an not a fan of "at risk" in the language.
19:22:10 <Orie> I agree that at risk does rightly apply to the existing terms that shipped in v1 without concrete support.
19:22:25 <PDL-ASU> tallted: last week we did take into account the W3C meaning of "at risk". We were going to list both in table of reserve terms and in the implementation section. whichever one won out woudl stay in the spect the other removed.
19:22:26 <dlongley> +1 to TallTed
19:22:32 <Orie> status list and credential schema are in good shape.
19:22:42 <dlongley> +1 to what TallTed being the best way forward as well
19:23:01 <PDL-ASU> ... same is true in reverse. Could lie fallow for a period of time and be addressed later.
19:23:16 <Orie> q+ to comment on controller vs owner
19:23:34 <decentralgabe> +1 @TallTed well said
19:23:42 <dlongley> +1 to TallTed's comments on the naming
19:23:46 <brent> ack Orie
19:23:46 <Zakim> Orie, you wanted to comment on controller vs owner
19:23:49 <PDL-ASU> Tallted: the use of confidence man should not impact the meaning of confidence. That objection has no utility for me.
19:24:42 <shigeya> present+ shigeya
19:24:53 <dlongley> q+ to say "confirmation" is much worse ... even existing mechanisms do not even "confirm".
19:24:56 <PDL-ASU> Orie: clarifying why confidence is problematic -it's a predicate in JSON-LD. It's an open RDF cookie and could allow adding a confirmation type of sending a person to a home (physically). Not a good idea to have any RDF type.
19:25:11 <brent> q+ to say let's poll
19:25:25 <TallTed> There *still* is no binding happening here.
19:25:44 <brent> ack dlongley
19:25:44 <Zakim> dlongley, you wanted to say "confirmation" is much worse ... even existing mechanisms do not even "confirm".
19:25:49 <PDL-ASU> ... legit to have a technical means to have a binding, but a vocab that invites people to do whatever they want isn't appropriate. Dislike word "confidence" he's amenable for a separate path forward.
19:26:29 <PDL-ASU> dlongley - in an open world model there will be objections.  Confidence is better than confirmation. Terminology is the best we have now and works with an open world model.
19:26:43 <brent> ack brent
19:26:43 <Zakim> brent, you wanted to say let's poll
19:26:48 <PDL-ASU> Brent: let's do some polls
19:26:56 <przemek> przemek has joined #vcwg
19:27:03 <Orie> In some sense it is better that we not use "confirmation" if it does not provide strong security characteristics unless used with a specific RDF type.
19:27:06 <PDL-ASU> Manu: asks Brent to craft something.
19:27:09 <SamSmith> SamSmith has joined #vcwg
19:27:18 <SamSmith> present+
19:27:28 <SamSmith> q
19:27:47 <brent> poll: we will add confidenceMethod to the reserved table and add the language to the spec with a note that it will be removed if there are not two implementations
19:28:00 <manu> +1
19:28:01 <dlongley> +1
19:28:03 <andres> +1
19:28:04 <decentralgabe> +1
19:28:05 <brent> +1
19:28:08 <GregB> +1
19:28:10 <PDL-ASU> Brent: poll open
19:28:10 <SamSmith> 0
19:28:11 <awhitehead> +1
19:28:13 <Orie> -1
19:28:14 <mprorock> -0.5
19:28:18 <PDL-ASU> +1
19:28:23 <shigeya> -0.5
19:28:27 <cabernet> 0
19:28:31 <TallTed> +1 "removed from the spec and left in the reserved table"
19:28:31 <PhilF> 0
19:29:01 <PDL-ASU> Tallted: clarification "removed form the spec and left in the reserved table"
19:29:14 <PDL-ASU> Brent: Orie's -1 is noted
19:31:01 <PDL-ASU> Shigeya: wondering if this method may increase confusion. People in this call understand there are different camps. The people who lead this spec might confuse this with the "confidence method"
19:31:13 <manu> q+
19:31:19 <PDL-ASU> Brent: poll makes it clear we don't have consensus and we'll continue talking about it.
19:31:32 <PDL-ASU> Manu: should it be marked as "do not merge" and move on?
19:31:35 <Orie> can we try a resolution to do what we did with render?
19:31:36 <brent> ack manu
19:31:50 <PDL-ASU> Brent: label it "discusss"
19:32:17 <decentralgabe> q+
19:32:22 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1064
19:32:22 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1064
19:32:25 <PDL-ASU> Manu: continuing with other PRs: next item "update json schema to accurately reflect context definition"
19:32:26 <brent> ack decentralgabe
19:32:46 <Orie> q+
19:32:52 <brent> ack Orie
19:32:59 <PDL-ASU> Gabe: this is blocked by a PR that's now been merged, which fixed the example context, which should reserve opposition.
19:33:40 <mprorock> +1
19:33:47 <PDL-ASU> Orie: Manu opened a PR an example context that makes it no longer return a 404.
19:33:53 <PDL-ASU> Brent:  The PR has been merged that makes it a 404.
19:33:58 <mprorock> i have approved
19:34:02 <PDL-ASU> Orie: changing to no objection
19:34:13 <decentralgabe> https://github.com/w3c/vc-data-model/pull/1111
19:34:16 <PDL-ASU> Gabe: can this be merged with 1111?
19:34:19 <mprorock> please!!!!
19:34:32 <PDL-ASU> Orie: can be merged this
19:34:44 <PDL-ASU> mprorock: yes to merge this and with 1111
19:35:13 <PDL-ASU> Brent: 1064 should be merged? No opposition. Mege it.
19:35:20 <PDL-ASU> Gabe: it's merged
19:35:23 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1111
19:35:43 <PDL-ASU> Manu:  next is 1111 and the one that Orie wish it to merged.
19:35:53 <PDL-ASU> Brent: Objections? None - merged
19:35:58 <PDL-ASU> Manu: merges 1111.
19:36:00 <decentralgabe> manu: is rebase and merge our practice? I have been squashing and merging
19:36:14 <Orie> q+
19:36:45 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1083
19:36:49 <brent> ack Orie
19:37:17 <PDL-ASU> Manu: 1083 manu is good with if Tallted's suggestions are addressed. Move on to another PR.
19:37:35 <PDL-ASU> Manu: 1100 and 1101
19:38:10 <PDL-ASU> Kevin: the discussion of these will merit more time to see if we can get through others.
19:38:22 <PDL-ASU> Manu: special topic call needed for 1100 and 1101.
19:38:34 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1107
19:38:51 <PDL-ASU> Manu: PR 1107 - topic clarifying relationship between securing mechanisms and media types.
19:39:15 <PDL-ASU> Orie: needs to review recent changes.
19:39:25 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1108
19:39:41 <PDL-ASU> Manu: PR 1108 - Add new v2.0 reserved properties.
19:40:10 <PDL-ASU> Manu: 4 objections with change requests from Orie, David Chandwick, Oliver and Kristina
19:40:23 <Orie> FWIW i think https://github.com/w3c/vc-data-model/pull/1107 can be merged outside of call time, I was the only objector.
19:40:38 <PDL-ASU> Manu: think Oliver and Kristina wanted to see confidence method merged before this PR is merged, which we're not doing today
19:40:56 <PDL-ASU> ... what are you thoughts on this Orie?
19:41:29 <PDL-ASU> Orie: seems like render method would go in by itself. there's work going in the CCG and people would agree with this
19:41:33 <brent> q?
19:41:52 <PDL-ASU> Orie: would approve render method and has presentation schema reservations.
19:42:13 <SamSmith> n the academic literature the word confidence is extremely common in expert systems and automated reasoning to provide a measure of uncertainty on a given predicate
19:42:28 <PDL-ASU> Orie: today Orie is ok with the confidence method in the table. Not a fan of it in any format and prefer to have it reviewed for terms independently.
19:42:45 <PDL-ASU> Manu: refactor PR to only refer to render method - any objections to that?
19:42:54 <PDL-ASU> Brent: no objections heard.
19:43:00 <shigeya> I share same thought on presentationSchema and renderMethod with Orie
19:43:02 <Orie> I would be a +1 to reserving render method, since their is a ccg spec which I can read that might eventually get 2 independent implementations
19:43:02 <dlongley> SamSmith: (and that's a match for its usage in VCs)
19:43:11 <PDL-ASU> Manu wil redo 1108 to only include render method.
19:43:28 <manu> subtopic: https://github.com/w3c/vc-data-model/pull/1112
19:43:54 <PDL-ASU> Manu: Add note to describe use of credentialschema with selective disclosure #1112 Ready to merge?
19:44:03 <PDL-ASU> Brent: no objections heard.
19:44:13 <PDL-ASU> Manu: tiny cleanup but will merge thereafter
19:44:24 <PDL-ASU> Manu: that concludes those over a week old.
19:44:52 <brent> subtopic: https://github.com/w3c/vc-jwt/pull/77
19:45:04 <PDL-ASU> Brent: handing things to VC JWT editors vor pull 77
19:45:36 <Orie> q+
19:45:44 <dlongley> q+
19:45:49 <PDL-ASU> mprorock: only one open change request from Kristina and outdated at this point.  Has been asked several times. Feel it is ready to merge.
19:46:03 <PDL-ASU> ... can adjust things with other language later as needed.
19:46:04 <SamSmith> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5378479/#:~:text=Nevertheless%2C%20there%20is%20a%20fundamental,commitment%20is%20overt%20or%20covert).
19:46:08 <brent> ack Orie
19:46:49 <brent> ack dlongley
19:46:52 <PDL-ASU> Orie: has asked Kristina several times with a warning recently if no feedback in a week we'd move forward. Not a nice to do for a chair we need to move on.
19:47:34 <Orie> q+
19:47:40 <mprorock> "There are three classes of JWT Claim Names: Registered Claim Names,    Public Claim Names, and Private Claim Names."
19:47:42 <PDL-ASU> dlongley: has outstanding change request - think we're asking for trouble if we don't do it. Use the work payload for JSON-LD in the text. The use of the term "claim set'
19:47:44 <mprorock> q+
19:47:51 <brent> ack Orie
19:47:57 <PDL-ASU> ... highly recommend using "payload" in this spec.
19:48:44 <PDL-ASU> Orie: have talked about this exact issue of "claim set".  When we say this is a 'private claim' one of the understandings is to look at if there is a private claim in the context file.
19:49:11 <mprorock> +1
19:49:21 <PDL-ASU> ... previously tried to refer to claim sets as payloads and has been chastised.  RFC call this a "claim set".  We should use what the RFC defines.
19:49:21 <dlongley> q+
19:49:43 <brent> q+ to say this feels like something that shouldn't block. Who will bend
19:49:45 <brent> ack mprorock
19:49:47 <PDL-ASU> ... Any jason object is a valid json payload and valid as a claim set as a token.
19:50:26 <PDL-ASU> mprorock: notes david's concerns and should be understood.  Claim set is about public and private claims which is the word used.
19:50:37 <kevingriffin-gleif> s/jason/JSON
19:50:45 <brent> ack dlongley
19:50:48 <PDL-ASU> mproprock if we shift this to a more JWS approach the problem would arise.
19:51:16 <brent> ack brent
19:51:16 <Zakim> brent, you wanted to say this feels like something that shouldn't block. Who will bend
19:51:35 <SamSmith> As can be imagined to avoid conflicting reasoning paths, complex sets of rules require precedence or weight to be assigned. This method, which helps establish the level of certainty of the expert system’s predictions and recommendations, is referred to as the confidence factor.
19:52:39 <Orie> Worth noting that using JWS would also support securing content types that are not JSON-LD... it might be nice to secure payloads that are not JSON... JSON Web Tokens, assumes json claimsets.... JSON-LD is sadly also JSON.
19:53:22 <PDL-ASU> dlongelyl note that private claims should not conflict nor with registered claims--  recommend shifting to more JWS language that problem would go away
19:53:51 <Orie> I appreciate the concern, please be clear if you will formally object
19:53:55 <mprorock> appreciate dave's approach on this
19:54:04 <mprorock> very much
19:54:05 <PDL-ASU> Brent: heard that dave wouldn't block this if we move this to a more JWS approach but he'll leave that to be resolved by the JWS editors
19:54:24 <dlongley> no formal objection, just raising concerns for VC-JWT editors to figure out how to resolve to avoid potential problems
19:54:37 <PDL-ASU> Brent: assuming Kristina's issue isn't further discussed it should go to the JWS editors.
19:54:53 <PDL-ASU> Brent: PR in status list we should look at.
19:54:56 <manu> q+
19:55:11 <PDL-ASU> Brent: PR 46 or PR 60
19:55:16 <Orie> +1
19:55:16 <manu> subtopic: https://github.com/w3c/vc-status-list-2021/pull/46
19:55:17 <manu> q+
19:55:18 <PDL-ASU> Manu: handle 46
19:55:23 <brent> ack manu
19:55:50 <dlongley> q+
19:56:19 <PDL-ASU> Manu: This PR46 need to make sure status list shoudl be dereferenced.  This is a data model spec, not related to the protocol used. Can open an issue to consider adding language around HTTP and maybe merge thereafter.
19:56:26 <Orie> This PR is an improvement, and should be merged, over the objections... Manu is correct, dereferencing might happen in a document loader that makes not network requests.
19:56:27 <Orie> q+
19:56:32 <brent> ack dlongley
19:56:34 <PDL-ASU> Manu: Without Mike or Kristina on the call we can't make progress.
19:57:00 <Orie> +1 dlongley, the objections don't make sense, the document loader seems to not be understood
19:57:03 <manu> yes, also what dlongley said
19:57:05 <brent> ack Orie
19:57:07 <PDL-ASU> dlongely: the actual recommendations from Mike don't make sense here. We're saying when a client fails to deference something it generates a validation error.
19:57:11 <mprorock> q+
19:58:06 <PDL-ASU> Orie: complete agreement.  A lot of confusion around the fundamentals. This is the same data model as in the core data spec.
19:58:12 <dlongley> +1 to Orie
19:58:51 <brent> ack mprorock
19:58:53 <dlongley> s/generates a validation error./generates a validation error. It doesn't make sense to have a client return an HTTP error, that's a server's job./
19:58:56 <PDL-ASU> ... confusion over how dereferencing works is close to things that cause formal objections. If it's not clear how defreferencing works then there is a security problem.
19:59:16 <PDL-ASU> mprorock: agreement with the above comments. Need to get this merged.
20:00:07 <brent> zakim, end the meeting
20:00:07 <Zakim> As of this point the attendees have been TallTed, decentralgabe, andres, kevingriffin-gleif, brent, dlongley, cabernet, PDL-ASU, PhilF, mprorock, manu, Orie, dwaite, shigeya,
20:00:10 <Zakim> ... SamSmith
20:00:10 <Zakim> RRSAgent, please draft minutes
20:00:11 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/10-vcwg-minutes.html Zakim
20:00:50 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
20:00:50 <Zakim> Zakim has left #vcwg
20:00:50 <brent> rrsagent, bye
20:00:50 <RRSAgent> I see no action items