DID WG Telco

Intros

dlongley: Wasn't on call last week. Dave Longley with DB. Co editors of DID and VC specs

kimhd: Do we want official response to EU issue?

<ivan> Issue on DI in the EU

kimhd: from the DID WG
… DIF wants to advocate for DIDs in EU ARF
… someone opened issue saying they shouldnt be there

kimhd: Not sure it is worth people chiming in on the thread. Think there is some confusion
… would DID WG be interested in collab with DIF to advocate for DIDs in the EU ARF

manu: +1 good to collab with DIF on this
… There are 11 statements that in issue 205 that are wrong or misleading at best

<kimhd> I try

manu: Agree with Kim lets focus on the positives. Make a case for why EU should be considering DIDs
… going to respond as an individual to the issue
… Lets work with DIF agree with kimhd

decentralgabe: Encourage folks to respond directly or continue on mailing list

* Agenda is linked in irc

<decentralgabe> https://www.w3.org/events/meetings/6893c0e2-41b5-4eaf-afc5-c0b46031594a/20240627T080000/

TPAC

<decentralgabe> https://www.w3.org/2024/09/TPAC/

decentralgabe: We have schedule to TPAC announced
… encourage folks to organise travel and accom

<decentralgabe> https://www.w3.org/calendar/tpac2024/

decentralgabe: DID WG to have meetings on monday and tuesday
… encourage folks to start thinking about topics and presentations
… Might be nice to have presentations on where DIDs are used in real world and how they might be used in the future

Processes

decentralgabe: Want to start work on our work items

<decentralgabe> topics/did-wg

<ChristopherA> I'd love to see an agenda item of people seeking collaborators on various DID-WG items.

decentralgabe: Going to go over our processes, should be familiar. Work done via github issues
… We hope to use a consistent labelling system to organise issues
… Editors are empowered to manage labels
… 7 day merge window. P.Rs will be kept open for at least a week
… General practice to try find consensus on issues before opening a PR
… Open to special topic calls, if required

burn: One comment, assume 7 day review policy for any resolution made on a call
… goal to get minutes out within a day of meetings so people who didn't attend can review these resolutions
… We are just getting started, for those who havent been around for the start of these things, just bear with us. Groups figure out there processes as they go
… if we miss anything please ping us

Work Item Kick-Off

decentralgabe: Reached out to potential editors for work items
… for did core we have manu markus steve and dimitri

<ChristopherA> I am interested in Registry

decentralgabe: for did resolution we have manu markus and steve
… looking for more editors if you are interested
… Looking to give time on the next call for editors to present on their work items and issues

<ChristopherA> I'd love to see a did-registry topic call scheduled.

decentralgabe: Want to give group OK to start raising issues and comments
… Note, no meeting next week. We will be meeting again in 2 weeks
… Please use the time to review existing issues etc
… For DID Core, we don't necessarily need FPW. But the chairs think it work following the full process

<ChristopherA> Where does Controller Documents fall?

decentralgabe: any comments or questions

ivan: On issue about DID core, if we go back to a working draft and start from there we would have to think about if this needs a new short name and url

<decentralgabe> did-core editors: Manu S, Markus S, Steve M, Dmitri Z; resolution: Markus S, STeve M, Dmitri Z

ivan: only thing visible on the same url would be a working draft
… This might have side effects for people viewing the spec

ChristopherA: Wondering where the DID controller document falls in our pipeling?
… Also can we get a DID registy call scheduled. Been a while, I would like to know how things have evolved in this area?
… Lot of things to discuss, like keri and others that would be worth discussing

<burn> For reference, the charter: https://w3c.github.io/did-wg-charter/

decentralgabe: I agree, a lot to discss with registries. Have some time allocated at the end of the call to start this

<ivan> VC Controller Document

<Zakim> manu, you wanted to note controller documents

decentralgabe: in terms of controller document, currently a work item in VCWG. Need to figure out how we want to tie these together

manu: Expectation is that when editors present on DID core, we are going to have to figure out our relationship to the controller document work at VCWG
… expect rich discussion

DID Resolution Transfer

<ChristopherA> I'd like to see IETF consider controller documents as well.

<burn> w3c-ccg/did-resolution

decentralgabe: DID resolution document is available as a source document from the CCG group
… no requirement that we use this as starting place. But is a sensible option
… CCG is open for us to begin the transfer
… Want to run a proposal to transfer this

markus_sabadello: I support using DID resolution as a starting point
… My question would be what do we do with the open issues currently in the ccg github

decentralgabe: first thought is handle after migration

