18:52:34 <RRSAgent> RRSAgent has joined #vcwg
18:52:38 <RRSAgent> logging to https://www.w3.org/2023/10/25-vcwg-irc
18:53:22 <brent> brent has changed the topic to: Meeting Agenda 2023-10-25: https://www.google.com/url?q=https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20231025T150000
18:53:35 <brent> brent has changed the topic to: Meeting Agenda 2023-10-25: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20231025T150000
18:53:48 <brent> zakim, start the meeting
18:53:48 <Zakim> RRSAgent, make logs Public
18:53:50 <Zakim> please title this meeting ("meeting: ..."), brent
18:54:14 <brent> meeting: Verifiable Credentials Working Group Weekly Teleconference
18:54:21 <brent> chair: Brent Zundel
18:54:33 <brent> agenda: https://www.w3.org/events/meetings/36ecd2da-2ec3-4012-b74a-72546ab352f4/20231025T150000
18:59:04 <pauld_gs1> pauld_gs1 has joined #vcwg
18:59:09 <pauld_gs1> present+
19:01:24 <brent> present+
19:01:33 <brent> present+ shigeya
19:01:47 <brent> present+ manu
19:02:04 <dmitriz> dmitriz has joined #vcwg
19:02:07 <dmitriz> present+
19:02:19 <brent> present+ bigbluehat
19:02:33 <JoeAndrieu_> JoeAndrieu_ has joined #vcwg
19:03:23 <brent> present+ JoeAndrieu_
19:03:25 <selfissued> selfissued has joined #vcwg
19:03:28 <selfissued> present+
19:03:38 <andres> andres has joined #vcwg
19:03:48 <andres> present+
19:04:05 <dmitriz> scribe+
19:04:28 <dmitriz> brent: welcome everyone
19:04:28 <TallTed> TallTed has joined #vcwg
19:04:40 <dmitriz> brent: our agenda is straightforward - wwe'll have a brief section on work item status updates
19:04:48 <dmitriz> ... review pertinent PRs, then move into discussion of issues
19:04:54 <dmitriz> ... primary issue being 1307
19:05:05 <dmitriz> ... after that, will move to other 'Before CR' issues we need to address
19:05:14 <dmitriz> ... anyone who would like changes to the agenda?
19:05:42 <dlongley> present+
19:05:58 <brent> Topic: Work Item status updates/PRs
19:06:04 <manu> q+
19:06:20 <dmitriz> brent: Looking for brief status updates for each work item
19:06:25 <brent> ack manu
19:06:26 <dmitriz> ... Manu, you're first up
19:06:31 <manu> https://github.com/w3c/vc-data-model/pulls
19:06:32 <dmitriz> manu: I'll run through these really quickkly.
19:06:46 <dmitriz> ... this is VC Data Model. there are 6 PRs that are newly opened over the last week
19:07:08 <dmitriz> ... one of them is on adding a def'n for well-formedness. One is on suggesting the use of oblivious HTTP, one about adding a section on key management
19:07:30 <TallTed> present+
19:07:31 <dmitriz> ... other is Trust Boundaries & Considerations, another on JWTs [something], and the last is about explanation of use of graphs in VC DM
19:07:59 <dmitriz> ... I'll also note that previous PRs marked 'Pending Close' have expired, so, we should close them (Brent)
19:08:20 <dmitriz> brent: 2 of the Pending Closes are PRs waiting on companion PRs. and 2 have expired, will close
19:08:27 <dmitriz> manu: got it
19:08:33 <Orie> Orie has joined #vcwg
19:08:36 <Orie> present+
19:08:37 <manu> https://github.com/w3c/vc-data-integrity/pulls
19:08:38 <dmitriz> ... moving on to Data Integrity
19:08:52 <dmitriz> ... here are the DI PRs, one is a 'During CR', other is the 'At Risk' marker for Controller Doc
19:09:03 <dmitriz> ... which we discussed yesterday. it's in PR Ready draft, will be merged in 2 days
19:09:15 <dmitriz> ... there are no active open PRs for ECDSA suite, also none for EDDSA
19:09:21 <dmitriz> ... all the issues are Post-CR
19:09:29 <manu> https://github.com/w3c/vc-bitstring-status-list/pulls
19:09:38 <dmitriz> ... moving on to Status List. No open PRs for this, I've done the rename for the spec
19:09:46 <dmitriz> ... and I think we picked the wrong name :)
19:10:02 <dmitriz> ... don't want to bikeshed today, but a bunch of different status methods use bitstrings
19:10:19 <dmitriz> ... we should pickk something else like 'Herd Privacy Status List' or similar (not for discuss today)
19:10:32 <dmitriz> ... we might want to call out what this Status List is going to do
19:10:34 <manu> https://github.com/w3c/vc-bitstring-status-list/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR
19:10:43 <dmitriz> ... there's a number (30) of Before CR issues that need to be processed
19:10:53 <dmitriz> ... and 8 of those are ready for PR, so expect updates & changes there over the coming weeks
19:11:00 <dmitriz> ... that's it for me
19:11:04 <brent> q?
19:11:12 <selfissued> q+
19:11:16 <brent> ack selfissued
19:11:29 <dmitriz> selfissued: I can talk to the VC JOSE/COSE
19:11:33 <dlehn> present+
19:11:40 <dmitriz> ... there is one editorial PR by TallTed,
19:11:48 <dmitriz> ... two editors believe it's ready to merge (strictly typo corrections)
19:11:56 <dmitriz> ... there are only 2 Before CR issues remaining
19:12:06 <dmitriz> ... one requires some language cleanup about using registered JWT claims in JOSE header
19:12:22 <dmitriz> ... the other is about Controller Documents, which we'll have discussion about
19:12:27 <dmitriz> ... so those are the two main things for CR
19:12:42 <dmitriz> brent: we're ready to move forward to next topic
19:12:46 <brent> Topic: Issue Discussion
19:12:58 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1307
19:13:03 <dmitriz> ... We'll begin with the continuation of the topic of our special topic call, which was Controller Doc
19:13:11 <dmitriz> ... there were a number of proposals that were brought before the group
19:13:19 <dmitriz> ... 3 of them were resolved
19:13:29 <dmitriz> ... check email / notes
19:13:52 <dmitriz> ... there are 4 more proposals that have been brought up, 3 of them concerning the same thing, and one I'm very confident won't pass even after long convo
19:13:59 <dmitriz> ... the focus will be around Key Discovery
19:14:19 <dmitriz> ... specifically, discovery using '.well-known/'
19:14:19 <dmitriz> ... one of the proposals says 'Shared doc will NOT use key discovery'
19:14:29 <dmitriz> ... the other one says, maybe we should do key discovery using .well-known
19:14:37 <selfissued> q+
19:14:47 <dmitriz> ... would it be amenable to the group for the primary doc to do .well-known as primary mechanism
19:14:49 <dlongley> q+ to say that we might get more support for things if we can agree that the controller document has multiple options for any other spec to reference, even if those specs profile those things down
19:14:54 <dmitriz> ... if there's consensus, we'll run a proposal
19:14:54 <dmitriz> q+
19:14:57 <brent> ack selfissued
19:15:12 <dmitriz> selfissued: it makes sense to include that, it's a standards based key representation used in practice
19:15:19 <manu> scribe+
19:15:19 <dmitriz> ... so it makes sense to make it available to both securing specs.
19:15:23 <brent> ack dlongley
19:15:23 <Zakim> dlongley, you wanted to say that we might get more support for things if we can agree that the controller document has multiple options for any other spec to reference, even if
19:15:27 <Zakim> ... those specs profile those things down
19:15:34 <dmitriz> dlongley: so, thinkking about our  call yesterday and the resolutions,
19:15:43 <dmitriz> ... and was thinking forward to how some securing specs might want to profile down
19:15:57 <dmitriz> ... as we agreed in the last resolution, and other specs might want to keep those options open
19:16:06 <dmitriz> ... given that, it only makes sense for the shared doc to provide multiple options
19:16:21 <dmitriz> ... I think that's were some of us were thinkking when we were talking about things in common.
19:16:43 <dmitriz> ... we might get more consensus on things like .well-known, if we agree that shared doc has things in it that may or may not be referenced by secured implementations
19:17:02 <dmitriz> ... if we're ONLY going to put things into the shared doc that current specs reference, that'll show preference for options where it's not needed
19:17:09 <Orie> Seems like showing preference for things that both specs use, would be good for implementers.
19:17:18 <dmitriz> ... I'm concerned we'll end up making different decisions on that basis, stripping down the shared document
19:17:25 <dmitriz> ... as a result, we might need to have multiple shared documents
19:17:28 <manu> ^ not when that preference doesn't exist, Orie.
19:17:48 <dmitriz> ... might be better for us that the shared doc has things that securing specs MAY reference
19:18:19 <dmitriz> ... that way, we can more likely get to a consensus on something like .well-known (given concerns of preference)
19:18:27 <manu> To say that the Data Integrity specs "prefer JWK" is not correct, it's provided as an option.
19:18:32 <dmitriz> brent: just to repeat, we have one suggestion from Mike that .well-known be included
19:18:53 <dmitriz> ... Dave is suggesting additionally that the core Controller Doc spec be inclusive of not just .well-known but other securing mechanisms / discovery mechanisms
19:19:06 <dmitriz> ... so that specs like VC J/C and DI can choose among the options there as a profile
19:19:11 <dmitriz> dlongley: yes, that's great
19:19:24 <dmitriz> ... if we do that generally, across all of our options, we'll have a much easier time to come to consensus
19:19:32 <brent> ack dmitriz
19:19:32 <selfissued> q+
19:20:00 <tzviya> tzviya has joined #vcwg
19:20:06 <Kristina> Kristina has joined #vcwg
19:20:26 <JoeAndrieu_>  q+ to oppose .well-known in the shared document as it relies on a centralized namespace
19:20:27 <manu> dmitriz: As a data point, about the .well-known mechanism, based on some recent VC implementations, there are a number of institutions like universities that are not allowed to create folders with dots in them. There are education institutions that can't put their keys in .well-known due to their web control panels and whatnot. It's useful, but not everyone can use it.
19:20:28 <Kristina> present+
19:20:31 <brent> ack selfissued
19:20:35 <dmitriz> selfissued: two responses
19:20:54 <dmitriz> .. first to Dmitri - I certainly believe you, but if they can't use .well-known, they can't produce OAuth metadata, just a bunch of things they can't do
19:21:09 <dmitriz> ... I feel for the people in those environments, but that may be not our problem to solve
19:21:14 <dmitriz> ... I appreciate Dave's thoughtful remarks
19:21:29 <dmitriz> ... my intent is to only have things in the shared controller doc that will be used for /both/ securing specs
19:21:31 <Orie> Good thing did:web allows you to but controller documents at arbitrary locations...
19:21:44 <manu> q+ to agree with selfissued (gasp)
19:21:49 <dmitriz> ... if it lets us move forward, I'd hold my nose and accept some things that were not used by both, as long as the securing specs could profile it to say 'don't use this part'
19:21:50 <brent> ack JoeAndrieu_
19:21:50 <Zakim> JoeAndrieu_, you wanted to oppose .well-known in the shared document as it relies on a centralized namespace
19:21:58 <dlongley> +1 to Mike, document everything in the shared spec and then profile down, that can get us to consensus
19:22:06 <dmitriz> JoeAndrieu_ I'm not a fan of .well-known because it's anchored in a centralized resource/url
19:22:32 <dmitriz> ... and I don't think that it applies to all our situations. I don't see VCs as a subset of the modern web, I see them as larger
19:22:52 <dmitriz> brent: just to clarify, are you opposed to .well-known included at all, or to it being the /only/ mechanism
19:23:00 <dmitriz> JoeAndrieu_: at all
19:23:06 <brent> ack manu
19:23:06 <Zakim> manu, you wanted to agree with selfissued (gasp)
19:23:12 <dlongley> i can hold my nose if everything (key formats, etc.) is in the shared doc and secured specs can profile down.
19:23:22 <dlongley> s/secured/securing/
19:23:33 <dmitriz> manu: I wanted to agree with what Dave was saying, and what Mike Jones just said. it would be fine to include a number of things in the controller doc, put them in a single document
19:23:42 <dlongley> +1 to Manu
19:23:47 <dmitriz> ... and when you go to profile, you can say 'Do not use X or Y, we don't want you doing that' -- that's perfectly fine
19:24:04 <dmitriz> ... we'd provide all the options in the controller doc spec, and then securing specs will profile them
19:24:19 <dmitriz> ... that feels like a good compromise, people who don't want to use features can call them out
19:24:22 <Kristina> This is what SD-JWT VC spec does. It mentions multiple mechanisms: .well-known, DID, x.509, etc. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-01#name-obtaining-public-key-for-is .
19:24:22 <dlongley> +1 to a resolution that says we provide all the "controller-document-related options" in the shared controller doc spec and then each securing spec profiles that down to what they accept.
19:24:30 <Orie> +1 Manu, although i still hope we can limit the controller document options to "good ones", if we can't agree on what good is, its ok to just split the difference.
19:24:37 <Kristina> And I think we should do the same here
19:24:43 <dmitriz> ... so, +1 to that. What that would mean is that we'd include 'publicKeyJWK', 'publicKeyMultibase', we'd include .well-known discovery mechanism
19:24:49 <dmitriz> ... we'd include multiple algos in there
19:25:08 <dmitriz> ... which means that the entirety of the contents of the DI spec could be lifted & placed into the new spec (minus DI-specific language)
19:25:24 <dmitriz> ... and we can add everything related in the JOSE/COSE spec. and add the language "Do not use X feature" etc.
19:25:28 <dlongley> +1 to Manu, very supportive of that approach -- and its sounds like others in IRC would support as well.
19:25:29 <dmitriz> ... so, +1 to that if it helps us move forward
19:25:52 <dmitriz> ... I also don't like .well-known, but I'd hold my nose to it being added to the shared spec
19:25:59 <dmitriz> brent: I believe we have roughly a path forward
19:26:19 <dmitriz> ... we had one person comment that an aspect would not be acceptable; everyone else seems to be willing to move forward with this (the profiling approach)
19:26:27 <shigeya> For a data point, for some usecases we will use .wll-known
19:26:30 <dmitriz> ... so I think we're to the point of trying to craft proposal language
19:26:39 <shigeya> s/will-known/well-known
19:26:46 <dmitriz> ... I'm happy to do that unless someone else wants to craft resolutions
19:28:30 <dmitriz> brent: here is draft proposal, anyone opposed? (and if yes, how should we change it)
19:29:32 <dmitriz> JoeAndrieu_ I have some concerns re temporality. the controller document 'will include', which seems in the future?
19:29:41 <dmitriz> ... or is it possible for securing specs to adjust what goes into it?
19:29:53 <dmitriz> ... so, causality needs clarifying
19:30:08 <dlongley> +1 to brent's interpretation
19:30:19 <dmitriz> brent: my understanding is - both DI and Jose/cose would be written in the controller doc, as they're written today
19:30:20 <dmitriz> ... and then they could be modified as profiles etc
19:30:28 <TallTed> sorry bad paste
19:30:52 <TallTed> PROPOSAL: The shared Controller Document specification will include all Controller Document features that are used by the securing specifications today, and each individual securing specification can profile the Controller Document spec down to make specific choices as desirable.
19:31:18 <Kristina> q+
19:31:19 <dmitriz> brent: does that help with causality, Joe?
19:31:23 <dmitriz> JoeAndrieu_ yes
19:31:24 <brent> ack Kristina
19:31:56 <manu> q+
19:32:01 <brent> ack manu
19:32:02 <dmitriz> Kristina: it seems that this resolution does not apply to just key discovery, but other aspects as well. is the intent to just mix all the features from the securing specs?
19:32:19 <dmitriz> manu: yes, my understanding as well. just to be crystal clear,
19:32:45 <dmitriz> ... I'm looking at the VC DI controller doc section right now. it defines effectively what's found in DID Core, says you can use 'publicKeyJwk' and 'publicKeyMultibase', and the secretKey properties too
19:32:58 <dmitriz> ... defines multibase bytes normatively
19:32:59 <Orie> the vc data integrity controller document defines capability system and encryption related terminology, which is not used in vc data model today.
19:33:01 <Orie> q+
19:33:05 <dlongley> and VC-JOSE-COSE talks about .well-known (or would) and that would be put into the shared doc too.
19:33:09 <dmitriz> ... I don't know what's in VC JOSE/COSE, maybe Orie and Mike could speak to it
19:33:16 <dmitriz> ... I'm hearing the .well-known stuff would move in there
19:33:28 <dmitriz> ... also believe that we have a 'Retrieve Verification Method' algorithm that'd move into the shared doc
19:33:40 <dmitriz> ... that also has a set of processing errors (table)
19:33:51 <dmitriz> ... things like, throwing an error about invalid controller doc, id, etc
19:33:52 <dlongley> +1 to Manu
19:33:55 <dmitriz> ... the errors would move too
19:34:05 <brent> ack Orie
19:34:28 <dmitriz> Orie: accurate. just in terms of current VC JOSE/COSE spec - it has already a profiled-down version, just needs to be able to refer to correct term definitions
19:35:01 <dmitriz> ... current version in latest draft just expresses preference for common JOSE/COSE key representations. Does not contain elaboration on capabilityDelegation, capabilityInvocation or keyAgreement, as they're not used in VCs currently, to my kknowledge
19:35:20 <dmitriz> ... so when we constructed it, we took the DI definition, removed 'proof', multibase, the delegation and key agreement keys
19:35:23 <brent> q?
19:35:27 <Kristina> Clear, thank you.
19:35:30 <dlongley> +1 for VC-JOSE-COSE to continue to profile down in the way Orie says.
19:35:36 <dmitriz> brent: with that, we are ready to run the proposal
19:35:42 <brent> PROPOSAL: The shared Controller Document specification will include all Controller Document features that are used by the securing specifications today, and each individual securing specification can profile the Controller Document spec down to make specific choices as desirable.
19:35:49 <manu> +1
19:35:58 <dlongley> +1
19:36:00 <brent> +1
19:36:03 <TallTed> +1
19:36:03 <dmitriz> +1
19:36:04 <selfissued> +1
19:36:06 <shigeya> +1
19:36:08 <andres> +1
19:36:10 <JoeAndrieu_> +1
19:36:10 <pauld_gs1> +1
19:36:13 <Orie> +1
19:36:23 <bigbluehat> +1
19:36:38 <brent> RESOLVED: The shared Controller Document specification will include all Controller Document features that are used by the securing specifications today, and each individual securing specification can profile the Controller Document spec down to make specific choices as desirable.
19:36:42 <manu> q+
19:37:00 <dmitriz> brent: if II'm understanding correctly, this single proposal captures all of the stuff from the remaining resolutions & proposals from yesterday
19:37:01 <dlongley> +1 to Brent, this captures the rest in one way or another.
19:37:04 <dmitriz> ... I think we can move to other issues
19:37:05 <brent> ack manu
19:37:05 <selfissued> q+
19:37:11 <dmitriz> manu: agreed
19:39:10 <brent> ack selfissued
19:39:28 <dmitriz> selfissued: question to chairs (I'm open to many different answers) -- is it time to request volunteers to workk on this new shared doc?
19:39:29 <manu> q+
19:39:38 <dmitriz> brent: If there are folks on the call who want to volunteer, I'd love to hear it
19:39:43 <dmitriz> selfissued: I'll volunteer
19:39:44 <brent> ack manu
19:39:48 <dmitriz> manu: I'll volunteer
19:40:15 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc+-label%3A%22pr+exists%22+-label%3A%22ready+for+PR%22+
19:40:19 <dmitriz> brent: solid editorial team. others are also welcome to volunteer now, or reach out to chairs.
19:40:34 <dmitriz> brent: the first issue we'll talk about is issue 1303
19:40:36 <brent> subtopic: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc+-label%3A%22pr+exists%22+-label%3A%22ready+for+PR%22+
19:40:53 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1303
19:41:06 <dmitriz> brent: noting this is labeled as 'Before CR', but we don't have anyone assigned
19:41:14 <dmitriz> ... 'Remove at-risk marker for Evidence'
19:41:25 <dmitriz> ... where do we go with this?
19:41:27 <Orie> q+
19:41:32 <brent> ack Orie
19:41:46 <dmitriz> Orie: the linked issue is about termsOfUse, which is one of the expiring pending close ones?
19:42:06 <dmitriz> manu: it'll be merged on its current path
19:42:23 <manu> q+
19:42:30 <dmitriz> Orie: to recap, there is an open PR, looks like it'll get merged. so once we see something about Evidence, we'll remove at-risk marker
19:42:38 <brent> ack manu
19:43:04 <dmitriz> manu: we should ask the EBSI folks to see if they volunteer?
19:43:23 <dmitriz> brent: sounds like Dmitri is also volunteering, so, with permission, I'll assign it to you
19:43:47 <dmitriz> brent: next issue, 1292
19:43:52 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1292
19:44:00 <dmitriz> brent: Prefer Arrays and Objects
19:44:13 <Orie> q+
19:44:19 <dmitriz> ... labeled as Before CR, no assignment. there's a bit of a conversation between folks. Orie - can you give us status?
19:44:23 <brent> ack Orie
19:44:45 <dmitriz> Orie: as you all know, our conforming docs are compact JSON-LD docs. So, in lots of cases, the JSON is polymorphic -- either a string or an array object, etc
19:45:03 <dmitriz> ... any of the predicates (schema, proof, subject, etc) can either be string, object, or array
19:45:19 <dmitriz> ... reason for that is how RDF data model treats graph representation
19:45:29 <dmitriz> ... unfortunately, this causes problems for strongly typed languages
19:45:54 <dmitriz> ... these are very common bugs
19:46:07 <dmitriz> ... I've run into them hundreds of time. Can we reduce this sort of thing?
19:46:12 <dlongley> q+
19:46:19 <dmitriz> brent: other thoughts?
19:46:31 <brent> ack dlongley
19:46:49 <dmitriz> dlongley: brief comment - we had a number of issues where we said, to increase interop, we should do a few of these things,
19:46:55 <dmitriz> ... without normatively requiring
19:47:06 <dmitriz> ... so maybe non-normative advice would suffice, for interop?
19:47:14 <manu> q+
19:47:22 <Orie> dlongley maybe you can propose some normative SHOULD language?
19:47:30 <brent> ack manu
19:47:30 <dmitriz> brent: suggestion before the group - can we address non-norm / post-CR, for future us to deal with?
19:47:33 <dlongley> Orie: normative "SHOULD" hasn't worked in other places...
19:47:54 <dmitriz> manu: I'm a bit on the fence about this. might be good to go all the way to SHOULD, I'd be -1 for MUST
19:48:08 <dmitriz> ... we could put SHOULD normative language for objects, for arrays for single values, etc.
19:48:30 <dmitriz> ... the problem is (and we've tripped over this in the past), yhou don't want it so that systems that aren't written to be robust when you DON'T do it, fail
19:48:51 <dmitriz> ... so, should we urge everyone to support polymorphism (like with accessor functions)?
19:48:59 <dmitriz> ... it's dicey
19:49:15 <dmitriz> ... one alternate approach is to go the other way, and enforce all those variations in our test suites
19:49:25 <dmitriz> q+
19:49:41 <dmitriz> manu: I'm fine with either route - SHOULD, or non-normative advice
19:50:02 <brent> ack dmitriz
19:50:03 <manu> scribe+
19:50:22 <manu> dmitriz: How do people about "always require arrays"?
19:50:29 <Orie> I would be +1 to always requiring arrays, based on our implementation experience
19:50:33 <dlongley> -1 some software already doesn't do that...
19:50:36 <dmitriz> I'd +1
19:50:36 <Orie> ... we do that in other specs
19:50:42 <manu> I'd be -1 to that ... 'cause there will be people that don't want to do that and we can't make them.
19:50:44 <dmitriz> @dlongley - what do you mean?
19:50:57 <shigeya> +0.5
19:50:57 <bigbluehat> -1 to new shape requirements...
19:51:00 <dmitriz> +1
19:51:02 <selfissued> q+
19:51:06 <kristina> kristina has joined #vcwg
19:51:07 <brent> ack selfissued
19:51:12 <andres> I'm not sure what the implications are.
19:51:15 <brent> present+ kristina
19:51:19 <manu> q+
19:51:20 <dmitriz> selfissued: this seems odd. what would this possibly accomplish?
19:51:31 <dmitriz> ... if stuff is naturally a singleton, it should be represented as such
19:51:32 <manu> Agree with selfissued
19:51:34 <brent> ack manu
19:51:36 <dlongley> +1 to Mike
19:51:47 <Orie> q+
19:51:51 <dmitriz> q+
19:52:20 <brent> ack Orie
19:52:22 <dmitriz> @manu - amend the proposal to 'require arrays when it's NOT a functional item' (single-only)
19:52:39 <dmitriz> Orie: it wouldn't be issuer (since you're not allowed multiple), but it would mean multiple subjects
19:52:42 <manu> q+ to say we don't express arity for properties.
19:52:51 <dmitriz> ... so, if you're only allowed to have an object or a string, you'd still see singleton
19:53:21 <dmitriz> ... remember, this compact JSON-LD doc is an instance of the RDF data model, so we get the array polymorphism from that
19:53:46 <brent> ack dmitriz
19:53:55 <dlongley> not sure if there's a "net improvement" here... we might improve in one direction and cause harm in another.
19:54:27 <Orie> in the real world there are multiple issuers.
19:54:45 <manu> dmitriz: To respond to all 3... Mike - reason we're discussing is this is a cause for a bunch of bugs, singleton vs. array... Orie - disagree that we're inheriting polymorphism from RDF data models, we're inheriting it from the real world -- sometimes it's a singleton, sometimes it's an array. Manu - you have a point, but it's amenable - require arrays only when arrays are possible (single items only require singletons).
19:54:48 <Orie> we are inheriting from using JSON-LD for conforming documents.
19:54:50 <brent> ack manu
19:54:50 <Zakim> manu, you wanted to say we don't express arity for properties.
19:55:13 <dmitriz> manu: people are suggesting 'require arrays whenever arrays are possible'. we don't have expressions of arity except in spec
19:55:26 <Orie> one place this is very likey to cause bugs is credentialSchema and credentialStatus
19:55:35 <dmitriz> ... the vast majority of the vocabularies don't specify arity; people don't go through the trouble of doing that
19:55:51 <dmitriz> ... we can say 'in OUR specification, we do specify the arity' for the fields defined in VC DM
19:55:52 <brent> zakim, close the queue
19:55:52 <Zakim> ok, brent, the speaker queue is closed
19:55:59 <dmitriz> ... but that falls apart the moment you extend the core DM
19:56:03 <dmitriz> ... so, this might be brittle
19:56:10 <pauld_gs1> present-
19:56:20 <dmitriz> ... I don't think we can require enforceable arity
19:56:31 <dlongley> push this to credentialSchema <--
19:56:39 <dmitriz> ... unless we require JSON Schemas for all VCs, this is non-enforcible
19:56:50 <dlongley> if you want it, use `credentialSchema`... that's one thing it's for, right?
19:56:56 <dmitriz> ... we can provide non-norm guidance for people not to do it
19:57:08 <dmitriz> s/enforcible/enforceable/
19:57:19 <dmitriz> brent: counter-proposal, if I understand, is 'Do nothing'
19:57:20 <Orie> I am fine closing the issue.
19:57:29 <dmitriz> ... turning mike over to Kristina
19:57:37 <brent> present+ pauld_gs1
19:57:48 <dmitriz> Kristina: I am stepping down as a co-chair of this WG. after this call, I'll make a PR removing myself from readme
19:57:58 <dmitriz> ... and close couple of PRs, will remove my rights, etc
19:58:17 <manu> Sorry to hear that you're stepping down, Kristina -- thank you for your service to the group!
19:58:19 <dmitriz> ... if anyone has questions, feel free to reach out to me
19:58:19 <dmitriz> ... thank you all, for the opportunity!
19:58:21 <Orie> Thanks for all your help Kristina! enjoy the time back : )
19:58:23 <dmitriz> brent: thank you Kristina, it has absolutely been a pleasure
19:58:35 <dmitriz> brent: thanks everyone, see you next week
19:58:54 <brent> zakim, who is here?
19:58:54 <Zakim> Present: brent, shigeya, manu, dmitriz, bigbluehat, JoeAndrieu_, selfissued, andres, dlongley, TallTed, Orie, dlehn, Kristina, pauld_gs1
19:58:57 <Zakim> On IRC I see tzviya, Orie, TallTed, andres, selfissued, JoeAndrieu_, dmitriz, pauld_gs1, RRSAgent, Zakim, brent, dlehn, Jem, cel[h], saysaywhat, Github, bumblefudge1, cel[m], npd,
19:58:57 <Zakim> ... w3c_modbot, MojGraph, ounfacdo, seabass, bumblefudge, shigeya, dlongley, manu, rbyers, hadleybeeman, bigbluehat, Dongwoo, cbiesinger, stenr, cel, csarven, rhiaro
19:59:25 <brent> present+ andres
19:59:31 <brent> zakim, end the meeting
19:59:31 <Zakim> As of this point the attendees have been pauld_gs, brent, shigeya, manu, dmitriz, bigbluehat, JoeAndrieu_, selfissued, andres, dlongley, TallTed, Orie, dlehn, Kristina, pauld_gs1
19:59:34 <Zakim> RRSAgent, please draft minutes
19:59:35 <RRSAgent> I have made the request to generate https://www.w3.org/2023/10/25-vcwg-minutes.html Zakim
19:59:43 <Zakim> I am happy to have been of service, brent; please remember to excuse RRSAgent.  Goodbye
19:59:43 <Zakim> Zakim has left #vcwg
19:59:47 <brent> rrsagent, bye
19:59:47 <RRSAgent> I see no action items