15:03:41 <RRSAgent> RRSAgent has joined #vcwg-special
15:03:45 <RRSAgent> logging to https://www.w3.org/2023/11/28-vcwg-special-irc
15:03:45 <Zakim> RRSAgent, make logs Public
15:03:46 <Zakim> please title this meeting ("meeting: ..."), ivan
15:04:02 <ivan> Meeting: Verifiable Credentials Working Group Special Topic Call on Outstanding PRs
15:04:02 <ivan> Date: 2023-11-28
15:04:02 <ivan> chair: brent
15:04:02 <ivan> Agenda: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20231128T110000/
15:04:04 <ivan> ivan has changed the topic to: Meeting Agenda 2023-10-31: https://www.w3.org/events/meetings/f6342df0-f7b5-4fc9-babd-61e55dc5fc2f/20231128T110000/
15:04:17 <TallTed> TallTed has joined #vcwg-special
15:52:55 <brent> brent has joined #vcwg-special
15:55:25 <ivan> present+
15:56:23 <brent> present+
15:57:49 <dmitriz> dmitriz has joined #vcwg-special
15:58:53 <ivan> present+ seabass, TallTed,
15:58:56 <TallTed> present+
16:00:57 <ivan> present+ identitywoman, dmitriz
16:01:33 <andres> andres has joined #vcwg-special
16:01:33 <manu> present+
16:01:34 <ivan> present+ selfissued
16:01:36 <andres> present+
16:02:09 <selfissued> selfissued has joined #vcwg-special
16:02:12 <selfissued> present+
16:02:17 <dlongley> present+
16:02:21 <selfissued> scribe+
16:03:04 <ivan> present+ nas
16:03:10 <selfissued> brent: Our agenda is straightforward
16:03:10 <brent> Topic: Issue Processing
16:03:11 <pdl-asu> pdl-asu has joined #vcwg-special
16:03:14 <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+
16:03:14 <pdl-asu> present+
16:03:16 <selfissued> ... We are going to do issue processing
16:04:22 <selfissued> Nas Hajia is a security architect representing Autodesk
16:05:20 <Orie> Orie has joined #vcwg-special
16:05:21 <Orie> present+
16:05:23 <JoeAndrieu> JoeAndrieu has joined #vcwg-special
16:05:32 <ivan> present+ JoeAndrieu
16:05:37 <selfissued> brent: We are going through pre-CR issues
16:05:45 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1328
16:05:54 <selfissued> The goal is to be ready for CR on the core data model by mid-December
16:06:09 <manu> q+
16:06:20 <brent> ack manu
16:06:35 <selfissued> manu: This would be a lot of work
16:06:37 <JoeAndrieu> for 1328 I can speak in a bit,  but Manu can probably cover
16:06:44 <selfissued> ... There might be a way to do this in the future
16:06:51 <selfissued> ... This could take months to resolve
16:07:05 <selfissued> ... Joe is going to do a review
16:07:10 <selfissued> ... Maybe validation doesn't need to be made normative
16:08:07 <ivan> present+ davidc
16:08:11 <DavidC> DavidC has joined #vcwg-special
16:08:19 <DavidC> present+
16:08:21 <ivan> present+ will
16:08:40 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1360
16:08:43 <manu> q+
16:08:49 <manu> q-
16:08:50 <Will> Will has joined #vcwg-special
16:08:53 <Will> present+
16:09:27 <dmitriz> q+
16:09:40 <brent> ack dmitriz
16:10:51 <selfissued> dmitriz: We want to be able to lock these down cryptographically
16:10:52 <manu> q+ to ask about "relatedProperties", and "relatedResource", and volunteer to write a PR for this.
16:11:01 <selfissued> ... We have only added this for verifiable credentials
16:11:09 <selfissued> ... But not for related resources
16:11:15 <selfissued> ... We need to do this for VPs
16:11:44 <brent> ack manu
16:11:44 <Zakim> manu, you wanted to ask about "relatedProperties", and "relatedResource", and volunteer to write a PR for this.
16:11:45 <selfissued> brent: Can the solution be as simple as saying "this section also refers to VPs".
16:12:03 <selfissued> manu: Do you mean "related resources"?
16:12:11 <selfissued> ... I can volunteer to write a PR for this
16:12:46 <JoeAndrieu> correct.  id we need to secure contexts we should do that.  arbitrary resources is a layer violation
16:12:49 <pdl-asu> pdl-asu has joined #vcwg-special
16:12:56 <JoeAndrieu> bayou to review pr
16:13:00 <JoeAndrieu> happy
16:13:00 <pdl-asu> present+
16:13:42 <JoeAndrieu> I can't yet
16:13:55 <selfissued> manu: Joe, do you have any comments on making validation normative?
16:14:01 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1362
16:14:12 <manu> q+
16:14:31 <selfissued> brent: There is a PR in progress that adds a verification algorithm to the spec
16:14:37 <selfissued> ... It seems to be progressing well
16:14:41 <ivan> https://github.com/w3c/vc-data-model/pull/1338
16:14:55 <brent> ack manu
16:15:19 <selfissued> manu: There was at least one thing - it's not clear if we're going to be able to make the PR
16:15:26 <selfissued> ... We need WG consensus
16:15:39 <selfissued> ... We need to define an interface in the securing mechanism
16:15:49 <selfissued> ... Jeffrey wants us to do that
16:15:58 <selfissued> ... We need a uniform interface
16:16:16 <selfissued> ... Currently we provide instructions for DI and jose-cose
16:16:27 <selfissued> ... about the extraction and verification functions
16:16:30 <selfissued> q+
16:16:41 <manu> scribe+
16:16:45 <manu> scribe-
16:16:47 <dmitriz> scribe+
16:16:52 <brent> ack selfissued
16:16:55 <manu> q+
16:17:00 <dmitriz> selfissued: as pointed out by Brent on the Editors call yesterday, we're explicitly not chartered to to APIs
16:17:04 <manu> q+ to note that this is not an API.
16:17:15 <dmitriz> ... what's being proposed here is an API, so therefore out of scope. It's fine to define normative language in the two securing specs
16:17:20 <brent> q+ to comment on interface vs API
16:17:23 <dmitriz> ... but providing an API to do it goes against charter
16:17:26 <brent> ack manu
16:17:26 <Zakim> manu, you wanted to note that this is not an API.
16:17:38 <manu> This is not an API: https://github.com/w3c/vc-data-model/pull/1338#issuecomment-1828821192
16:17:39 <dmitriz> scribe-
16:18:18 <selfissued> manu: We do define algorithms
16:18:39 <brent> ack brent
16:18:39 <Zakim> brent, you wanted to comment on interface vs API
16:18:41 <selfissued> ... That's in scope
16:18:56 <selfissued> selfissued: Then call them algorithms - not a uniform interface
16:18:59 <selfissued> manu: Done
16:19:50 <selfissued> brent: The concern I have is that what we have in #1338 is in response to comments from a W3C member saying that if this isn't addressed, they will formally object
16:20:09 <manu> q+ to note that the commenter has agreed to the PR, suggest "at risk" as a way to mitigate charter concern.
16:20:13 <selfissued> ... On the other hand, we have charter language prohibiting creating APIs
16:20:28 <brent> ack manu
16:20:28 <Zakim> manu, you wanted to note that the commenter has agreed to the PR, suggest "at risk" as a way to mitigate charter concern.
16:20:38 <Core9422> Core9422 has joined #vcwg-special
16:20:39 <selfissued> ... From my perspective, the safe route is to figure out an algorithm to address this
16:20:53 <selfissued> manu: Jeffrey has approved the PR
16:21:01 <selfissued> ... It is definitely a grey area
16:21:07 <Orie> lets make sure the algorithm does not contradict any of our terminology or definitions, particularyly the "extract" vs "credential" definitions.
16:21:20 <selfissued> ... If there is concern about somebody objecting to the charter, we have a strong defense
16:21:28 <selfissued> ... This can't work without algorithms
16:22:37 <selfissued> manu: We have a path to defend against formal objections
16:22:51 <selfissued> brent: We will have a more thorough conversation about #1338 tomorrow
16:22:53 <manu> agree with Orie that we don't want those algorithms to contradict any terminology/definitions in the securing mechanism specifications.
16:23:13 <manu> The algorithm is meant to defer to the securing specs for all important implementation details.
16:23:30 <dlongley> and agree it's important that the algorithm not impede things like SD-JWT and ECDSA-SD
16:23:57 <selfissued> brent: If we get agreement on #1338 then #1362 can be closed
16:24:12 <ivan> present+ bigbluehat
16:24:38 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1363
16:24:43 <Orie> q+
16:25:05 <selfissued> brent: The current path we are on relies on media types with multiple suffixes
16:25:23 <selfissued> ... The spec for multiple suffixes in IETF has been more contentious than anticipated
16:25:32 <selfissued> ... And possibly a whole lot more work than anticipated
16:25:48 <selfissued> ... This issue is another path to sidestep this
16:25:58 <brent> ack Orie
16:26:10 <selfissued> Orie: This issue can be used with or without multiple suffixes
16:26:33 <selfissued> ... Our current registrations require multiple suffixes, even though this isn't possible at present
16:27:00 <selfissued> ... Even for application/vc the subtype can contain media type parameters
16:27:04 <brent> q+ to say what it will mean for a multiple suffix to be registered without the RFC
16:27:11 <TallTed> q+
16:27:17 <selfissued> ... Those parameters can express characteristics of the media type
16:27:33 <identitywoman> identitywoman has joined #vcwg-special
16:27:33 <selfissued> ... Specifying the text type is a common usage
16:27:44 <TallTed> q+ to clarify what is the "subtype"
16:27:49 <selfissued> ... This tracks the intended use of the profile parameter
16:28:09 <selfissued> ... We should provide guidance on the use of profile
16:28:10 <selfissued> ... We could say not to use it
16:28:23 <identitywoman> present+
16:28:23 <selfissued> ... We could say to use it in the same way as ld+json
16:28:39 <brent> ack brent
16:28:39 <Zakim> brent, you wanted to say what it will mean for a multiple suffix to be registered without the RFC
16:28:51 <selfissued> brent: Thank you for clarifying the relationship between the parameters
16:29:09 <selfissued> brent: We can register media types with multiple suffixes
16:29:30 <manu> q+ to note status of multiple suffixes, profile parameter is problematic -- can't do file extensions, not usually processed by most implementers, etc. but not blocking it (good to say something about it)
16:29:37 <selfissued> ... The current interpretation of a+b+c is that a is the prefix and b+c is the suffix
16:29:43 <brent> ack TallTed
16:29:43 <Zakim> TallTed, you wanted to clarify what is the "subtype"
16:29:49 <Orie> we can request registrations that rely on multiple suffixes, but they cannot be registered, until their interpretation is clear... it is a mistake to request registrations that we know cannot be approved.
16:30:10 <selfissued> TallTed: The first thing after the slash isn't what matters
16:30:19 <selfissued> ... The subtype is what's after the last + sign
16:30:24 <dmitriz> q+
16:30:35 <selfissued> ... There are multiple layers of subtyping
16:30:42 <selfissued> ... I don't know why the IETF did this
16:31:05 <Orie> if you have questions regarding media types, you can ask the media type list. see https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/
16:31:28 <selfissued> ... You process as many of the subtypes that you understand
16:31:37 <selfissued> ... This is complex and esoteric
16:31:37 <Orie> +1 TallTed, its complicated : (
16:31:53 <selfissued> ... The problem with multiple + signs is that the interpretation is undefined
16:32:09 <selfissued> ... There may be many more drafts
16:32:41 <selfissued> ... We can specify what our media types mean but those will only apply to people who understand our spec
16:32:53 <ivan> q+
16:32:53 <Orie> here is the repo: https://github.com/ietf-wg-mediaman/suffixes ... TallTed, eager to see your PR : )
16:33:07 <brent> ack manu
16:33:07 <Zakim> manu, you wanted to note status of multiple suffixes, profile parameter is problematic -- can't do file extensions, not usually processed by most implementers, etc. but not
16:33:10 <Zakim> ... blocking it (good to say something about it)
16:33:17 <selfissued> ... It's to let people who don't understand what's to the left of the +s to still work with what's to the right of the +s
16:33:25 <selfissued> manu: I am the editor of that spec
16:33:38 <selfissued> ... There is only one remaining issue
16:33:52 <selfissued> ... It's about whether to register all the things in between
16:34:09 <dlongley> for "application/vc+ld+json" processing is: "application", then "json", then "ld+json", then "vc+ld+json" ... another way to understand this subclass processing is: "application/square+rectangle+shape" ... you can understand any "application" content, then, if you want, more specifically any "shape", ... then any "rectangle" ... "square".
16:34:17 <selfissued> ... The chair of the WG wants to take it to last call
16:34:47 <Orie> My recommendation would be to not depend on multiple suffixes, we raised a PR to remove the dependency from vc-jose-cose ... https://github.com/w3c/vc-jose-cose/pull/186
16:34:50 <selfissued> ... I don't think the multiple structured suffixes draft is in a place that it's not going to be ratified soon
16:35:03 <selfissued> ... Ted is right that we can just specify what our media types mean
16:35:14 <selfissued> ... We don't need to change anything about the media types used in the spec
16:35:24 <selfissued> ... The profile problem is problemantic
16:35:31 <selfissued> ... Many people don't prrocess it
16:35:39 <Orie> related registration for https://www.iana.org/assignments/media-types/application/ld+json
16:35:46 <selfissued> ... You can have multiple different IETF registrations stomp over it
16:36:04 <Orie> related specification Manu mentioned: https://www.w3.org/TR/activitystreams-core/#media-type
16:36:05 <selfissued> ... I realize we used it in JSON-LD.  I wish we hadn't.
16:36:12 <selfissued> ... We can tell people not to use it
16:36:26 <selfissued> ... What we've learned is that people don't implement it correctly
16:36:33 <Orie> feels like implementing profile correctly, is easier than using multiple suffixes consistently.
16:36:41 <dmitriz> @orie - agree
16:36:41 <selfissued> ... It's often destroyed or mangled as it goes through HTTP servers
16:36:49 <selfissued> ... We can only pick one filename suffix
16:36:53 <brent> q?
16:36:56 <brent> ack dmitriz
16:36:57 <selfissued> ... We can't use profile to do that
16:37:16 <TallTed> *sighs* people who don't conform to specs (e.g., by misconfiguring servers or otherwise breaking the `profile` option) should not be justification for not conforming to specs!
16:37:22 <manu> It's not easier to implement profile correctly, Orie. :) -- We have multiple decades of experience now that people don't implement it correctly.
16:37:25 <dlongley> as long as multiple suffixes follows the rule that each subtype fits within the same wider syntax, things are kept clean (and correct) ... i think trouble has come from people thinking it's for enveloping, when it isn't.
16:37:41 <selfissued> dmitriz: I want to agree with Orie that hierarchical multiple suffixes is way more trouble than it's worth
16:37:42 <manu> ^ yes, that.
16:37:47 <manu> (to what dlongley said)
16:37:49 <brent> ack ivan
16:37:59 <selfissued> ... I don't think there's any need for hierarchical multiple suffixes
16:38:14 <Orie> +1 ivan
16:38:25 <dmitriz> +1 to at risk
16:38:26 <selfissued> ivan: If we want to keep multiple suffixes, we should put the whole concept as being at risk in the document
16:38:34 <selfissued> ... Put it as at risk
16:38:43 <selfissued> ... We can see what happens at the IETF
16:38:54 <selfissued> ... If it goes through at IETF, we can remove the at risk
16:39:01 <selfissued> ... Otherwise we can reconsider
16:39:08 <selfissued> ... We have to defend ourselves
16:39:22 <ivan> q+
16:39:37 <Orie> q+
16:39:39 <selfissued> brent: We're relying on multiple suffixes but not normatively pointing to them
16:39:40 <brent> ack ivan
16:39:57 <manu> Note that JSON-LD has gone through multiple RECs w/ this in there: https://w3c.github.io/json-ld-syntax/#structured-extension-ld-json
16:39:58 <manu> q+
16:40:09 <selfissued> ivan: On the other hand, we are supposed to register media types we use during CR and we can't do it now
16:40:16 <selfissued> ... We can't ignore this
16:40:20 <brent> ack Orie
16:40:24 <selfissued> ... That's why we have to mark it as at-risk
16:40:46 <selfissued> Orie: I spoke to our W3C liaison at the IETF - Martin
16:40:57 <selfissued> ... It might be fine to go into CR that way
16:41:09 <selfissued> ... To become a recommendation, we have to finish the IETF work
16:41:20 <selfissued> ... It's OK to go into CR with the references are they are
16:41:38 <selfissued> ... If we have to correct this, it would be good to be able to do this without going through CR
16:41:54 <selfissued> ... If marking it as at-risk helps, let's do that
16:41:57 <brent> ack manu
16:42:11 <selfissued> ... I don't know how the DID spec got to Rec with multiple suffixes
16:42:31 <selfissued> ... If this isn't resolved before REC, I will formally object
16:42:38 <Orie> thats not true manu
16:42:48 <Orie> I added the +ld+json structured suffix
16:43:04 <selfissued> manu: The DID and JSON-LD specs have gone through REC with multiple structured suffixes
16:43:16 <selfissued> ... You can treat it as an opaque thing
16:43:21 <Orie> https://github.com/w3c/json-ld-syntax/pull/415
16:43:27 <selfissued> ... We can change it to application/vc if we need to
16:43:32 <selfissued> ... But that's doing the wrong thing
16:43:43 <selfissued> ... We should fix the IETF's broken suffixes
16:43:54 <selfissued> ... We should stop routing around this damage at the IETF
16:44:00 <brent> https://www.w3.org/TR/did-core/#application-did-ld-json
16:44:13 <Orie> seems like the W3C is responsible for the broken behavior, and I agree that it needs to be fixed.
16:44:18 <ivan> q+
16:44:28 <Orie> I am trying to fix it FWIW
16:44:29 <brent> ack ivan
16:44:31 <selfissued> brent: The DID spec said that it will be registered as soon as the IETF spec is done
16:45:02 <selfissued> ivan: The only thing I don't want is to go there and not even mention the problem
16:45:17 <selfissued> ... If we include a note like we did in the DID spec, that may be enough
16:45:40 <selfissued> brent: What are the steps forward for the profile parameter issue?
16:45:49 <manu> q+ to suggest text "do not use profile parameters, but if you do... do it this way"
16:45:52 <selfissued> ... We could prohibit their use or say how to use them
16:46:03 <brent> ack manu
16:46:03 <Zakim> manu, you wanted to suggest text "do not use profile parameters, but if you do... do it this way"
16:46:09 <selfissued> manu: We tell people how to use profile parameters correctly
16:46:26 <selfissued> ... Expect people to break this and it not to work correctly across the ecosystem
16:46:53 <selfissued> ... We should warn them that it has never worked out well when people rely on the profile parameter
16:47:06 <ivan> +1 to manu's direction
16:47:06 <selfissued> brent: We don't need to include doomsaying
16:47:25 <selfissued> brent: We would need someone willing to be assigned to the issue
16:48:00 <selfissued> brent: If you feel strongly that doing nothing is the right approach, then please volunteer to be assigned
16:48:14 <selfissued> ... If noone is assigned, then by default, we will be doing nothing about this
16:48:16 <ivan> q+
16:48:25 <brent> ack ivan
16:48:50 <Orie> the media types impact the "verification algorithm"
16:48:53 <selfissued> ivan: All these options we are talking about are editorial
16:48:58 <Orie> are they still editorial?
16:49:18 <selfissued> brent: The media types affect the verification algorithm
16:49:37 <selfissued> ... We don't have anyone willing to be assigned
16:49:58 <Orie> the reason I am not volunteering is that we are removing the dependency from vc-jose-cose.
16:50:06 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1290
16:50:26 <manu> q+
16:50:38 <selfissued> brent: I believe this has been overtaken by events
16:50:44 <brent> ack manu
16:50:57 <selfissued> ... But we received a comment on it by Oliver yesterday
16:51:15 <selfissued> manu: Oliver may be requesting a minor modification to the text
16:51:39 <selfissued> ... We may want to ask Oliver to propose text that we can remove
16:51:52 <selfissued> ... We don't use "JSON-only processing" anymore
16:52:03 <Orie> +1 to JSON-LD processing and RDF processing.... there is no JSON processing.
16:52:28 <selfissued> brent: I can tag Oliver
16:52:43 <selfissued> ... We will ask for a concrete suggestion from Oliver
16:52:59 <selfissued> ... I'm going to leave pending close on there for now
16:53:08 <manu> q+
16:53:11 <manu> q-
16:53:35 <selfissued> brent: We will meet tomorrow to dive more deeply into 1338 - the verification algorithm
16:53:52 <selfissued> ... We are in good standing to enter CR by mid-December, which is our goal
16:53:58 <ivan> rrsagent, draft minutes
16:54:00 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/28-vcwg-special-minutes.html ivan
16:55:05 <ivan> rrsagent, bye
16:55:05 <RRSAgent> I see no action items