15:58:41 <RRSAgent> RRSAgent has joined #did
15:58:45 <RRSAgent> logging to https://www.w3.org/2024/12/12-did-irc
15:58:45 <decentralgabe> rrsagent, draft minutes
15:58:46 <RRSAgent> I have made the request to generate https://www.w3.org/2024/12/12-did-minutes.html decentralgabe
15:58:48 <decentralgabe> rrsagent, make logs public
15:58:50 <TallTed> TallTed has joined #did
15:58:52 <decentralgabe> Meeting: Decentralized Identifier Working Group
15:58:59 <decentralgabe> Chair: Gabe Cohen
15:59:09 <decentralgabe> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Dec/0003.html
15:59:29 <decentralgabe> present+
16:00:40 <Wip> Wip has joined #did
16:01:32 <decentralgabe> Topic: Agenda Review, Introductions
16:01:32 <markus_sabadello> markus_sabadello has joined #did
16:01:34 <manu> present+
16:01:48 <Wip> present+
16:02:05 <ivan> present+
16:03:47 <pchampin> present+
16:04:38 <TallTed> present+
16:06:00 <smccown> smccown has joined #did
16:06:13 <smccown> scribe+
16:06:37 <danpape> danpape has joined #did
16:06:44 <danpape> present+
16:07:08 <decentralgabe> q?
16:07:10 <smccown> Gabe:   review agenda:  review special topic call
16:07:21 <decentralgabe> topic: Special Topic Call in January
16:07:31 <decentralgabe> https://www.w3.org/2024/12/11-did-minutes.html
16:09:02 <smccown> decentralgabe: resolution path parameters in next special topic call, Jan 8th or 15th?
16:09:33 <smccown> decentralgabe:  this group meet next week, next special topic call Jan 8th
16:09:36 <decentralgabe> Topic: DID Core Updates
16:10:14 <manu> q+
16:10:15 <bigbluehat> bigbluehat has joined #did
16:10:18 <decentralgabe> ack manu
16:10:50 <JoeAndrieu> JoeAndrieu has joined #did
16:10:58 <smccown> manu:  controlled identifier spec doc is ready to go into CR1.   However, need to review with all horizontal reviewers
16:11:48 <smccown> manu:  stability on the name & short name, features, and most of text.  Will update DID Core doc with the presumption that it will get into CR
16:13:05 <smccown> manu:  will do that before addressing new PRs ... an editorial update, fix lang, etc.
16:13:11 <TallTed> q+
16:13:17 <decentralgabe> ack TallTed
16:14:07 <decentralgabe> Topic: DID Resolution Issue & PR Processing
16:14:46 <decentralgabe> subtopic: open PRs
16:14:56 <decentralgabe> https://github.com/w3c/did-resolution/pull/99 will be merged
16:15:13 <decentralgabe> https://github.com/w3c/did-resolution/pull/103, https://github.com/w3c/did-resolution/pull/104
16:15:38 <decentralgabe> https://github.com/w3c/did-resolution/pull/96/ was merged
16:16:09 <smccown> markus_sabadello:  Updates on PRs 99, 103, 96.
16:17:04 <Phil> Phil has joined #did
16:17:09 <smccown> markus_sabadello:  103 adds detail to dereferencing.  1) did not found, 2) when did dereferences to a did doc
16:17:10 <Phil> present+
16:17:11 <decentralgabe> q?
16:17:47 <manu> q+
16:18:56 <JoeAndrieu> q+
16:18:57 <decentralgabe> ack manu
16:19:01 <smccown> markus_sabadello:  next PR describes what to do with did path, dereferencing algorithm should be explained in more detail
16:19:56 <smccown> manu:  PR 103:  taking out abstract data model stuff from did core.  Seems markup syntax is abstract or concrete representation?
16:20:29 <smccown> markus_sabadello:  need to update to show concrete representation
16:20:52 <smccown> manu:  is okay in examples for show_json
16:21:33 <manu> q+ to note notation might suggest things other than JSON are ok?
16:22:00 <smccown> markus_sabadello:  algorithm says if certain inputs, then these are the outputs ... will ponder more and revise
16:22:00 <decentralgabe> ack JoeAndrieu
16:22:13 <smccown> JoeAndrieu:  +1 to make examples in JSON
16:22:48 <decentralgabe> ack manu
16:22:48 <Zakim> manu, you wanted to note notation might suggest things other than JSON are ok?
16:22:56 <smccown> JoeAndrieu:  suggested language / details for did doc and VDR
16:23:42 <smccown> manu:  others have had strong negative reaction to abstract syntax.  Should express as JSON to avoid confusion about how data is returned
16:24:47 <smccown> markus_sabadello:  happy to change / update.  PR could be reviewed in terms of functionality and presentation of results.  These are easy to update
16:25:04 <manu> q+ to set up .pr-preview
16:25:12 <decentralgabe> ack manu
16:25:12 <Zakim> manu, you wanted to set up .pr-preview
16:25:41 <smccown> manu:  will find docs about how to setup .pr-preview
16:25:47 <manu> Instructions on how to do that here: https://github.com/marketplace/actions/deploy-pr-preview
16:26:23 <ivan> q+ to ask about an absolutely administrative thing
16:26:33 <manu> Example in vc-data-model: https://github.com/w3c/vc-data-model/blob/main/.pr-preview.json
16:26:55 <smccown> markus_sabadello:  parameters in did core.  did resolution alg only describes how to dereference some parameters.  This PR adds placeholders to define how algorithm will process parameters.
16:27:49 <manu> q+
16:27:53 <decentralgabe> ack manu
16:28:08 <pchampin> markus_sabadello I just made a PR to configure PR-preview. Sorry I overlooked this earlier.
16:29:04 <smccown> manu:  looking through algorithm.  At a high level algorithm seems fine.  There is some discussion about fragment identifier processing.  This seems about path / query params.  do you feel algorithm  is complete?
16:29:58 <manu> q+ to note yes, include did core parameters
16:30:02 <smccown> markus_sabadello:  this is meant as preparation for special topic call.  How to process path / query.  one question, do we want to define parameters that we already have in did core?
16:30:26 <decentralgabe> ack manu
16:30:26 <Zakim> manu, you wanted to note yes, include did core parameters
16:30:36 <smccown> manu +1 to include those
16:31:06 <smccown> manu:  do we need text in did core that says if defining query parameters, then you need processing algorithm for them?
16:32:01 <smccown> manu:  if we revise params, then we need to revise algorithms in did resolution.  Should we move the text to other specs?
16:33:20 <smccown> markus_sabadello:  yes.  Alg in PR 104, alg copies all params in did core, the alg says that did methods may define how to process parameters.  DID resolution spec wouldn't have to be updated every time
16:35:13 <smccown> markus_sabadello:  showing did-resolution algorithm dereferencing resource.  Displaying examples (in the spec) of params and how they are to be processed.  (described. more in special topic call).
16:35:53 <decentralgabe> q?
16:35:56 <manu> q+
16:36:01 <decentralgabe> ack manu
16:36:42 <smccown> @manu:  do we need a step that says "you can run any alg on any query param?"
16:37:08 <smccown> manu:  concern that impression is that only a subset of params are processed
16:37:38 <smccown> manu:  may need to say that there *will* be an alg
16:38:17 <JoeAndrieu> q+
16:38:23 <decentralgabe> ack JoeAndrieu
16:39:44 <smccown> JoeAndrieu:  has significant concerns about how did methods may interpret what the did url means.  We need to determine what the path part means regardless of did method implentation
16:40:35 <smccown> markus_sabadello:  found 6 issues, which may propose new params.  do we want to add new params in did resolution spec that are not already in did core?
16:41:02 <manu> q+ to ask if we want to move all of that into did-resolution? Or separate specs?
16:41:16 <decentralgabe> ack manu
16:41:16 <Zakim> manu, you wanted to ask if we want to move all of that into did-resolution? Or separate specs?
16:41:25 <smccown> markus_sabadello:  examples:  service parameter by name, type, etc.  do we want to add this into did resolution or inform implementers to handle in their implementation
16:42:11 <smccown> @manu:  find to add new parameters into did method implementation.  Wondering if did core is right place to do that.  Definitions in did core, but normative in implementation?
16:42:28 <smccown> manu:  however we do it, they should be all in one place
16:43:25 <smccown> markus_sabadello:  could be, but could also be handled on a case by case basis
16:43:29 <JoeAndrieu> q+ to ask why not move them all to did resolution?
16:43:50 <decentralgabe> ack JoeAndrieu
16:43:50 <Zakim> JoeAndrieu, you wanted to ask why not move them all to did resolution?
16:43:53 <manu> q+ to ask Joe if we can do that -- is it a class 3?
16:44:17 <smccown> JoeAndrieu:  why not move all to did resolution?  are there params that shouldn't go there?
16:44:51 <smccown> markus_sabadello:  all params we're discussing are part of did resolution.
16:45:01 <decentralgabe> ack manu
16:45:01 <Zakim> manu, you wanted to ask Joe if we can do that -- is it a class 3?
16:45:41 <decentralgabe> Subtopic: Issues around DID URL Dereferencing (85, 90, 39,40, 5, 43)
16:45:50 <decentralgabe> https://github.com/w3c/did-resolution/issues/85
16:46:05 <smccown> manu:  all params in did core are did resolution related.  While we're not allowed to make class 3 changes, not clear if we can move normative features to a different spec.  If we do that, do we modify 'normativeness' of features?
16:46:27 <smccown> manu:  would prefer to move param definitions to did-resolution
16:46:37 <pchampin> we are allowed to make class-3 changes...
16:46:45 <smccown> markus_sabadello:  sounds good.  we've already moved a lot of params
16:46:52 <JoeAndrieu> q+ to mention CID
16:47:09 <decentralgabe> ack JoeAndrieu
16:47:09 <Zakim> JoeAndrieu, you wanted to mention CID
16:47:30 <smccown> JoeAndrieu:  need to be able to refactor params and definitions
16:48:06 <pchampin> q+
16:48:36 <markus_sabadello> s/already moved a lot of params/already moved some sections related to resolution/
16:48:44 <decentralgabe> ack pchampin
16:48:54 <smccown> Ivan:  question is, does it change / affect implementers, performance, etc.  if yes, is class 3 change, if no, then not.  Seems we're just moving normative things that don't affect implementers.  To me, seems fine, but would need to ask lawyers
16:49:33 <smccown> pchampin:  moving statements seems okay.  However, we are allowed to make class 3 ... just not class 4
16:49:50 <smccown> Ivan:  question is whether these changes are class 3 or 4
16:50:08 <manu> My read is that these changes would be a class 3 change -- moving parameters from did-core to did-resolution.
16:50:11 <smccown> decentralgabe:  decision that these are class 3 changes and not class 4
16:50:16 <manu> q+
16:50:21 <decentralgabe> ack manu
16:51:08 <smccown> manu:  we should make the changes (as class 3).  Move params from did core to did resolution.  Will adjust text accordingly.
16:52:09 <decentralgabe> q?
16:52:19 <smccown> markus_sabadello:  if params are selected by service type, then support for did resolution.
16:52:20 <manu> +1 for serviceType
16:52:50 <decentralgabe> https://github.com/w3c/did-resolution/issues/90
16:53:12 <smccown> markus_sabadello:  PR #90 will allow parameter selection of verification by did doc
16:53:57 <manu> q+ to wonder if we need features for extracting portions of a DID Document?
16:54:02 <decentralgabe> ack manu
16:54:02 <Zakim> manu, you wanted to wonder if we need features for extracting portions of a DID Document?
16:54:49 <JoeAndrieu> q+ to say I'd prefer a cleaner interface
16:55:42 <smccown> manu:  wondering how useful features are.  if you get a did doc back, then its simple to dereference a property.  Concern is:  that too much messing with parameters might be too much
16:55:44 <decentralgabe> ack JoeAndrieu
16:55:44 <Zakim> JoeAndrieu, you wanted to say I'd prefer a cleaner interface
16:56:20 <manu> q+
16:56:28 <decentralgabe> ack manu
16:56:42 <smccown> JoeAndrieu:  wanted to echo what manu said.  There's a case for returning a subset / object, but usually should return did document as a whole
16:57:17 <Wip> q+
16:57:33 <brent> brent has joined #did
16:57:45 <smccown> manu:  typical case is to return full did doc, but some cases where partial can be returned.  Concern is that complex path requests will make did methods too custom vs having a common interface
16:57:55 <decentralgabe> ack Wip
16:58:05 <manu> q+ to ask about DID Core FPWD
16:58:35 <smccown> Wip:  who's responsible for returning params vs did doc?
16:59:22 <decentralgabe> ack ivan
16:59:22 <Zakim> ivan, you wanted to ask about an absolutely administrative thing
16:59:28 <smccown> markus_sabadello:  we've already opened the door to return data objects vs full did document.  These proposals are similar
17:00:01 <JoeAndrieu> markus_sabadello FWIW, I don't think that door is closed.
17:00:42 <pchampin> will look at it :-/
17:00:43 <decentralgabe> ack manu
17:00:43 <Zakim> manu, you wanted to ask about DID Core FPWD
17:00:47 <smccown> ivan:  Looking at official W3C repos and these repos don't appear.  Worried that someone just created a new repo in GitHub vs official W3C processes
17:01:53 <smccown> Ivan:  let's ensure we follow the official W3C processes for creating repos, docs, etc.
17:02:36 <pchampin> RRSAgent, make minutes
17:02:38 <RRSAgent> I have made the request to generate https://www.w3.org/2024/12/12-did-minutes.html pchampin
17:03:09 <pchampin> m2gbot, link minutes with transcript
17:03:09 <m2gbot> sorry pchampin, I don't understand "link minutes with transcript"
17:03:22 <pchampin> m2gbot, help
17:03:22 <m2gbot> pchampin, I am an IRC bot to link github issues and PRs to the minutes of the meetings where they were discussed.
17:03:22 <m2gbot> ... I am an instance of minutes_to_gh version 0.8.0.
17:03:23 <m2gbot> ... To know more, see https://github.com/pchampin/minutes_to_gh
17:03:38 <pchampin> m2gbot, link issues with transcript
17:04:58 <brentz> brentz has joined #did
17:06:37 <pchampin> m2gbot, help
17:06:37 <m2gbot> pchampin, I am an IRC bot to link github issues and PRs to the minutes of the meetings where they were discussed.
17:06:37 <m2gbot> ... I am an instance of minutes_to_gh version 0.8.0.
17:06:38 <m2gbot> ... To know more, see https://github.com/pchampin/minutes_to_gh
17:06:51 <pchampin> m2gbot, link issues with transcript
17:07:10 <pchampin> m2gbot, link issues
18:21:29 <dlehn1> dlehn1 has joined #did
19:00:57 <bkardell_> bkardell_ has joined #did
19:33:13 <Zakim> Zakim has left #did
20:24:45 <brentz> brentz has joined #did
20:24:45 <brent> brent has joined #did