Update to the correct location of the did:keri specification. #395
Conversation
Signed-off-by: Phil Feairheller <[email protected]>
pfeairheller
requested review from
kdenhartog,
mprorock,
msporny and
OR13
as code owners
|
Recently in the DIF I&D WG, we had a proposal that
Is there consensus in the KERI community where the Maybe @Joachim16 or @Exulansis can comment? |
|
As the registrant and original author of the As the registrant of this did method isn't it my choice which repo to use? |
If you were a member of DIF, and the KERI spec was submitted under DIF, then it might be the case that DIF has a copyright claim to the specification. This can be the case for W3C specifications (it prevents forking of specifications). That said, many organizations have reverted back to Creative Commons style copyright policies that enable forking, W3C included. I would check to see if DIF 1) has a copyright claim to KERI, 2) if they want to retain that copyright claim and/or the specification at DIF, and 3) get something in writing clarifying the transfer of copyright/home. The above matters to the DID Spec Registries maintainers because we don't want to be caught up in the middle of a copyright violation or a forking disagreement. A statement from DIF that they are aware and are supportive of the move, and a clarification on their copyright policy regarding the move, would help move this PR forward. |
After addressing @msporny's requests/suggestions, I would suggest you also ask an appropriate person at DIF to update that repo with a pointer to the new/current/forever(?) repo, and then archive the outdated DIF repo, so there aren't competing repos moving forward. |
|
@msporny sorry, I'm not a lawyer and don't have much experience with copyrights. The current spec was published with the following: Copyright © 2021 the document editors/authors. Text is available under the Creative Commons Attribution 4.0 International Public License; additional terms may apply. Does that indicate that the copyright does not lie with DIF but with the editors and authors of the document? |
It is a good indicator that DIF doesn't have copyright on the document, assuming that you used the default copyright assertion for ReSpec (the tool that document is using to render the spec) throughout the lifetime of the document, which I assume you did. Sometimes, though, organizations can claim copyright on any document put within their purview (to ensure that the organization can't lose control of work that is done under their purview). You'd want to speak w/ the Chairs of the group that worked on KERI, as I believe that there is a copyright clause in each WG membership document (or one overall for DIF). Perhaps @nembal knows? |
|
This is likely to be a sticky situation that we need to make sure there's alignment between the KERI community on before approving. In the recent past there was a split in the KERI community about how best to progress forward so I suspect there's differing opinions about how this should be handled. I'm not fully read into the resolution that has been made up to this point, so I'd like both sides to weigh in on this DIF/WebOfTrust communities before I make my decision. |
This needs to be bumped to a call with the WG. In particular, we need to decide the process for managing control and/or ownership of entries in the registry. @pfeairheller is listed as one of the contact names in the existing registry. As such, I would presume that his directions should be followed without further recourse. HOWEVER, he is not the editor of the currently listed spec. @SmithSamuelM is. Of course, the registry does not currently list the formal legal entity who has legal control of the entry in the registry. For historical reasons, I would presume the editors of the linked specification are the appropriate controllers. However, since the registry process says nothing about who controls existing entries, we have a significant gap that needs fixing. We should open this up for WG discussion. Managing who controls what entry is going to need a lot more than a "contact name". |
|
If only we had a decentralized identifier system we could use such that one merely had to prove control authority over an identifier to authorize a change to an entry in the registry 😉 In other registries, domain name registration for example, all I have to do is log into my account to prove ownership of the entry I originally created. Using the current state of things with the did method registry, the closest analogy would be the owner of the GitHub account that originally create the entry in the registry. Of course I mention this because my account is the one that originally created the entry for However, if it would further help my cause to have the editor (and creator of KERI) @SmithSamuelM chime in on this change, I'm sure he'd be glad to approve it as I originally created this PR at his behest. |
|
+1 to what @pfeairheller is requesting. |
|
First of all, Thanks @***@***.*** for tagging me. I want to
invite @***@***.*** to this conversation.
Recently, the KERI WG (at DIF) accepted a decision to reorganize the WG
work and move certain work items to other DIF WGs.
did:keri work item will be managed by the DIF Identifiers and Discovery WG
(Chaired my @markus Sabadello ***@***.***>).
Please see ID WG meeting notes here
<https://github.com/decentralized-identity/identifiers-discovery/blob/main/agenda.md>
.
I want to invite the DIF ID WG members to weigh in on this discussion. (I
notified them)
Best regards,
…--
Balázs
ᐧ
On Wed, 29 Dec 2021 at 15:51, Samuel Smith ***@***.***> wrote:
+1 to what @pfeairheller <https://github.com/pfeairheller> is requesting.
—
Reply to this email directly, view it on GitHub
<#395 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEZMU5ADKP33KRCSDHYK2ZLUTMN73ANCNFSM5KVJ6JTQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
The KERI community split and as chairman at the time we moved the work on did:keri outside of DIF. As creator of keri the original dif keri WG chain and the copyright holder of the KERI whitepaper I believe I have a legitimate claim to the did:keri . As far as I can tell the only actual work being done on did:keri is being done by the Phil and myself. |
|
@SmithSamuelM wrote:
FWIW, I agree with the statement above regarding "legitimate claim". I've always found it extremely distasteful when an organization or group attempts to snatch a creator's work away from them without consent. If DIF is going to continue to claim some ownership over a @peacekeeper, since you've been identified as the Chair of that WG, could you provide some input here? (I think @nembal was trying to tag you via email, but it didn't show up in the issue as Github (thankfully) censors email addresses in responses). |
Thanks =) |
|
Agreed, with both the editor and one of the contacts endorsing this change, I don't see any reason the WG should deny the request to update the URL. Should DIF believe this is contrary to their (potential) copyright interests, that is a different matter. But we have a resolution strategy for that. That said, the WG should decide a mechanism to formally recognize the "owner" of entries in the registry. This is a different matter than the owner of the copyright for the method spec. It's also different from the contact person. It is also different from the person who submitted the PR to the registry. These additional factors are good evidence for settling a dispute, but we can't assume that the contact is the legal owner, especially as emails are often personal rather than organizational. For example, while Veres one is listed with an organizational contact, which implies strongly that owner of digitalbazaar.com is the owner of the entry, BTCR only lists four individuals, Christopher Allen, Ryan Grant, Kim Hamilton Duffy. If those four are not in agreement, how do disputes get resolved? Is there no guidance other than seeking redress by the WG then escalating? If just one is ok with a change to the entry, is that sufficient to allow a change? If just one is against a change to the entry, is that sufficient to prevent a change? On a related note, I believe we should not only add a definitive legal owner (and rules for "co-owning") but we should provide means for authenticating the owner programmatically. In particular, if the owner has a DID, we could use an authentication relationship to specify a public key for establishing the current owner. We can also do an email based authentication loop. I was super bummed that Veres One didn't list an email. I have repeatedly asked for contact information from our DID Method entries to support the rubric work and frankly, a web address doesn't really streamline contacting the entry owners. (@manu, please add an email!) Another option would be to list github handles, which can be used for authentication using OAuth. In short, I think we should support something like: "legalOwner" : "legal name" One of the nice features of this approach is that we can automate PRs from authenticatable owners. |
|
Apologies for the late reply… this thread caught me while on vacation. First of all I would like to say that I wear two heads, SC member of DIF and CEO of Jolocom (early contributor to Keri work under DIF - initially ID WG, then Keri WG; https://github.com/decentralized-identity/keriox, chunningham and 35359595) DIF On the base of that, various parties have been contributing to, and promoting Keri, trusting in DIF as organization being the maintainer that takes care of the community and legal governance of spec and code. Dissent I’m not a lawyer as well, so to clarify the legal status of the document in question needs to be reviewed by a legal expert. To my understanding the document was however created when all relevant individuals were contributing under DIF (before the fork). Jolocom Forward
|
Yeah, this was exactly the sort of thing I was concerned about. At this point, the only question that is up for debate wrt. the DID Spec Registries is "Who is the change controller for the did:keri entry?" -- and that is, IMHO and sadly, debatable. I do think there is a stronger argument that @SmithSamuelM and @pfeairheller are the change controllers for the Method... and that is a value judgement (where we value the initial creator of a DID Method with the moral authority to determine how and where it is developed as long as they continue to be involved in the development of said method)... something we have tried very hard to avoid making in the DID Spec Registries. So, let's try this: I'm going to suggest we merge this PR, with @SmithSamuelM and @pfeairheller as the change controllers for the If the merge goes through, there will remain questions around copyrighted contributions to the |
msporny
added
ready to merge
|
I can't comment on the legal situation. I don't know who "owns" KERI and/or did:keri. From my perspective:
I agree with most of what has been said in this thread about change controllers and legal control of registries entries. However, since we don't have clear rules on this right now, I believe we should do our best to make sure the registry entries reflect community consensus. In this case, there is no consensus yet on what the correct location of did:keri is, and it might be better to wait until such consensus is reached, before making changes. |
|
Nothing strange at all about the commit histories @peacekeeper, the document was moved out of the |
There was a problem hiding this comment.
as mentioned by @peacekeeper here in myself here https://github.com/w3c/did-spec-registries/pull/395#issuecomment-1003589987 there are legitimate legal concerns about the change request by @pfeairheller. therefore I object to the change requested
|
I'm not an editor, and I don't have a strong opinion here, and I also agree that deep legal topics or community issues should be discussed elsewhere. But I will note that "contactName == change controller" is an idea that's suddenly being introduced now in this thread. While this does make some sense and may have been the initial assumption of many, this should probably be discussed on a call. I could imagine several situations (besides this one) where such an assumption may not work very well. |
Seems like you're conflating the contact information to mean that this is also the change controller. That was never established before this thread as far as I understand. Can you point me to notes or a github issue that states otherwise? Historically the contact information was a way for the editors to have a point of contact with spec editors if we needed something from them. Not a further granting of privileges which is the problem I see here. It's unclear who should be granted the additional privileges since it wasn't stated from the outset. I'm making the same interpretation as @peacekeeper here that change controller only appeared now in this discussion and it's not clear to me if the 3 contacts were listed as the 3 because they held roles within the KERI WG and therefore were acting on behalf of the WG or whether they are acting on their own volition at the time of registration. This is why I'm trying to get all the facts and this information remains unclear to me. It's very clear to me that @pfeairheller and @SmithSamuelM are the main drivers behind the spec, but I'm concerned that we're endorsing the forking of this work even though one of the reasons I understood that people want specs to be moved to groups like DIF and CCG is because then the rights are maintained by the WG and not by individuals. By allowing individuals to remain the moral controller of the work what additional guarantees are we granted by doing work in the CCG, DIF, IETF or any standards body for that matter? Would we expect the same if members of the CCG objected to moving specs out of the CCG while the editors decided they no longer wanted to deal with the CCG politics? There's a reason that the works we're doing in this community is always being subjected to scrutiny until it's moved into a legal entity which puts everyone on the same ground and I find it antithetical to the purpose of moving work into WGs. This is why I'm trying to clearly understand which hat @pfeairheller @SmithSamuelM and @chunningham were representing at the time when the registration was made and which hat they're wearing now. The way in which we interpret this is going to affect other did methods which also have not determined the change controller which is why I'm trying to get all the facts laid out before weighing in. To be clear here, I'm inclined to allow @pfeairheller and @SmithSamuelM maintain the point of registration for this particular circumstance because I know that's the best thing for the KERI community. However, since we're setting a precedent which grants moral authority of the spec to whoever is the change controller here I want to make it very clear about the facts and circumstances of this so that we can remain consistent on the way in which we're deciding. This allows me to have clear delineations that I can point out to show why I'm deciding differently between different decisions or I can have precedent to point back to if I'm weighing in the same way. Consistency is key here to the future of this registry which is why I'm being so specific about the details here. |
I very strongly agree with Manu on this point. Despite the downsides of a centralized registry for decentralized identifier namespaces, one of the primary reasons for having such a registry is to prevent namespace collisions—and the massive security implications that would have. Multiple implementations of the same DID method specification are fine (though trust decisions about each implementation should be made separately), but confusion about which DID method spec is authoritative for a DID namespace would be a nightmare. |
|
Hey all, I think the |
Sorry, I wasn't very clear. The irony I was referring to was that the authors of that IANA document had anticipated the problems we are now currently encountering by not following that particular guideline. |
|
The issue was discussed in a meeting on 2022-01-11
View the transcript5.
|
|
Per #402 (comment) ... IBM withdrew did:idc partly with this as one of two of their primary reasons. From the owner of the Keri registered trademark: https://www.crownlaboratories.com/terms-of-use/
Should the W3C be in the position of accepting DID Method name registry applications for well known trademarks from other than the rights holder? Perhaps did:keriprotocol is a better choice? |
Crown Laboratories doesn't operate in the IT sector and isn't challenging the claim that the trademark infringes on their uses. Nor do I think they could because they don't operate in the sector. I don't find this to be that compelling of an argument personally. |
|
Crown Laboratories owns the Keri registered trademark and at anytime can be expected to join the Decentralized Movement. It doesn't matter what industry or marketplace they are part of.
The @w3c should consider adopting the Principle that any and every trademark owner is expected to: a) have an app at some point (not disputable) and b) is entitled to use the trademarks they own as DID Method names. It's no different (or shouldn't be any different) from today's world of trademarks, web sites, and domain names.
For example, has the @w3c gone on record with the Fortune 1000 group of companies, in the public press, and/or issued a public press release, about the W3C DID Method Registry and warned trademark owners that their companies' existing trademarks are being put at risk by the current @w3c Registry policies (or lack thereof).
|
|
(I am not a trademark attorney either; my BS-Mgmt/Acctg included only a smattering on the topic --- but that smattering was more than enough to know that you're blowing the smoke of ignorance and FUD, here.) @mwherman2000 -- You are not a trademark attorney, as demonstrated by your original comment about the boilerplate language you found on the Crown website, which you found surprising. For unknown reasons, you did not see fit to respond to my response thereto, nor even to mention it here in your repeat pointer to Crown's boilerplate. Trademarks are not universal nor perpetual, and their validity may be diluted and even ended if the trademark holder fails to assert that holding in a timely fashion. I think it's fairly clear that Crown has failed to do so regarding "keri", just based on the first couple pages of results Google delivers (out of ~58 Million). Trademarks are generally not granted on common spellings of common words, because they're "pre-diluted." (This is generally why you see odd misspellings used as product names.) Whether "keri" would be adjudicated as such a common word is beyond my pay grade, but I would not bet against that determination. (To be more clear: I would bet against Crown securing a judgement against a good-faith use of "keri" in a space outside of Crown's primary businesses and outside of Crown's use of "keri".) Searching the US Patent & Trademark Office's "TESS" site, I find 73 records containing "keri", most unrelated to Crown/Keri Lotion. These records include that string within longer strings, and blends active with inactive records. As should be clear, but I'll state explicitly, these records are only about the USA; they do not cover any other nation's trademark protections.
Nobody "owns" a registered trademark. Trademark registrations expire, among other things, so at best, Crown might be considered to be the current leaseholder.
Yes, for trademark purposes, which is what you are arguing here, it does. |
You're quoting out of context. For Crown Laboratories to be part of the Decentralized Movement and claim a DID Method name, it doesn't matter what industry or marketplace they are part of. That's a truism. They certainly don't have to be primarily involved in IT as @kdenhartog asserted. |
Are you legally representing them and providing the editors here of a public notice on their behalf that this method registration is an infringement on their trademark? If not let's move on from this discussion because there's nothing actionable that I can see coming from this argument. |
Speaking of quoting out of context... Yes, Crown Laboratories could claim a DID Method name. It does not, however, follow that they could claim keri as that DID Method name, for a variety of reasons, not least being that they are not first come (so they cannot be first served) and that they are not the only entity using the name "keri" in commerce with or without trademark registration (so they are not the only entity entitled to use their trademark status as justification for claiming Any entity that has been using "keri" in IT, with or without trademark registration, without a trademark claim being made against them by Crown, has a very strong claim to |
|
@pfeairheller @rh7 @SmithSamuelM -- where are we with this DID Method registration. Has the issue been settled between the various parties, clearing us to merge this entry? |
|
There were several meetings, brokered by @talltree Drummond Reed that resulted in a draft mutual agreement enabling the change. However that agreement has not been finalized. We are waiting on DIF. The draft document reached substantial mutual agreement prior to the last DIF steering committee meeting. There were some last minute edits that Robert Mitwicki wanted to add and he and @Joachim16 (Jolocom) promised to make those and send around the document for final review, but that was over three weeks ago and I have not seen anything since. So we are waiting for DIF. It was discussed at the DIF steering committee 3 weeks ago and I believe got a green light subject to the final edits. I don’t know any more. Maybe Robert Mitwicki or @Joachim16 Jolocom would like to comment on the status. The promise was to have it completed in time for the next DIF steering committee meeting which is imminent. The ball is in DIF’s court. |
|
To add to @SmithSamuelM 's update, I might be part of the bottleneck. @Joachim16 has asked several questions about the draft mutual agreement that I have not responded to due to other workloads. I have pushed it back up the stack and will try to post responses in the next day or so. We should be able to reach closure within the next few weeks. |
|
thank you for clarifying @talltree! And no worries from my side that there are other prios, full empathy. |
|
Any update on this? I prefer not to leave PRs open for many months in a blocked state. It's always possible to raise a PR in the future. I suggest merging this PR or closing it. |
I believe that there is some hope of reaching a resolution to the underlying KERI issues in person at IIW next week. If that's the case, we should be clear to merge. Otherwise, I'll come back in and close this issue. Is that acceptable? |
|
@pfeairheller yes! thanks for the update. |
|
Following some discussions in various community events and channels (IIW, etc.), the proposal to add Therefore, from my perspective this PR here could go ahead. |
|
DIF recently completed a disclosure request to tie up any loose IP ends with respect to KERI. To the extent the questions about IP were an issue for pausing this pull request, I believe those are not resolved. Quoting Paul Grehen " By way of follow up to the earlier email requesting formal disclosure of any essential claims regarding work within the DIF KERI Working Group and respective repositories, we hereby notify that no claims have been made by the end of the notification period. What does this mean? As no formal claims have been made, this clears any respective activity that has occurred within the DIF working group from having any potential impact on ongoing work outside DIF or within the workgroup to the end date of the notification period (25th May 2022). If you have any questions relating to this advice or any aspect of the notification or disclosure request, please don't hesitate to contact DIF directly at [email protected]. Kind regards, Paul Grehan |
OR13
removed
the
do not merge
|
I removed the do not merge label, hopefully waiting another 7 days won't hurt, if someone else has not merged by then, i will merge. |
|
@Joachim16 Do you have any further objections to closing this pull request? |
no objections from my side as Jolocom. I don't speak for the DIF KERI WG nor for DIF as an organization, and would leave this to @rh7 |
|
It seems like all relevant parties are in agreement. I don't see any objections from DIFs' perspective. |
|
That is my understanding as well, so I think we're good to go. Thanks to everyone who has helped work through this. |
The did:keri specification has moved to a new repository located at https://github.com/weboftrust/did-keri/. It is about to receive a major upgrade and we wanted to ensure that the link in the registry is correct.
Signed-off-by: Phil Feairheller [email protected]