Structured Error Messages

[kjetilk]

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 .

[csarven]

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?

[RubenVerborgh]

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.

[acoburn]

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.

[RubenVerborgh]

+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.

[kjetilk]

👍 to detail errors in RDF

[csarven]

#112 generalises this issue with server errors: #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 solid/data-interoperability-panel#29 as possible input.

[csarven]

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.

[csarven]

Retracted the need for servers sharing additional error details: #111 (comment) .

Edit: Issue #44 covers link relation and resource describing the constraints.

The Security and Privacy Considerations section of the Solid Ecosystem spec ( #147 ) should include information along the lines of https://tools.ietf.org/html/rfc7807#section-5

[csarven]

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 ( #44 (comment) ) 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.

[ThisIsMissEm]

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: ietf-wg-httpapi/rfc7807bis#48