15:21:20 <RRSAgent> RRSAgent has joined #vcwg-special
15:21:24 <RRSAgent> logging to https://www.w3.org/2023/11/14-vcwg-special-irc
15:21:24 <Zakim> RRSAgent, make logs Public
15:21:25 <Zakim> please title this meeting ("meeting: ..."), ivan
15:21:55 <ivan> Meeting: Verifiable Credentials Working Group Special Topic Call on Outstanding PRs
15:21:55 <ivan> Date: 2023-11-14
15:21:55 <ivan> chair: brent
15:21:55 <ivan> Agenda: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20231114T110000/
15:21:56 <ivan> ivan has changed the topic to: Meeting Agenda 2023-10-31: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20231114T110000/
15:57:19 <brent> brent has joined #vcwg-special
15:57:49 <brent> brent has changed the topic to: Meeting Agenda 2023-11-14: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20231114T110000/
15:58:51 <ivan> present+
16:01:05 <TallTed> TallTed has joined #vcwg-special
16:01:11 <andres> andres has joined #vcwg-special
16:01:15 <andres> present+
16:01:17 <brent> present+
16:01:38 <ivan> present+ will, brent, selfissued, tallted
16:03:12 <dlongley> present+
16:03:12 <TallTed> present+
16:03:21 <DavidC> DavidC has joined #vcwg-special
16:03:27 <DavidC> present+
16:03:33 <ivan> present+ manu
16:03:52 <cabernet> cabernet has joined #vcwg-special
16:03:54 <ivan> present+ seabass
16:03:56 <cabernet> present+
16:04:40 <cabernet> scribe+
16:05:25 <JoeAndrieu> JoeAndrieu has joined #vcwg-special
16:05:36 <cabernet> brent: welcome, focus today is pull requests, with goal to determine whether there is a path forward or if we should close each PR
16:05:53 <will> will has joined #vcwg-special
16:05:53 <ivan> present+ jandrieu
16:05:55 <will> present+
16:05:59 <cabernet> ... expect core datamodel to be ready for CR before mid-December
16:06:13 <ivan> present+ dmitriz
16:06:17 <brent> Topic: Pull Requests
16:06:18 <brent> https://github.com/w3c/vc-data-model/pulls
16:06:28 <ivan> present+ bigbluehat
16:06:37 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1271
16:06:42 <manu> q+
16:07:12 <DavidC> q+
16:07:16 <brent> ack manu
16:07:20 <cabernet> brent: orie requested explanation of why and how interop would be reduced
16:07:37 <cabernet> manu: I had volunteered but have not had a chance as I though this PR would be closed
16:08:09 <DavidC> q-
16:08:11 <cabernet> ... one thing worth mentioning, there are other language PRs that Benjamin has raised. we will probably strike telling people they shouldn't use that language in context property
16:08:16 <cabernet> ... and that they should use @base
16:08:26 <cabernet> ... once done, we should ask Orie for re-review
16:08:44 <cabernet> brent: agreed, if we don't hear by end of this week we merge and indicate we have attempted to address change requests
16:08:53 <cabernet> manu: I'll work on update today
16:09:02 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1276
16:09:17 <cabernet> brent: this is post-cr, so would like to understand status today
16:09:29 <DavidC> q+
16:09:44 <TallTed> q+
16:09:52 <cabernet> manu: I believe DavidC was asking for changes and manu requested and received re-review with some subsequent discussion
16:10:06 <cabernet> ... I think that we need an example from DavidC to move this along
16:10:26 <brent> ack DavidC
16:10:28 <cabernet> ... sounds like DavidC is opposed to this PR as it stands, would like some changes, and we need explicit change requests
16:10:49 <cabernet> DavidC: I did produce the text, but TallTed had suggested reformat as a block
16:11:05 <cabernet> ... at the moment there is one example, which uses a term defined in @context and uses the alias for that
16:11:24 <cabernet> ... I wanted to add a second example with an alias not explicitly defined in @context that would be turned into a URI using @vocab
16:11:36 <brent> ack TallTed
16:11:53 <cabernet> TallTed: that explanation is helpful, but I don't see that communicated in the current text
16:12:18 <cabernet> ... if you update your change request with this text I think it will be easier to move forward
16:12:46 <cabernet> DavidC: I had some difficulty with the GitHub UI trying to add multiple lines to the change request
16:13:24 <manu> q+
16:13:42 <cabernet> ... I will try just adding a block of text to bypass this (maybe broken) UI issue
16:13:50 <brent> ack manu
16:14:16 <cabernet> manu: Can we change this one to pre-cr? I've been ignoring post-cr issues, but this one seems like it may have a resolution this week.
16:14:28 <cabernet> brent: It might make sense to do that, yes
16:14:47 <cabernet> ... it seems like we are close, and ideally this one will get merged this week.
16:15:02 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1302
16:15:33 <cabernet> brent: my understanding is that this is still not closer to consensus than it was. is this at all closer and worth talking about, or should we move on?
16:15:44 <cabernet> ... moving on
16:15:57 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1320
16:16:12 <cabernet> brent: another post cr, don't believe any changes have been made since last discussion
16:16:22 <manu> q+
16:16:24 <manu> q-
16:16:34 <cabernet> ... propose we move on, as there doesn't seem to be additional consensus
16:16:50 <cabernet> Zakim: my sense from last week was that we were headed towards closing this, should we add pending close?
16:17:09 <manu> q+
16:17:11 <manu> q-
16:17:12 <cabernet> brent: you are not wrong, that's why we added post-cr in case we see a path towards consensus later that hadn't been available before
16:17:15 <ivan> s/Zakim/Joe/
16:17:35 <cabernet> Joe: I'm okay with that
16:17:37 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1332
16:18:10 <cabernet> brent: there was one change request on this one, which folks seemed fine with. I think we are waiting on Orie to respond
16:18:39 <cabernet> ... I will ping Orie directly to ask him to respond (he is not available for these Tuesday calls)
16:19:09 <seabass> +1 to JoeAndrieu (IRC) - I think we have consensus. Can we note this for Orie's benefit?
16:19:11 <cabernet> JoeAndrieu: seems like there was reasonable consensus to remove that last line, but I do think it is appropriate to bring in Orie on this one
16:19:38 <cabernet> brent: I think there is broad agreement on this one if the recommended change is made
16:19:48 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1333
16:19:53 <manu> q+
16:20:04 <manu> q-
16:20:18 <cabernet> brent: no approvals, and one change request. We still have not had any response from Orie based on the change request.
16:20:39 <cabernet> manu: I don't understand the language in the PR.
16:20:39 <seabass> q+
16:20:44 <TallTed> q+
16:20:51 <ivan> I do not understand that comment either
16:20:58 <cabernet> ... I don't know what Orie means by "localized", maybe I18N?
16:21:09 <cabernet> brent: I will add this to the things that I ask Orie about
16:21:14 <brent> ack seabass
16:21:58 <cabernet> seabass: I can't speak for Orie, but I think what he means is that the actual names of the RDF properties can't be translated into, e.g., French, without overhead. Similarly to how you have to use the english terms
16:21:59 <brent> ack TallTed
16:22:02 <ivan> q+
16:22:05 <cabernet> ... "for" and "while" for loops in C
16:22:13 <brent> ack ivan
16:22:34 <dlongley> +1 to ivan, this is true for everything, this isn't specific to anything in ... computer science.
16:22:42 <cabernet> ivan: that is indeed the intention, this is not RDF specific, this is a general feature for all the apis used on the web.
16:23:20 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1336
16:23:29 <manu> q+
16:23:43 <brent> ack manu
16:23:45 <cabernet> brent: this PR has nothing but approvals, and has been open for more than a week.
16:23:56 <cabernet> manu: was going to mention the comment from andres.
16:24:20 <cabernet> ... I took a shot at naming the conformance class. Right now we call it ConformingIssuerProcessor, but could make an editorial change in the future
16:24:30 <JoeAndrieu> q+ to agree
16:24:37 <cabernet> ... JoeAndrieu would like your thoughts on changing to ConformingIssuer, but expect pushback
16:24:38 <brent> ack JoeAndrieu
16:24:38 <Zakim> JoeAndrieu, you wanted to agree
16:24:44 <TallTed> i/this is true for everything/TallTed: as commented in the thread, this appears to be about the language used for URI construction, which should be considered opaque anyway. There are ways to "localize" via multiple schema:name, rdfs:label, dcterms:description, rdfs:comment, dcterms:title, etc.
16:24:59 <dlongley> +1 to "software"
16:25:10 <cabernet> JoeAndrieu: I think we need a good set of vocab to refer to these aside from roles.
16:25:24 <dlongley> is fine with "implementation"
16:25:37 <JoeAndrieu> +1 to software or implementation
16:25:40 <seabass> +1 to Mike from me
16:25:57 <dlongley> +1 to "implementation" generally over "processor".
16:26:10 <cabernet> brent: would anyone be opposed to ConformingIssuerImplementation?
16:26:39 <manu> q+
16:26:43 <cabernet> q+
16:27:14 <brent> Seems to be support for that, which Mike suggested.
16:27:26 <cabernet> andres: my interpretation is that the "should" becomes moot
16:27:41 <brent> ack manu
16:27:43 <seabass> +1 to andres from me also. I wouldn't mind making that a MUST
16:27:50 <cabernet> manu: you are correct, that needs to be struck
16:28:27 <dlongley> +1 to remove the top-level one.
16:28:33 <andres> +1 to that as well
16:28:40 <brent> +1 to remove top-level one
16:28:47 <cabernet> ... probably what we need to do here... I'm wondering if we should just remove the classes and just have ConformingIssuer and ConformingVerifier
16:28:56 <dlongley> and then leave the others alone
16:28:56 <cabernet> ... e.g., remove the top-level ones and keep the more specific ones
16:29:16 <andres> q+
16:29:22 <cabernet> manu: the reason the statement was "SHOULD" - some implementations may want to continue processing something with an error in the vc
16:29:41 <cabernet> ... "date" is a great example because we have new language in the spec saying you must produce dates with utc timestamp
16:29:52 <seabass> q+ to talk about errors in real-world (tickets)
16:30:07 <JoeAndrieu> q+ to talk about validation
16:30:08 <cabernet> ... if the date is wrong in a way that the verifier feels is recoverable, we should allow them to recover. That is why it is a "SHOULD" instead of a "MUTS"
16:30:13 <cabernet> s/MUTS/MUST/
16:30:24 <manu> scribe+
16:30:26 <brent> ack cabernet
16:31:17 <manu> cabernet requests clarity on selfissued's comment wrt. "implementation" vs. "software" vs. "processor"
16:31:33 <cabernet> selfissued: suggest we call it a conformingissuerimplementation
16:31:46 <manu> "conforming issuer implementation" <-- we'll use that.
16:32:00 <brent> ack andres
16:32:10 <manu> q+
16:32:16 <pdl-asu> pdl-asu has joined #vcwg-special
16:32:17 <cabernet> andres: wondering what the value is of introducing normative statements for those classes
16:32:23 <pdl-asu> present+
16:32:25 <manu> q+ to note why we have conformance classes.
16:32:40 <cabernet> ... seems to me that creating a label for conformance class is simply a grouping of which normative statements are correctly implemented by a specific implementation
16:32:43 <brent> q+ to respond to why normative conformance classes
16:32:49 <manu> q-
16:33:01 <cabernet> ... just wondering what the value is vs. just saying "implementation X does actually pass all normative statements that are testable"
16:33:05 <brent> ack seabass
16:33:05 <Zakim> seabass, you wanted to talk about errors in real-world (tickets)
16:33:26 <cabernet> seabass: responding to manu from earlier regarding conformance requirement where MUST is appropriate
16:33:48 <cabernet> manu: yes, specifically I'm saying the time value is corrupt, not wrong
16:34:02 <cabernet> ... for whatever reason the verifier may know they can recover
16:34:23 <cabernet> seabass: thanks, real world example: vc from phone when accessing turnstile
16:34:46 <cabernet> ... for some reason the qr is corrupted. by saing MUST in the specification, we are saying that somewhere in the system some alarm must be raised
16:34:58 <cabernet> ... what is not being said is that the turnstyle cannot open
16:35:30 <manu> q+ to note that SHOULD might be buying trouble... decreasing interop.
16:35:33 <cabernet> ... therefore I don't think it unreasonable to say the implementation should not produce errors (via MUST)
16:35:36 <selfissued> selfissued has joined #vcwg-special
16:35:36 <DavidC> q+
16:35:37 <brent> ack JoeAndrieu
16:35:38 <Zakim> JoeAndrieu, you wanted to talk about validation
16:35:38 <selfissued> present+
16:35:55 <selfissued> Mike Jones is in the IRC now
16:36:01 <cabernet> JoeAndrieu: responding to manu - we are assuming processing stops on error. I don't think that's what we are talking about
16:36:09 <cabernet> ... only that software has to rEPORT the error
16:36:30 <ivan> s/rEPORT/report
16:36:32 <brent> ack bigbluehat
16:36:33 <cabernet> ... if the verifier needs to make a business decision, that's validation. If it is something always checked, that is verification and should be a MUST
16:36:37 <brent> ack brent
16:36:37 <Zakim> brent, you wanted to respond to why normative conformance classes
16:37:07 <cabernet> brent: practically, because we had a Google rep review and say we really needed normative conformance classes. This is in response to that direct feedback.
16:37:27 <brent> ack manu
16:37:27 <Zakim> manu, you wanted to note that SHOULD might be buying trouble... decreasing interop.
16:37:50 <cabernet> manu: in addition, having conformance classes makes it clear to vendors what kind of software they are producing.
16:38:15 <cabernet> ... sometimes a customer will ask if you are conformant to a standard, and you want to say with confidence that we produce conforming issuer implementations
16:38:31 <cabernet> ... often w3c specs may talk about different sets of software and requirements
16:38:44 <andres> q+ to say that given that, I'm opposed to SHOULD.
16:38:50 <ivan> +1 to Manu
16:38:50 <cabernet> ... e.g., conforming issuer implementations, status list implementations, etc.
16:39:09 <cabernet> ... I am hearing we should just make this a MUST, and we may decrease interop if these corrupt examples are being accepted
16:39:17 <andres> q-
16:39:19 <pdl-asu> +1 to Joe's comment that this should be made "must" if it is a verification.
16:39:20 <cabernet> ... agreed we are saying must produce errors, not halt processing.
16:39:32 <seabass> +1 to manu and to use of 'MUST' here
16:39:50 <brent> ack DavidC
16:39:50 <cabernet> brent: path forward seems to be keep MUST, get rid of first tier conformance classes, and just keep IssuerImplementation and VerifierImplementation
16:40:13 <cabernet> DavidC: I agree with the MUST, but seabass' use case was slightly wrong - conflating validation and verification
16:40:23 <JoeAndrieu> +1 to validation can ignore the errors.
16:41:10 <cabernet> brent: this should be merged by end of week at the latest
16:41:17 <manu> q+
16:41:23 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1338
16:41:32 <cabernet> brent: another before CR pr related to Jeff's review
16:41:42 <brent> ack manu
16:41:43 <cabernet> ... I think the request for changes has been addressed already
16:42:07 <cabernet> manu: I would like the group to pay particular attention to this PR. It is the first time we are adding an algorithm with a set of steps into the spec
16:42:14 <cabernet> ... that is also dependent on the external specification
16:42:28 <cabernet> s/specification/securing specification/
16:42:48 <cabernet> manu: I believe we have a bead on the right levels of abstraction
16:43:08 <cabernet> ... this is also forcing us to describe what a warning or error  object looks like (I've called thes anomolies)
16:43:17 <cabernet> ... looking for bikeshedding in the PR on this naming
16:43:37 <JoeAndrieu> +1, I'll take a look
16:43:41 <ivan> q+
16:43:47 <cabernet> ... a W3C member has indicated formal objection if this was not defined this time around
16:44:22 <cabernet> brent: agreed that this addresses what was requested, and that folks should review. This has been open for six days, so review period is close to being up
16:44:30 <brent> ack ivan
16:44:55 <cabernet> ivan: in the PR, there are a number of places where there are discussions going on and it is marked as outdated - not sure what I need to be looking at.
16:45:01 <cabernet> ... can that be improved?
16:45:17 <cabernet> manu: I did not want to resolve statements until WG members had a chance to look through them
16:45:40 <cabernet> manu: whenever reviewing, always look at "files changed" to do your review, not the converstation tab
16:46:16 <cabernet> brent: just to note, the "outdated" label is specific to the code snippet, which has been changed. The conversation should still be available, and current code
16:46:20 <cabernet> ... is in the "Files changed" tab
16:46:31 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1339
16:46:57 <cabernet> brent: Benjamin, can you give status update?
16:47:25 <manu> q+
16:47:25 <cabernet> benjamin: this one got good feedback from addison, and there is a suggestion about requiring language definition, which would be a major change for everybody
16:47:36 <brent> ack manu
16:47:37 <cabernet> .. that is the piece that needs discussion - otherwise approvals throughout
16:47:59 <cabernet> manu: my one concern is that there are two ways to specify
16:48:18 <JoeAndrieu> q+ to say MUST is likely unattainable
16:48:38 <cabernet> ... best way is to be precise. The other way is @language and @direction in the @context which will set it blanket for the entire doc
16:48:55 <bigbluehat> q+ to note nothing else does that
16:48:59 <cabernet> ... both of Benjamin's PRs say use one or the other, up to you. Addison is saying no to that.
16:49:23 <cabernet> ... question to group: do we want to mandate saying you MUST set the @language for every type of VC that you issue/
16:49:35 <cabernet> s#/#?#
16:49:41 <dlongley> IMO, you can't force people to do the right thing here -- you will just get bad language data (e.g., English as the default language, but the content will be in another language)
16:49:53 <brent> ack JoeAndrieu
16:49:53 <Zakim> JoeAndrieu, you wanted to say MUST is likely unattainable
16:50:15 <dlongley> +1 to Joe, MUST is aspirational that won't be attained
16:50:26 <cabernet> JoeAndrieu: I think MUST is something we probably would not be able to realize, and would lead to lots of non-conforming implementations and ignoring on the front-end
16:50:37 <cabernet> ... agree it should be there, just don't think MUST is feasible
16:50:38 <brent> ack bigbluehat
16:50:38 <Zakim> bigbluehat, you wanted to note nothing else does that
16:50:39 <seabass> q+
16:51:10 <brent> ack seabass
16:51:10 <cabernet> benjamin: +1 to what was said, HTML, JSON, JS don't do this. Providing language as a capability is good, requiring it is a "bridge too far"
16:51:23 <cabernet> seabass: as we are releasing 2.0 to the world, this is the best time to promote language support
16:51:31 <TallTed> q+
16:51:41 <cabernet> ... maybe people are right, but this is probably the best time to try and support making this a mUST
16:51:46 <cabernet> s/mUST/MUST
16:51:46 <brent> ack TallTed
16:51:49 <dlongley> q+ to say the argument is: a MUST will hurt more than help.
16:52:00 <cabernet> TallTed: making this a MUST means derivative certs are not doable
16:52:15 <cabernet> ... SHOULD is almost a MUST, e.g., do it unless you have a good reason not to
16:52:35 <brent> ack dlongley
16:52:35 <Zakim> dlongley, you wanted to say the argument is: a MUST will hurt more than help.
16:52:35 <cabernet> ... VCs are not the path to force I18N on the world
16:52:57 <cabernet> dlongly: agree with TallTed, this will hurt more than help, and we can't force people to do this
16:53:05 <seabass> q+ to ask what difficulties are expected
16:53:20 <brent> ack seabass
16:53:20 <Zakim> seabass, you wanted to ask what difficulties are expected
16:53:39 <cabernet> seabass: question - where are the difficulties expected to be here?
16:53:58 <cabernet> ... I know what language I am using, so it seems easy. Can someone explain where the pain points are here?
16:54:11 <cabernet> brent: encourage folks to respond to seabass in the PR
16:54:16 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1344https://github.com/w3c/vc-data-model/pull/1344
16:54:19 <manu> q+
16:54:28 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1344
16:54:42 <cabernet> brent: this PR is broadly approved with no unresolved change requests
16:54:49 <brent> ack manu
16:54:51 <cabernet> ... we are going to merge in a couple of days
16:55:16 <cabernet> manu: heads up to the group, this is also significant. When you express a time value in any VC, you should express it as a date timestamp formatted value.
16:55:42 <cabernet> ... anyone verifying, if they do not see a relative UTC offset, has to interpret it as UTC.
16:55:50 <JoeAndrieu> q+ to limit this to explicit properties
16:56:02 <cabernet> ... this means you cannot express (should not express) a date that does not have a timezone offset at the end of it for any time value in a VC
16:56:05 <brent> ack JoeAndrieu
16:56:05 <Zakim> JoeAndrieu, you wanted to limit this to explicit properties
16:56:32 <manu> q+
16:56:36 <cabernet> JoeAndrieu: also commentd in github - would like to see this scoped to just the properties we are defining in the VCDM. Don't want to see this on custom properties, or
16:56:38 <brent> ack manu
16:57:01 <cabernet> manu: that is the intention. we are trying to increase interop.
16:57:44 <cabernet> brent: let's continue the conversation on the PR.
16:58:04 <cabernet> ... please be aware of and review other PRs that we didn't get a chance to review today
16:58:17 <ivan> rrsagent, draft minutes
16:58:18 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/14-vcwg-special-minutes.html ivan
16:59:21 <ivan> rrsagent, bye
16:59:21 <RRSAgent> I see no action items