Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Access Requests and Grants #9

Open
woutslabbinck opened this issue Aug 8, 2024 · 1 comment · May be fixed by #37
Open

Access Requests and Grants #9

woutslabbinck opened this issue Aug 8, 2024 · 1 comment · May be fixed by #37
Assignees
@NuttyShrimp

Comments

@woutslabbinck
Copy link
Collaborator

Currently, it is possible to grant access to resources under your control. But what if you know a resource from a different Solid Agent (user, identified by WebID) and want to request access.

The only way of achieving that is asking the person behind the Solid Agent for access.

It would be nice if instead, you could request access for that resource to the Solid Agent directly.

A limitation right now is that for a given resource, you don't know the agent that has acl:Control and can not discover it.
So if you want access, you will both need to know the resource URL and some sort of agent Inbox (maybe part of the WebID Document) such that you can send a notification to request access.

Some pointers:
@bjdmeest
Copy link

bjdmeest commented Sep 2, 2024

For this, what would be needed, is that the resource owner needs to specify which resources are 'discoverable to request access to': So I expect the UI to have a button/switch 'Can people ask access to this resource?' (which gets saved separately in another, publicly readable resources.json file, because this switch doesn't directly affect access control). If an external user then requests access (via loama), the loama app can then (via the resources.json file of the owner) show which resources access can be requested to.

So flow could be:

  • User A logs into Loama
    • User A selects profile/myFriendsData and switches on 'Can people ask access to this resource?'
    • Loama stores profile/myFriendsData in userA.pod.com/resources.json (makes the file resources.json if needed, and sets public read of resources.json to true).
  • User B logs into Loama
    • User B clicks 'request access'
      • User B enters/selects userA.pod.com/profile/card#me
      • Loama fetches userA.pod.com/resources.json and visualizes all requestable resources to User B (in this scenario, only containing the description of profile/myFriendsData)
      • User B clicks 'request access' for profile/myFriendsData
      • Loama sends an access request LDN for profile/myFriendsData to the inbox of User A
  • User A logs into Loama
    • Loama checks the inbox of User A and discovers an unprocessed access request for profile/myFriendsData
    • Loama visualizes the access request to User A
    • User A consents to the access request of User B
    • Loama sends an access grant LDN for profile/myFriendsData to the inbox of User B
  • User B logs into Loama
    • Loama checks the inbox of User B and discovers an unprocessed access grant for profile/myFriendsData
    • Loama visualizes the access grant to User B as a notification (that can be just clicked away, User B can't use Loama to actually view the contents of profile/myFriendsData)

In a first version, you could skip the resources.json file dependency and have user B to manually both enter/select userA.pod.com/profile/card#me ánd enter userA.pod.com/profile/myFriendsData, but I'm not sure doing it in 2 phases would give that much efficiency gain.

@NuttyShrimp NuttyShrimp linked a pull request Nov 8, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@NuttyShrimp NuttyShrimp

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Feat: add access request & granting SolidLabResearch/loama
3 participants
@bjdmeest @NuttyShrimp @woutslabbinck