19:00:47 <RRSAgent> RRSAgent has joined #vcwg
19:00:47 <RRSAgent> logging to https://www.w3.org/2021/10/06-vcwg-irc
19:00:55 <brent> zakim, start the meeting
19:00:55 <Zakim> RRSAgent, make logs Public
19:00:56 <Zakim> please title this meeting ("meeting: ..."), brent
19:01:08 <brent> meeting: Verifiable Credentials Working Group
19:01:14 <brent> chair: Brent Zundel
19:01:55 <brent> present+
19:02:58 <brent> brent has changed the topic to: VCWG Weekly Teleconference
19:04:37 <dmitriz> dmitriz has joined #vcwg
19:05:18 <rgrant> rgrant has joined #vcwg
19:06:29 <kdenhartog> kdenhartog has joined #vcwg
19:06:32 <kdenhartog> present+
19:06:38 <cel> present+
19:06:39 <rgrant> present+
19:06:41 <dlongley> present+
19:06:43 <dmitriz> present+
19:10:02 <cel> scribe+
19:11:27 <brent> https://htmlpreview.github.io/?https://github.com/w3c/vc-data-model/blob/kdh/rec-snapshot-10062021/REC/2021-10-05/index.html
19:12:02 <MacTed> present+
19:12:10 <cel> brent: if we resolve as a group we will transition in a week and notify the group by email that they have a week to object, i believe will meet process and the narrow window to publish
19:12:43 <cel> ... Between the 6th and 20th of December is window to publish. If reach resolution today, we should reach the center of that window just right.
19:13:04 <cel> ... The agenda today is straightforward. Apologies for the lack of content in the agenda reminder email.
19:13:08 <TallTed> present- MacTed
19:13:11 <TallTed> present+
19:13:20 <cel> ... The W3C tools were down; I couldn't use them to construct the agenda.
19:13:36 <cel> ... The agenda is to look at a proposal to submit the substantive changes, and all editorial changes thus far agreed upon...
19:13:52 <cel> ... as a set of candidate changes as an updated recommendation for the Verifiable Credentials Data Model.
19:14:11 <cel> ... As time remains after that, we will triage issues, and address editorial changes if time after making a resolution about substantive ones.
19:14:29 <cel> ... Does anyone have qestions or comments; desires for changes to the agenda?
19:14:33 <brent> topic: vote on candidate changes
19:15:04 <cel> ... I will begin to construct a proposal; we can tweak the language as a group.
19:15:58 <cel> ... Here is a rough draft of the initial proposal. I know it needs more. The link is not pretty. I think we need to add language around ...
19:16:58 <dlongley> i think we want to say that the text at that link will be at a static link and it's what's at that link that we will ask review of
19:17:02 <cel> ... the "according to the process for revising a recommendation" - the reason for being a little less specific and pointing to process... I don't know if any other spec has gone through this the way we are doing it... so we've had to reach out to find out what process requires for creating a static copy... what the process has to be... like for pointing out errata - all of that is pretty new
19:17:43 <dlongley> q+
19:19:13 <cel> dlongley: What we have is an issue that what we are voting on is at [Kyle's link], but the content will be made static using the usual process, and that link is what will be made public in the request for review.
19:19:35 <brent> ack dlongley
19:20:13 <cel> brent: [Reads proposal]. Does anyone want to propose changes to that before we put it to the group?
19:20:27 <cel> TallTed: Is that going to persist indefinitely?
19:20:33 <cel> brent: Is which ...?
19:20:44 <cel> TallTed: The static thing at that link, the HTML preview
19:20:56 <cel> kdenhartog: No, it won't; that branch will be deleted...
19:21:12 <cel> TallTed: I'm suggesting we need to put in a link to where it will be, in the minutes...
19:21:34 <cel> ... There's no other way for people who are reading the minutes to know what we are talking about.
19:21:58 <kdenhartog> q+
19:22:02 <cel> ... It could be a static file in our repo, or anywhere in W3C space... FWIW, the W3 systems should be up now (It was taken down for a day.)
19:22:13 <cel> brent: We do have a somewhat better link...
19:22:32 <TallTed> s/taken down/down due to cloud infrastructure provider issue/
19:22:36 <cel> ... I wish Ivan were here, I don't know where...
19:22:49 <brent> PROPOSAL: No sooner than 2021 10 13 we will submit a request for wide review of the candidate changes represented at the link: https://github.com/w3c/vc-data-model/tree/main/REC/2021-10-05. The content for review will be made static using the regular publishing process and changed modulo that process for revising a recommendation
19:23:03 <cel> ... I've swapped out the link so that we have something more firm to point to.
19:23:20 <cel> ... Does this ease your concerns, Ted, or should we revise further?
19:23:34 <cel> TallTed: As long as that will be persistent, for people coming along in the future.
19:23:37 <brent> +1
19:23:39 <TallTed> +1
19:23:40 <dlongley> +1
19:23:40 <dmitriz> +1
19:23:41 <rgrant> +1
19:23:45 <kdenhartog> +1
19:23:45 <cel> brent: I think so. And I did it as a proposal. So go ahead and vote. ^
19:24:02 <cel> +1
19:25:19 <brent> RESOLVED: No sooner than 2021 10 13 we will submit a request for wide review of the candidate changes represented at the link: https://github.com/w3c/vc-data-model/tree/main/REC/2021-10-05. The content for review will be made static using the regular publishing process and changed modulo that process for revising a recommendation
19:26:09 <wayne> +1
19:26:21 <brent> topic: issue triage
19:26:32 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+-label%3A%22substantive+change+v1.2%22+sort%3Aupdated-asc+-label%3Av1.1+-label%3Adefer-v2
19:26:57 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/823
19:27:06 <cel> brent: This link should give us any issues not marked with a ... label
19:27:20 <dlongley> q+
19:27:30 <brent> ack kdenhartog
19:27:59 <cel> kdenhartog: I'm not certain... we brought up an issue on BBS+, planned to link to it but couldn't find it...
19:28:30 <cel> ... I will link to that. +1 to dmitriz's suggestion... not sure though because nonce is related to proof property - need to double-check on specificity, for specific suites...
19:28:33 <brent> ack dlongley
19:28:37 <cel> ... could result in additional text
19:28:57 <cel> dlongley: I think they are largely asking questions - but ultimately about a property that is not part of the VC data model - it's part of the proofs
19:29:05 <dmitriz> q+
19:29:09 <brent> ack dmitriz
19:29:11 <cel> ... When VCWG recharters ... we might cover this, or defer to other specs
19:29:24 <brent> q+
19:29:39 <cel> dmitriz: We do mention challenge in the Verifiable Presentation section.
19:29:48 <cel> ... Unless I'm looking at the wrong version and we took it out...
19:29:57 <cel> ... I'm wondering if that might be the place to contrast challenge and nonce.
19:29:59 <dlongley> q+
19:30:04 <kdenhartog> q+
19:30:04 <brent> ack brent
19:30:16 <cel> brent: We had a similar issue in the Presentation Exchange spec...
19:30:49 <dmitriz> or maybe it would be good to add language to the VC Implementation guide?
19:31:06 <brent> https://identity.foundation/presentation-exchange/#presentation-request
19:31:24 <dmitriz> ohhh, this is the section I meant. It IS in the implementation guide https://www.w3.org/TR/vc-imp-guide/#presentations
19:31:33 <cel> ... We recognized that alongside the presentation definition object, a verifier might want to specify the challenge or nonce. We put some generic language there, that might be appropriate here
19:31:36 <brent> ack dlongley
19:32:07 <cel> dlongley: We could certainly put something informative in the spec... but I don't know if that would resolve this person's issue... they are looking for something more concrete...
19:32:29 <cel> ... We are looking to add that to the next charter, with specific details.
19:32:47 <brent> ack kdenhartog
19:33:10 <cel> kdenhartog: This would require changes to the context, which we've traditionally declared defer-v2
19:33:16 <DavidC> DavidC has joined #vcwg
19:33:20 <DavidC> present+
19:33:28 <cel> ... I think we should defer it, not a handwavy approach
19:33:37 <brent> present+ bumblefudge
19:33:44 <cel> ... It is close to authentication protocols - might need to put that in scope - but more controversial - in the charter
19:33:57 <dlongley> +1 to defer v2 and question labels
19:34:03 <kdenhartog> +1
19:34:07 <cel> brent: Label "defer v2 and "question"?
19:34:23 <cel> s/"defer v2/"defer v2"/
19:35:53 <cel> brent: [Describing the resolution for David and Juan who just joined the call]
19:36:04 <brent> topic: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Av1.1+sort%3Aupdated-asc
19:36:15 <brent> topic v1.1 issues
19:36:33 <cel> topic: v1.1 issues
19:37:06 <cel> brent: All these issues we anticipated would be editorial. Understanding editorial changes don't require the same review period.
19:37:09 <kdenhartog> q+
19:37:14 <brent> ack kdenhartog
19:37:36 <cel> kdenhartog: Shall I close all the ones that have PRs open?
19:37:42 <cel> brent: I don't have a problem with that
19:37:55 <cel> kdenhartog: (Some were not closed automatically that should be have been)
19:38:11 <cel> DavidC: It's more than that...
19:38:36 <cel> brent: If in your editorial purview you feel the PR that was merged properly addresses the issue, then make that statement and close it.
19:38:39 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/209
19:39:16 <cel> brent: I vaguely remember this conversation... several years ago. We talked about it a few months ago
19:39:48 <kdenhartog> q+
19:39:49 <cel> ... At the time I was confident I could write a PR to address this, but now reviewing it I no longer recall...
19:39:58 <brent> ack kdenhartog
19:40:31 <cel> kdenhartog: ... We left it more vague... questions about pseudonymity... a cover clause to abstract around ZKPs...
19:40:33 <dlongley> q+
19:40:38 <cel> ... that the issuer must give you something you can derive from
19:40:41 <brent> ack dlongley
19:40:59 <TallTed> q+
19:41:03 <cel> dlongley: I think that is good and helpful... Letting people reading the spec know that if the issuer is not cooperating to do this, then you don't get it.
19:41:16 <cel> ... The issuer has to offer you this feature, and not try to backdoor recreate correlation or collision
19:41:29 <cel> ... The notion is that there is some trust in the issuer to cooperate in this scheme for it to work.
19:41:31 <kdenhartog> This is the statement in the spec, that I think generally covers this: "The verifiable credential MUST contain a Proof, using the proof property, so that the holder can derive a verifiable presentation that reveals only the information than the holder intends to reveal."
19:41:37 <cel> ... I think this should be stated in the spec
19:41:45 <brent> ack TallTed
19:42:02 <cel> TallTed: I recall the issue was about active participation by the issuer, rather than about making a derived credential of a credential one has in their hand
19:42:05 <dlongley> q+
19:42:17 <brent> ack dlongley
19:43:08 <cel> dlongley: One attack: even if the issuer is following these protocols... if the issuer is creating a different public key for every user they issue a credential to, they re-introduce a way to correlate and track users.
19:43:22 <kdenhartog> q+
19:43:23 <cel> ... Issuer should opt in, and must also decide not to track you
19:43:26 <brent> ack kdenhartog
19:43:28 <brent> q+
19:43:52 <cel> kdenhartog: I see that, think it could be added to the privacy section, not tie specifically to ZKPs only
19:44:08 <brent> ack
19:44:11 <brent> ack brent
19:44:14 <cel> ... There are other ways an issuer could create pseudonymity... active issuer policies
19:44:38 <dlongley> thanks brent
19:44:40 <TallTed> +1 kdenhartog's described editorial addition, whether done by kdenhartog or brent
19:44:40 <cel> brent: I'll put a PR in, and we'll see if it's acceptable
19:44:49 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/734
19:45:15 <cel> brent: Have fields for locale-specific information been checked? This is a comment from the Internationalization folks that came in after the Candidate Recommendation wide review period.
19:45:22 <cel> ... The issue speaks for itself.
19:45:48 <TallTed> q+
19:45:55 <brent> ack TallTed
19:46:07 <cel> ... Would anyone like to volunteer to review the spec, or to write a PR to address this?
19:46:29 <DavidC> q+
19:46:31 <cel> TallTed: There's no standard for this. "name" and "address" - leave it t that
19:46:38 <brent> ack DavidC
19:46:41 <cel> s/it t that/it at that/
19:47:06 <cel> DavidC: It doesn't matter if the address is specific to a country if it says what the country is in the address, because it's destined for that country.
19:47:23 <cel> ... In our examples we could have addresses, India, Thailand, ...
19:47:29 <TallTed> q+
19:47:30 <cel> ... Address for England has to be an England address, etc.
19:47:34 <brent> ack TallTed
19:47:37 <dmitriz> q+
19:48:09 <cel> TallTed: The point of their comment is that there are subfields listed, street, city, province, postal code, etc. UK address breakdown does not work in US address breakdon. The breakdown is the problem. That is where it breaks down ;)
19:48:15 <brent> q+
19:48:16 <cel> ... So just say name, and "address".
19:48:21 <brent> ack dmitriz
19:48:50 <cel> dmitriz: +1 to what Ted said. We should change out detail tags with a single address field, like already modelled
19:48:52 <cel> q+
19:49:04 <rgrant> also +1 to non-schema address examples
19:49:06 <brent> ack brent
19:49:22 <cel> brent: I agree, solution would be to make examples less specific rather than more specific
19:49:27 <brent> ack cel
19:49:30 <brent> scribe+
19:49:46 <dmitriz> I can volunteer to make that change
19:49:58 <brent> cel: I was going to say I'm familiar with that use of the country as the separater, buty don't know the standard for that
19:49:58 <kdenhartog> q+
19:50:05 <kdenhartog> q-
19:50:06 <brent> ack kdenhartog
19:50:30 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/734
19:50:35 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/751
19:51:07 <cel> q+
19:51:21 <brent> ack cel
19:51:52 <brent> cel: I looked at this and started trying to write something to address it. It was too difficult, but I could post what I have or link to it.
19:51:53 <dlongley> https://www.w3.org/TR/vc-data-model/#dfn-verify is what the spec says today
19:52:00 <brent> TallTed: comment that on the issue
19:52:17 <cel> cel: thanks, i'll do that
19:52:36 <cel> brent: We do have a verify definition, but look forward to comments from cel, but don't see reason to take away Manu's assignee status there.
19:53:01 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/781
19:53:47 <cel> kdenhartog: I have a partially written branch on this... will get around to it.
19:53:59 <cel> ... Trying to editorialize what was stated in that CCG thread, and put it in an appendix
19:54:47 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/733
19:54:57 <cel> DavidC: [offered to help with 781]
19:55:00 <kdenhartog> q+
19:55:07 <brent> ack kdenhartog
19:55:24 <cel> kdenhartog: I'm pretty sure we addressed this in two PRs, but need to check that. One is marked pending close...
19:56:01 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/721
19:56:15 <cel> brent: Kyle, can you give us an update here?
19:56:30 <cel> kdenhartog: For this one, I believe there is some work in progress for getting these updated;
19:56:42 <cel> ... the problem is the way we are updating these SVGs I don't think went all the way to meeting it.
19:56:57 <cel> ... There are some optimized, some unoptimized. I don't have the original images that were used to generate.
19:57:04 <cel> ... I don't know how Charles was generating them...
19:57:20 <cel> ... Another issue is to make it more accessible - those two could probably be combined and done at the same time.
19:57:34 <cel> s/Charles/chaals/
19:57:43 <cel> ... If someone has those images, please post them
19:57:56 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/732
19:58:27 <cel> "
19:58:41 <cel> brent: [reads title "4.1 Link to going anywhere that makes sense"]
19:59:07 <cel> kdenhartog: Context URLs are failing... that's the empty folder.
19:59:26 <cel> ... I think we need Ivan's help with this
19:59:42 <cel> ... The basic problem is the ids are not linking to the human-readable descriptions
20:00:12 <cel> brent: Thank you everyone
20:00:34 <cel> ... Chairs and editors will make transition request
20:00:52 <brent> zakim, who is here
20:00:52 <Zakim> brent, you need to end that query with '?'
20:00:55 <brent> zakim, who is here?
20:00:55 <Zakim> Present: brent, kdenhartog, cel, rgrant, dlongley, dmitriz, TallTed, DavidC, bumblefudge
20:00:57 <Zakim> On IRC I see DavidC, kdenhartog, rgrant, dmitriz, RRSAgent, Zakim, TallTed, brent, tzviya, rhiaro, stonematt, bigbluehat, wayne, hadleybeeman, cel, dlongley, manu, dlehn
20:01:18 <brent> zakim, end the meeting
20:01:20 <Zakim> As of this point the attendees have been brent, kdenhartog, cel, rgrant, dlongley, dmitriz, MacTed, TallTed, DavidC, bumblefudge
20:01:20 <Zakim> RRSAgent, please draft minutes
20:01:20 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/06-vcwg-minutes.html Zakim
20:01:23 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
20:01:28 <Zakim> Zakim has left #VCWG
20:01:30 <brent> rrsagent, bye
20:01:30 <RRSAgent> I see no action items