-
Notifications
You must be signed in to change notification settings - Fork 20
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
HTTP 403 - does the user or the application lack required access mode? #34
Comments
Actually, NSS5 will give "403 Origin Unauthorized" or "403 User Unauthorized" based on this, but indeed, this needs to be speced. |
Note that status text has disappeared from HTTP/2, so we need a means of specifying this inside of the response body. |
Right! I could have sworn we had an issue open for structured error messages, but I can't find it now... Anyone remember? |
I think way may need to think in more general way about apps/clients and don't assume anything about origin. Especially that only IdP/AS would do redirect in oauth flow so RS has no way to directly verify origin claimed by the app/client in HTTP header (even in browser app could use a proxy to change it solid/web-access-control-spec#34). I think we might need at lest two error codes
Getting Client Unauthorized app could ask User for permission. This also hits #43 - app would need to know which AS has authority over that resource, resource associated or user associated. Also https://github.com/solid/specification/issues/80 may play role if user has multiple associated AS, but I think User can figure it out since it all stays on their side. |
Yeah, I agree, origin based trust is unsustainable, I was just mentioning as an example of what we already have. :-) |
User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization: 3.3.6 Authorization Server Response to Client on Authorization Failure includes some examples where they use plain |
solid/specification#28 goes in the direction of addressing the need generally for Solid, and not coupled with an authorization mechanism. |
AFAIK currently client receiving HTTP 403 response doesn't have a way to tell the difference between the user missing required access mode or just the app missing required access mode. That difference usually will impact next steps in the interaction:
or
In separate issue I will propose new role of user's proxy which among other issues may also help with addressing this one.
The text was updated successfully, but these errors were encountered: