sending access control rules to the client in 401 body?

[bblfish]

When returning a 401 the server can link to the access control resource using Link acl headers as in

HTTP/1.1 401 Unauthorized
WWW-Authenticate: HttpSig realm="/comments/"
Host: alice.name
Date: Thu, 01 Apr 2021 00:01:03 GMT
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel=type
Link: <http://www.w3.org/ns/ldp#Resource>; rel=type
Link: </comments/.acl>; rel=acl

The allows the client to fetch the description at that resource, as described in ACLs on ACLs. In HTTP/2.0 the content could be immediately pushed to the client too using "server push", to avoid the delay of a request.

But it is also reasonable to think the server could send the content in the body of the 401 as e.g. is hinted at in Inbox discovery PR).

Argument for pushing the data:
if the client did not connect with the right authentication credentials to begin with, then it did not know or remember the rules, so one might as well send those along.

Things that need to be worked on are:
• Is that going to conflict with other reasonable uses for returning content in a 401?
• Would the content be content-negotiated? How would that work on a 401 on an image, video, ms-word document, or cobol source code resource?
• is it reasonable to assume the client understands Turtle or JSON-LD in all these cases?
• should the returned content in the 401 be thought of as the content of the ACL? (but the the conned issue above)

These types of issues tend to make the simple answer of having the client fetch the ACL document be an easier starting point, especially as HTTP/2.0 server push makes the efficiency gains moot.

Other thoughts?

[elf-pavlik]

@bblfish After discussin it during the last call, do you still see need for more feedback or you can close this issue already?

[bblfish]

Nobody in the call was supportive of the idea, for essentially the reasons given above.
Perhaps @csarven has an opinion?

[csarven]

Do not close an issue without recording a reasonable response to the points raised.

---

But it is also reasonable to think the client could send the content in the body of the 401 as e.g. is hinted at in Inbox discovery PR).

Did you mean to write "server" (instead of "client")? That PR didn't at all hint at including the content of eg. an ACL resource in the response body! What was mentioned was about structured error messages!

[bblfish]

(fixed client-typo)

The main objection is that resources that return a 401 will need to return human readable content for say human readable content. That I think is similar to the content-negotiation issues. Of course the HTML could return RDFa come to think of it.

The other point is that HTTP/2 has an optimization for returning content in advance when needed - though I heard it had been switched off by chrome.

[csarven]

I still don't understand the purpose of this issue.. is it to explore the possibility? Did someone suggest it? Where?

RFC 7231 says:

Response messages with an error status code
usually contain a payload that represents the error condition, such
that it describes the error state and what next steps are suggested
for resolving it.

Including the required access control rules in the response body wants to give different semantics to the payload than what's intended by 7231. Not "violating" per se if we want to split hairs.. but definitely a stretch.

[bblfish]

Including the access control rules, seems to be compatible with what the text from RFC 7231 says, since the Access Control Rules tell the client what the next steps to follow are.

I brought it up, as it is an option. Following the Link: <...>; rel="acl" header is another.

[csarven]

Link relation to an ACL resource conveys something different than the response body in a 401.

The link relation is not an advertisement for how to resolve the error but indeed a client could make use of it towards resolving the error.

I don't find dumping the authorization policies in the response body in and itself hints at "next steps" to resolve the error. If need to, it should be more explicit. As discussed, it could be incorporated into structured error messages (eg. solid/specification#28 ). For the use case specific to invalid or refused credentials (RFC 7235), the structured error message needs to express why the request was rejected. The inner structure / snippet that's to be included as part of the problem detail can be covered in this panel but the main issue on communicating structured error messages I believe should be addressed on the Protocol spec level.

[bblfish]

the structured error message needs to express why the request was rejected.

That is a very good point. There has to be space for expressing that the key is not valid or the credential does not fit, that there is not enough money on the bank account etc...

That feels to me like a pretty conclusive argument.

So I can see one would want some kind of machine readable response to say things like:

• You did not authenticate and the resource is not public. See <there.acl> .
• Your credentials is out of date.
• Your credential signature is invalid,
• You authenticated as X but X is not allowed access. See <there.acl> .
• ... but extra proof is required to show that X has property P which would allow access ...
• ...