HTTP 403 - does the user or the application lack required access mode?

[elf-pavlik]

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:

• App needs to ask user for granting it missing access mode.

or

• User needs to ask resource owner for granting her missing access mode.

---

In separate issue I will propose new role of user's proxy which among other issues may also help with addressing this one.

[kjetilk]

Actually, NSS5 will give "403 Origin Unauthorized" or "403 User Unauthorized" based on this, but indeed, this needs to be speced.

[RubenVerborgh]

Note that status text has disappeared from HTTP/2, so we need a means of specifying this inside of the response body.

[kjetilk]

Right!

I could have sworn we had an issue open for structured error messages, but I can't find it now... Anyone remember?

[elf-pavlik]

Actually, NSS5 will give "403 Origin Unauthorized"

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

• User Unauthorized
• Client Unauthorized

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.

[kjetilk]

Yeah, I agree, origin based trust is unsustainable, I was just mentioning as an example of what we already have. :-)

[elf-pavlik]

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 application/json for error messages. I think we could use something similar with application/ld+json and text/turtle.

[csarven]

solid/specification#28 goes in the direction of addressing the need generally for Solid, and not coupled with an authorization mechanism.