owned this note
owned this note
Published
Linked with GitHub
# W3C Solid Community Group: Authorization Panel
* Date: 2022-03-30T14:00:00Z
* Call: https://meet.jit.si/solid-authorization
* Chat: https://gitter.im/solid/authorization-panel
* Repository: https://github.com/solid/authorization-panel
## Present
* Matthieu B
* Justin B
* e Pavlik
* Abel Van Den Briel
---
## Announcements
### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Use panel chat and repository. Queue in call to talk.
### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* If this is your first time, welcome! please introduce yourself.
### Scribes
* Matthieu Bosquet
* Elf Pavlik
---
## Topics
### Data Grants implementers call
* E. Pavlik: Based on Data Grants domain model it should be easy to translate a Data Grant into access rules as long as we use common modes.
* Justin: We did something with WAC which was challenging but ACP would not necessarily have those limitations.
* Elf: Especially for inherited scopes in Data Grants, if a project has tasks, you could give access to a project based on that. You could have a Solid Container
* Justin: We have a use case for this "[Conditional by relationship](https://solid.github.io/authorization-panel/authorization-ucr/#conditional-relationship)".
* Elf: There is in the primer a contained: https://solid.github.io/data-interoperability-panel/primer/application.html#data-grant-inheritance
* ...: The shape tree reference defines a virtual hierarchy based on specific properties.
* Justin: You can have a resource that has a parent based on basic LDP containment and based on Shape Trees virtual containment. See also: [Shape trees assignment](https://shapetrees.org/TR/specification/index.html#assigning).
* ...: The solid resource would be linked to a [Shape tree manager](https://shapetrees.org/TR/specification/index.html#manager) where a physical and virtual hierarchy can be defined. When defining a physical containment (that is LDP basic containment/`ldp:contains`) Shape Tree allows you to restrict the shape of contained RDF and the resource hierarchy.
* ...: For example, the shape tree has such a [simple hierarchy described](https://shapetrees.org/TR/specification/index.html#tree). Trying to put a resource in a container that don't conform to the shapes defined must reject requests.
* ...: A virtual project tree wouldn't have `st:contains`, it would just reference shape paths `st:viaShapePath` and properties `st:viaPredicate`.
* ...: If I wanted then to make an authorization rule that only gives "Matthieu" access to resources related to the project 1 subject node via a specific property.
* Matthieu: What about resources which don't have a shape tree. Can one assign shape tree later.
* Justin: Yes, the resource just need to conform when shape tree gets assigned. Otherwise assignment will fail.
* Matthieu: Let's say we define virtual containment relationships using shape trees. Than SAI uses the Shape Tree spec to define the things you have access to?
* Justin: Data Grant with Inherited scope can understand those relationships in data. Once the Data Grants are issued, the access control systems doesn't need to understand shape trees. It just sets a rule based on graph relationship.
* Elf: What I want to clarify is that the most basic use of Data Grants is that an application has no idea where you keep projects for example. The access needs that an application has is not tied to any specific use of data. The application can use a Shape Tree reference to construct access needs. Then the end user authorization agent knows where to find a user's data.
* ...: Based on that we generate data grants to allow an application to follow the data. It's not even allowed to understand that you have some kinds of data.
* Matthieu: Isn't the entire idea that you would advertise the kind of data that you have?
* Justin: No, the app would advertise the kind of data it wants access to. You should never have to disclose access to anything that you have.
* Elf: Plus if the app tries to access bank statements you don't have to authorize it to access anything else. You isolate the app's knowledge.
* Matthieu: Isn't it always the case that an app wouldn't have access to all your data?
* Elf: Even if you had a private type index, if you allow the application to allow a private type index, then the app would know which type they have.
* Justin: Exposing info in a private type index, any app has access to all kinds of revealing data index references (unemployment/medical prescriptions...).
* Justin: SAI takes principle of least priviledge. App will only know about existence of data once you granted it some access to it. Also dont in user friendly way.
* Matthieu: Apps need to advertise the shape of the data they want to access.
* Justin: SAI defines Access Needs which use references to common Shape Trees. Those are discoverable via application Client ID Document (also used in Solid-OIDC).
* Matthieu: That is an interesting pattern. I don't know if we can get everyone to agree on particular shapes.
* Justin: Sure any shape tree can be used.
* Matthieu: Currently access can be granted to one specific resource or container hierarchy.
* Justin: Who makes that authorization? The user?
* Matthieu: Yes in an application.
* Justin: It could be useable in a file browser but not really otherwise.
* Matthieu: OK, so you want to streamline granting access to a specific shape of RDF stored within a pod or from a specific resource/or a collection of resources.
* Justin: In interop we have a data registry each data registration has a 1:1 with a ShapeTree type. It gives us a kind of flat storage structure which makes it really easy to know what goes where. Basically, there is 1 type per container, say Project/Task/Image/... You could actually have everything flat.
* Matthieu: OK, so all of your data sharing needs would be based on types of information.
* Elf: Imagine we have more than one storage (home/work). If I work with two different organisations I can keep all the flexibility. We're working on the open source implementation of an authorization agent to show how friendly that can be.
* Justin: Maybe it's worth if no one objects for the next week to do a bit of a sequential walk through.
* Matthieu: I think it would be good next week to talk about how we can translate the use of data grants in ACP, it should be possible to say in a resource that access to a resource via data grant is allowed and delegate validation of such grants to a Data Grant validation service. One main challenge being virtual hierarchies. My problem with delegating all ACL editing to an authorization agent is that it wouldn't work well in any case where the permissions would be edited via any other means (potentially creating conflicting permissions) and we don't want to stop other ways of editing ACLs.
* Justin: Ok, going through data grants would be fairly simple. Let's see how it may be ineroperable with ACP.