UC3 Inheritance

[matthieubosquet]

No description provided.

[bblfish]

In commit 2517390 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

[csarven]

I don't quite understand how this is "evaluation" or whether it is intended to systematically compare potential solutions. What's being measured exactly? It comes across like an analysis/study of the potential solutions rather than an actual evaluation. IMO.

[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"?

[TallTed]

These were written more than 12 hours ago, and got stuck in a "pending" state for some reason...

[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?

[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.