-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Registry handling #58
Comments
I'll be glad to accept this one as CCG has to figure out how to deal with the VCWG registries. |
The CCG is still figuring out its process. Our intention is to specify an extremely lightweight approach, something like: registries must be created in accordance with W3C policy. That policy is TBD, and the CCG co-chairs are still working through both charter and election issues at the moment. |
Please see also: https://github.com/w3c/did-core-registries |
I think this has been mostly fixed, I have made a lot of updates to: |
This is being discussed in W3C CCG and the hope is we take the best of the DID Spec Registries process, the VCWG Maintenance WG process delegated to W3C CCG, and apply them to how these registries are handled. |
Conversation is ongoing, no resolution yet. |
We need to clearly document the process of how the registry is updated. This issue will be closed when we can point to a clearly documented process in the CCG. |
We had agreement in issue #169 to replace dependencies on registries administered by community groups to registries administered by this working group. Therefore, I consider it a strange proposed regression that we're even talking about "a clearly documented process in the CCG". We should instead be talking about "a clearly documented process described in a DID working group specification". |
At some point, this WG will end and the question of who will maintain the registry then will need to be answered. This was answered in the W3C VCWG by delegating the day-to-day management to the W3C CCG. This group will most likely take the same path... a DID Maintenance WG will be set up where consensus decisions are made in the CCG and then elevated to the DID Maintenance WG for a thumbs up/ thumbs down vote (as a safe guard against bad decisions or things outside of the WG Charter. The process will be defined in the DID Spec Registries document, but the execution of those rules will be delegated to the CCG. The CCG needs a documented process for how they're going to handle their side of this. That has not been completed yet. That's the document we need to be able to point to to ensure that the process on both sides is set up correctly. |
I disagree that this working group will delegate administration of its registries to any community group or other working group. All of those will eventually end. Rather, as discussed during the face-to-face working group meeting in January 2020, the W3C is developing procedures to operate registries itself. We should turn administration of the registries over the W3C when the working group terminates - just as IETF specs turn over ongoing registry administration to IANA - which is constituted for that purpose. @iherman , can you update us on the progress made in establishing W3C registry procedures since January? Thanks! |
Yes, I've participated in those discussions. Here was the latest attempt at the process: https://w3c.github.io/w3process/registries/#registries The work item has been deferred to next years W3C Process: The DID Spec Registries document and process is aligned with the latest general thinking wrt. W3C Registries. That is the process that is defined in the DID Spec registries. We haven't named a custodian yet, and it is presumed that the W3C CCG is a natural maintainer for the registry. We have picked the W3C CCG in the past (for VCWG registry maintenance, Linked Data cryptosuite registry maintenance, etc.) because it has existed for many years, is composed of 400+ people, has a stable process that we can depend on, and we can always fall back to W3C Team as backup in case the W3C CCG fails... it also offloads that work from the W3C Team, whose time is very limited and precious. If you'd like to name some entity other than the W3C CCG as the maintainer, @selfissued, I suggest you make a concrete proposal and put it in front of the group. |
I am afraid there is nothing new to report on this subject, @selfissued; as @msporny said, the issue will be picked up in the process discussions in 2021. Just some comments on what has been said so far:
|
Hi, the CCG is happy to facilitate involvement at whatever desired level as a work item, whether it's the work done in CCG and registry accepted in the DID WG, or any less or greater level of involvement. What do the contributors prefer? |
If this WG is going to be changed into a maintenance WG, then there is nothing to do. If this WG is going to hand over maintenance of the registry to the CCG (just like the VCWG did), then there is nothing to do. The DID Spec Registries document already outlines a process, it needs to be updated, and an issue should be raised over there if anything more needs to be done. Marking this issue as pending close. It will be closed in 7 days unless there are objections. |
As I wrote in August:
We should make an affirmative decision to turn administration over to the W3C after the working group ends. We should also go on record that the registries will not be turned over to any community group. |
@selfissued who will manage pull requests, W3C Staff? I think the amount of work that is necessary to safely support the registry is not comprehended by anyone in the working group.... We need to support:
As long as the WG commits to these things happening.... I don't care who the registries is delegated too... but if any of these things are jeopardized by handing the registry maintenance to some hyper biased / closed / opaque / slow process... This will kill DIDs.... I agree this needs to be defined clearly ASAP. |
There is no affirmative decision needed in my view. W3C owns the rights to the DID Core spec as well as the Registry document. The copyright statement is part of the header of all those documents. When the Working Group charter runs out, it is up to the W3C membership to decide on what happens there, based on the proposal of interested parties. As long as this decision is pending, W3C, as owner of the spec, indeed "administers" the specification. I am not sure what decision this W3C could take.
"turned over" would mean that W3C abandons its copyright. I do not see that happening. However, the ultimate decision of that lies in the hands of the W3C Members; the AC members may vote of, say, rescinding a recommendation and any other document. Legally speaking this WG cannot do anything against that, so such "record" does not really carry any weight in my view. However. The WG can of course go on record, as a group resolution, on a preferred set of actions as for the future of the registries. Following the current practice, the expected approach is to set up a maintenance DID WG (provided, of course, that the W3C Membership votes for such a maintenance group). Such a group does not really do new development, but maintains the IPR on the documents and maintains the registry. The group could then "administer" or "control" the WG registry. The charter of the maintenance WG may include a cooperation with the CCG that could act as an incubator group. All this is the subject of the membership's review vote. There are recent examples. In my own practice only I am staff contact for the VC and JSON-LD "maintenance" Working Groups, and the vote has just ended for the Audiobooks Working Group. All following the same model. Each of those have a strong cooperation with a CG (the CCG for the VC, the JSON-LD CG for, well, JSON-LD, and the Publishing CG for the upcoming Audiobook Working Group). |
The proposal is to:
I have done the first item here: w3c/did-extensions#149 ... which means the only thing left to do is close this issue * for DID Core *. |
I see this was marked pending close 9 days ago, but it appears @selfissued still believes differently. I'll leave this one open while we await response on the options presented by @msporny to go forward (which would leave this issue to be closed). |
Thanks @kdenhartog -- since @selfissued is disagreeing, we'll have to take it up in a call and get a formal resolution to close this. |
@selfissued would you mind making a proposal in advance of the special topic call that addresses my concerns raised here: #58 (comment). I think we can potentially resolve this on this thread if we can make clear proposals, |
@jandrieu and I are currently assigned this issue, but are no longer CCG co-chairs. You probably should make it clear/explicitly invite all three CCG co-chairs to this special meeting. Not all are members of DID-core. |
@wyc and @kimdhamilton are assigned to this issue and have been since June, when @jandrieu and @ChristopherA were unassigned. This issue will be the topic of discussion during a special DID WG call Thursday, December 17, 2020. |
Hi @brentzundel, I plan to attend tomorrow. Basically we need to group to decide what is acceptable for the administration of registries, and we are happy to support any work items if it is agreed that CCG is the right place. |
The issue was discussed in a meeting on 2020-12-17 List of resolutions: Resolution 1: The DID Working Group will maintain the DID Spec Registries until the end of its charter. The DID Working Group plans to request the management of W3C to submit a charter for a maintenance DID Working Group to the W3C Advisory Committee as a successor to this Working Group. Per the planned charter of that Working Group, that group would officially manage the registry, and would do that in cooperation with the W3C Credentials Community Group. Resolution 2: The DID Spec Registries maintenance process will be documented in the DID Spec Registries document.. Resolution 3: The Editors of the DID Spec Registries must consider copyright, trademark, legal, security, moral, and privacy concerns when reviewing additions to the registry and may reject registry entries if they deem the addition would cause undue harm. Considerations will be expressed as policies in the DID Spec Registries Process section. Entities registering items can challenge rejections first with the DID WG and then with the W3C Staff.. Resolution 4: W3C Staff need not be consulted on changes to the DID Spec Registries, but do have the final say on registry contents. This is to ensure that W3C can adeqately respond to time sensitive legal, privacy, security, moral, or other pressing concerns without putting an undue operational burden on them.. View the transcript1. Registry ownership and maintenance roadmapSee github issue #58, did-spec-registries#149. Brent Zundel: we have a large enough group to get started. Ivan Herman: let me try to summarise some things that were discussed. Manu Sporny: agree with ivan. Ivan Herman: we should try to separate those things. Manu Sporny: +1. Brent Zundel: I think we can put those proposals forward.
Ivan Herman: we should be formal, this is a long term commitment. The resolution of this call is not formal, so that should be reaffirmed by the WG next week if possible. Brent Zundel: will add to agenda. Ivan Herman: should be administrative, but prefer to have something like that.
Brent Zundel: next tuesday is last calls of the year, normal call and special topic call. |
As of 2020-12-22, deadline for objecting to resolutions has been extended by the chairs to 2021-01-05 (tuesday). |
Resolution 1 on the call on 2021-01-05 charts a way forward for registry handling once the current WG is closed. Closing issue. |
I am not sure how we should handle the registries (LD Cryptographic Suite Registry, DID method registry) listed in Appendix A. There are discussions at W3C on setting up a somewhat more controlled approach for such registries, and this may be at our disposal in the lifetime of this WG. Alternatively, we may want to publish them as WG notes, to give them somewhat more weight. Something to keep an eye on.
The text was updated successfully, but these errors were encountered: