search

solid / authorization-panel

Github repository for the Solid Authorization Panel
MIT License
19 stars 20 forks source link

UC3: fixes and add story for privacy #241

Closed bblfish closed 3 years ago

bblfish commented 3 years ago

Following today's panel discussion I added a little twist to show how ACRs can both be readable and privacy friendly. I also fixed a few other problems, and added some clarifications.

bblfish commented 3 years ago

@matthieubosquet wrote:

However, I don't see/understand what solution to allow people finding out which credentials to present is suggested here. Could you maybe explain in comment?

I made some edits to help. But perhaps I need to add a bit more.

The idea was described here: https://github.com/solid/authorization-panel/issues/189#issuecomment-797638239

An ACL resource can specify a group who has read/write access. That group may only be visible to the members of the group: ie. the acl of the group gives read access only to members of that group.

How would you know that you are a member of that group? Well you'd need an invite, a message of sorts to your inbox. This is different from say ACLs requesting one prove one is over 18, as those can be public, and only rely on the client having an authoritative credential.

Even if the access control resources are designed to let a client read which groups can have access to a resource, you would need to know group membership otherwise.

yes, that would need to be sent to you for an invite for non-public groups. There is no other way around that.

I think it's generally the direction to take:

  1. A mechanism to advertised all keys to the door
  2. A mechanism to keep and match the keys on the actor's side

But I'm not sure I see it clearly here.

Can you check out https://github.com/solid/authorization-panel/issues/189#issuecomment-797638239

perhaps leave a comment there or here if something is not clear.

matthieubosquet commented 3 years ago

@bblfish https://github.com/solid/authorization-panel/issues/189 is clear to me. However, it only addresses one type of credential (group membership) and is not very specific in the way to keep track thereof:

How would you then know you are a member of the group? You'd need to be invited using Linked Data Notification or something similar.

It is an interesting suggestion for best practices in Access Control Resource editing but I think that required credentials discovery should potentially not only rely on best practices and have a dedicated mechanism addressing it. I created https://github.com/solid/authorization-panel/issues/242 to discuss it.

bblfish commented 3 years ago

@bblfish #189 is clear to me. However, it only addresses one type of credential (group membership) and is not very specific in the way to keep track thereof:

How would you then know you are a member of the group? You'd need to be invited using Linked Data Notification or something similar.

It is an interesting suggestion for best practices in Access Control Resource editing but I think that required credentials discovery should potentially not only rely on best practices and have a dedicated mechanism addressing it. I created #242 to discuss it.

The point was to show that you can have ACRs that are widely readable (how much depends on the use case) without loosing privacy: anyone can know that members of some group have access, but without knowing who is member of that group. So the idea that ACRs must be readable by only the controller for privacy reasons is shown to be wrong.

The LDN solution seems to me to be very workable.