W3C

– DRAFT –
Decentralized Identifier Working Group

27 February 2025

Attendees

Present
denkeni, JC, KevinDean, manu, markus_sabadello, ottomorac, pchampin, TallTed, Wip
Regrets
-
Chair
Will Abramson
Scribe
ottomorac

Meeting minutes

<KevinDean> https://w3c.github.io/scribe2/scribedoc.html

Agenda Review & Introductions

wip: Welcome everyone. Let Jan Christophe to introduce himself....

JC: happy to be here, thanks for the invite. This my first time here.

<Wip> ?

wip: Any additions to the standard agenda

DID Core Issue Processing

wip: ... ok lets keep going...

wip: Manu some issue you would like to speak about?

Manu: no, been busy with verifiable credential spec.

<Wip> https://github.com/w3c/did/issues

wip: please remember to act on issues that you are assigned to....

w3c/did#805

wip: Let us look at one issue that I wanted to discuss this week....

wip: this issue was raised some time ago... I think I came to the conclusion that perhaps what Rick is asking for is already included...

manu: Yeah I think we should remember that Rieks comment came for 4 years ago when the spec was much newer....

manu: I think we promised to go through the spec top to bottom with a particular look at the property to update semantics....

manu: if that is done Wip, then we could circle back with Rieksj...

wip: Yes I kind of that in my reply....

<Wip> https://www.w3.org/TR/cid/#verification-methods

wip: I think the only place that may be lacking is the CID spec...

wip: I think that was CIDs point in regards to the value of the controller property...

manu: ok for that definition we should point folks to the controller section ...

manu: perhaps we need to clarify some wording about the controllers...

manu: we will likely not update CID spec at this point

<Wip> https://w3c.github.io/did/#service-properties

<pchampin> strictly speaking, this is an editorial change which probably could be published as a proposed amendment to CID 1.0

wip: I think this is addressed, but I will perhaps take one more pass...

wip: ok let give Riejs some time to react....

DID Resolution PRs

manu: reminder to all to write PRs for issues assigned to you :)

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

w3c/did-resolution#126

wip: ok.... so first one...

wip: related to an optional resolution option for relative URLs...

markus_sabadello: this was one of the enhancements that we discussed...

markus_sabadello: there is a section in did-core that talks how to do this...

markus_sabadello: you added a comment wip, that it should be more precise....

markus_sabadello: should we improve the language?

wip: yes, potentially some small tweak...

markus_sabadello: ok will work on it

w3c/did-resolution#125

wip: this is adding a service type parameter.... Markus?

markus_sabadello: this is also an enhancement that we discussed.... this would introduce a parameter to select a service by type....

markus_sabadello: I see that you Wip also had some comments on it....

markus_sabadello: you correctly pointed out some details about it...

wip: yes in regards to the service parameter...

markus_sabadello: Yes i think we discussed about resolution.... and also it would depend on media type as to the list of URIs or service objects...

markus_sabadello: I think it would make sense to update the PR in that regard...

w3c/did-resolution#123

wip: hopefully we can get these updated and merged....

markus_sabadello: yes this is a consequence on the controlled identifier...

markus_sabadello: this PR solves some issues on.. no longer necessary to distinguish between a resolve() and resolveRepresentation() function.

markus_sabadello: from my pov this is looking good

manu: yes +1 to that PR....

manu: yes let me take a look at it...

manu: I undertstand this is a simplification that others have asked

tallted: reminder to use SVG instead of PNG where possible...

pchampin: yes perhaps sad to see the loss of the abstract data model...

pchampin: one argument was that it was not testable...

manu: this has caused so much conflict, that adding any note would just create conflict...

manu: in regards to Teds.. point... I will leave these as PNGs this would be complex...

manu: I think Ted's suggestion is so that we ease everyone's job...

manu: perhaps this can be solved with just HTML and some CSS styling...

<TallTed> +1 as manu says, changing these example images to HTML would be fine.

markus_sabadello: Yes I agree... I think I can use either SVG or HTML... will do that...

wip: ok thanks....

<manu> +1 to raising a separate issue to deal w/ the conversation.

<Wip> w3c/did-resolution#114

wip: if you look at the issue that triggered this change...

wip: is that you were referring to Pierre?

manu: I think its different.... with CBOR LD ....

manu: ... I don't think we should prevent implementations from having other representations of did documents...

manu: this is not an abstract data model thing...

manu: that is a decision up to the implementer...

manu: we can still support accept headers...

