Decentralized Identifier Working Group

Meeting minutes

Agenda Review

Wip: quick announcement, agenda review, and then some issues and PRs
… I didn't leave time for DID Core... Manu?

manu: just a few things on that. Horizontal review, etc. Just a few minutes probably

Announcement about Affiliation

Wip: I'm no longer formerly representing DCD on these calls.
… I'll be representing Legendary Requirements going forward
… I plan to continue chairing this group for the foreseeable future

ivan: formally, you have to be reappointed as a chair with the change of affiliation
… mostly pchampin can take care of that...but it does have to be done.

pchampin: I will start the process to get you reappointed, Wip

DID Core

manu: I prepared a 1.1 draft

<manu> CR-ready DRAFT has been created: https://lists.w3.org/Archives/Public/public-did-wg/2025Sep/0005.html

manu: I've sent an announcement email
… this is the first CR ready thing
… changes are reflected in the version history and in the spec
… the implementation report is also ready for 1.1
… this includes 1.0 and 1.1 tests
… ivan, I have not done the Quad comparison between 1.0 and 1.1
… those should match, if they don't, I'll fix it
… our privacy review has been completed
… they've signed off on 1.1
… they did raise one issue that we cannot address in our current charter
… there's a request to improve the review criteria
… that'd be a class 4 change
… which is blocked by a recharter need
… pchampin there's one in here for finalizing the context files pre-req
… staff and chairs will need to sort out timing

<Zakim> JoeAndrieu, you wanted to ask about registry

manu: but everything is preparred

JoeAndrieu: question for manu about the class 4 changes

manu: Kyle wants us to change the specification text
… basically, Kyle wants us to tighten the MUST statements up around DID Methods
… mostly because some of the methods don't have good security sections
… and other folks have raised issues around certain methods being aggressively centralized
… did that put more context around it?

JoeAndrieu: we do have control over the registry
… and we could raise the bar on getting into the registry
… regardless of the spec text

manu: we could, but I'm a bit concerned about adding that at the end of the charter
… vs. putting our time into DID Resolution
… mostly, I'm not sure we have bandwidth

JoeAndrieu: technically, we do have the need to define these rules for the registry anyway
… so maybe we can better express these needs in that activity

Wip: we did take that work on, but agreed we may not have time to do it
… right now, I'm feeling a bit nervous about getting DID Resolution through in time
… but if people have time to push these other things forwards, that's also fine

manu: I don't think there's anything stopping anyone from doing a PR for that registry change
… but I plan to focus on DID Resolution
… maybe JoeAndrieu , you can address it along with Kyle's concerns?

JoeAndrieu: yeah...I've got threat modeling I'm doing
… unfortunately, I can't sign up the way I want to
… but I take the point about the need for the work

Wip: k. I think we're just waiting on other horizontal reviews then

manu: could we do a resolution today?
… it would basically say, we're ready to publish once the horizontal reviews are in
… could we get that on the books?
… I think I set it as 2 weeks after TPAC

Wip: isn't that Thanksgiving?

manu: I tried to avoid that...

Wip: does W3M schedules effect this?

manu: it does. We could say ASAP

Wip: anyone objecting to that?

ivan: our webmaster is not in the US, so Thanksgiving may not be an issue for publication

<JoeAndrieu> +1 to Manu's clarification

JoeAndrieu: will we need another resolution if changes are made after horizontal review?

manu: if some WG participants object to publish it after such changes, we will take another resolution

ivan: this should not be a problem;
… if the horizontal review provide comment, that will prevent us from going to REC, but we can publish a new CR snapshot after the first one

