UC3 Inheritance

[bblfish]

In commit 251739002c96477b373db651d12cf46214bc4f6d I made it clearer where the different resources are located, and used relative URLs named after the example use case being discussed, so as to make comparison with the UCR easier.

I think the description of the layout of the files should be moved up to the top of the file so that it can be re-used by the ACP examples.

[bblfish]

original here https://github.com/solid/authorization-panel/blob/uc3-inheritance/proposals/evaluation/uc-3-inheritance.md

[matthieubosquet]

@csarven it is intended to systematically compare potential solutions. The goal is just understanding in details how each approach works to solve problems.

[kjetilk]

I'd like to echo @csarven 's sentiment here, this needs to take a step back and focus on "policy reuse" rather than inheritance.

Every access control system more sophisticated that the UNIX filesystem I have ever used has had a concept of inheritance, so, yes I can absolutely see the desire for this. However, there are two things that needs consideration (I would argue they are evaluation dimensions): One thing is that every access control system I have ever used have been constructed for experts and are used by people trained for it, but we can't do that if we are making something for everyone. From what I can see from being a parent of a nearly-teen, every teen on the planet are screaming for an efficient access control system that works for them, and from what I can see, policy reuse is very important to them.

The other dimension is that we're on the decentralized Web, and so anything beyond "look up a single resource, find the access controls there and you're done" will have performance implications that we need to consider very carefully. Possibly, we will be in a position where some use cases can be satisfied, but other use cases, perfectly legitimate, good use cases that some want, can't yet. The latter class is of course the most interesting work on, but I believe we need to classify those early, so we can progress quickly on the things we can do in the short term, and then have resources for the harder things.

[bblfish]

@kjetilk

this needs to take a step back and focus on "policy reuse" rather than inheritance.

Yes, I think we agree. I had not actually really given much thought to the difference. How do you distinguish them? Would :imports not fall on the side of "policy reuse"?

[kjetilk]

@kjetilk

this needs to take a step back and focus on "policy reuse" rather than inheritance.

Yes, I think we agree. I had not actually really given much thought to the difference. How do you distinguish them? Would :imports not fall on the side of "policy reuse"?

I think it has a potential as a solution to many use cases around policy reuse, and as a way to implement inheritance too.

I see a lot of policy reuse use cases in my immediate vicinity, like a group of parents that would like to share policies around what games their kids play (which is a non-inheritance based but decentralized policy reuse), for my own family, I would probably be the one who would implement the base policies, and then my daughter for example, would further restrict access based on that, an inheritance-based reuse. Within my daughter's friends, it is quite likely that their complex social rules on what to share and not could be put into access control policies by one them, but shared possibly not just within the group, but also to other teens sharing the same concerns. This is really interesting stuff, they have consciously decided to give up TikTok without us parents telling them to because of this shortcoming, and they perceive Youtube as far too open.

How about this: Lets use the https://github.com/solid/user-stories repo, I'll create "policy reuse" label there, we can submit user stories there and then the panel can create the use cases based on the user stories there?

[bblfish]

I added an ac:imports example and removed the text that was causing disagreement.

[bblfish]

@kjetilk wrote:

I'd like to echo @csarven 's sentiment here, this needs to take a step back and focus on "policy reuse" rather than inheritance.

In my last commit you'll see (here is best) a couple of sections with :imports that show how policy re-use works.

[bblfish]

@kjetilk

How about this: Lets use the https://github.com/solid/user-stories repo, I'll create "policy reuse" label there, we can submit user stories there and then the panel can create the use cases based on the user stories there?

Ah, I did not know about that user-stories repository. I see you have a Policy Reuse tag now with 5 stories tagged there. So that helps. Perhaps we can evolve the use case a little bit towards reuse which in a way I already have started doing just by noticing that WAC and ACP both don't have a good answer for that in the basic use cases - one of the first use cases one comes across when building a server.

[matthieubosquet]

@csarven I think your concern has been addressed as we removed the controversial phrasing.

If your requested change is satisfied, could you mark it as resolved?

I would suggest that we will create a separate UC for reuse but this one currently focuses on inheritance as per the use case it portrays.

[bblfish]

I would rather we extend this use case to cover re-use too since in a way we are moving from one to the other smoothly just by evaluating the inhertiance use case. Otherwise we'll just have to copy all the story here to another page, and then continue from there, which seems a bit of a waste.

[bblfish]

There could be a use case specialized on re-use to of course that could have a deeper look at it. But we should not be worried about showing how it appears here already.