Meeting minutes
<swcurran> Is there as guide to how to scribe?
<KevinDean> https://
Agenda Review
<Zakim> manu, you wanted to cover other procedural items
Update on Procedural Items
manu: controller document seems to be ready to transition to candidate recommendation.
<manu> https://
manu: will meet after IIW to look at next steps.
manu: once in CR, we can start to modify DID Core Rec.
<manu> Poll to rename Controller Document specification: https://
manu: poll will be open for next three weeks.
<Zakim> ChristopherA, you wanted to ask about latest changes to vc controller potential CR.
<Zakim> manu, you wanted to respond to ChristopherA
<swcurran> The email yesterday says one vote per VCWG member. Not DID WG Members?
manu: TAG taking issues with DID spec
manu: we have been dealing with the issues and no major comments yet
manu: we want to point them to DID Use cases doc, but there is requirements section with 21 points, but controller document only meets 10 of them.
manu: but this group shoudn't be worried about it too much.
christopherA: Did abstract syntax model come up?
manu: not really
<Zakim> ChristopherA, you wanted to ask about CBOR note for controller documents
manu: we added some clarifications that seemed good, they want semantics to be clean, but they didn't ask we take the ADM out.
christopherA: is there sufficient interest in this community to work on CBOR for controller docs?
manu: we could put it in DID core, but not really the best place.
<Zakim> JoeAndrieu, you wanted to say I think it's a new spec
<manu> Agree with Joe that it's a new spec.
JoeAndrieu: want to caution to put it in DID core. should be its own spec.
manu: should just create an issue in DID core to track it, not put text in the spec.
IETF Announcement
wip: should we participate in the IETF meeting?
<Zakim> manu, you wanted to note I can't make next two weeks.
manu: I will be out the next two weeks.
ChristopherA: I will attend the APAC meeting. if we cancel too much, we will lose what interest we have.
<manu> APAC is important, we should keep those meetings (long term).
ChristopherA: hard to keep APAC folks updated without manu?
JoeAndrieu: I will also be there.
DID Extensions
Wip: we want to talk about DID extensions on a more regular basis.
… how can we lead that discussion?
<Zakim> JoeAndrieu, you wanted to bring up semantic overreach: properties changing how we interpret path, query, and fragment parts.
JoeAndrieu: we have properties in the extensions for path parts. might be a bad idea, we need to be clear about different url parts.
markus_sabadello: it might be too late for that, especially regarding other parameters.
… I talked about that in my TPAC presentation.
… sometimes parameters affect resolution, sometimes other processing as well.
ChristopherA: seems like we need hints for resolution mechanism in the extenstions. Maybe hints for the resolver.
… resolver instructions and requests for data should be separate.
<Zakim> manu, you wanted to speak to "too late"
manu: agree, that makes sense.
… re: "too late to do this". There are features we get criticism for. We should try to establish some defaults for how to interpret DID methods.
… worth talking about all the many interpretations. does it harm our ecosystem?
… I don't think we are too late for some did methods that don't have much deployment yet. we should tighten up text around paths and parameters.
Wip: this is important discussion, how to we track this?
ChristopherA: I will start an issue for us.
markus_sabadello: there are also issues on dereferencing. I should break up some of the larger issues and make new smaller ones.
… we created matrix params years ago, we wanted to try to keep things separate between parameters for identifiers.
… maybe we can categorize params in the registration group.
pchampin: default behavior sounds good to me.
<Zakim> JoeAndrieu, you wanted to say we still have issues of conflict when two extensions are both present, but each have different interpretations of a URL part
pchampin: I won't be reassured to hear that DID methods could override default behavior. may hurt interop.
<Zakim> ChristopherA, you wanted to ask what does those people using VC controller want?
JoeAndrieu: we want to make it easy to share properties. maybe explore markus's idea about categrories.
ChristopherA: want to ask manu if we talk about non DID community, do they want something from controller docs?
manu: they just want clearly defined https urls
… activitypub have "active documents"
w3c/did-extensions#565
<ChristopherA> I just added w3c/
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?
DID Resolution
<markus_sabadello> https://
markus_sabadello: please see above link
… there are four initial feedback issues. we need to check if there are other topics and possibly split them up.
Wip: the issues seem broad. we need people to look at them and help split them.
<markus_sabadello> w3c/
markus_sabadello: issue 8 is six years old, but could be interesting to look at
… this one talks about linking DIDs to domain names, other things too.
… this could be a topic at IIW next week.
… should we add any of that language to DID resolution spec?
… or at least we make the spec flexible enough to support it.
Wip: good discussion today.
… next week is APAC meething time.