Prioritize initiatives for the panel

[justinwb]

The following initiatives were discussed in the panel meeting on 6/10 as candidates for the panel to focus on. These initiatives should be prioritized in forced-rank order.

Work may happen on more than one initiative in parallel, but should always be aimed on items at the top of the priority list. Please use this issue to suggest adjustments to the list, including adding or removing initiatives, or to provide thoughts on suggested prioritization.

Proposed Initiatives in (suggested) priority order:

1. Document use cases and requirements for authorization
2. Produce normative draft text of the Web Access Control specification
3. Extend WAC specification with client application constraints
4. Extend WAC specification with tagging
5. Extend WAC specification with triple level filtering
6. Extend WAC specification with verifiable credential support

[elf-pavlik]

This Pending PR #28 talks about requesting access. I see it as another initiative. Possibly also notifications sent once access gets granted even if not requested.

[justinwb]

This Pending PR #28 talks about requesting access. I see it as another initiative. Possibly also notifications sent once access gets granted even if not requested.

Should include a standard way for tracking access grants, and remote data that access has been granted to as part of that initiative. Note there is work on a proposal for these in interoperability panel that can be collaborated with

[bblfish]

It may be important to help organize priorities and solutions by making clear general Access Control principles. One principle in client server communication is that the access control issues be something that both client and server are able to reason about together, and with a client that can follow links. See #73

[justinwb]

Note that the following initiatives were voted on and accepted by the panel per the minutes from 6/17. The others haven't been voted on yet.

Document use cases and requirements for authorization: JB+1, EP+1, JC+1, JM+1, HS+1
Produce normative draft text of the Web Access Control specification: JB+1, JM+1, EP+1, JC+1, HS+1
Produce and propose mechanism(s) for client constraints: JC+1, JM+1, JB+1, HS+0, EP+1

[acoburn]

I did not attend the meeting where this was discussed, but here is my +1 on the proposal. Also an extra +1 on prioritizing the documentation of use cases and the generation of normative text. That will provide a good foundation before extensions are added.

[csarven]

This Pending PR #28 talks about requesting access. I see it as another initiative. Possibly also notifications sent once access gets granted even if not requested.

Should include a standard way for tracking access grants, and remote data that access has been granted to as part of that initiative. Note there is work on a proposal for these in interoperability panel that can be collaborated with

Requesting resource access was one of the cases originally proposed for the Notifications Panel ( https://github.com/solid/notifications-panel ): solid/data-interoperability-panel#13 . See also the linked issues as to how this case emerged.

There is certainly a shared interest from different panels.

🚲 ⛏️ Bikeshedding alert: As to which should panel should take lead is another matter. The general protocol and notification shape describing what clients and servers need to do might fall on the notifications panel which can cover the notion of "request" altogether. The authorization panel can define the specific shapes for outgoing/incoming notifications pertaining to access.

[csarven]

Perhaps it goes without saying for all panels but issues pertaining to authz in other repositories (eg. solid/specification) should have some priority or acknowledged here.

[justinwb]

The following three initiatives from the OP have had individual issues created for them:

• Extend WAC specification with tagging (Proposed initiative - Extend WAC specification with tagging #77)
• Extend WAC specification with triple level filtering (Proposed Initiative - Extend WAC specification with triple-level filtering #78)
• Extend WAC specification with verifiable credential support (Proposed Initiative - Extend WAC specification with verifiable credential support #79)

We can continue discussions and vote over whether / when to undertake these in their respective tickets, and this one can be closed.