ChristopherA: CCG was never authorized to list things that were more than just provisional

<Zakim> manu, you wanted to propose that issues are transferred over and cleaned up here.

<burn> +1 manu

manu: Speak in favour of transfering from CCG. Including all the issues

<JoeAndrieu> +1 to transferring and adopting as initial starting point, including issues

<dlongley> +1

manu: fairly easy lift to pull these in

<Zakim> burn, you wanted to discuss deliverable differences between core and resolution

burn: quick reminder, 2 different document. DID resolution and DID core. Different changes permitted for these documents
… DID Core is in maintenance mode. Wheras resolution is a new working draft rec document

<ChristopherA> +1 as a good draft.

<burn> w3c-ccg/did-resolution

<ChristopherA> +1

<decentralgabe> PROPOSAL: Adopt the DID Resolution repo from the CCG (w3c-ccg/did-resolution) to the W3C to be used as a starting point for the DID Resolution work item, including migrating all issues.

<ChristopherA> +1

+1

<burn> +1

<JoeAndrieu> +1

<JennieM> +1

<manu> +1

<KevinDean> +1

<dlongley> +1

<mccown> +1

<markus_sabadello> +1

<ivan> +1

<shigeya> +1

<bigbluehat> +1

<swcurran> +1

<kimhd> +1

<swcurran> Apologizes for the question, but who is allowed to vote here?

RESOLUTION: Adopt the DID Resolution repo from the CCG (w3c-ccg/did-resolution) to the WG to be used as a starting point for the DID Resolution work item, including migrating all issues.

Registries

<decentralgabe> https://www.w3.org/TR/did-spec-registries/

<decentralgabe> https://w3c.github.io/did-rubric/

decentralgabe: We have 2 registries in scope. One the DID spec restrity, another for the rubric
… both are currently WG notes, we could migrate these to W3C registries
… few approaches. Start from scratch, migrate over, some hybrid
… burn you noted that we should clearly freeze the current registries

burn: because we need to go to a different format for a registries. We need a starting point for that and can use existing as that.
… But i want to recommend that we freeze the existing as is

decentralgabe: also need editors for these work items

ChristopherA: 2 purposes for registry: 1. Make sure people don't stomp on each others namespace.
… We could continue to use CCG or others to continue to manage some provisional things with the registry
… only have WG able to deprecate for example. A higher level of registry.
… important we respect decentralization here though. Remain relatively easy to get provisional etc

<Zakim> JoeAndrieu, you wanted to ask about process

<burn> It was premature for me to suggest freezing the existing ones. I just meant that as a group we will need to create clear advice on how to interpret the original once we are in a world with a completely new document.

JoeAndrieu: agree with ChristopherA, a lot of work to do to update the process
… lets figure this out. Going to take some time
… Want to find out where the process for w3c registry exists
… No process for transfering a registry currently documented. There is a process for starting a registry

<ivan> Registry track process in the process document

JoeAndrieu: The chairs think we need to follow process of creating a registry a new. But can use any starting point

<JoeAndrieu> https://www.w3.org/policies/process/#registries

<decentralgabe> https://www.w3.org/policies/process/#reg-def

burn: Very important we follow a creation process, rather than a transfer process. When we start that process we need to be clear of the difference between these two things that will exist

<Zakim> manu, you wanted to note doing anything drastic this early on would need a discussion.

<ChristopherA> I'd prefer not to grandfather CCG, instead, be a subset of CCG registry.

manu: 23 open P.Rs for DID registrations. Could do something that upsets these people
… Currently 39 issues on the current registry that needs processing
… Need to think carefully how this transfer/freezing will work
… Want to make sure we send the right message

<ChristopherA> @manu, I appreciate that community!

manu: Been a while. We have a large set of volunteers able to do reviews of submissions. Think it is helpful that they do the initial reviews
… Agree with ChristopherA around questions of deprecation. Set a new bar for entry. E.g. need an implementation
… a lot to discuss before we have a registry process
… in the mean time lets continue processing existing entries

decentralgabe: What should we do in terms of the same repo. keep same or move to a new one

<Zakim> swcurran, you wanted to Christopher's comments

decentralgabe: Maybe open an issue on existing repo to conitnue discussion

swcurran: similar comments to manu. The registry undermines DIDs with it being so long
… need to define a process that will make this work
… suggest reorganising the list. Add additional requirements. Categorise the list

<ChristopherA> @swcurran — do you object to being too lists? a provisional vs next level?

