equivalent to or a sub-path of the request URI?

[handrews]

From the Hyper-Schema Security Considerations:

When link relation of "self" is used to denote a full representation of an
object, the user agent SHOULD NOT consider the representation to be the
authoritative representation of the resource denoted by the target URI if
the target URI is not equivalent to or a sub-path of the URI used to request
the resource representation which contains the target URI with the "self"
link.

Does anyone understand the "sub-path" part of this? It seems a bit related to the old pathStart keyword. I can't find anything in RFCs 3986, 4287 (where "self" was first defined), 7230, or 7231 that indicates anything special about URI "sub-path"s, with respect to "self" links or otherwise.

@awwright do you have any idea what this was about? @Julian?

[awwright]

I'm not sure where that came from either. It probably intends to refer to the origin instead, following the Web origin security model.

I would expect the definition of the "self" link relation to give us all the necessary security concerns, though... what about it poses a unique threat to Hyper-schema?

[handrews]

what about it poses a unique threat to Hyper-schema?

No clue. Should we just remove this subsection?

[handrews]

@awwright Reading through this again, I think that the case this is addressing is the one in the collection example (that I just reworked yesterday), where each element in the collection representation is in fact a full representation of the item, and therefore each element has both a "self" link and an "item" link.

The issue seems to be the question of whether you can safely assume that the context representation of those "self" links can be used in place of fetching a representation from the "self" link's target, saving a network operation.

In this case, the sub-path stuff seems to line up. In that example, the "URI used to request
the resource representation which contains the target URI with the "self"
link" is /things, while the target URIs of the "self" links of the two collection elements are /things/1234 and /things/6789 (or something like that).

Those are sub-paths of the collection URI, which means that according to this guideline, you can treat the embedded element representation within the collection representation as an authoritative full representation, and skip fetching individual elements.

A corollary of this is that "self" links SHOULD NOT (or even MUST NOT) be used when the context representation is not a valid full representation (defined as validating against the full representation's schema, I suppose, which does leave some leeway assuming optional fields).

I see the point of this, but it's explained in a very convoluted way and I have no idea if it is grounded in any larger theory or security framework.

[awwright]

Oops, I thought I emailed back something like Yeah, we should rewrite this.

[handrews]

@awwright I did end up putting in a more detailed CREF along the lines of that last comment. Sorry if I missed an email or something, we'll definitely revisit this in the next draft.

[Julian]

(/me is just searching through this repo looking for mentions you hit me with that I missed in the torrent of emails :)

I don't unfortunately recall either.

[handrews]

@Julian you can actually filter on the X-GitHub-Reason: mention header if your email client allows that. Although I think the reason keeps being "mention" forever on that issue. But if you're not mentioned on all that many it should help.

[Julian]

Hmmmm that does in fact sound useful thanks, let's see if I can make that do nice things.

…

On Tue, Dec 18, 2018, 01:17 Henry Andrews ***@***.*** wrote: @Julian <https://github.com/Julian> you can actually filter on the X-GitHub-Reason: mention header if your email client allows that. Although I think the reason keeps being "mention" forever on that issue. But if you're not mentioned on all that many it should help. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/json-schema-org/json-schema-spec/issues/485#issuecomment-448060116>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUIXvadtqilvN2LUBmZcr94JY_yKo1nks5u6EIhgaJpZM4QclZs> .