Meeting minutes
DID WG Agenda 2024-11-21 https://lists.w3.org/Archives/Public/public-did-wg/2024Nov/0005.html
decentralgabe: welcome everyone
… we'll talk about media types, DID extensions, DID resolution issue & PR processing
… anyone want to add to agenda or introduce themselves?
Announcements
<decentralgabe> https://
decentralgabe: DID Extensions were published to the TR space, thanks to PA for doing that
<decentralgabe> https://
<decentralgabe> https://
decentralgabe: there should be links in the extension section to the 3 other docs
<decentralgabe> https://
decentralgabe: DID resolution is not yet published; PA is working on it by end of month
<Zakim> manu, you wanted to suggest next steps w/ did-extensions (move back to Echidna)
manu: just to follow up on next steps, this was a procedural thing,
… which is great. I'd like us to set these docs back to auto-publish (on anytime a PR is merged, using Echidna)
… I think we've already taken a resolution to use Echidna to publish snapshots, so I don't think any more resolution is necessary
RESOLUTION: https://
manu: for the 4 URLs, I'd like us to transition to using Echidna
… looking for feedback from group / guidance from chairs.
decentralgabe: far as I'm concerned, we did pass the resolution, so you're clear to enable Echidna etc.
manu: will do
decentralgabe: US Thanksgiving is next week, so no meeting.
… so next we'll meet at the APAC friendly time on Thurs Dec 5th, and then regular time Dec 12th
DID Core Resolutions
<mwherman2000> Hi
<ChristopherA> recap yesterdays resolution?
decentralgabe: is the FPWD ready for publication?
manu: +1 to the two things WIll mentioned (media type etc)
… I don't remember if we passed a resolution to adopt application/did media type
… we agreed to use application/did media type, the IANA considerations section needs to be updated
… we need to instruct the W3C staff to register the media type at IANA
… the basis for the registration is the existence of the DID Core 1.0 spec
<manu> https://
manu: so the new spec (the Latest Editor's Draft) has this section in it
… the process is typically - the second you enter CR, you're supposed to request a media type at IANA, we didn't do that,
… due to the 4-year side-quest of multiple suffixes
… so now our media type is just application/did. when we go to register it, we should say that there IS a req,
… and therefore we're requesting this media type for all versions of the DID spec
ivan: why the rush?
… 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.
… the fact that it's in the draft is ok. to get to IETF right now, what do we gain by it?
<Zakim> manu, you wanted to comment on "why the rush"
manu: DID Docs are in production, people are struggling to deploy them using the old invalid mime type
… if we don't rush, we'll be stuck with the wrong media type
ivan: ok
decentralgabe: manu, would you like to run a resolution to solidify this?
manu: yeah, let's
JoeAndrieu: just to clarify, this mime type is for a DID Document, right? Not for Controller Doc or any other artifact?
manu: yes
<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.
<manu> +1
<ivan> +1
<Wip> +1
<dmitriz> +1
<bigbluehat> +1
<JoeAndrieu> +1
<decentralgabe> +1
<JennieM> +1
<TallTed> +1
<danpape> +1
RESOLUTION: 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.
decentralgabe: resolved, please feel free to add this language to the spec
… next, we should pass a similar resolution to move to a FPWD
… and then, if timing is right, add this language to it, email it out to the IANA list
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
<mwherman2000> Hi
manu: we don't need full agreement to publish a FPWD, it's totally legitimate to just get some copy out there
… that puts a stake in the ground around patent review, horizontal review, and so on
… but we shouldn't ask for horizontal review yet until we've aligned with the Controller Document spec, which we're planning on doing
… 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,
then auto-publication will happen as usual
… and after that we'll request horizontal review
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?
… is the mailing list sufficient?
manu: I didn't quite understand the question.
mwherman2000: so, projects are going to prod using the old obsolete DID media type.
manu: yes, and they shouldn't.
mwherman2000: is there a comms plan to broadly inform people about the correct media type?
manu: the IANA registration request is that.
… all we can do is document it in the spec, and then we all reach out to our communities, and pass along the message
… it's not really our job to do that -- we publish the spec, and it goes from there, but we'll do our best.
… at some point we'll ad the media type req to the test suite
ivan: two additional things
… I think that's the main reason why we go to FPWD with 1.1
… otherwise we could wait til Controller Doc sync up happens. but at least for me, that's the main motivation for 1.1
… the other thing - manu you said W3C makes public announcements of these things (which is correct). usually, it's a pretty minimal announcement
… 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
… and I think Michael is right that we should emphasize this media type change
… the announcement goes pretty wide, and is also on the homepage news, and so on
decentralgabe: thanks, makes sense.
<decentralgabe> PROPOSAL: Publish the current DID Core v1.1 Editor's Draft as a First Public Working Draft during the next possible publication window.
<manu> +1
<ivan> +1
<ChristopherA> +1
<dmitriz> +1
<decentralgabe> +1
<Wip> +1
<TallTed> +1
<danpape> +1
<bigbluehat> +1
<mwherman2000> +1
<JennieM> +1
RESOLUTION: Publish the current DID Core v1.1 Editor's Draft as a First Public Working Draft during the next possible publication window.
decentralgabe: thanks manu and everyone. this should unblock things
manu: next steps are - I'll create a static copy, and work with P.-A. to raise the transition request and process it
DID Extensions
w3c/did-extensions#581
decentralgabe: this PR on adding did:tdw to the registry
… chairs have some thoughts, but would like to hear the group discussing
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
… we have legal guidance around Trademark issues.
… 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.
… 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
… so basically the requirement is -- you have to have a registered TM if you want to stop the process
… and point the maintainers to it, then we can stop the registration or de-register
<ChristopherA> +1 manu
manu: otherwise, registration happens (and it's up to the claimant to register the TM and assert it after)
… the other thing we can do is - allow multiple registrations. which is something that's been proposed before
… I don't think it would've helped us in this case
… so regardless we need clear guidance.
… 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.
<Wip> Handling duplicates issue for the minutes - w3c/
decentralgabe: ivan, is there official w3c guidance? we're not lawyers, should not be in the business of legal considerations
… it should be resolved between those submitting the registrations, and others
mwherman2000: there's been some progress, I have a meeting with DIF to discuss this.
… the duplicate registration is slightly of a red herring, it doesn't help the trademark issues
… the other thing is - the interpretation that manu presented with respect to required registered TMs, is that in any existing doc or process?
ChristopherA: I was just looking up the TM policy. I believe we already have a process for that...
… but I need to check
… the question then is - for things that _aren't_ registered TMs. I like manu's proposal
… this is a murky area. DNS world for example also requires a registered Trademarks. so that's good precedent.
… so we should follow suit.
… I also agree that the issue of multiple registrations doesn't solve the trademark issue.
manu: to respond to mwherman2000's question re - do we have this process already documented - yes
<manu> https://
manu: text is a bit old, needs to be updated. specifically, the language that we have in the extensions registry today around Trademarks is -
<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
<manu> the extension to require licensing a patent.
<ChristopherA> …Any addition MUST NOT create unreasonable legal, security, moral, or privacy issues that will result in direct harm to others.
manu: it gives an exmaple - DID methods that use TM'd names
… in the case of did:tdw, it's not a registered TM.
… 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
… so we should clarify the 'concerned' language.
… I'm concerned about the utilization of titles of copyrighted works, that's likely a bad example
… the assertion needs to be based on a legal determination on enforceability
<ChristopherA> ICANN's policy is: "https://
manu: we should follow DNS/ICANN
<mwherman2000> The word registered does not appear in any context in the above document
mwherman2000: I looked at the link above, and the word 'registered' doesn't seem to be there
… I also have issue 580, where I suggest using a domain name through a regular domain registrar
<decentralgabe> w3c/
<manu> yes, that's the problem ^ because that was the intention but we didn't say it.
mwherman2000: it'd be a low-cost way of resolving the issue
<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."
<ChristopherA> So yes, ICANN Is registered trademark.
decentralgabe: ok, let's table that for the special topics call.
DID Resolution Issue & PR Processing
decentralgabe: unfortunately Markus could not make it today
… there are 5 open PRs
5 open PRs
<decentralgabe> https://
<mwherman2000> Unregistered trademarks are recognized as trademarks in Canadian law
<mwherman2000> w3c/
did resolution issues https://github.com/w3c/did-resolution/issues
Wip: I want to talk about enhancements, in this iteration of the work
… at some point soon, there'll be a feature freeze, so we should decide scope
… I have at least one I can speak to
decentralgabe: I see Markus just joined.
Wip: I want to speak to issue 90
w3c/did-resolution#90
Wip: it's an enhancement, as I was reading through the de-referencing language
… basically, should we add some language to the DID Resolution spec about how to deref a verificationMethod
… or verification methods in other verif. relationships (authentication, etc)
… basically, spell out that when you dereference, you need to check that the method is authorized for that verification type
<manu> https://
manu: I thought we had language on that already? (in the Controller Doc)
… what do people think, does that address it?
Wip: I haven't read through that, so, possibly
<mwherman2000> Davos in January?//Davos in January?
markus_sabadello: I agree with Will, it's a common operation, so we do need to specify it somewhere
… I'm not sure if the controller doc section already covers it, will look
… the question is - should we also add a DID Parameter to the Resolver? to make it part of the resolution logic?
manu: yes, we can just link to the Controller Doc section (-1 to duplicating that language in the DID Resolution spec)
… the question was - do we want to add a feature/param to the Resolution spec
… huge +1 to that, that'd be very useful to have
… my hope is that the feature could point to the algorithm we have in the Controller Doc
… since it took a while to craft that language
<Zakim> ChristopherA, you wanted to ask if really need path version of this?
<markus_sabadello> +1
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
… in the DID path component.
… we're putting so many things in the DID path stuff, I want to make sure that's separate
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 the future?
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)
… we do have an open issue in DID Resolution, which is related
<mwherman2000> Thx
markus_sabadello: issue 8 I think
… so if anyone wants to write a PR for that.
<JoeAndrieu> High assurance DIDs: https://
markus_sabadello: related to previous topic, verification relationships and did param -- I agree with Manu that this should ideally reference the algorithm & language in Controller Doc
… this is one of several open issues we have in DID Resolution spec, that propose new DID params for the Resolver
… there's some other issues for enhancements
<mwherman2000> I can work with Markus on the DNS language proposal/PR
decentralgabe: let's leave the issue open until the Controller Doc is ready?
Wip: sounds good
<mwherman2000> DNS is not centralized. Anyone can host one
markus_sabadello: I notice there's 2 open issues that have to do with the 'service' parameter
… which selects the service endpoint, and there's a related param 'relativeRef'
w3c/did-resolution#97
markus_sabadello: used to construct a DID URI
… two issues have been raised that are basically bugs in the current language
… these are issues 61 and 97
https://github.com/w3c/did-resolution/issues/97, w3c/did-resolution#61
markus_sabadello: both can potentially be fixed in a single PR
… so everyone, please contribute
<mwherman2000> Any method can host its own clusters of DNS services e.g. http://
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
… I don't think we quite discussed what should happen here.
… 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?
… 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
… barring someone having a usecase for that (full URL for service endpoint), I wonder if we should support that case?
… the way Twrn is describing it, thinking that the URL part of the ID doesn't matter. But it absolutely does
… so we want to make sure to clarify
<mwherman2000> We shouldn't be building in limitations...who knows how interlinked did documents will be valid and useful
manu: simplest thing, I think, is to only support fragment ID.
… and we focus on -- if you're gonna have a service endpoint, make it an ID, make it be relative
… what do people think?
decentralgabe: we have 2 mins
markus_sabadello: it's a question for DID Core, really
… it just says it must be a URI, doesn't constrain beyond that. I agree with you Manu, though
<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.
markus_sabadello: my expectation has always been - it should just be a fragment / relative uri
<mwherman2000> https://
markus_sabadello: so DID Core should verify the constraints.
<Zakim> ChristopherA, you wanted to add future agenda item.
decentralgabe: thanks for the discussion, we'll continue it
ChristopherA: I'd like to request to look at extending other things than methods. What's the process for that?
… meaning, how do you add a new verification method? (like SSH)
decentralgabe: sounds good, we'll cover it in a special topic call.