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.

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

'Request Access' html on 401 responses #40

Open
michielbdejong opened this issue Apr 3, 2019 · 4 comments
Open

'Request Access' html on 401 responses #40

michielbdejong opened this issue Apr 3, 2019 · 4 comments
Assignees

Comments

@michielbdejong
Copy link
Contributor

Similar to how you can request access to a document on Google Docs, we could invent a way such that a visitor could cause an email to be sent to the owners, so they can consider whether they want to add an ACL rule for the visitor's webid.

@michielbdejong
Copy link
Contributor Author

This is a suggestion that came up during the 'acl:trustedApp' session of the unconference we did in Boston on 22 March.

@csarven
Copy link
Member

csarven commented Apr 3, 2019

What aspects of the interaction or flow are expected to be prescribed (as per "spec")?

Not that I'm against email, but see the following as to make a "request" via the inherent capabilities of the platform:

@csarven
Copy link
Member

csarven commented Apr 3, 2019

As discussed elsewhere issues/chats.. one thing that could be spec'd is the "shape" (SHACL/SheX/Whatever) of the request notification that an application sends to the server's inbox eg. who wants it on what resource, what controls, validity etc.. So, the client application needs to be able to assemble the request (shape) and the server needs to be able to verify that shape, and maybe follow up (not particularly safe but maybe there are UCs or heuristics for that).. or just store it and wait for an application to consume the request by a Control user and then they act on the request.

Edit: I should add that this approach also opens up a space for new class of Solid applications ;) Which is much needed IMO.

@csarven
Copy link
Member

csarven commented Apr 3, 2019

FWIW, the way I see it for the WAC spec is to not require additional dependencies like email. Use cases around requesting should work independently - decoupled from other major protocols. Hence, I see working around shaped notifications to be more closely aligned with the current state of WAC and what the surrounding protocols and stack provides.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants