Omit solution-centric references

[csarven]

Solution-centric references have no place in a UCR document.

Had there been a prior UCR document, then this current UCR would be an addendum to the prior UCR as additional needs are brought forward, and not because of particular solutions.

[bblfish]

I find that paragraph quite useful, as it helps understand what may be new features that one needs to look at beyond what exists now.

Perhaps the title or text introducing it just needs to be changed. There is nothing wrong with the current deployments being limited, as deployments always are. (They have the advantage of being deployed, which means they show a certain level of consensus).

I am not sure these are solution centric, since no solution is proposed. I am in fact arguing that most of these could work as extensions of WAC as it is now, by removing certain restrictions for example. (But I can't be 100% sure of that of course, as various solutions will need to be tried out).

[csarven]

The point is that the UCR exists independently of the solutions. Just as the very first sentence claims:

The [[#usecases]] in this document represent real-world scenarios that a Solid authorization system should support.

(based on the needs of those that showed-up...)

That's clear and says nothing about any particular solution -- whether it is access control model or capability-based security or something else.

In reality, the UCR document for the most part is done with attribute-based access control in mind. It is trivial to frame the use cases - change the language - such that a particular solution wouldn't at all be in the family of ABAC.. and instead the solutions could strictly be capability-based systems. There is definitely an element of solution-engineering already baked into the current UCR. I think that we don't need to go above and beyond that by actually referring to specific solutions.

[elf-pavlik]

I'm ok as long as we don't just bury it in git history. Maybe before merging this PR we can create an issue for each of the limitations and label it with WAC? Each issue could link to a use case related to the limitation it captures.

[justinwb]

I find that paragraph quite useful, as it helps understand what may be new features that one needs to look at beyond what exists now.

Agree - the section has proven useful already in discussions about why we're spending all of this time on a new and/or evolved approach. That said, it doesn't necessarily have to exist in this document, but it should go somewhere, because it is useful. If we're going to move it, lets first decide where a more suitable place would be for it to live. Alternatively, feel free to suggest better language that would let it fit more naturally in this document.

[csarven]

How about we create issues for the use cases at solid/web-access-control-spec repo? Alternatively, create issues proving that it is a limitation.

[bblfish]

I think opening issues to prove the current spec does not enable these use cases is a good idea. I will try with a few examples by attempting to sketch an implementation that uses WAC and show what extra features would be needed to get what is needed. That would be a good way to build up an idea of what is missing in the current spec. (Is it just some extra piece of vocabulary, is it the way things are deployed, is it reasoning, ...) ? Then it will be up to WAC defenders to show that this can in fact be done, because perhaps I missed something in the specification.

[elf-pavlik]

Maybe let's take it as opportunity to clarify how we will evaluate proposals - seeing WAC as one of them. I think it might be useful to list requirements which given proposal does and doesn't satisfy. Requirements are illustrated by use cases, while proposals I think should satisfy requirements, possibly demonstrating it by showing how use case(s) illustrating this requirement can be implemented. ACP started doing it well in https://github.com/solid/authorization-panel/blob/master/proposals/acp/use-cases.md

Since WAC will stay in it's own repo, we could just create evaluation matrix (as CG note) in this repo and for each proposal check which requirements it satisfies.

EDIT: If such evaluation table makes sense for others I would make PR with template and than we could have another PR mapping what this PR removes to a WAC column in that table. Requirements would be rows.

[justinwb]

EDIT: If such evaluation table makes sense for others I would make PR with template and than we could have another PR mapping what this PR removes to a WAC column in that table. Requirements would be rows.

@elf-pavlik this sounds like a reasonable solution. what would be the ETA on getting this PR submitted to evaluate?

[elf-pavlik]

early poc https://github.com/solid/authorization-panel/pull/180