add functional reqs to ucr

[justinwb]

In process PR on functional requirements based on agreed-upon use cases.

[csarven]

Thanks for getting this started. Early feedback:

Unless there is more detailed information recorded on the reasons behind conformance level in the document here besides:

Eric: Change "shall" to "MUST" for anyting related to conformance.

https://github.com/solid/authorization-panel/blob/master/meetings/2020-12-09.md

And alternatively approach that was raised in chat but no response recorded:

As there won't be time for me to speak: Perhaps instead of deciding on MUST or may one can add a heading at the top for the moment saying that some of these are not yet determined. Or also that some need to be possible in the future. So in that case shall allow is not bad either.

https://gitter.im/solid/authorization-panel?at=5fd0ed100697c1210daf2a7d

Here are my thoughts:

I don't see how requirement level keywords for the functional requirements text is particularly useful here. Actual conformance levels are set in the spec language for the requirements that actually make their way into the spec.

If anything, the decision on conformance levels MUST use actual input (data) from the UC survey:

https://github.com/solid/authorization-panel/blob/master/proposals/wac-ucr/uc-survey.md

If we don't have a strong sense of what people are actually pledging to implement and link to their ongoing work, and stick with the outcome of the work - on record - then whatever is being decided here is fairly arbitrary. Or worse, easily manipulated by people's preferences/hypotheticals over tangible/demonstrable work/needs/use.

As ridiculous this may sound, on what ground should access-controls be favoured/required over possession/capability based security (MUST..MAY)? Or why shouldn't a simple UC be favoured / required over a complex one? Yes, I'm aware of the reasons - our gut feelings - based on group's experience.. but that's orthogonal to why are we doing the UCRs and the UC survey in the first place in the authorization-panel. What's the point of these UCs and Rs if the end is pre-determined? We can indeed skip the chatter and just spec-ify our implementations.

So, I propose to use "shall" or non-normative text - which is the norm in the other CG/WGs, see examples listed in solid/specification#9 (comment) - instead of conformance keywords for the functional requirements to get us through. We can decide on the exact levels based on how they work alongside other requirements once we get a better understanding of the proposed solutions to the requirements. As far as I can tell at this time, there is no data besides the UC survey - which needs more responses indeed - that can be used towards determining the conformance levels. It is significant input because it precisely captures what's really desired based on ongoing work and pledges.

[bblfish]

+1 on what @csarven wrote regarding MUST or MAY. Those only need to be used for specs.

Regarding the various forms of access control such as Attribute Based Access Control (ABAC), RBAC, RelBAC, ... I have added a new tag theory so that work in those areas can be discussed, tracked, and the relevance to our work studied.

[justinwb]

+1 on what @csarven wrote regarding MUST or MAY. Those only need to be used for specs.

Have reverted the language back to "shall" in the latest commit.

[bblfish]

I opened an issue to consider efficiency of the protocol as a requirement. #162
Would that fit in here?

[bblfish]

The requirements seem to state that access to ACRs must be limited.

[bblfish]

We need a requirement for the "Limit information disclosure through URI" use case.

This is a security requirement which is completely compatible with the slash semantics of Solid which itself has a very simple answer: distinguish solid:Container from ldp:Containers, and I furthermore believe this answer was agreed upon with @csarven .

We should discuss this in the WG meeting on Wednesday, as I think the agreement is a lot closer than the admittedly very long conversation on the issue (which did not take into account security considerations) would make it seem to be. A simple answer can often get lost in a long conversation.

We here need to build for a broader security community that will by default consider the Tor use case and evaluate our work based on the feasibility of that use case. I would even go so far as to say that anyone who starts thinking about security by default falls into this mode of thinking. You can see that with Emmet who on gitter last week wrote:

saying permission denied exposes the fact that a resource exists. That in itself is leaikage
I would enable 401 in developer mode. But I would change it to 404 in production mode

If you think that way, then you will come to the conclusion that you are leaking even more information when revealing the hierarchy of your containers...

Again. We can get both to work without any problem and have a better protocol for it.

[matthieubosquet]

distinguish solid:Container from ldp:Containers

@bblfish, does this mean that only Solid Containers would enforce slash semantics and LDP Containers would be perfectly usable in and compatible with Solid?

saying permission denied exposes the fact that a resource exists.

It sounds like the correct level of strictness. And by extension, could we say that if I am not allowed to see a resource, I MUST not see any authoritative statement implying its existence, which is stronger than the no semantics in the URI approach?

I think we have a slight problem of conflating information resources with the server-managed statements about them.

Given an information resource x, the statements about x should not be considered part of x.

Statements bridging the information resource layer to RDF via LDP/Solid should probably be considered like the data driven runtime of Solid servers. When someone does a GET request on x, they should only see exactly what they're allowed to see about x, no less, no more.

[bblfish]

distinguish solid:Container from ldp:Containers

@bblfish, does this mean that only Solid Containers would enforce slash semantics and LDP Containers would be perfectly usable in and compatible with Solid?

Yes, LDP Containers would then work with Solid Access control. I think of it as

 solid:Container rdfs:subClassOf ldp:Container

saying permission denied exposes the fact that a resource exists.

It sounds like the correct level of strictness. And by extension, could we say that if I am not allowed to see a resource, I MUST not see any authoritative statement implying its existence, which is stronger than the no semantics in the URI approach? ...

Perhaps we should discuss that particular part on gitter or in a separate issue, as that is now quite tangential to the UCR :-)

[matthieubosquet]

Perhaps we should discuss that particular part on gitter or in a separate issue, as that is now quite tangential to the UCR :-)

Maybe a separate issue?

I couldn't find anything specifically about that. I have a feeling it might also be a more general solid spec issue, besides an authorization one. Do you remember something similar being discussed?

[bblfish]

@matthieubosquet I think there is a discussion of that here: solid/specification#14 (comment) which I got to from the recent gitter discussion.

[bblfish]

Looks good enough to commit.
Further changes can be made in other commits later. What would that be? Eg. standardizing on vocabularies used in other communities: eg: one could use Wallet for a Credential holder, etc...