solid
Structured Error Messages
In NSS5, we implemented more detailed status messages to give clients more feedback. We should bring this along into the spec.
We have
- 401 Unauthenticated
- 403 User Unauthorized
- 403 Origin Unauthorized
This was not added in #13 and #26 .
Remind me, what's the implementation based on? Anything to do with https://tools.ietf.org/html/rfc7807 or some other standard or existing convention?
Shall we first distill the problem we are addressing?
Then we can look into various solutions. I’m not a big fan of the reason phrase, as this is no longer present in HTTP/2, so will get lost (https://tools.ietf.org/html/rfc7540#section-8.1.2.4).
I think we should instead add details to the body.
For machine readability, we could also make use of Link headers with rel="http://www.w3.org/ns/ldp#constrainedBy". That could point to an IRI that gives lots of additional information.
I would also note that, for authN and authZ errors, providing lots of additional data can leak security-related information that really shouldn't be conveyed to a client.
+1 for the above as a third option.
Regarding security, agreed; this is what we started to convey in https://github.com/solid/specification/pull/13/files#diff-8d72b2ee1631b8eec737030e9b4a3c9cR37-R38 and https://github.com/solid/specification/pull/13/files#diff-8d72b2ee1631b8eec737030e9b4a3c9cR59-R60; we probably want to add more details.
https://github.com/solid/specification/issues/112 generalises this issue with server errors: https://github.com/solid/specification/issues/111 .
We agree on detailed errors in RDF in either response body or link relation (constrainedBy). For interop, we need to have a data model. See also https://github.com/solid/data-interoperability-panel/issues/29 as possible input.
Since the ldp:constrainedBy relation is for client errors, then only the response body in RDF can be used for both client and server errors.
Retracted the need for servers sharing additional error details: https://github.com/solid/specification/issues/111#issuecomment-647486154 .
Edit: Issue #44 covers link relation and resource describing the constraints.
The Security and Privacy Considerations section of the Solid Ecosystem spec ( https://github.com/solid/specification/issues/147 ) should include information along the lines of https://tools.ietf.org/html/rfc7807#section-5
Detailed messages for client errors and a resource describing the constraints are independently useful. They can be used together. For example, it is possible use a URI that is part of the Solid spec defining the constraint ( https://github.com/solid/specification/issues/44#issuecomment-648048614 ) as well as for server-controlled (pre-determined) constraints. Whereas the error message in response body can provide any and specific information in context of the fail.
RFC7807 is now in "last-call": https://twitter.com/httpapi_wg/status/1583141665639899136?s=61&t=R4e3GveO_jnwbe_Vbmq2Vg
Perhaps it'd be an idea to become compatible with that specification? There is also a proposal for publishing a JSON-LD context: https://github.com/ietf-wg-httpapi/rfc7807bis/pull/48