w3c/did-resolution#122

wip: ok good. feel like this PR is getting ready.. agree with the image suggestion

wip: so this PR attempts to Define verificationRelationship as a derferencing option

wip: I think this approach works better from my personal perspective...

wip: thoughts from the group?

manu: not sure I got the last bit...

<Wip> did:example:1234?versionId=1#vm-2

wip: yes, let clarify

wip: if I reference that did....

<Wip> https://w3c.github.io/cid/#retrieve-verification-method

wip: so... this the retrieve verification mehtod..... I don't want to call the resolve function again,....

wip: I already have a did document....

wip: basically the verification method identifier.. would not have any parameters...

markus_sabadello: its a bit difficult to combine the 2 algorithms...

markus_sabadello: Not sure this fits in with the rest of the alg...

markus_sabadello: I like your improvement....

markus_sabadello: I wonder if we have to reference the other alg....

markus_sabadello: or just copy some of the steps...

manu: yes, agree you can just copy the steps....

manu: you can run the entire alg... and just have one more step for the verification relationship....

manu: and if you get back a verification method, then ensure it matches the verification relationship...

wip: yes.... I tried do that....

wip: I will take another pass... and do what you suggested Markus...

w3c/did-resolution#119

wip: ok this is pretty straightforward

wip: Add versionId and versionTime to DID resolution options

markus_sabadello: Yes we can probably merge this...

wip: one thing I know, in that did resolution alg.... I know we have placeholders for the version handling....

wip: I don't think the did resolution spec should handle this,.... each did method will probably handle versioning differently...

markus_sabadello: yeah I totally agree....

markus_sabadello: we should probably say in the resolution algorithm to clarify that....

markus_sabadello: saying version id and version time are passed to the did method....

wip: ok yes...

DID Resolution Issue Processing

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

wip: maybe we go into the recently updated....

w3c/did-resolution#12

wip: Design versioning features....

markus_sabadello: I think once we add the options and the PR....

<manu> +1 once versionTime and versionId are merged, we're good to go... issue resolved.

markus_sabadello: I will add a comment on it...

w3c/did-resolution#37

DID-URL uniqueness across time...

wip: Kyle is asking about the keys in the document...

manu: Yes we should allow it.... it is not necesarrily good practice...

manu: we may want to warn people...

manu: in our implementation we just use the public key identifier value as the identifier for the key....

manu: works to guarantee this over time...

<JoeAndrieu> +1 to recommending using keys rather than restricting values

markus_sabadello: I also think we should allow it....

markus_sabadello: yes, you should able to change keys... again not best practice...

markus_sabadello: yes this in general is a feature.... and add a warning

wip: ok yes we can mark as pending closed... and open an issue in did-core along with some security considerations....

manu: before we move on... lets not bury in security considerations...

manu: it should clearly warn people about the implications...

wip: Yes that make sense, but the challenge is also have the CID spec....

manu: Yes that is true....

manu: we should probably have this group take over the CID spec once its published....

w3c/did-resolution#28

'remote' vs 'local' DID Resolvers raised by Chris Allen....

wip: we should probably invite Chris Allen to lead a discussion on this....

wip: does anyone have comments on it...

markus_sabadello: Yes its about architecture and where a resolver is deployed....

markus_sabadello: it needs some updating...

markus_sabadello: its related to trust and selective disclosure... look forward to a discussion on it....

wip: invite the group to read about this... and prepare for the discussion....

w3c/did-resolution#6

DID method governance #6

raised by Markus....

markus_sabadello: yes, I will mark as pending closed....

markus_sabadello: unless anyone has any comments...

<manu> +1 to pending close

w3c/did-resolution#95

Minimizing the extent of profiling of requestors #95

wip: is there an action on this one?

<manu> +1 privacy considerations

markus_sabadello: yes this came up in November, its newer...

markus_sabadello: I think its still valid, perhaps to be addressed in the security considerations...

wip: ok sounds good...

wip: ok last thing I want to mention....

wip: about the APAC call... I have moved to an EU friendly time...

wip: it will be interesting to see who from the APAC time zone joins...

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Succeeded: s/pierre:/pchampin:

Succeeded: s/pierre:/pchampin:

Succeeded 35 times: s/markus:/markus_sabadello:/g

All speakers: JC, Manu, markus_sabadello, pchampin, tallted, wip

Active on IRC: denkeni, JoeAndrieu, KevinDean, manu, markus_sabadello, ottomorac, pchampin, TallTed, Wip