Meeting minutes
Wip: [announce agenda], any addition to suggest?
<smccown> PR #610 seems about done. Could we review it?
smccown: w3c/did-extensions#610 is addressing the copyright issue we have been having
… there has been good feedback.
DID Extensions
w3c/did-extensions#610
smccown: I looked at how ICANN is doing.
… Everyone can register a domain. People with copyright must document it.
<Zakim> JoeAndrieu, you wanted to mention international law
wil: thanks for this work, smccown. Everyone, have a loot at the PR.
… I think the PR is good, needs approval.
manu: +1
JoeAndrieu: I don't know what jurisdiction we should base ourselves on. Appart from that, this is good work.
manu: good question.
… I think that we should focus on what can be enforced at an international level.
… People have argued that you can not have a global trademark or an international patent.
… That's not entirely true, even if some countries do not recognize what many do.
… I don't think we need to wait on clarity to accept the language, but I take your point.
<Phil-ASU> Would help if the language was reviewed by as Patent attorney?
manu: See the discussion about allowing duplicates.
w3c/did-extensions#569
manu: If people are not in the same jurisdiction, then we would just keep the duplicate.
manu: this is the POLL we ran last week, with an addition suggested by Markus, to show people the order in which things were registered.
… In case of a conflict, one of the party may go to a court, and come back to us with a court order to remove the entry (if the other party is in the same jurisdiction).
<Phil-ASU> +1 looks reasonable to me.
smccown: I think that's a great proposal.
… From a practical perspective, what happens for implementers (e.g. the universal resolver) when there are duplicates?
decentralgabe: relates to my comments in the last meeting. If we are not the source of truth, other source of truths will emerge.
… I don't think we are the right people to be a source of truth.
markus_sabadello: that's why the registration order is important.
… If you don't know which one to implement, implement the first one -- unless you have good reason to pick another one.
… we should provide some guidelines.
Wip: if we decide to support duplicates, there will be other issues to deal with.
manu: +1 to markus_sabadello about providing guidelines.
<manu> PROPOSAL: Allow multiple registrations in the DID Methods extensions list but make it clear in the registration process that doing so is potentially problematic (due to interop concerns). Duplicates will have an issue raised to track the concern and noted in the list, with the registrants asked to address the concern. Duplicate registrations will be listed in chronological order by date of initial listing.
<ivan> +1
<Wip> +1
<Phil-ASU> +1
<manu> +1
<JoeAndrieu> +1
<swcurran> +1
<TallTed> +1
<bigbluehat> +1
<decentralgabe> +0
<markus_sabadello> +1
RESOLUTION: Allow multiple registrations in the DID Methods extensions list but make it clear in the registration process that doing so is potentially problematic (due to interop concerns). Duplicates will have an issue raised to track the concern and noted in the list, with the registrants asked to address the concern. Duplicate registrations will
<pchampin> +0.5
<Wip> be listed in chronological order by date of initial listing.
<Zakim> manu, you wanted to discuss next steps.
Wip: what are the next steps?
manu: I can raise a PR with updated text, so that we can review it.
… Some mechanical things need to be changed. Entries will need a "first registered" date, which we can derive from the github history.
… We need an issue marker for submissions and duplicates.
<Zakim> JoeAndrieu, you wanted to talk about rules
manu: The text must describe that we allow duplicates, with the appropriate caveat.
JoeAndrieu: wondering if the current rules as framed would satisfy the new Registry process?
pchampin: do we want to move to a W3C Registry?
… I would suggest that we don't call this a registry anymore, as the term comes with expectations of unicity.
… And therefore, that we don't migrate it to a W3C Registry.
manu: there was some confusion. My recollection was that we decided *not* to turn it into a W3C Registry.
… To JoeAndrieu, no the rules are not appropriate right now.
<Zakim> JoeAndrieu, you wanted to say we need to resolve this. I thought we HAD decided to make it a W3C registry, but not call it a "registry"
<Wip> here https://
Wip: we did pass a Resolution saying that our registries are *likely* to be managed as a W3C Registry.
JoeAndrieu: I hope we agreed to not call them "registries", they are friendly list.
… But it was also that we would be guinea pigs to push the W3C process to its limits.
<Zakim> manu, you wanted to note I'm happy to try to make it a registry.
manu: this is more work, and would be a bumpy ride.
… but I agree with Joe that if we are not part of the conversation, we might be imposed things from the outside.
DID Core
<Zakim> manu, you wanted to talk about shortname
manu: I finally made a FPWD snapshot for DID-core.
… Do we still want to call this doc "did-core"?
… The Controlled Identifier Document spec is called cid-1.0
… The reason for calling DID-Core like that was to avoid confusion with DID methods.
… In retrospect, this was not so necessary.
… proposal is to now use the shortname "did" rather than "did-core"
ivan: if we do that, we need to coordinate with webmaster so that the name change appears in the document's history
pchampin: the version-less "did" would point to the latest REC, right?
manu: correct
<Zakim> manu, you wanted to ask the W3C Staff to ask W3M / publishing for a "general pattern".
markus_sabadello: the homogeneity between "cid" and "did" is not necessarily appropriate... "cid" defines a document, "did defines an identifier.
… but I'm not against the change.
manu: that's where we are now. I would argue that eventually, CID should mean "Controlled Identifier".
… We can defer that conversation to the future, but that would be good enough for now.
… to ivan and pchampin: many WGs do the same mistake of not versioning their first recommendation.
… should we suggest a homogeneous way of managing that at W3C? with versionless always pointing to the latest REC?
ivan: there is a page somewhere (I have to find it) about patterns that are done automatically.
… It is not totally an unknown problem.
<manu> PROPOSAL: Change the shortname of did-core to did. Set up redirects for did-core -> did, did -> 1.0 REC, did-1.0 -> 1.0 REC, and did-1.1 to the latest v1.1 version published by Echidna.
<swcurran> Ivan -- would really appreciate you finding that. I'd love to see if for our spec. We're hitting the same issue.
<TallTed> it's *so* much better to initially name as 1.0 and never update, than it is to initially name without version and struggle to rename when what should be 1.1 comes around. "This will never be updated" almost never proves true.
<pchampin> +1
<Wip> +1
<TallTed> +1
<ivan> +1
<manu> +1
<JoeAndrieu> +1
<markus_sabadello> +1
<decentralgabe> +1
<swcurran> +1
<Phil-ASU> +1
RESOLUTION: Change the shortname of did-core to did. Set up redirects for did-core -> did, did -> 1.0 REC, did-1.0 -> 1.0 REC, and did-1.1 to the latest v1.1 version published by Echidna.
<Wip> https://
w3c/did-core#854
manu: I will do this one, this is a lot of surgery for the document
w3c/did-core#842
manu: who ever takes this issue needs to see what happens when you try to normalize DID URLs with existing libraries.
… We should see what they do, make sure that the spec is aligned with what they do.
… This is a class-3 change; we were expecting URLs to be normalized, but where not specific about how this should be done.
… Ideally, we defer to WHATWG spec and see "this is how it should be done", but need to check what libraries actually do.
Wip: anyone willing to take that on?
KevinDean: I volunteer
w3c/did-core#870
manu: this issue is suggesting to describe the intended audience.
… Fairly straightforward editorial.
markus_sabadello: there is a similiar issue in did-resolution, to describe the intended audience.
… Good first issue for anyone willing to contribute.
Wip: I'll take this one, as well as the did-resolution one.
w3c/did-core#860
manu: this one is also for you, Wip :)
… The W3C TAG raised an issue on the CID spec, saying we don't define fragment processing rules.
… It was not a problem when it was plain JSON-LD, but now that it has its own mime-type (and likewise for application/did),
… we need to define fragment-processing rules.
… Actually, I will make a new issue.
… If we are lucky, we can point to CID fragment processing rules, and avoid a class-3 change.
markus_sabadello: the IANA section says that we defer to the fragment-processing rules from JSON-LD.
… Isn't that sufficient?
<JoeAndrieu> +1 for us just using JSON-LD fragment processing rules
manu: now that we made the `@context` optional, and since we target communities that do not like JSON-LD,
… we might get some pushback if we do that.
ivan: is it possible to define a DID document as did+cid, and therefore inherit from CID like that?
manu: we could, but I suggest we don't, considering the troubles we had about this whole suffix question!
… It would be painful to explain which part we inherit, and which part we don't.
ivan: ok, forget it.
w3c/did-core#872 and this w3c/did-resolution#106
markus_sabadello: I created a PR in did-core and a corresponding PR in did-resolution to move the parameters section from did-core to did-resolution,
… as we discussed last time.
<Wip> This w3c/
w3c/did-core#170
Wip: I see this one is pending-close, we should probably close it, we got no response
manu: agreed
w3c/did-core#839
manu: we don't define how you do mutisig in the DID spec.
… We should probably say that multisig is defined by the verification mechanism.
<JoeAndrieu> +1 to Manu's summary
manu: We should add some language pointing to verification methods and cryptosuite, and not say anything more.
markus_sabadello: there is a verification that some people have worked one, "conditional proof" or something like that.
… It is a CCG work item, I will link it to this issue.
… And I can take care of this issue.
w3c/did-core#805
manu: it is a purely editorial clean up of the specification.
… I would suggest to start with the introduction. Touching the terminology will cause a lot of debates.
Wip: anyone interested in this?
[crickets]
w3c/did-core#812
Wip: anyone with experience in delegation, to adapt the examples?
… I do have some code, I can take this one as well.
Next meeting
Wip: this was the last call of the year.
… The next one, 8 Jan, will be a special topic call. We will send a call.
… Happy holiday everyone.
m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/