[wac-ucr] initial use cases

[justinwb]

Initial set of use-cases for web access control.

This pull request supersedes #83, which introduced the definitions that were used extensively in the use cases included in this pull. Consequently, the branch of #83 was merged into this one so the use cases could be authored. Discussions and/or feedback from #83 should/will continue in this PR.

[csarven]

First, please address #83 (comment) .

This PR has the same issue as highlighted in solid/data-interoperability-panel#41 (comment) - I fail to see how Requirements can precede Use Cases. Even the document title follows an intuitive order UC->R.

Legacy Web Access Control does not satisfy the following use cases:

Why would this UCR need to mention the "Legacy" mechanism? Did any of the sample UCRs listed in solid/specification#9 (comment) make a similar contrast?

As mentioned before, there are bits and pieces in this UCR that indicate that what's being documented feels like reverse-engineering the desired outcome - read: probably what's built or will be argued for. Thus the purpose of this document would only justify the outcome "we have a UCR so what follows is legitimate" as opposed to identifying the foundational requirements so that the spec can provide a way to meet them. Are there any UCs or Rs in this document that's marked as out of scope? Did we genuinely write everything here and found out that everything was exactly what we needed in the whole Web access control domain? That'd be pretty impressive though :)

I'll follow up with another review at a later date.

[bblfish]

On the whole I find this document to be very helpful. I think there is enough experience to justify quite precise use cases, and so the reference to legacy implementations also makes sense (one wants to take those into account, as those provide 10 years of experience).
@csarven this is a first version. I think it is fine to add use cases if you feel that something more general is missing. (I thought that a use case for helping minimise privacy of the client was missing so I mentioned that yesterday).

I will review in more detail too.

[csarven]

@bblfish I would not have classified them as legacy or failure of the prior WAC in that case. No need to mention "Legacy".

My general point is that when something like this is defined:

A resource controller is an agent with fully permissioned access and control over one or more resources residing on a resource server on the Web.

and referred right from the beginning of the UC section, it pretty much sets everything there is to follow. It already has the requirements and scope in mind, and what follows is filling in the blanks. So, the issue is not so much about adding use cases but coming to consensus on which ones to remove. And I'm genuinely concerned that this is going to be bloated, and even more concerned that the requirements that will come out of this may not align well with the foundations in other parts of the ecosystem.

As for individual use cases, I'd like to see votes documented as proposed in solid/specification#9 (comment) .

To have a fair and well representative voting, I'd suggest that people working on implementations (and voting +1) indicate what they are working on so that we don't have an overwhelming support of a use case that's of interest to one implementation/team but not to others.

[ericprud]

Is there some word other than "Legacy" that would more neutral? Maybe "conventional"?
I have two reasons that I like including the conventional WAC:

1. swaps some people in very quickly, and those some people are most of the people working on this.
2. it helps us understand why we're bothering with this exercise.

I agree that we shouldn't let conventional WAC define or constrain our solution but I'm in favor of whatever we can include that accelerate this process. IIRC, the LDP WG used the existing OSLC infrastructure to ground our conversations. None of that persistent into the final drafts but it was very useful in early drafts.

[bblfish]

@ericprud I thought "conventional" is not quite right. Perhaps "deployed"

[ericprud]

I can't believe I had to wait most of a minute for your response.

[justinwb]

@csarven

First, please address #83 (comment)

Description text of this PR has been updated to reference back to #83, which was closed when this replaced it.

From #83 (comment) (specific to the definitions section):

The UCR should have no knowledge about the things that's being defined here.

I'm not sure it's possible to write good use cases for a web-based authorization system without using common terms for an authorization system. In the live review in yesterday's panel session, the definitions proved quite helpful in grounding the intended meaning of these terms in the context they were written. At this stage of the draft, it's probably in our best interest to ensure we all mean the same thing when using particular terms.

From #83 (comment) (specific to the definitions section):

When this is defined, it is reverse-engineering the UCR where it should instead work from its own needs to come up with the requirements.

I disagree - these are pretty vanilla definitions of an authorization system. Sure there is a slight bend to known elements given that we're not creating this in a vacuum (we do have an existing scheme that we're looking to improve), but if you asked someone to sit down and write out the elements of a generic access control system, the list would probably look a lot like this.

From #83 (comment) (specific to the definitions section):

Why is the UCR defining terminology instead of referring to where they are actually defined?

To make the text as consumable as possible to the reader, and ensure that there's no ambiguity in the terms used in the text. This is the same strategy used by the Verifiable Credentials WG, and the Decentralized Identifiers WG, which are in a complementary space and share some related subject matter:

• DID Use Cases and Requirements - Concepts of Decentralized Identity
• Verifiable Credentials Use Cases - Terminology

I fail to see how Requirements can precede Use Cases. Even the document title follows an intuitive order UC->R.

Moved requirements to follow use cases in b7cd84e.

Why would this UCR need to mention the "Legacy" mechanism? Did any of the sample UCRs listed in solid/specification#9 (comment) make a similar contrast?

Not that I'm aware of, but I suspect it's because they weren't written after the fact, so there wasn't a prior (legacy) version in the field to compare to. I believe that makes this particular situation unique, and I think it is helpful context for the reader to understand the use cases that aren't believed to be satisfied by what is in the field. I don't know if it should live in this document long-term, but for now it seems to be helpful context.

As mentioned before, there are bits and pieces in this UCR that indicate that what's being documented feels like reverse-engineering the desired outcome

It would be more constructive to provide specific examples, or propose specific adjustments. As written this is difficult to respond to. These are pretty vanilla use cases.

Are there any UCs or Rs in this document that's marked as out of scope?

TLDR; No. There are no Rs submitted yet - only use cases. I would imagine that scoping wouldn't be appropriate until we start writing requirements at the earliest, if not during authoring of the specification text.

Did we genuinely write everything here and found out that everything was exactly what we needed in the whole Web access control domain? That'd be pretty impressive though :)

Assuming this is a rhetorical statement. Per the description in the pull request - this is an initial set of use cases. I'm not aware of any statements to the contrary. I'd be happy to correct them if there are. A sincere effort was made to capture as many unique use cases as possible, including ones that were provided by panel members in the recent weekly sessions.

My general point is that when something like this is defined:

A resource controller is an agent with fully permissioned access and control over one or more resources residing on a resource server on the Web.
and referred right from the beginning of the UC section, it pretty much sets everything there is to follow. It already has the requirements and scope in mind, and what follows is filling in the blanks.

I honestly don't know how we can write precise and detailed use cases for authorizing access to resources without an actor that has permission to authorize access to resources. I don't believe this is over-prescribing given the focus is use cases for web access control.

So, the issue is not so much about adding use cases but coming to consensus on which ones to remove.

I'm not sure I see a world where we can remove things from WAC and do anything practical. As it stands, there are several key pieces of functionality typical of most authorization systems that WAC doesn't provide, and some real hurdles in the current inheritance algorithm. This document was deliberately organized to avoid redundancy so that we could zero in on the minimal set of requirements for a viable system.

And I'm genuinely concerned that this is going to be bloated, and even more concerned that the requirements that will come out of this may not align well with the foundations in other parts of the ecosystem.

If you see specific use cases that you’re concerned about being bloated, please refer to them. I share your focus on the entire ecosystem, but thus far I don’t see anything here that raises alarms. That said, I am more than willing to dig into anything specific that concerns you at this point.

As for individual use cases, I'd like to see votes documented as proposed in solid/specification#9 (comment) .

That is the intent here. They have to be documented for people to give feedback. The panel voted to produce this text and iterate on it. I don't think it's productive to file every single one of these in a separate ticket and look at them in a vacuum. When designing an authorization system, the context of a given use case or need in relation to the others is as important as the need itself.

[acoburn]

The use cases here are very well described. The definitions are really useful for having a common vocabulary to discuss this, but I share @csarven's concerns that they go too far towards solution engineering. For example:

An authorization statement is an expression included in an acl resource that identifies permitted access modes to authorization targets by authorization subjects.

Why does an authorization statement necessarily need to be in an acl resource? Why is the authorization statement the unit that pulls together authorization targets and authorization subjects?

I can come up with an alternative model that meets all (or most) of the use cases described here, but which doesn't conform to the definitions, which seem like a problem with the definitions.

Similarly:

An acl resource is a resource that includes one or more authorization statements applied to one or more resources.

This is solution engineering. A specification that defines a formal model for authorization structures could have a definition such as this, but in the context of use cases and requirements, there are too many assumptions about structure bleeding through this sentence. Something better might be "An acl resource is a special resource that defines how authorization is enforced for a resource or set of resources". Do you see the difference?

