2021-07-07.md

2021-07-07 Solid Authorization

https://meet.jit.si/solid-authorization

Agenda

• Minutes - #235
• Close issue 236 on user stories? - #236
• Remove references to acp:AccessPolicy and Access Policy Resources - #234
  • AccessPolicy - #145
  • AccessPolicyResource - #217
  • Policy resource in ontology - #142
• UC1 Resource access - #215
• UC3 Inheritance - #216
• Initial use case for consent workflow - #232 & #231
• Relaxing acl:default - #191
• Remove discussions from the repository - #226 * Part of point below 👇
• Strategy for processing 90 (and growing) issues currently open
• ACP Draft status

Present

• Elf Pavlik
• Eric Pru'Hommeaux
• Justin Bingham
• Henry Story
• Matthieu Bosquet
• Sarven Capadisli

Minutes

ACL default

Let's discuss further on GitHub and catch-up on it next week.

Issues on WAC vs Authorization panel

Sarven: Should we move that issue to the WAC repo?

Henry: But then, should we follow the issues in the WAC repo to discuss them in the authorization panel?

Pavlik: I think that issue should be moved to the WAC repo since it is very specific to WAC.

Henry: What about WAC+?

Sarven: I think high level authorization stuff is ok to be discussed in the authorization panel.

Henry: I'm happy to incubate here and move once there is enough feedback (where there would be more visibility for implementers).

Matthieu: +1 to that

Henry: Is the newest WAC spec finished now?

Sarven: Yes, it is merged and published as an ED. This week I'll make a new PR for the Solid specification. The version that among us should be considered as a working draft kind of document. I don't expect much reviewing to happen. ED is equivalent to a WD. We said that we can't expect changes substantial at any level before we arrive at an implementable spec.

Pavlik: I think I agree with Solid OIDC, but I understood that WAC is a special case, trying to stay more historic and not have substantial changes.

Sarven: No, or rather it is hard to answer. It does not have major changes to what it is supposed to be, as part of the protocol. But that doesn't mean that all the issues and extensions being proposed can't be introduced.

Pavlik: OK, that clarifies my understanding.

Eric: I think the instruction was document as is and carry on.

Sarven: But there are things acknowledged — like client ID, for example, or extended access modes — that could be introduced to WAC. I think we'll go case by case to know whether it is part of this version or subsequent versions.

Henry: I think the imports is one feature that could solve a problem and be moved to WAC+, and it might get more reviews if it is on the WAC repository. Could I move it myself?

Sarven: We have an issue to deal with permissions. Is 210 mature enough to be moved to WAC?

Henry: The UC3 seems to say that :import could be used also by ACP.

Sarven: If it is something that could also be used by ACP, then we should keep it there.

Issues vs discussions

Henry: We can move them and tag them "discussions" but we should also look through the issues to make sure we have the relevant ones tagged accordingly.

Pavlik: The problem would be mostly having the WAC draft being stalled by too many open issues. If you act as an editor of ACP, what can be the best way of having dicipline of processing the issues? It is easier if each draft has its own repo.

Matthieu: I'm fine with the discussions being tagged and mixed with the rest

Pavlik: OK; also maybe create the appropriate template: https://github.com/solid/authorization-panel/blob/main/.github/ISSUE_TEMPLATE/config.yml

ACP draft status

Justin: How will ACP be referenced next to WAC?

Matthieu: I could make the draft PR ready to merge.

Justin: Are you aware of efforts to come for the CSS to support ACP?

Matthieu: I have an implementation ACP written in TypeScript it would require a bit of work to make it work on the CSS but I'm not sure what the sequence of events should be.

Justin: I think review and feedback on a proposed draft is always much more rich and productive when there is some implementation to discuss what is stated in the spec. If the two efforts happen in parallel, you end up with better drafts faster and better implementations. It doesn't mean that they have to be at the same stage, but it is good to have both active in parallel.

Pavlik: I think release early and release often approach is good rather than to have too much. Try to capture what you have and let's iterate.

Matthieu: Agreed.

Actions

• Catch-up on GitHub to make sure the UCs are ready to merge, and merge as soon as consensus is reached.
• Move issue #191 to the WAC repo
• Matthieu to move discussions to issues and maybe add an issue template