<Wip> PROPOSAL: Publish the DID v1.1 specification (https://w3c.github.io/did/transitions/2025/CR/) as a Candidate Recommendation Snapshot after the Horizontal Review is complete with a target publication date towards the end of November.

<manu> +1

<JoeAndrieu> +1

<pchampin> +1

<TallTed> +1

<pdl> +1

<Wip> +1

<JennieM> +1

<markus_sabadello> +1

<bigbluehat> +1

<ivan> +1

RESOLUTION: Publish the DID v1.1 specification (https://w3c.github.io/did/transitions/2025/CR/) as a Candidate Recommendation Snapshot after the Horizontal Review is complete with a target publication date towards the end of November.

DID Resolution Horizontal Review

Wip: same questions for DID Resolutions; what do we need to bring DID Resolution to CR?

<Wip> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3ATAG

Wip: we need to complete the Security review, Privacy review, TAG review

w3c/did-resolution#185

<Wip> w3c/did-resolution#194

Wip: markus_sabadello already reviewed this; we can discuss it here
… my goal is to have TAG review by the end of the month
… Contrarily to DID core, this is a brand new spec, so we want to give those groups enough time to review.

w3c/did-resolution#191

Wip: this one is currently not assigned to anyone. Is anyone willing to take it?
… There is a link to the questionnaire.

markus_sabadello: I think I said I would do it. I should have time.

Wip: thank you. Please self assign.

TallTed: things are shifting. Not sure this questionnaire is what the group is now looking for.
… The other side is a threat-model based Security consideration section. But this is not yet well defined.

Wip: currently, the documentation says to fill in that questionnaire.
… We are just getting the process started.

<smccown> I just joined, so I didn't get it all, but I'd be happy to help with the privacy questionnaire

w3c/did-resolution#92

Wip: sorry about yesterday, I didn't feel I had enough done to warrant taking time on a call.
… I have done some work on the test suite.
… I have a handful of tests, now waiting for DIDs to be passed in.

<Wip> https://github.com/w3c-ccg/vc-test-suite-implementations/blob/main/implementations/DIF.json

Wip: Are there any implemeters of resolver here (or that we know of) who could submit things?

manu: we intend to submit one, but we have a big backlog.
… We have the resolution software, only not yet the HTTP binding.

<Zakim> JoeAndrieu, you wanted to say we should try to get Shaun Conway's Ixo implementation, but I don't know if they have https

JoeAndrieu: I will try to get Sean Conway's implementation.
… I don't think their implementation is up to speed with our HTTPS approach.

Wip: anyone else we should be reaching out to?

JoeAndrieu: We should ask DCD for a BTCR2 resolver.

manu: we don't formally need to have a test suite, the requirement is to have two independent implementations for each features.

<ivan> +1 to manu

manu: We determine this. Of course a test suite is a good idea to do it.
… But that's not blocking us for going to CR.

Error codes for unsupported DID features

<Wip> w3c/did-resolution#190

JoeAndrieu: it may be that a resolver does not support a specific feature, but it is still a valid DID.

Wip: this is a relatively simple change in the spec. If anybody could propose a PR...

JoeAndrieu: I like markus_sabadello's suggestion in the thread.

markus_sabadello: there is already an error code "Method not supported", and "Unsupported public key type"
… I'll put it also as a comment in there.

Wip: there are probably a few other error kinds that will bubble up with implementation experience

JoeAndrieu: should there be a registry of common error codes across did methods?
… This looks similar to common properties.

manu: you could view it as such, but I'm not sure we need this.

<markus_sabadello> https://www.w3.org/TR/did-extensions-resolution/#error

manu: People can currently use URLs for error codes, which is pretty decentralized.
… Actually, we do define error codes in a vocabulary. We just don't put them in did-extensions.

markus_sabadello: there are already extension error codes that are not in the spec.
… We may have to update the registry.

DID Resolution PR Processing

<Wip> https://github.com/w3c/did-resolution/pulls

w3c/did-resolution#182

TallTed: this PR confuses me. I made a comment to replace "remote DID resolver" to "resolver of remote DID".

<Zakim> JoeAndrieu, you wanted to ask about conformance class

<KevinDean> +1

JoeAndrieu: TallTed's comment made me realize that we are defining conformance classes.
… Maybe that's how we should explain it, and "remote" should indeed apply to the resolver.

markus_sabadello: I also find in the title of the issue confusing
… "https binding" is about how the client interacts with the resolver, not how the resolver interacts with other components

JoeAndrieu: we need to figure out where to say that we have 2 conformance classes, and how to define them.
… Probably in this PR, but not in this section.

<Wip> Seems like it should go here https://w3c.github.io/did-resolution/#conformance

JoeAndrieu: But we do need to define "remote resolver"

Wip: [comment about two conformance classes] I'll add a comment in the issue for otto

w3c/did-resolution#183

Wip: anyone having concerns about this PR?

w3c/did-resolution#192

Wip: another one from Otto, also about binding.

markus_sabadello: it is about adding a POST binding, which we don't have right now.
… I think it is fine.
… It goes together with PR w3c/did-resolution#196 which I submitted.

w3c/did-resolution#196

markus_sabadello: I try to define of how the POST interface would work:
… how you construct the URL, what to put in the headers, in the body.

Wip: review wanted on these PRs.
… Also the OpenAPI YAML needs to be updated.

markus_sabadello: yes

DID Resolution Issue Processing

Wip: we have 33 open issues, quite a few of them related to Horizontal Review, and threat modeling

w3c/did-resolution#163

Wip: we are currently stating that a DID document SHOULD include a 'created' property.
… In some cases it will be made up.

markus_sabadello: I created a PR related to this issue, which has been merged.
… It was reorganizing some sections about metadata but I didn't feel it addressed the main topic of this issue.
… The 'created' property is sometimes verifiable, sometimes self-attested.
… There is some language in the spec about this: what's the source of the metadata?
… Built into the DID method? Something the controller can influence?
… Maybe we need more of this.

Wip: I was thinking about this from the perspective of did:ptcr2

<Zakim> JoeAndrieu, you wanted to mention self-attested metadata seems oxymoronic

Wip: In this case, the DID resolver would probably ignore the SHOULD, it has no way to derive the information.

JoeAndrieu: I'm good with the language SHOULD; it allows for some methods to not provide it if they have good reasons.
… That said, a more conceptual question confuses me, about self-attested properties.
… We don't have a way in BTCR2 to allow the controller to put such metadata in the document, so the self-attested idea does not fit here.

markus_sabadello: this came up with did:web, where self-attested metadata about the DID document can be added.
… You would not trust these values very much, but that would be compliant.
… If you compare this to fully blockchain-based DID methods, with verifiable timestamps... this is what this text is about.
… To allow variations across implementations.

<JoeAndrieu> +1 for what is basically a published "sidecar" style metadata like the DID Loge Entry in webvh

– DRAFT –
Decentralized Identifier Working Group

18 September 2025

Attendees