<Zakim> JoeAndrieu, you wanted to say I think we could freeze after we have the new registry process ready.

swcurran: try to eliminate the fluff from the registry

<ChristopherA> two lists. Sorry.

<manu> +1 to swcurran on "simple mechanical" proposals we should explore (and I support a number of them)

JoeAndrieu: Think we can be more nuanced in freeze and handoff
… make a decision to adopt current registry and get them into a new process

<swcurran> +1 to Joe's statement

JoeAndrieu: new process should be up, before we freeze the existing. Should not have down time

burn: Apologies for ever using the word freeze, but we are going to create something new. There will be two registries. The original and this new one we are creating
… need to be clear about the distinction

<Zakim> Wip, you wanted to ask if we can freeze for new submissions while continue processing existing

Wip: I was going to say, is there a way to "freeze" the registry... but prefer getting a new one set up first and stop people submitting new ones.

<Zakim> manu, you wanted to preserve the repo and its history.

<burn> We will need a snapshot at a point in time to use as a starting point for the new doc.

manu: I agree with what has been said. Concerns about loosing history
… doesn't feel like we need drastic changes, defo a -1 for having new thing loose history associated with it
… history is important to understand when DID methods where added, when changes were made. Etc

<swcurran> +1 to Manu. I think we could just define a new process that floats viable methods -- separating them from the unmaintained. But allowing the unmaintained to exist.

manu: Feels like we can just modify the process and hav a time in which we enact the change. One clear history

yep, that ^

<swcurran> I don't like the idea of a new name space.

Yes, agreed, swcurran

decentralgabe: I see some risk in having 2 separate documents

I'm concerned about having two separate documents, ever.

ChristopherA: My proposal is simple. The WG continues to loan authority to the CCG but ask for a number of changes.
… clear statement about what it means to be provisional
… DID methods are clearly identified as provisional

yes, +1 ChristopherA, I think we can do that in the current document... and we can change the Respec document type as well -- I think we might be making this more complex than it needs to be :) (which will be a shock to no one in this group :P)

ChristopherA: Then the registry that we create as a WG, is a new list. With requirements that you have to have been a provisional in old registry

<burn> manu/swcurran, we may not have a choice on namespace because this will be a W3C technical report in that namespace

ivan: registries at w3c is a new thing. Has to go through a long process including a vote through the AC
… like a rec but not IPR as far as I know
… this takes time, need to factor this in
… if we follow the model of ChristopherA, we can say everything in the existing registry is provisional

burn, hmm, right if we're forced to change away from this URL: https://www.w3.org/TR/did-spec-registries/ -- I'm more concerned about the content having continuity than the URL.

<swcurran> If the we change the name space, we deprecate/redirect the old to the new. I just don't like the idea of two name spaces.

ivan: setting up a new registry is going to take time

manu: Might be making this more complicated than necessary.
… Think this can be a simple process
… agree with swcurran, lets not have two namespaces pls

<ChristopherA> 1. provisional methods 2. validated methods 3. ???

ivan: What do we gain by turning what we have into an official W3C registry?

manu: We gain continuity. I don't see why we can;t apply the new rules to the existing registry we have

<swcurran> +1 manu -- what we need to do is sort the list -- float "real" things to the top -- where the creator must meet the "real" bar.

<burn> manu, please review https://www.w3.org/policies/process/#registries . Ivan's question was about why we want create an official W3C registry at all

ivan: To put it another way, what do we loose by cleaning up the existing registry and NOT creating a W3C official registry

manu: I don't think we loose much. Desire for us to classify this as a W3C registry using the new process

<burn> As a WG we can decide NOT to move to the new W3C Registry process.

ChristopherA: I dont see any value in having an official registry. And there are some risks in this
… People may see this as W3C controlling this thing
… whole point of DIDs is to be decentralised. Are we sending wrong message
… What is point of registry. 1. So people don't stomp on other peoples names. 2. To manage expiration, people who drop off. 3. Maybe some level of validation, code exists. It is real.
… Got a new git related proposal, there is an old git namespace registered.. But it isn't really being developed
… How do we handle methods going "stale"

<decentralgabe> w3c/did-spec-registries#565

markus_sabadello: Agree with ChristopherA, however the WG has to find ways to demonstrate interop. Having an official registry may help with that

<TallTed> we should strive to start on time (at top of the hour, x:00), and end at 5-to-the-hour (x:55)

decentralgabe: Thanks for discussion. Speak in 2 weeks.

<ChristopherA> @markus_sabadello maybe a separate registry of methods that have been validated to work with the did-resolver?