Project Proposal - Coordinating the Solid Specification

[justinwb]

Proposing that the Solid Editorial Team undertakes a project focused on the coordination and orchestration of the v1.0 Solid Specification.

Goal:
Coordinate the completion of a comprehensive and reliable v1.0 specification for Solid.

Approach
The Solid Editorial Team, supported by additional subject matter experts, will provide guidance, encouragement, and coordination to any known panels, individuals, or groups working on Candidate Proposals to the Solid Specification, helping to orchestrate and optimize those efforts to minimize blocking dependencies and maximize high-quality output that will pass in-depth editorial review.

Background
Now that we have an established process, it's time to use it to coordinate our various workstreams into one concerted effort to complete the v1.0 Solid Specification. We can use the structures we now have in place to focus and encourage the work and time people are spending towards this common aim. I believe that an important responsibility of the editorial team is to proactively provide this guidance and coordination. Issues such as solid/process#135, solid/authorization-panel#36, and solid/authorization-panel#33 underscore the need for this.

Proposed Next Steps:

• Itemize the work - Break down the various elements of the specification that are needed for 1.0 as work items.
• Determine order of effort - Consider the dependencies. In what order should this work be tackled? Which are so tightly intertwined that they need to be tackled together?
• Identify active groups and workstreams - Which panel is most equipped to undertake a given item of work? Does one exist? Is it in a healthy working state already?
• Coordinate efforts - Collaborate with panels to guide and encourage their efforts towards the 1.0 Specification plan. What kind of help or encouragement might that panel need to produce output that can support this initiative?
• Plan, Support, and Iterate - Publish an overarching execution plan. Identify efforts for each work item by a given panel or individual. Provide regular updates to the community, and work to constantly keep things heading in the right direction at an acceptable cadence.

[kjetilk]

Yes, indeed! Lets try to find some time to have a proposal for this together when we meet.

[RubenVerborgh]

Fully support this.

Perhaps just replace "Prioritize" by "Determine an order". I want to avoid any perception of it being a judgement of importance.

[dmitrizagidulin]

+1 to all this, and @RubenVerborgh's comment about Determining an Order.

[justinwb]

Fully support this.

Perhaps just replace "Prioritize" by "Determine an order". I want to avoid any perception of it being a judgement of importance.

Adjusted the language above to reflect.

[csarven]

s/plan of attack/execution plan? :p

Sounds good to me.

[justinwb]

s/plan of attack/execution plan? :p

Sounds good to me.

@csarven Adjusted the language above from plan of attack to execution plan 😄

[michielbdejong]

One thing I think should definitely make it into version 1.0, even if nothing else does, is attenuated app authorization.

[RubenVerborgh]

attenuated app authorization

Very basic question, but what is it, and do we have pointers to it?

[michielbdejong]

Ah sorry, basically it's https://forum.solidproject.org/t/read-only-or-sub-folder-oidc-scopes/767 and https://github.com/solid/authorization-and-access-control-panel - in a sentence, and at the minimal level:

If Alice gives Bob read-access to (a part of) her pod, then how can Bob give a document-viewer app "attenuated" access to only one resource on there, but not the others.

So the goal is a situation where Alice has control-access to her entire pod, Bob has read-access to some part of it, and the document-viewer app has read-access to only one single document, so a strict subset of the access that Bob himself has.

In theory this is already possible: Bob emails Alice the origin of the app and which doc it should be allowed to open, and Alice goes and edits the ACL with an acl:origin entry, then emails Bob back. But in practice we (obviously) want a better system for this.

[RubenVerborgh]

Thanks, let’s make a specific issue for this. Lots of dependencies there though, so many other things that need a solution first before we can properly tackle it.