Most of the definitions are hard to disagree with, but everything that starts with "An authorization X is a ..." strikes me as problematic.

[justinwb]

Most of the definitions are hard to disagree with, but everything that starts with "An authorization X is a ..." strikes me as problematic.

@acoburn I can see where the specific definitions you describe are overly prescriptive. I think I have addressed these concerns now in 146c3c1.

[csarven]

@justinwb :

That is the intent here. They have to be documented for people to give feedback. The panel voted to produce this text and iterate on it. I don't think it's productive to file every single one of these in a separate ticket and look at them in a vacuum. When designing an authorization system, the context of a given use case or need in relation to the others is as important as the need itself.

What you're citing is not relevant to why voting on each use case is important, which is at the core of what I'm trying to draw attention to. I don't think that the way to collect and analyse as you've raised and argued against is the only one. An alternative: any single document including all of the proposed use cases with votes, names and intent will suffice, and there are number of ways to achieve that.

It shouldn't be seen as a burden but something we should definitely be taking advantage of in order to get a better understanding as to what's significant, needs prioritisation, determine in/out of scope. If it helps, think of it as a filter to see what will most likely get implemented - again, people voting +1 on use cases and claiming they'll implement in good faith is a useful signal to pursue those use cases. Use cases that are less attractive or have no interest in getting implemented helps us to document and de-prioritise them - at least for the short term. Consequently, the group neither has to invest further energy on them or come up with technical requirements, thereby keeping the spec to the essentials. Moreover, having a basic sense of what will get implemented helps to ensure that the specs can advance to - the roughly equivalent of - "Candidate Recommendation" and actually receive implementation reports for the required features. As part of the "Exit Criteria", the features that do not have sufficient number of implementations will get removed.

These are all critical social and technical wins as I see it.

Lastly, in order for the Solid Community Group to produce (technical) reports based on open discussion and consensus, we should be recording how we got there as best as we can. Capturing the votes per use case contributes to that goal.

The above applies to all panels or otherwise producing UCRs and specs.

[justinwb]

What you're citing is not relevant to why voting on each use case is important, which is at the core of what I'm trying to draw attention to. I don't think that the way to collect and analyse as you've raised and argued against is the only one. An alternative: any single document including all of the proposed use cases with votes, names and intent will suffice, and there are number of ways to achieve that.

@csarven There's an implication that I'm arguing against consensus or voting. I'm not. My point was that a use case needs to exist first before you can vote on it. We've taken the first step in the process by drafting some. I am happy to raise a case by case vote to the panel in the next session.

[acoburn]

FWIW, here is my 👍 to the use cases recorded here.

3.1 Basic resource access

I am planning to implement and foresee no issues with the 3.2 use cases.

3.2 Basic collection access

I am planning to implement and foresee no issues with the 3.2 use cases.

3.3 Inheritance

I am planning to implement and foresee no issues with the 3.3 use cases

3.4 Conditional access

This is a really interesting set of use cases. I can imagine ways to implement these, but this would not have the same level of priority as the 3.1 - 3.3 use cases. I would want to consider how this impacts cacheability.

3.5 Permissioning applications

This is really important, but we need to clarify how applications are able to strongly identify themselves. If that can be spec'ed out (it involves interaction with the authN flows) and if we can ensure that application identifiers are not easily spoofable, then I would certainly implement this. We'd also want to consider cacheability for this.

3.6 Privacy

I am planning to implement and foresee no issues with the 3.6 use cases.

3.7 Trust

This is another interesting one. Typically I would think about this as a server-level configuration, but supporting this at the resource level seems reasonable. I don't foresee significant implementation issues with this, though it wouldn't have the same priority as 3.1 - 3.3.

3.8 Validation

This seems quite sensible, and I don't foresee any significant issues with this. I could use ShEx or SHACL to validate the incoming RDF, though it may be even easier to use a simpler model for validation.

3.9 Capabilities

Another very interesting one. The VC use case is one that I'd put more into the authN realm and proceed using the existing authZ mechanisms, but there are many details to flesh out there. There are lots of ways to handle "possession of a link". As with some of the other use cases, I find this interesting though possibly not the highest priority from an implementation perspective.

[justinwb]

Merging per the action item from the panel session on 7/22.