14:48:25 <RRSAgent> RRSAgent has joined #did
14:48:29 <RRSAgent> logging to https://www.w3.org/2025/03/20-did-irc
14:48:32 <Wip> rrsaget, draft minutes
14:48:38 <Wip> rrsagent, draft minutes
14:48:40 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/20-did-minutes.html Wip
14:48:49 <Wip> rrsagent, make logs public
14:48:57 <Wip> Meeting: Decentralized Identifier Working Group
14:49:02 <Wip> Chair: Will Abramson
14:49:06 <Wip> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Mar/0009.html
14:49:09 <Wip> present+_
14:49:11 <Wip> present+
14:54:18 <TallTed> previous meeting: https://www.w3.org/2025/03/13-did-minutes.html
14:54:18 <TallTed> next meeting: https://www.w3.org/2025/03/27-did-minutes.html
14:59:27 <pchampin> present+
14:59:55 <ottomorac> present+
15:00:39 <markus_sabadello> markus_sabadello has joined #did
15:00:51 <manu> prsent+
15:01:02 <manu> s/prsent/present/
15:01:10 <JoeAndrieu> JoeAndrieu has joined #did
15:01:30 <markus_sabadello> present+
15:03:14 <KevinDean> KevinDean has joined #did
15:03:19 <KevinDean> present+
15:03:42 <ivan> present+
15:05:24 <TallTed> present+
15:06:00 <JennieM> JennieM has joined #did
15:06:04 <JennieM> present+
15:07:41 <danpape> danpape has joined #did
15:08:00 <manu> present+ danpape
15:08:08 <KevinDean> FYI, there's a trick you can use with bookmarks to jump into IRC with all fields pre-filled. https://irc.w3.org/?nick=YourNicknameHere&realname=First+Last&channels=did
15:08:15 <manu> present+ pchampin
15:08:40 <manu> present+ dmitriz
15:08:53 <Phil> Phil has joined #did
15:08:58 <manu> present+ iherman
15:09:00 <manu> present+ Phil
15:09:07 <Phil> present+
15:09:16 <Phil> scribe+
15:09:20 <Wip> Topic: Agenda Review
15:09:22 <manu> present+ JoeAndrieu
15:09:54 <Wip> Topic: Horizontal Review
15:10:20 <Phil> topic: horizontal review
15:11:30 <Phil> manu: horizontal reviews take time. This can take 3-6 months to get a response. FIrst Public Working drafts done for DID v1.1. and resolution
15:11:54 <Phil> manu: could include extensions and othet things we're working
15:12:22 <Phil> manu: it goes to many groups. If sent now we'd hear back by Dec or fall
15:12:32 <Phil> Manu: suggest we get on this now.
15:12:48 <Wip> q?
15:12:59 <Phil> Will: preferred path probably a resolution to move it forward.
15:13:10 <markus_sabadello> q+
15:13:16 <Wip> ack markus_sabadello
15:13:39 <manu> q+
15:13:41 <Wip> ack manu
15:13:47 <Phil> marcus: which version will they review if it takes so long given the spec will change during this waiting period
15:14:01 <smccown> smccown has joined #did
15:14:31 <Phil> Manu: suggest we give them the latest editors draft.  They'll do the initial review. when win candidate rec we can ask for a final review of the doc. That goes faster
15:14:48 <Phil> Manu: give them editor's draft links to review
15:14:56 <Wip> q?
15:15:12 <Phil> Will:  manu would you draft a resolution proposal
15:15:27 <Phil> Manu: yes, have we done  one of these before?
15:15:43 <Phil> Joe: no we haven't done an FPWD
15:16:18 <Phil> Manu: we'll request read of active documents
15:16:44 <Phil> Joe: haven't touched those docs. Phil Archer his co-editor
15:17:08 <Phil> Joe: are there gaps, new editors needed, and work items needed
15:17:25 <Phil> Will: will put those work items on next week's agenda
15:17:39 <ivan> q+
15:17:44 <Phil> Will: Do we want to say giving editor's draft
15:17:45 <Wip> ack ivan
15:18:03 <Phil> Manu: don't need to do that (give editor's draft
15:18:25 <Phil> Ivan: they may ask for more specificity
15:18:44 <Phil> Ivan: intention is a resolution to go out for the request and then subsequently list the docs.
15:18:46 <Wip> PROPOSAL: Request horizontal review on our actively developed documents.
15:18:49 <manu> +1
15:18:50 <TallTed> +1
15:18:51 <ivan> +1
15:18:52 <Wip> +1
15:18:53 <ottomorac> +1
15:18:54 <markus_sabadello> +1
15:18:54 <JennieM> +1
15:18:54 <Phil> +1
15:19:03 <JoeAndrieu> +1
15:19:14 <Wip> RESOLVED: Request horizontal review on our actively developed documents.
15:19:22 <pchampin> +1
15:19:25 <Phil> Proposal outcome is unanimous approval
15:19:28 <Wip> Topic: TPAC 10 - 14th November in Kobe, Japan
15:20:21 <Phil> Wip: how much time do we want to at TPAC on this?
15:20:26 <manu> q+ to suggest something.
15:20:29 <Wip> ack manu
15:20:29 <Zakim> manu, you wanted to suggest something.
15:21:19 <Phil> Manu: if we hold a 2-day meeting and did methods group will split the community up if we hold a long meeting.  Perhaps do a one day or half-day and share a 1/2 day with the did methods working group.
15:22:01 <Phil> Manu: want to make sure with  other WGs (DID methods of VC WG)
15:22:21 <Phil> Wip: can use one day effectively - don't need more
15:22:25 <Wip> q?
15:22:48 <Phil> Wip: Keep TPAC on your calendar
15:22:54 <Wip> Topic: DID Core PR Processing
15:23:09 <Phil> Wip one PR to review
15:23:12 <Wip> subtopic: https://github.com/w3c/did/pull/883
15:23:19 <manu> q+
15:23:27 <Wip> ack manu
15:24:04 <Wip> q+
15:24:30 <Wip> ack Wip
15:24:36 <TallTed> q+
15:24:42 <Phil> manu: merged Wip's changes. One last proposal on some language. Asks that we remove normative "may" word. We're requesting spec requirements but if "may" we won't enforce. Change "may" to "can" so it conveys the same thing without normative language which requires a test suite
15:25:18 <Wip> ack TallTed
15:25:22 <Phil> wil: this requires a verification but it doesn't mean you can control the did doc with that verification method
15:25:32 <manu> +1 to what Will just said.
15:26:02 <Wip> q?
15:26:10 <Phil> TallTed: has a modification which TallTed will make shortly
15:26:17 <Wip> Topic: DID Core Issue Processing
15:26:27 <Wip> https://github.com/w3c/did/issues?q=is%3Aissue%20state%3Aopen%20label%3Adiscuss%20sort%3Acreated-asc
15:26:47 <Wip> subtopic: https://github.com/w3c/did/issues/337
15:26:59 <Phil> Wip: issues for discussion first issue: #337
15:27:48 <manu> q+
15:27:51 <Wip> ack manu
15:28:08 <Phil> wip: asking if you are referencing your verification method as a URL, should we drop those query parms for the comparison. Is the version ID in the proof supposed to match that you're trying to resolve
15:28:40 <JoeAndrieu> +1 it is the DID value that matters, not the DID URL
15:28:42 <Phil> Manu: we should drop every parm and fragment. ID value needs to be the base value of the parameter.
15:29:21 <Wip> q+ to ask about vm ids
15:29:27 <Phil> manu: can argue differently, but we make clients become much more complicated when looking at a DID doc, know whether it's a historical doc or not, etc.
15:29:56 <Phil> manu: identifier should be a bare identifier. Nothing more.
15:29:57 <Wip> ack Wip
15:29:57 <Zakim> Wip, you wanted to ask about vm ids
15:30:10 <ottomorac> +1 agree with the proposal from Manu. did.document.id should be a bare identifier.
15:30:20 <manu> Q+
15:30:27 <Wip> https://w3c.github.io/cid/#retrieve-verification-method
15:30:40 <Phil> wip: ID can be did URL, what does that suggest?
15:30:51 <Wip> ack manu
15:31:20 <Wip> +1 to that
15:31:42 <Phil> Manu: we need clarity when you are using the think and what process you're following. Just have no parameters or fragments. But doesn't mean you can't use those elsewhere.
15:31:56 <Wip> q+
15:32:23 <Phil> Manu: use these parameters and queries where are needed and used as inputs to algorithms
15:32:53 <markus_sabadello> q+
15:33:19 <Phil> Manu: the algorithm state when they should have parms and queries
15:33:44 <Phil> s/state/should state/
15:33:50 <JoeAndrieu> q+ to ask about how to profile v CIDs
15:33:53 <Wip> ack Wip
15:33:59 <Wip> https://w3c.github.io/cid/#retrieve-verification-method
15:34:42 <manu> q+
15:34:43 <Phil> wip: if you're verification method is an identifier, and the controller doc is identifier minus the fragment. If it doesn't match an error will be made.
15:34:47 <Wip> ack markus_sabadello
15:34:57 <Phil> Wip: happens in that case?
15:35:39 <Phil> Markus: we're not really dropping anything, we're following the algorithms requirements.
15:36:15 <Wip> ack JoeAndrieu
15:36:16 <Zakim> JoeAndrieu, you wanted to ask about how to profile v CIDs
15:37:08 <Phil> Joe: +1 in general with Manu and Markus's comments. Need to profile against the CID. the integrity constraints on DID are different from controlled identifiers
15:37:33 <Wip> ack manu
15:38:19 <Phil> manu: people can do crazy stuff with specs. Why would someone use a query parm to get to a CID?  You can do that but why would you?
15:38:46 <Wip> q+
15:38:52 <JoeAndrieu> q+ to say most of us don't know why anyone would use CIDs in the first place
15:39:04 <Phil> Manu: the algorithm will fail in the way Wip described it. It should fail there because we don't want that to work
15:39:48 <Phil> Manu: pay attention to the algorithm you're using. Profiling would have to be in the DID spec. Not sure what we'd say there. Would like to resolve this to get to writing the PR
15:40:48 <Phil> Manu: Could also say something like, do not put query parameters in fragment identifiers in DID identifiers - they aren't part of the DID identifer.
15:41:08 <Phil> Manu:  that sounds normative, but let's keep it simple.
15:41:08 <Wip> ack Wip
15:41:44 <manu> +1 to what Will is saying.
15:41:45 <manu> q+
15:41:51 <Phil> wip: Agrees with Manu. Would expect the version ID query identifier is just for that point in time.
15:41:53 <Wip> ack JoeAndrieu
15:41:53 <Zakim> JoeAndrieu, you wanted to say most of us don't know why anyone would use CIDs in the first place
15:42:54 <Wip> ack manu
15:43:17 <Phil> Joe: You can't put parameters in your DID. It doesn't meet DID requirements. CIDs were intended to take CIDs of the DID spec.  Need to be careful about what those who want to use CIDs want to use them
15:44:33 <Phil> Manu: Dangerous path to put parameters in the DID.  Fragment identifiers need to be unique throughout all time. Use unique identifiers for your keys to avoid this.
15:45:10 <Phil> Manu: if you put a version ID parameter in there, you're pushing a lot of complexity into the client. This complicates things enormously
15:45:36 <Wip> Topic: DID Resolution PR Processing
15:45:42 <Wip> https://github.com/w3c/did-resolution/pulls
15:46:00 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/122
15:46:23 <manu> q+
15:46:41 <manu> q-
15:47:15 <markus_sabadello> q+
15:47:19 <Wip> ack markus_sabadello
15:47:24 <Phil> wip: DID verification method brought across to the PR#122  Has this been checked at this point?
15:48:47 <Phil> Markus: the PR is much better at this point. Not sure if you have to check if the identifier is the same as that in the dereferenced form.
15:49:15 <Phil> wip: the verification method controller must equal the controller of the DID - is that always the case?
15:49:19 <manu> q+
15:49:22 <Wip> ack manu
15:49:43 <markus_sabadello> q+
15:50:10 <Wip> ack markus_sabadello
15:50:16 <Phil> manu: if you allow authentication they can operate on your behalf but you can remove them from the write privs to your DID doc
15:51:25 <Phil> Markus: checking the controller of the verification relationship should be checked if verification relationship option is present or not.
15:51:43 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/125
15:51:52 <Phil> Wip: skipping PR#123 is ready to be reviewed.
15:53:37 <Phil> Markus: This PR adds service type that lets you select services from the DID doc.  Algorithm answers questions when service identifier is any URI.  Fixes a bug in processing the relative reference parameter. Relatively big PR. Possibly more reviews would be useful, but it looks like it's in good shape now.
15:53:58 <Wip> q?
15:54:00 <Phil> wip: would be good to get more reviews on this PR
15:54:04 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/135
15:55:07 <ivan> q+
15:55:48 <Wip> ack ivan
15:55:51 <Phil> Markus: fixes the term of the DID doc  in the JSON-LD context.  Preference to just use the JSON-LD structure.
15:56:49 <markus_sabadello> q+
15:56:50 <Phil> Ivan: This goes beyond the PR itself. There are two discussions needed.  1)  we shouldn't use JSON-LD for the sake of it. It makes sense when you have an environment when you are mixing vocabularies with other vocabs.
15:57:30 <Phil> Ivan: This isn't the case with this resolution spec. May want here to say simply this is just JSON and use its terms
15:58:40 <Phil> Ivan: if we want to use JSON-LD we are using linked data. Have to define a proper vocab in the RDF sense  (in turtle, JSON-LD, etc.) this is not the same as th context file. IF we do this we need a voca document specification.
15:59:57 <Phil> Ivan: there are two consequences. Need proper vocab specification. Ivan's happy to do this now that there's useful tool for doing so.
15:59:57 <Phil> Ivan: do we want mutiple vocabularies. One with different uses with DID specific terms used by DIDcore and the resolution spec, etc.
16:00:15 <Phil> Ivan: suggests just using a single one and not having multiple vocabularies.
16:00:25 <markus_sabadello> q-
16:00:32 <Phil> Wip : helpful if Ivan can put this into an issue.
16:00:41 <Phil> scribe -
16:01:00 <pchampin> RRSAgent, make minutes
16:01:01 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/20-did-minutes.html pchampin
16:02:18 <pchampin> s/topic: horizontal review/
16:02:19 <pchampin> RRSAgent, make minutes
16:02:20 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/20-did-minutes.html pchampin
16:12:34 <pchampin> q+
16:15:06 <pchampin> q-
18:16:55 <Zakim> Zakim has left #did