Where should dereferencing details go?

[ChristopherA]

At our meeting today, there was some discussion about what to do about dereferencing path parameters.

One suggestion was to move them entirely out of the extensions document.

Another was to to break up the parameters into two or three categories, essential ones that instructions/hints for a resolver keep in spec, those that result in data another, and then language that explains how methods might override or extend these.

[pchampin]

This was discussed during the did meeting on 24 October 2024.

View the transcript

w3c/did-extensions#565

<ChristopherA> I just added w3c/did-extensions#582

ChristopherA: in issue 565, there is some recent discussion about TPAC slides and meeting notes.
… I want to note we didn't formally accept anything from the proposal.
… there was consensus to do some exploration.
… to recap: we want to avoid name collisions; simple spec requirements; we called them provisional, but we need a PR to renew provision.
… some proposal for an official w3c registry.
… Big thing missing: Joe's issue 569. We have a goal to avoid name collisions, but maybe that shouldn't be a requirement.
… Is there anything we want to firm up or get consensus on?
… any action items?

manu: we need to move this forward. most pressing: create a new view for DID methods.
… people say: too many DID methods. can we clean up abandoned ones?
… maybe say after a period of time, we need to see an implementation. No spec-only methods.
… perhaps we need to see a resolver that works? maybe a driver for universal resolver.

<JoeAndrieu> fyi, 200 methods today

manu: we need a higher bar on methods that we show?
… I am concerned about negative thoughts if our registry has different methods for the same DID method name.
… if we allow it, then maybe a duplicate method needs to have a concreate implementation. or at least more concrete than the previous method.

<Zakim> ChristopherA, you wanted to ask if we should just initially add one or more field to the method json.

ChristopherA: do we want to change this all at once? maybe just add a few field to method's JSON entry.
… if you don't update, we will remove your old method.

<Zakim> JoeAndrieu, you wanted to mention white pages semantics

JoeAndrieu: speak to better semantics: let's call it a white pages? no worries there about duplicates.
… I don't care about people who want centralized registries. we are all about decentralization.

KevinDean: +1 to Joe

<manu> Yes, Joe's arguments for why allowing multiple registrations do resonate with me.

<swcurran> -1 to Joe. We want decentralized identifiers primarily, decentralized DID methods secondarily

KevinDean: but it should be ok for developers of methods to not be production ready yet.

Wip: we should encourage method owners to start making implementations.

manu: I'd be fine if we add expiration date on method specs without an implementation

<swcurran> +1 for expiration. Could also have a second list in the registry of deprecated methods.

manu: we could do it automatically. give people six months to reply or submit something.
… maybe we sort results in registry by most recently updated
… but that might not get us to where we want to be.

<swcurran> +1 to manu

manu: let's propose adding expiration date.

<Zakim> ChristopherA, you wanted to ask "can get consensus to just add expiration date"?

<JoeAndrieu> registration/update?

ChristopherA: +1

ChristopherA: however, we need to address larger problem. people need to fix and update their specs.

ivan: we should say more about what update means. do they just have to change the date, or should be make substantial updates?

KevinDean: I am concerned about governance about this. managing expiration dates is out of scope of our group.

<Zakim> manu, you wanted to note that we can discuss that in another proposal :)

manu: unfortunately, we are well down that path.
… (managing dates)
… I tried to keep my draft proposal above to be simple incremental progress.
… does require more discussion.

Wip: let's talk about this next time.

<Zakim> ChristopherA, you wanted to answer Ivan

ChristopherA: two things: we have volunteers to deal with expiratin dates (CCG, manu)
… want to let ivan know that manu is proposing last updated date, not an expiration date.
… we can automate the filtering of the method list.

ivan: I'm not opposed to last updated. however, I'm uneasy about sticking in things without clear semantics.

KevinDean: I don't have problem with how things are today. But I'm worried about long-term. what happens years down the line if methods aren't updated?

---