16:01:18 <RRSAgent> RRSAgent has joined #did
16:01:22 <RRSAgent> logging to https://www.w3.org/2024/11/21-did-irc
16:01:24 <Zakim> Zakim has joined #did
16:01:50 <decentralgabe> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Nov/0005.html
16:02:17 <danpape> danpape has joined #did
16:02:21 <decentralgabe> Topic: DID WG Agenda 2024-11-21 https://lists.w3.org/Archives/Public/public-did-wg/2024Nov/0005.html
16:02:56 <Paul> Paul has joined #did
16:02:56 <decentralgabe> decentralgabe has changed the topic to: DID WG Agenda 2024-11-21 https://lists.w3.org/Archives/Public/public-did-wg/2024Nov/0005.html
16:02:56 <Wip> Wip has joined #did
16:03:04 <Wip> present+
16:03:07 <decentralgabe> present+
16:03:31 <ivan> present+
16:04:27 <danpape> present+
16:06:01 <JennieM> JennieM has joined #did
16:06:02 <dmitriz> scribe+
16:06:06 <JennieM> present+
16:06:09 <JoeAndrieu> JoeAndrieu has joined #did
16:06:19 <dmitriz> present+
16:06:21 <TallTed> TallTed has joined #did
16:06:45 <ChristopherA> ChristopherA has joined #did
16:06:50 <ChristopherA> present+
16:06:55 <dmitriz> decentralgabe: welcome everyone
16:07:12 <dmitriz> ... we'll talk about media types, DID extensions, DID resolution issue & PR processing
16:07:25 <dmitriz> ... anyone want to add to agenda or introduce themselves?
16:07:29 <manu> manu has joined #did
16:07:32 <manu> present+
16:07:33 <dmitriz> topic: Announcements
16:07:34 <decentralgabe> topic: Announcements
16:07:49 <decentralgabe> https://www.w3.org/TR/did-extensions/
16:07:51 <dmitriz> decentralgabe: DID Extensions were published to the TR space, thanks to PA for doing that
16:08:03 <decentralgabe> https://www.w3.org/TR/did-extensions-methods/
16:08:05 <manu> q+ to suggest next steps w/ did-extensions (move back to Echidna)
16:08:06 <decentralgabe> https://www.w3.org/TR/did-extensions-resolution/
16:08:10 <dmitriz> ... there should be links in the extension section to the 3 other docs
16:08:11 <decentralgabe> https://www.w3.org/TR/did-extensions-properties/
16:08:25 <dmitriz> ... DID resolution is not yet published; PA is working on it by end of month
16:08:32 <decentralgabe> ack manu
16:08:33 <Zakim> manu, you wanted to suggest next steps w/ did-extensions (move back to Echidna)
16:08:41 <dmitriz> manu: just to follow up on next steps, this was a procedural thing,
16:08:56 <dmitriz> ... which is great. I'd like us to set these docs back to auto-publish (on anytime a PR is merged, using Echidna)
16:09:12 <dmitriz> ... I think we've already taken a resolution to use Echidna to publish snapshots, so I don't think any more resolution is necessary
16:09:17 <decentralgabe> resolution: https://www.w3.org/2024/09/24-did-minutes.html#r02
16:09:22 <dmitriz> ... for the 4 URLs, I'd like us to transition to using Echidna
16:09:23 <TallTed> present+
16:09:38 <dmitriz> ... looking for feedback from group / guidance from chairs.
16:09:51 <dmitriz> decentralgabe: far as I'm concerned, we did pass the resolution, so you're clear to enable Echidna etc.
16:09:53 <dmitriz> manu: will do
16:10:12 <dmitriz> decentralgabe: US Thanksgiving is next week, so no meeting.
16:10:26 <mwherman2000> mwherman2000 has joined #did
16:10:31 <dmitriz> ... so next we'll meet at the APAC friendly time on Thurs Dec 5th, and then regular time Dec 12th
16:10:33 <decentralgabe> topic: DID Core Resolutions
16:10:36 <mwherman2000> Hi
16:10:46 <Wip> q+
16:10:51 <ChristopherA> recap yesterdays resolution?
16:10:56 <decentralgabe> ack Wip
16:10:59 <dmitriz> decentralgabe: is the FPWD ready for publication?
16:11:16 <manu> q+
16:11:23 <decentralgabe> ack manu
16:11:29 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/21-did-minutes.html TallTed
16:11:37 <dmitriz> manu: +1 to the two things WIll mentioned (media type etc)
16:11:52 <dmitriz> ... I don't remember if we passed a resolution to adopt application/did media type
16:12:55 <dmitriz> ... we agreed to use application/did media type, the IANA considerations section needs to be updated
16:12:55 <dmitriz> ... we need to instruct the W3C staff to register the media type at IANA
16:13:01 <KevinDean> KevinDean has joined #did
16:13:09 <dmitriz> ... the basis for the registration is the existence of the DID Core 1.0 spec
16:13:16 <TallTed> s/topic: Announcements//
16:13:16 <manu> https://w3c.github.io/did-core/#application-did
16:13:22 <dmitriz> ... so the new spec (the Latest Editor's Draft) has this section in it
16:13:42 <dmitriz> ... the process is typically - the second you enter CR, you're supposed to request a media type at IANA, we didn't do that,
16:13:50 <dmitriz> ... due to the 4-year side-quest of multiple suffixes
16:13:53 <TallTed> i/topic: Announcements/chair: decentralgabe/
16:14:05 <dmitriz> ... so now our media type is just application/did. when we go to register it, we should say that there IS a req,
16:14:16 <dmitriz> ... and therefore we're requesting this media type for all versions of the DID spec
16:14:20 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/21-did-minutes.html TallTed
16:14:26 <ivan> q+
16:14:32 <decentralgabe> ack ivan
16:14:39 <dmitriz> ivan: why the rush?
16:14:59 <dmitriz> ... if we wait until we go to CR with the version we're working on right now, nobody would ask any questions & we don't have to explain ourselves.
16:15:08 <manu> q+ on "why the rush"
16:15:08 <dmitriz> ... the fact that it's in the draft is ok. to get to IETF right now, what do we gain by it?
16:15:12 <decentralgabe> ack manu
16:15:12 <Zakim> manu, you wanted to comment on "why the rush"
16:15:26 <dmitriz> manu: DID Docs are in production, people are struggling to deploy them using the old invalid mime type
16:15:45 <dmitriz> ... if we don't rush, we'll be stuck with the wrong media type
16:15:50 <dmitriz> ivan: ok
16:16:09 <dmitriz> decentralgabe: manu, would you like to run a resolution to solidify this?
16:16:12 <dmitriz> manu: yeah, let's
16:18:18 <bigbluehat> bigbluehat has joined #did
16:18:28 <JennieM> JennieM has joined #did
16:18:43 <dmitriz> JoeAndrieu: just to clarify, this mime type is for a DID Document, right? Not for Controller Doc or any other artifact?
16:18:55 <dmitriz> manu: yes
16:19:27 <decentralgabe> PROPOSAL: Register the media type for application/did at IANA. The media type is for DID Documents as described in DID Core v1.0 and v1.1. The W3C Staff contact will follow the appropriate procedures for registration through IETF and IANA.
16:19:30 <manu> +1
16:19:35 <ivan> +1
16:19:35 <Wip> +1
16:19:35 <dmitriz> +1
16:19:38 <bigbluehat> +1
16:19:40 <JoeAndrieu> +1
16:19:42 <decentralgabe> +1
16:19:42 <JennieM> +1
16:19:43 <TallTed> +1
16:19:48 <danpape> +1
16:19:50 <decentralgabe> RESOLVED: Register the media type for application/did at IANA. The media type is for DID Documents as described in DID Core v1.0 and v1.1. The W3C Staff contact will follow the appropriate procedures for registration through IETF and IANA.
16:20:03 <dmitriz> decentralgabe: resolved, please feel free to add this language to the spec
16:20:11 <dmitriz> ... next, we should pass a similar resolution to move to a FPWD
16:20:27 <dmitriz> ... and then, if timing is right, add this language to it, email it out to the IANA list
16:20:56 <dmitriz> manu: let me add some nuance to that. so the reason we're doing a FPWD sooner rather than later is to kick off the horizontal review sooner
16:20:56 <mwherman2000> mwherman2000 has joined #did
16:21:06 <mwherman2000> Hi
16:21:13 <mwherman2000> q+
16:21:15 <dmitriz> ... we don't need full agreement to publish a FPWD, it's totally legitimate to just get some copy out there
16:21:27 <dmitriz> ... that puts a stake in the ground around patent review, horizontal review, and so on
16:21:43 <dmitriz> ... but we shouldn't ask for horizontal review yet until we've aligned with the Controller Document spec, which we're planning on doing
16:22:01 <dmitriz> ... so, we can do the FPWD, that'll establish a v1.1 for DID Core, then take a few weeks to align with Controller Doc,
16:22:05 <dmitriz> then auto-publication will happen as usual
16:22:11 <dmitriz> ... and after that we'll request horizontal review
16:22:26 <decentralgabe> ack mwherman
16:23:01 <dmitriz> mwherman2000: one of the rationales for the proposal was to shortcut existing project with the old media type. there should be some kind of broad communication plan, to get the message out?
16:23:03 <decentralgabe> q?
16:23:05 <dmitriz> ... is the mailing list sufficient?
16:23:17 <manu> q+
16:23:21 <decentralgabe> ack manu
16:23:27 <dmitriz> manu: I didn't quite understand the question.
16:23:45 <dmitriz> mwherman2000: so, projects are going to prod using the old obsolete DID media type.
16:23:56 <dmitriz> manu: yes, and they shouldn't.
16:24:13 <dmitriz> mwherman2000: is there a comms plan to broadly inform people about the correct media type?
16:24:19 <dmitriz> manu: the IANA registration request is that.
16:24:33 <ivan> q+
16:24:35 <dmitriz> ... all we can do is document it in the spec, and then we all reach out to our communities, and pass along the message
16:24:55 <dmitriz> ... it's not really our job to do that -- we publish the spec, and it goes from there, but we'll do our best.
16:25:10 <dmitriz> ... at some point we'll ad the media type req to the test suite
16:25:27 <decentralgabe> ack ivan
16:25:32 <dmitriz> ivan: two additional things
16:25:40 <dmitriz> ... I think that's the main reason why we go to FPWD with 1.1
16:25:54 <dmitriz> ... otherwise we could wait til Controller Doc sync up happens. but at least for me, that's the main motivation for 1.1
16:26:12 <dmitriz> ... the other thing - manu you said W3C makes public announcements of these things (which is correct). usually, it's a pretty minimal announcement
16:26:38 <dmitriz> ... but we publish the document so that the staff contact and the chairs can ask the staff to include a specific message with the announcement
16:26:55 <dmitriz> ... and I think Michael is right that we should emphasize this media type change
16:27:07 <dmitriz> ... the announcement goes pretty wide, and is also on the homepage news, and so on
16:27:12 <dmitriz> decentralgabe: thanks, makes sense.
16:27:41 <decentralgabe> PROPOSAL: Publish the current DID Core v1.1 Editor's Draft as a First Public Working Draft during the next possible publication window.
16:27:43 <manu> +1
16:27:45 <ivan> +1
16:27:46 <ChristopherA> +1
16:27:46 <dmitriz> +1
16:27:47 <decentralgabe> +1
16:27:48 <Wip> +1
16:27:50 <TallTed> +1
16:27:51 <danpape> +1
16:27:51 <bigbluehat> +1
16:27:51 <mwherman2000> +1
16:27:52 <JennieM> +1
16:28:01 <decentralgabe> RESOLVED: Publish the current DID Core v1.1 Editor's Draft as a First Public Working Draft during the next possible publication window.
16:28:13 <manu> q+
16:28:18 <dmitriz> decentralgabe: thanks manu and everyone. this should unblock things
16:28:21 <decentralgabe> ack manu
16:28:38 <dmitriz> manu: next steps are - I'll create a static copy, and work with P.-A. to raise the transition request and process it
16:28:50 <decentralgabe> topic: DID Extensions
16:28:58 <decentralgabe> subtopic: https://github.com/w3c/did-extensions/pull/581
16:29:04 <manu> q+
16:29:07 <danpape8> danpape8 has joined #did
16:29:11 <dmitriz> decentralgabe: this PR on adding did:tdw to the registry
16:29:20 <dmitriz> ... chairs have some thoughts, but would like to hear the group discussing
16:29:23 <decentralgabe> ack manu
16:29:49 <dmitriz> manu: I think the biggest problem with the PR is that it puts the volunteers (some of which don't have legal representation) in positions where they have to make a judgement call that makes legal implications for them
16:29:54 <dmitriz> ... we have legal guidance around Trademark issues.
16:30:23 <dmitriz> ... in this case, there's a claim of an un-registered Trademark, and that creates a problem - it's not clear what a maintaner should do in this case.
16:30:43 <dmitriz> ... we have two options. one - any trademark dispute is between the entity registering and the person asserting the trademark, it has nothing to do with us
16:30:58 <dmitriz> ... so basically the requirement is -- you have to have a registered TM if you want to stop the process
16:31:09 <dmitriz> ... and point the maintainers to it, then we can stop the registration or de-register
16:31:11 <mwherman2000> q+
16:31:14 <ChristopherA> +1 manu
16:31:26 <dmitriz> ... otherwise, registration happens (and it's up to the claimant to register the TM and assert it after)
16:31:38 <dmitriz> ... the other thing we can do is - allow multiple registrations. which is something that's been proposed before
16:31:48 <dmitriz> ... I don't think it would've helped us in this case
16:31:56 <dmitriz> ... so regardless we need clear guidance.
16:32:14 <ChristopherA> q+
16:32:27 <dmitriz> ... so, 1) if you want to stop a registration, you need to have a registered TM. OR 2) allow multiple DID registration with the same tag.
16:32:28 <Wip> Handling duplicates issue for the minutes - https://github.com/w3c/did-extensions/issues/569
16:32:43 <dmitriz> decentralgabe: ivan, is there official w3c guidance? we're not lawyers, should not be in the business of legal considerations
16:32:51 <decentralgabe> ack mwherman
16:32:55 <dmitriz> ... it should be resolved between those submitting the registrations, and others
16:33:09 <dmitriz> mwherman2000: there's been some progress, I have a meeting with DIF to discuss this.
16:33:23 <dmitriz> ... the duplicate registration is slightly of a red herring, it doesn't help the trademark issues
16:33:41 <manu> q+
16:33:42 <dmitriz> ... the other thing is - the interpretation that manu presented with respect to required registered TMs, is that in any existing doc or process?
16:33:48 <decentralgabe> ack ChristopherA
16:34:04 <dmitriz> ChristopherA: I was just looking up the TM policy. I believe we already have a process for that...
16:34:10 <dmitriz> ... but I need to check
16:34:26 <dmitriz> ... the question then is - for things that _aren't_ registered TMs. I like manu's proposal
16:34:55 <dmitriz> ... this is a murky area. DNS world for example also requires a registered Trademarks. so that's good precedent.
16:34:59 <dmitriz> ... so we should follow suit.
16:35:13 <dmitriz> ... I also agree that the issue of multiple registrations doesn't solve the trademark issue.
16:35:23 <mwherman2000> q+
16:35:46 <decentralgabe> ack manu
16:36:01 <dmitriz> manu: to respond to mwherman2000's question re - do we have this process already documented - yes
16:36:06 <manu> https://www.w3.org/TR/did-extensions/#the-registration-process
16:36:24 <dmitriz> ... text is a bit old, needs to be updated. specifically, the language that we have in the extensions registry today around Trademarks is -
16:36:29 <manu> The language that we have in the extensions registry today around trademarks is this: If there are copyright, trademark, or any intellectual property rights concerns, the addition and use MUST be authorized in writing by the intellectual property rights holder under a F/RAND license. Examples include DID Methods that use trademarked brand names, property names that utilize the titles of copyrighted works, and patented technology that would cause the use of
16:36:29 <manu> the extension to require licensing a patent.
16:36:41 <ChristopherA> …Any addition MUST NOT create unreasonable legal, security, moral, or privacy issues that will result in direct harm to others.
16:36:55 <dmitriz> ... it gives an exmaple - DID methods that use TM'd names
16:36:55 <dmitriz> ... in the case of did:tdw, it's not a registered TM.
16:37:11 <dmitriz> ... so one reading would be, we should let the registration go through. But the first sentence says 'if there are concerns'. which is overly broad
16:37:18 <decentralgabe> q?
16:37:24 <dmitriz> ... so we should clarify the 'concerned' language.
16:37:39 <dmitriz> ... I'm concerned about the utilization of titles of copyrighted works, that's likely a bad example
16:37:55 <mwherman2000> mwherman2000 has joined #did
16:38:16 <dmitriz> ... the assertion needs to be based on a legal determination on enforceability
16:38:21 <ChristopherA> ICANN's policy is: "https://www.icann.org/resources/pages/help/dndr/udrp-en"
16:38:24 <dmitriz> ... we should follow DNS/ICANN
16:38:33 <mwherman2000> The word registered does not appear in any context in the above document
16:38:47 <JennieM> JennieM has joined #did
16:39:14 <decentralgabe> ack mwherman
16:39:27 <dmitriz> mwherman2000: I looked at the link above, and the word 'registered' doesn't seem to be there
16:39:52 <dmitriz> ... I also have issue 580, where I suggest using a domain name through a regular domain registrar
16:39:57 <decentralgabe> https://github.com/w3c/did-extensions/issues/590
16:39:59 <manu> yes, that's the problem ^ because that was the intention but we didn't say it.
16:40:01 <dmitriz> ... it'd be a low-cost way of resolving the issue
16:40:04 <ChristopherA> specific to ICANN: "Annex any documentary or other evidence, including a copy of the Policy applicable to the domain name(s) in dispute and any trademark or service mark registration upon which the complaint relies, together with a schedule indexing such evidence."
16:40:19 <ChristopherA> So yes, ICANN Is registered trademark.
16:40:22 <dmitriz> decentralgabe: ok, let's table that for the special topics call.
16:40:32 <decentralgabe> Topic: DID Resolution Issue & PR Processing
16:40:42 <dmitriz> ... unfortunately Markus could not make it today
16:40:55 <dmitriz> ... there are 5 open PRs
16:40:59 <decentralgabe> subtopic: open 5 prs
16:41:21 <decentralgabe> https://github.com/w3c/did-resolution/pull/101, https://github.com/w3c/did-resolution/pull/100, https://github.com/w3c/did-resolution/pull/99, https://github.com/w3c/did-resolution/pull/98, https://github.com/w3c/did-resolution/pull/96
16:42:04 <mwherman2000> Unregistered trademarks are recognized as trademarks in Canadian law
16:42:04 <TallTed> s/subtopic: open 5 prs/subtopic: 5 open PRs/
16:42:08 <mwherman2000> https://github.com/w3c/did-extensions/issues/586#issuecomment-2465573298
16:42:18 <Wip> q+
16:42:18 <decentralgabe> subtopic: did resolution issues https://github.com/w3c/did-resolution/issues
16:42:23 <decentralgabe> ack Wip
16:42:44 <dmitriz> Wip: I want to talk about enhancements, in this iteration of the work
16:42:46 <markus_sabadello> markus_sabadello has joined #did
16:42:53 <markus_sabadello> present+
16:42:55 <dmitriz> ... at some point soon, there'll be a feature freeze, so we should decide scope
16:43:02 <dmitriz> ... I have at least one I can speak to
16:43:10 <dmitriz> decentralgabe: I see Markus just joined.
16:43:28 <dmitriz> Wip: I want to speak to issue 90
16:43:31 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/90
16:43:48 <dmitriz> ... it's an enhancement, as I was reading through the de-referencing language
16:44:06 <dmitriz> ... basically, should we add some language to the DID Resolution spec about how to deref a verificationMethod
16:44:21 <dmitriz> ... or verification methods in other verif. relationships (authentication, etc)
16:44:41 <manu> q+
16:44:44 <markus_sabadello> q+
16:44:51 <decentralgabe> ack manu
16:44:55 <dmitriz> ... basically, spell out that when you dereference, you need to check that the method is authorized for that verification type
16:45:10 <manu> https://w3c.github.io/controller-document/#retrieve-verification-method
16:45:13 <dmitriz> manu: I thought we had language on that already? (in the Controller Doc)
16:45:27 <dmitriz> ... what do people think, does that address it?
16:45:35 <dmitriz> Wip: I haven't read through that, so, possibly
16:45:38 <manu> q+
16:45:41 <mwherman2000> Aside: is anyone in the community planning to attend the WEF/Davos in January?
16:45:45 <decentralgabe> ack markus_sabadello
16:46:10 <dmitriz> markus_sabadello: I agree with Will, it's a common operation, so we do need to specify it somewhere
16:46:18 <ivan> s/Aside: is anyone in the community planning to attend the WEF/Davos in January?//
16:46:30 <dmitriz> ... I'm not sure if the controller doc section already covers it, will look
16:46:32 <ChristopherA> q+ to ask if really need path version of this?
16:46:55 <dmitriz> ... the question is - should we also add a DID Parameter to the Resolver? to make it part of the resolution logic?
16:47:15 <decentralgabe> ack manu
16:47:42 <dmitriz> manu: yes, we can just link to the Controller Doc section (-1 to duplicating that language in the DID Resolution spec)
16:47:54 <dmitriz> ... the question was - do we want to add a feature/param to the Resolution spec
16:48:01 <dmitriz> ... huge +1 to that, that'd be very useful to have
16:48:14 <dmitriz> ... my hope is that the feature could point to the algorithm we have in the Controller Doc
16:48:26 <dmitriz> ... since it took a while to craft that language
16:48:32 <decentralgabe> ack ChristopherA
16:48:32 <Zakim> ChristopherA, you wanted to ask if really need path version of this?
16:48:34 <mwherman2000> q+ use of DNS services as a DID Document repository/registry
16:48:40 <markus_sabadello> +1
16:48:55 <dmitriz> ChristopherA: I feel like there's two aspects. there's returning this in proofs when dereferencing. but then also there's the 'path' version of this
16:48:58 <markus_sabadello> q+
16:49:13 <dmitriz> ... in the DID path component.
16:49:23 <dmitriz> ... we're putting so many things in the DID path stuff, I want to make sure that's separate
16:49:31 <decentralgabe> ack markus_sabadello
16:49:37 <mwherman2000> q+
16:49:43 <decentralgabe> ack mwherman
16:49:50 <decentralgabe> q+ markus_sabadello
16:50:12 <dmitriz> mwherman2000: this might be for later discussion, but a number of us in web 7.0 project, are using DNS server based DID Doc registries. I wonder how that would factor in, in teh future?
16:50:15 <decentralgabe> ack markus_sabadello
16:50:34 <ivan> s/teh/the/
16:50:55 <dmitriz> markus_sabadello: to answer Michael's question, that is being discussed in a number of places (how would a DNS based trust registry, how it relates to DID resolution etc). there's this concept of High Assurance DIDs (linked to domain names)
16:50:57 <dmitriz> ... we do have an open issue in DID Resolution, which is related
16:51:03 <mwherman2000> Thx
16:51:06 <dmitriz> ... issue 8 I think
16:51:20 <dmitriz> ... so if anyone wants to write a PR for that.
16:51:22 <JoeAndrieu> High assurance DIDs: https://www.ietf.org/archive/id/draft-carter-high-assurance-dids-with-dns-03.html
16:51:51 <dmitriz> ... related to previous topic, verification relationships and did param -- I agree with Manu that this should ideally reference the algorithm & language in Controller Doc
16:52:04 <dmitriz> ... this is one of several open issues we have in DID Resolution spec, that propose new DID params for the Resolver
16:52:09 <dmitriz> ... there's some other issues for enhancements
16:52:21 <mwherman2000> I can work with Markus on the DNS language proposal/PR
16:52:43 <dmitriz> decentralgabe: let's leave the issue open until the Controller Doc is registry?
16:52:55 <dmitriz> Wip: sounds good
16:53:03 <dmitriz> s/is registry/is ready/
16:53:11 <mwherman2000> DNS is not centralized. Anyone can host one
16:53:22 <dmitriz> markus_sabadello: I notice there's 2 open issues that have to do with the 'service' parameter
16:53:37 <dmitriz> ... which selects the service endpoint, and there's a related param 'relativeRef'
16:53:52 <decentralgabe> subtopic: https://github.com/w3c/did-resolution/issues/97
16:53:55 <dmitriz> ... used to construct a DID URI
16:54:04 <dmitriz> ... two issues have been raised that are basically bugs in the current language
16:54:30 <dmitriz> ... these are issues 61 and 97
16:54:39 <decentralgabe> subtopic: https://github.com/w3c/did-resolution/issues/97, https://github.com/w3c/did-resolution/issues/61
16:54:39 <dmitriz> ... both can potentially be fixed in a single PR
16:54:55 <dmitriz> ... so everyone, please contribute
16:55:17 <manu> q+
16:55:23 <decentralgabe> ack manu
16:55:37 <mwherman2000> Any method can host its own clusters of DNS services e.g. http://didns.directory
16:55:45 <dmitriz> manu: I think this issue started on the Controller Doc or DID Core, then got moved to Resolution. I don't know what the right solution is
16:55:52 <dmitriz> ... I don't think we quite discussed what should happen here.
16:56:17 <dmitriz> ... when you provide a service endpoint using your DID, should you be able to use a full URL? or should it just be a fragment identifier to the DID Doc?
16:56:33 <markus_sabadello> q+
16:56:34 <dmitriz> ... I think it'd be weird to use a full URL, unless you're maybe referencing a DID Document, which again I don't quite understand what the use case would be
16:56:55 <dmitriz> ... barring someone having a usecase for that (full URL for service endpoint), I wonder if we should support that case?
16:57:44 <dmitriz> ... the way Twrn is describing it, thinking that the URL part of the ID doesn't matter. But it absolutely does
16:57:53 <dmitriz> ... so we want to make sure to clarify
16:57:54 <mwherman2000> We shouldn't be building in limitations...who knows how interlinked did documents will be valid and useful
16:58:03 <dmitriz> ... simplest thing, I think, is to only support fragment ID.
16:58:20 <dmitriz> ... and we focus on --  if you're gonna have a service endpoint, make it an ID, make it be relative
16:58:47 <decentralgabe> ack markus_sabadello
16:58:50 <ChristopherA> q+
16:58:55 <dmitriz> ... what do people think?
16:58:55 <dmitriz> decentralgabe: we have 2 mins
16:59:01 <dmitriz> markus_sabadello: it's a question for DID Core, really
16:59:01 <ChristopherA> q+ to add future agenda item.
16:59:13 <dmitriz> ... it just says it must be a URI, doesn't constrain beyond that. I agree with you Manu, though
16:59:14 <JoeAndrieu> mwherman2000 DNS is only operationally decentralized. It retains a centralized authority of fewer than 200 blessed root CAs. The hole point of DIDs is to extract ourselves from dependence on that root authority.
16:59:25 <dmitriz> ... my expectation has always been - it should just be a fragment / relative uri
16:59:33 <mwherman2000> https://hyperonomy.com/2019/03/12/internet-protocols-and-standards-not-only-need-to-be-open-but-more-importantly-open-to-innovation/
16:59:46 <dmitriz> ... so DID Core should verify the constraints.
16:59:50 <decentralgabe> ack ChristopherA
16:59:50 <Zakim> ChristopherA, you wanted to add future agenda item.
16:59:52 <dmitriz> decentralgabe: thanks for the discussion, we'll continue it
17:00:13 <dmitriz> ChristopherA: I'd like to request to look at extending other things than methods. What's the process for that?
17:00:27 <dmitriz> ... meaning, how do you add a new verification method? (like SSH)
17:00:35 <dmitriz> decentralgabe: sounds good, we'll cover it in a special topic call.
17:00:46 <ivan> rrsagent, draft minutes
17:00:47 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/21-did-minutes.html ivan
17:00:55 <dmitriz> ... Ok thanks everyone, see you in a few weeks!
17:01:17 <ivan> m2gbot, link issues
17:01:18 <m2gbot> comment created: https://github.com/w3c/did-extensions/pull/581#issuecomment-2491787753
17:01:19 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/90#issuecomment-2491787886
17:01:20 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/97#issuecomment-2491787973
17:01:21 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/61#issuecomment-2491788030
17:01:52 <Paul> Paul has left #did
17:50:16 <brent> brent has joined #did
18:50:25 <dmitriz> dmitriz has joined #did
18:59:35 <bkardell_> bkardell_ has joined #did
19:03:30 <Zakim> Zakim has left #did
20:01:12 <TallTed> TallTed has joined #did
20:57:23 <brent> brent has joined #did
21:53:52 <brent> brent has joined #did
23:57:54 <brent> brent has joined #did