14:50:38 <RRSAgent> RRSAgent has joined #vcwg
14:50:43 <RRSAgent> logging to https://www.w3.org/2023/09/06-vcwg-irc
14:50:43 <Zakim> RRSAgent, make logs Public
14:51:14 <Zakim> please title this meeting ("meeting: ..."), ivan
14:51:15 <ivan> Meeting: Verifiable Credentials Working Group Telco
14:51:15 <ivan> Date: 2023-09-06
14:51:15 <ivan> Agenda: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20230906T110000/
14:51:15 <ivan> chair: brent
14:51:15 <ivan> ivan has changed the topic to: Meeting Agenda 2023-09-06: https://www.w3.org/events/meetings/ae05a21b-c065-4e69-8d5e-352a0d391513/20230906T110000/
14:58:08 <ivan> present+
14:58:16 <brent> brent has joined #vcwg
14:58:46 <ivan> present+ brent
15:00:47 <ivan> present+ seabass
15:01:37 <GregB> GregB has joined #vcwg
15:01:43 <GregB> present+
15:01:46 <bumblefudge_> bumblefudge_ has joined #vcwg
15:01:47 <ivan> present+ gregb, manu
15:02:04 <ivan> present+ bumblefudge, TallTed
15:02:27 <decentralgabe> decentralgabe has joined #vcwg
15:02:30 <decentralgabe> present+
15:02:42 <przemek> przemek has joined #vcwg
15:02:56 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:03:16 <JoeAndrieu> present+
15:03:45 <ivan> present+ Przemek
15:03:45 <ivan> present+ dlongley
15:03:48 <seabass> brent: you have no audio?
15:04:12 <ivan> present+ JoeAndrieu
15:04:27 <bumblefudge_> i scribe
15:04:32 <bumblefudge_> scribe ++
15:04:39 <bumblefudge_> present+
15:04:44 <bumblefudge_> scribe+
15:04:59 <ivan> present+ orie
15:05:04 <TallTed> s/scribe ++//
15:05:19 <brent> https://docs.google.com/spreadsheets/d/1OXEEkZ-ffd4PBdGVJ2c0vjfcnqoGXeOO0RvC5eMEx7M/edit#gid=179611341
15:05:27 <DavidC> DavidC has joined #vcwg
15:06:07 <bumblefudge_> topic: TPAC in sevilla
15:06:22 <bumblefudge_> brent: still accepting last-minute agenda requests from the group
15:06:40 <ivan> present+ davidc
15:06:53 <bumblefudge_> ... spreadsheet above to register attendance in-person and/or virtual
15:07:18 <ivan> present+ selfissued
15:07:25 <brent> Topic: Work Item status updates/PRs
15:07:52 <manu> q+
15:08:07 <brent> ack manu
15:08:18 <bumblefudge_> manu: statuslist work item update: would like to discuss at TPAC, hoping to iterate slightly to facilitate that
15:09:06 <bumblefudge_> ... big question is whether to allow multiple formats/legacy format. single bitstring version versus multiple bitstring version
15:09:36 <bumblefudge_> ... the two designs have different privacy properties and there may be usecases for each
15:09:47 <brent> q+
15:09:56 <brent> ack brent
15:10:11 <bumblefudge_> ... so the question is whether both are optional, or one is an optional extension or legacy version of the other... tradeoff may be time to recommendation
15:10:31 <manu> q+
15:10:37 <brent> ack manu
15:10:41 <bumblefudge_> brent: multiple versions sounds good, if different use-cases can be defined
15:11:07 <pl-asu> pl-asu has joined #vcwg
15:11:44 <bumblefudge_> selfissued: are the two versions so different aside from length of bits?
15:11:44 <bumblefudge_> manu: review the PR, the differences are substantial
15:11:44 <bumblefudge_> selfissued: such as?
15:12:15 <bumblefudge_> manu: TTL, different privacy attack surface... i can summarize in an issue if that would help
15:12:30 <oliver> oliver has joined #vcwg
15:12:31 <oliver> present+
15:12:36 <bumblefudge_> selfissued: I would object to complexity or optionality here, strong preference for minimizing the delta
15:13:01 <Orie_> Orie_ has joined #vcwg
15:13:02 <Orie_> present+
15:13:05 <bumblefudge_> selfissued: I would like to close the PR adding multibase to Jose/Cose
15:13:09 <Orie_> Sounds like adding security considerations is probably a safe thing to do though (re status list concerns)
15:13:11 <decentralgabe> q+ test suite / cr question
15:13:15 <Orie_> q+
15:13:16 <seabass> q+ 1254
15:13:20 <ivan> present+ pdl-asu
15:13:24 <brent> subtopic: https://github.com/w3c/vc-jose-cose/pull/144
15:13:27 <seabass> q- 1254
15:13:36 <manu> q- test
15:13:38 <steele> steele has joined #vcwg
15:13:39 <manu> q- suite
15:13:42 <manu> q- /
15:13:44 <manu> q- cr
15:13:46 <seabass> q+ to discuss 1254
15:13:46 <manu> q- question
15:13:51 <bumblefudge_> selfissued: jose and cose already have native key formats, I don't see why other key formats should be allowed
15:14:26 <bumblefudge_> decentralgabe: clarification of CR requirements
15:14:38 <ivan> present+ dlehn
15:14:38 <brent> ack Orie_
15:14:42 <pl_asu> pl_asu has joined #vcwg
15:14:49 <pl_asu> present+
15:15:05 <Orie_> https://w3c.github.io/vc-jose-cose/#key-discovery
15:15:05 <bumblefudge_> orie: provide clarity for vc-jose-cose#144 - intention was to close as many red issues quickly
15:15:34 <bumblefudge_> ... as possible. see link
15:15:46 <kristina> kristina has joined #vcwg
15:15:57 <kristina_> kristina_ has joined #vcwg
15:15:59 <kristina_> present+
15:16:03 <bumblefudge_> ... discovery of keys is a topic that covers many of these, in particular around `controller` documents
15:16:32 <bumblefudge_> ... as we have been discussing this, a normative reference to the data integrity spec was rejected, so we opted to paste in some relevant text from there
15:16:52 <steele> present+ nsteele
15:17:44 <bumblefudge_> ... ; I opened this PR because I feel that minimizing external concepts and being as silent as possible on DIDs leaves a gap in the implementability around key discovery
15:18:18 <ivan> s/... ; I/.../
15:18:42 <brent> q?
15:19:53 <bumblefudge_> ... In the interest of timeliness, I would like to know as soon as possible what is acceptible to the group
15:20:04 <bumblefudge_> selfissued: I believe that nothing involving multibase will be acceptible to the group
15:20:15 <brent> ack seabass
15:20:15 <Zakim> seabass, you wanted to discuss 1254
15:20:34 <selfissued> selfissued has joined #vcwg
15:20:39 <bumblefudge_> topic: localization and #1254
15:20:47 <selfissued> present+
15:20:59 <ivan> s/topic: localization and #1254//
15:21:53 <bumblefudge_> brent: Orie has requested that this PR be moved forward with concrete suggestions, re: multibase and/or otherwise
15:22:13 <brent> topic: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+-label%3Abefore-CR+-label%3Apost-CR
15:22:22 <brent> topic: IUssue Triage
15:22:33 <brent> topic: Issue Triage
15:23:04 <TallTed> s|topic: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+-label%3Abefore-CR+-label%3Apost-CR||
15:23:11 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1267
15:23:13 <TallTed> s/topic: IUssue Triage//
15:23:38 <bumblefudge_> brent: oliver, can you walk us through #1267 and why it should be pre- or post-CR
15:24:27 <bumblefudge_> awoie: This issue resulted from ping group review, and a clarification or addition to security considerations would probably cover it, I believe
15:24:27 <seabass> q+
15:24:53 <manu> q+
15:25:01 <bumblefudge_> ... I can't think of any normative changes that this would necessitate, and I don't have strong opinion on pre- versus post
15:25:04 <brent> ack seabass
15:25:15 <bumblefudge_> brent: if non-normative, post- should be fine
15:25:21 <DavidC> present+
15:25:38 <bumblefudge_> seabass: OHTTP hasn't cleared IETF yet, so even if we wanted to add a normative reference we can't yet
15:25:38 <brent> ack manu
15:25:40 <kristina_> http has not been published by ietf yet!?
15:25:47 <dlongley> ohttp
15:25:52 <manu> https://w3c.github.io/vc-data-integrity/#fingerprinting-network-requests
15:25:56 <seabass> 'oblivious' HTTP
15:26:09 <oliver> +1 manu
15:26:19 <bumblefudge_> manu: the precedent is in the link i've just shared
15:26:21 <dlongley> https://datatracker.ietf.org/doc/draft-ietf-ohai-ohttp/10/
15:26:48 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1263
15:26:50 <bumblefudge_> seabass: I can take this issue and add a note post-CR
15:27:12 <ivan> q+
15:27:38 <brent> ack ivan
15:28:04 <bumblefudge_> ivan: I would argue this issue (1263) should be pre-CR
15:28:33 <TallTed> q+
15:28:44 <bumblefudge_> ... diagram and vocabulary should reflect what's in the normative spec text; nowhere in the spec does it specify that these can be used in VPs
15:28:52 <Orie_> The vocab does not perfectly reflect the spec for abstract classes and domain and ranges... thats part of the challenge.
15:29:02 <brent> ack TallTed
15:29:07 <bumblefudge_> ... if there is a desire to include these in the vocabulary or the diagram, we can do that, but only if the relevant spec text changes pre-CR
15:29:16 <Orie_> q+
15:29:41 <bumblefudge_> TallTed: I understand the normative text is upstream of the diagram, but the diagram is consequential and without it I would not have noticed this VC/VP delta
15:29:53 <seabass> +1 TallTed (IRC) to importance of diagram to be correct and available
15:30:03 <Orie_> +1 TallTed
15:30:04 <bumblefudge_> ... I think these discrepancies deserve attention
15:30:08 <brent> ack Orie_
15:30:34 <ivan> q+
15:30:40 <bumblefudge_> orie: There is another example where vocab, diagram and text seem misaligned: abstract categories
15:31:06 <bumblefudge_> s/categories/classes/
15:31:37 <manu> q+ to agree to have abstract classes in spec defined (for those that want to do RDF)
15:31:42 <bumblefudge_> orie: abstract class for CredentialSchema types are, for example, very important in the work items around JSONSchema
15:31:56 <brent> ack ivan
15:32:12 <bumblefudge_> ... so I support clarifying this and making it more explicit pre-CR
15:32:20 <bumblefudge_> ivan: I volunteer to be assigned this issue
15:32:38 <bumblefudge_> ... and as a sidenote, I want to briefly summarize what Orie means by abstract classes
15:33:35 <Orie_> if you don't like RDF just think of the abstract classes and Interfaces in TypeScript : )
15:33:41 <brent> ack manu
15:33:41 <Zakim> manu, you wanted to agree to have abstract classes in spec defined (for those that want to do RDF)
15:34:05 <Orie_> FWIW, I think the classes should be in the spec, or removed from the vocab, since its confusing if they only appear in vocab.
15:34:12 <dlongley> +1 yes, the VCDM just uses a simple object / class-based modeling constraint to express information as opposed to "anything goes"
15:34:14 <bumblefudge_> ... abstract classes allow properties to be inherited by subtypes, this is a powerful tool
15:34:26 <dlongley> which happens to map cleanly to RDF statements of subject -> property -> value
15:34:29 <bumblefudge_> ... (scribe struggles to summarize)
15:35:08 <brent> Topic: Issue Discussion
15:35:18 <manu> We should have a section in the specification that defines the abstract classes for those that care about RDF, that'll close that loop, I'm not hearing any objections to that path.
15:35:23 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1254
15:35:32 <manu> q+
15:36:05 <brent> ack manu
15:36:15 <bumblefudge_> seabass: this one is going well and almost done, maybe today, will move on to the other issue assigned to me soon
15:36:58 <bumblefudge_> manu: my one thought on 1254 is that internationalization guidance (w3c-wide) is being updated lately, and i don't know if you want that in your PR or in a separate one
15:38:04 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1264
15:38:12 <bumblefudge_> seabass: actually I think the PR was only mentioning `@language` in reference to security of LD documents
15:38:17 <manu> Great, that sounds like it's not an issue then, Sebastian! :)
15:38:22 <manu> q+ to speak to 1264
15:38:23 <bumblefudge_> ... so not related I don't think
15:38:26 <brent> ack manu
15:38:26 <Zakim> manu, you wanted to speak to 1264
15:38:28 <bumblefudge_> subtopic: https://github.com/w3c/vc-data-model/issues/1264
15:39:19 <selfissued> selfissued has joined #vcwg
15:39:27 <bumblefudge_> manu: in w3c i18n review, github user aphillips who is in this issue has been trying to align our spec with recent w3c i18n guidance
15:40:08 <bumblefudge_> ... specifically around `@language` annotations in credentials and documents
15:40:21 <Orie_> q+ to ask for us to add a note telling people to not use the feature, for reasons stated.
15:40:36 <bumblefudge_> ... which I don't think many implementers have been following, at great peril for i18nal machine-readability
15:41:09 <seabass> q+
15:41:16 <bumblefudge_> ... I don't think there's a standard way to use this feature in standard-tooling JSON, and I don't think many implementers are using it in JSON-LD
15:41:45 <bumblefudge_> ... so the concern here is that cross-processing as outlined in the spec (reading JSON-LD as JSON) could be hindered with little tradeoff if no one's using it
15:42:17 <bumblefudge_> ... so my questions are 1.) would the group object to describing this as a recommended way of doing i18n
15:42:28 <ivan> present+ bigbluehat
15:42:43 <bumblefudge_> ... and also 2.) would the group object to that description warning implementers about the base64 footgun this presents to cross-processing
15:42:50 <brent> ack Orie_
15:42:50 <Zakim> Orie_, you wanted to ask for us to add a note telling people to not use the feature, for reasons stated.
15:43:19 <manu> q+ to clarify "not recommending it"
15:43:34 <bumblefudge_> orie: thanks for that explanation. do i understand correctly that this is being removed in v2?
15:43:51 <bumblefudge_> ... i would prefer we took a strong position that we are discouraging it if no one implemented it after we recommended it in v1
15:44:11 <bumblefudge_> ... i think it's worth mentioning that it was in v1 and not in v2, if not also an explanation of why
15:44:26 <brent> ack seabass
15:44:31 <bumblefudge_> ... ideally something that makes the recommendation simple, because too much detail can overwhelm confused implementers
15:45:38 <bumblefudge_> seabass: I would actually argue that i18n is very important here, and I think putting the `@language` inline might confuse JSON parsers less than annotating from `@Context`
15:46:04 <brent> ack manu
15:46:04 <Zakim> manu, you wanted to clarify "not recommending it"
15:46:51 <Orie_> +1 to being clear... lets not give many options, lets give a single clear recommendation.
15:47:01 <bumblefudge_> manu: that is an option, but Orie's point on a clear and rationaled default recommendation should be taken seriously here
15:47:17 <Orie_> wrong ~= re recommended something that people are not using.
15:47:28 <Orie_> s/re/we/
15:47:57 <bumblefudge_> ... and I wouldn't characterize this as having recommended A in v1 and recommending not-A now, it's more like I think we have insufficient feedback from implementers
15:47:57 <seabass> q+
15:48:07 <bumblefudge_> ... and I would appreciate feedback
15:48:17 <TallTed> 1. record erratum (really, bug) on v1; 2. explain in v2 why changed from v1, why NOT to do that thing we thought was a good idea before we had experience to date; 3. push I18n WG to produce some kind of whitepaper for all SDOs to refer to (because it seems like non-W3C orgs may not be doing such a great job with I18n, and *everybody* needs *every* SDO to do better with I18n)
15:48:42 <Orie_> i'd be ok outlining many paths forward, and then picking one.
15:48:46 <bumblefudge_> ... since I feel like the v1 text was a compromise solution without a clear enough recommendation or rationale
15:49:05 <brent> q?
15:49:09 <brent> ack seabass
15:49:20 <bumblefudge_> ... which would take some time to create in v2, i.e. writing up multiple options and considering their pros and cons
15:49:27 <Orie_> we should say UTS-46 / WHATWG URL for i18n.
15:49:59 <bumblefudge_> seabass: I am more bullish on timeline because I do not think we have that many options to weigh or people defending each
15:50:07 <bumblefudge_> ... would consensus on this call be possible?
15:50:12 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc
15:50:27 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1240
15:50:34 <manu> q+
15:50:49 <brent> ack manu
15:51:04 <bumblefudge_> manu: I am on the hook for this PR
15:51:07 <Orie_> +1 Manu, its also related to the vocab vs spec.
15:51:23 <manu> yep ^
15:51:29 <bumblefudge_> ... which I am ready to work on, given the prior discussion about vocab vs spec
15:51:36 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1247
15:52:13 <bumblefudge_> seabass: status update: I am going to work on it in the next few days
15:52:32 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1185
15:52:39 <manu> q+
15:52:44 <brent> ack manu
15:53:05 <Orie_> q+
15:53:47 <brent> ack Orie_
15:53:49 <bumblefudge_> manu: oops new comments inthread, will PR soon
15:54:41 <bumblefudge_> orie: related to your last comment on processing the data model in JSON-LD, I think a quick sentence or two would be enough. i'll propose inthread
15:54:47 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1264
15:54:59 <bumblefudge_> brent: sebastian has a resolution proposal
15:55:40 <JoeAndrieu> q+
15:55:40 <bumblefudge_> ... call for refinements or changes before they go into the minutes?
15:55:48 <ivan> q+
15:55:50 <Orie_> q+
15:55:54 <brent> ack JoeAndrieu
15:56:22 <brent> ack ivan
15:56:32 <bumblefudge_> joeandrieu: I would change `support` to `specify` or `include` -- an additional/supplemental context file should be able to include it or apply it
15:56:35 <manu> q+
15:56:47 <seabass> q+ from me to JoeAndrieu (IRC) and ivan (IRC)
15:56:54 <seabass> +1 that is
15:56:58 <bumblefudge_> ivan: nit: not just language but language directionality was mentioned in the issue, and not here in the proposal
15:57:03 <brent> ack Orie_
15:57:39 <JoeAndrieu> +1 to that advice from Orie
15:57:48 <manu> yes, +1 to what Orie is saying.
15:57:53 <seabass> +1
15:57:55 <bumblefudge_> orie: I would have expected the recommendation to be bipartite: not in core context, and how/if/whether to use in additional contexts
15:58:00 <manu> @language is a sledgehammer that shouldn't be used for VCs.
15:58:09 <manu> (when expressed in the base context)
15:58:16 <bumblefudge_> ... or, as I thought i heard, that the recommendation was not to use it in either
15:59:03 <seabass> +1
15:59:16 <JoeAndrieu> q+
15:59:16 <Orie_> q+
15:59:22 <brent> ack manu
15:59:27 <bumblefudge_> brent: dlongley and orie have variations in the irc
15:59:28 <Orie_> q-
15:59:33 <bumblefudge_> .. that overlap considerably
15:59:35 <manu> https://w3c.github.io/vc-data-model/#language-and-base-direction
15:59:54 <TallTed> this is so dangerous to decide without LOTS of evidence. see https://www.w3.org/International/articles/strings-and-bidi/
15:59:57 <bumblefudge_> manu: I think we need more time, there is already guidance in the link i just shared, and what orie is calling the second part is what's missing
15:59:58 <Orie_> I'd be good with dlongley's proposal
16:00:08 <brent> ack JoeAndrieu
16:00:14 <bumblefudge_> ...and i worry that even that would not fulfill the i18n peoples' request
16:00:24 <Orie_> its an improvement over what we have now, its not sufficient.
16:00:31 <manu> yes ^
16:00:35 <dlongley> notes we could also require all encoded values use type multibase to enable language in the context, but that is very unlikely to get consensus
16:00:43 <TallTed> also see https://www.w3.org/TR/string-meta/
16:00:44 <bumblefudge_> joeandrieu: I think it might be reductive to say it should never be used in `@context`s, there are places even in VC were it might make sense
16:00:58 <ivan> rrsagent, draft minutes
16:00:59 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/06-vcwg-minutes.html ivan
16:01:38 <bumblefudge_> ivan!
16:02:05 <ivan> zakim, end meeting
16:02:05 <Zakim> As of this point the attendees have been ivan, brent, seabass, GregB, manu, bumblefudge, TallTed, decentralgabe, JoeAndrieu, Przemek, dlongley, bumblefudge_, orie, davidc,
16:02:08 <Zakim> ... selfissued, oliver, Orie_, pdl-asu, dlehn, pl_asu, kristina_, nsteele, bigbluehat
16:02:08 <Zakim> RRSAgent, please draft minutes
16:02:10 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/06-vcwg-minutes.html Zakim
16:02:16 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:02:16 <ivan> rrsagent, bye
16:02:16 <RRSAgent> I see no action items
16:02:16 <Zakim> Zakim has left #vcwg