Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct
@/all Solid meetings are using different video conferencing tools/services. They are controlled by different parties. No single party needs to control, start/end meetings or require proprietary tooling to be installed on desktop or run in the browser. We can simplify and keep things neutral - as much as we reasonably can - for the W3C Solid Community Group.
Fortunately, there are already have open source tool/platform/service options eg. Jitsi. I suggest for all spec / panel meetings to happen at:
- https://meet.jit.si/solid-specification (current using Jitsi instance: https://meet.zrh.init7.net/solid-specification )
- https://meet.jit.si/solid-test-suite
- https://meet.jit.si/solid-authentication (currently using https://inrupt.my.webex.com/inrupt.my/j.php?MTID=m131f1588eb27afc298276f1cbf077a79 )
- https://meet.jit.si/solid-authorization ( currently using https://global.gotomeeting.com/join/544111573 )
- https://meet.jit.si/solid-data-interoperability (currently using https://global.gotomeeting.com/join/620786365 )
If anyone would like to raise an objection, please share your preferences or expectations.
(Plenty of other Jitsi instances to choose from: https://jitsi.github.io/handbook/docs/community-instances . We could - although this is a lot more work - even host our own at meet.solidcommunity.net or something but that's probably a bit far down the road.)
1 reply
acp:allows in Link headers. You are also using it in the ACP Document, where it makes sense to have it be related to a acp:AccessPolicy
If you have an existing application that was built against the Node Solid Server it is likely that changes will need to be made to the application in order to work with the Enterprise Solid Server. This is due to the latest changes in the spec not being reflected in the Node Solid Server. " - can you comment on that @csarven?
Michiel, I think Oz and Emmet can clarify the statements in the blogpost. My interpretation - take this as informal as it can be: the statements in the blogpost alludes to the current activities in the authorization-panel. See the post's link to https://docs.inrupt.com/developer-tools/javascript/client-libraries/tutorial/manage-acp/ for clarification, where it states "ACP is an alternative to Access Control Lists and is being proposed for inclusion in the Solid specifications." That is accurate in that there are a couple of initiatives running in parallel, and this is what I can formally summarise on the current state of the CG's activities:
The authorization-panel is currently/generally transitioning from the Use Cases that was proposed to coming up with (Non-)Functional Requirements. The Requirements will actually be what all proposed solutions need to address as normative spec text. There is also the UC survey to determine which UCs the Community Group is interested in seeing/using/developing for servers/applications so as to help determine and prioritise which UCs the authorization-panel should focus on. At the same time, ACP is a WIP proposal addressing some of the UCs in which are not deemed to be covered by WAC. The details pertaining to delta/overlap between WAC and ACP are also being worked on. To make things even more interesting, there is the possibility of an Authorization Framework for the Solid Ecosystem which might tie up the work, allowing wider coverage of UCs by different (mostly/hopefully orthogonal) authorization systems.
So, it is all moving forward. Things should clear up in the next weeks/month(s?) As for the current Solid Ecosystem, WAC is currently a MUST for Authorization. The output of the authorization-panel will be proposed for the Ecosystem.
