ldp:constrainedBy recommendations

[acoburn]

The LDP specification introduces an IRI to be used to advertise any constraints on the ability of a client to create or update resources:

Link: <https://example.com/SpecificErrorCondition>; rel="http://www.w3.org/ns/ldp#constrainedBy"

If Solid published a common vocabulary of error conditions, this feature could potentially be used to accomplish a high level of interoperability across servers. Is such a recommendation within the scope of the Solid specification?

[csarven]

Generally agree on making use of ldp:constrainedBy.

Before discussing a vocabulary for error details - generally a good idea any way, and I think we have some options there - can we inspect the underlying mechanism and iron out some assumptions:

• If a constraint exists, should it be always advertised (currently MAY in LDP)?
• Who generates a constraint?
  • Server autogenerates based on known set of errors. Also factor in unknowns?
  • Can a client generate a constraint and associate it with a resource? eg. I only want notifications with CC0 license. In/out of scope?
• Can a constraint be updated? Who can update?
• Which information model(s) / shape languages (eg. SHACL and/or ShEx..) may/must be used to communicate constraints?

[csarven]

Related #28

[justinwb]

@csarven

Generally agree on making use of ldp:constrainedBy.

Also agree that there's a home for it here 👍

Before discussing a vocabulary for error details - generally a good idea any way, and I think we have some options there - can we inspect the underlying mechanism and iron out some assumptions:

• If a constraint exists, should it be always advertised (currently MAY in LDP)?

I think this depends on the type of constraint - it cannot be generalized. For example - a wac acl is a constraint, but it is only advertised if the acl:agent has acl:Control privileges. Regardless, if the goal is to stick with LDP conventions, the statement in 4.2.1.6 of the LDP spec only requires as a MUST that ldp:constrainedBy be used in the response to a request that failed based on imposed constraints.

LDP servers must publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with an appropriate context URI, a link relation of http://www.w3.org/ns/ldp#constrainedBy, and a target URI identifying a set of constraints [RFC5988], to all responses to requests that fail due to violation of those constraints

IMHO - we should stick to the case LDP requires, which is including a Link header with a context URI, a link relation of ldp:constrainedBy, and a URI identifying the constraint(s) being violated, in response to a constraint violation. We need to do that while being mindful of possible data leakage by providing too much detail on the nature of the constraint. For example, a URI that explains what a user authorization error is, vs. a URI that details the authorization statement that triggered the failure. The former is acceptable, while the latter could leak sensitive information.

• Who generates a constraint?
  • Server autogenerates based on known set of errors. Also factor in unknowns?
  • Can a client generate a constraint and associate it with a resource? eg. I only want notifications with CC0 license. In/out of scope?
• Can a constraint be updated? Who can update?
• Which information model(s) / shape languages (eg. SHACL and/or ShEx..) may/must be used to communicate constraints?

Another case where I think it depends on the type of constraint, and so it should be determined in the definition for that type (in resource metadata).

[justinwb]

Here's why I don't think we should use ldp:constrainedBy as the link relation used to advertise constraints of all types in Link headers (realized I didn't address this head on):

1. Rules around what to include / not include in link headers vary for each type of constraint (e.g. acl vs shape)
2. WAC ACLs are constraints, and we use a specific link relation for them (rel=acl). This establishes a precedent. If we use ldp:constrainedBy for others but not for WAC ACLs, that would seem inconsistent and somewhat counterintuitive.

[csarven]

I think this depends on the type of constraint - it cannot be generalized. For example - a wac acl is a constraint, but it is only advertised if the acl:agent has acl:Control privileges.

re WAC/ACL, why? Minimise/eliminate attack vector? If so, what kind of attacks are unique to ACL resources? Related: I take it that no URI pattern will be specified for ACL resources in any case.

Another case where I think it depends on the type of constraint, and so it should be determined in the definition for that type (in resource metadata).

Fine by me if those, similar or relevant questions are addressed in the definitions.

For example, a URI that explains what a user authorization error is, vs. a URI that details the authorization statement that triggered the failure. The former is acceptable, while the latter could leak sensitive information.

Generally agree. IIRC, we haven't however agreed to specify the model for error descriptions that can be used in the RDF body of the target of the constrainedBy URI . Issues like #146 , #112 , #111 , #28 can help here. Whether all potential errors should be specified or left at the discretion of the server (provided that they follow an outline, be machine-readable etc) also needs to be decided.

WAC ACLs are constraints, and we use a specific link relation for them (rel=acl). This establishes a precedent. If we use ldp:constrainedBy for others but not for WAC ACLs, that would seem inconsistent and somewhat counterintuitive.

As I understand it, constrainedBy would explain the conditions that needs to be met. An ACL resource doesn't actually articulate that - and certainly not useful if the proposal to only expose rel=acl if user has Control - but I can see how it can be purposed that way. I do however see that shapes or machine-readable specs (or fragments within) to be closer for intended use.

[csarven]

Servers MUST publish any constraints on clients’ ability to create or update resources by adding a Link header with an appropriate context URI, a link relation of http://www.w3.org/ns/ldp#constrainedBy, and a target URI identifying a set of constraints [[!RFC8288]], to all responses to requests that fail due to violation of those constraints. For example, a server that refuses resource creation requests via HTTP PUT, POST, or PATCH would return this Link header on its 4xx responses to such requests. The same Link header MAY be provided on other responses. The representation of the constraints MUST have an RDF serialisation. The URIs of the constraints that are defined by this specification SHOULD be used where applicable. Servers MUST NOT allow clients to update or delete constraints under its authority. The appropriate context URI can vary based on the request's semantics and method; unless the response is otherwise constrained, the default (the effective request URI) SHOULD be used.

[csarven]

Proposal for the constraint URIs:

The target URI of the constrainedBy can be a URI that is part of the Solid spec defining the constraint. The test suite uses those constraints in which the implementation reports are also based on.

The issue on having an HTML+RDFa spec: #6 can in fact help to address with constrainedBy recommendation in a human- and machine-readable way. For example, the LDN spec has URIs for each constraint and described with RDFa. The URIs are used in the test suite and implementation reports (eg. https://www.w3.org/TR/ldn/#test-receiver-post-response-contraints-unmet defines the server requirement on failing a request.)

So, there is at least a way to refer to Solid spec defined constraints. If there are other constraints or server wishes to extend the description of the constraint in their own environment, they can do so at a URI under its control. For example, the constraint can be in a language (different than the Solid spec) that the server supports and based on content negotiation with the client.

If linking to the Solid spec poses a security risk - because it is under a different authority - we can suggest a best practice for servers where they can reuse the definitions from the spec, extend if need to, and use their own URIs.

[csarven]

As support for the proposal above, the Web Annotation Protocol https://www.w3.org/TR/annotation-protocol/ in fact has the same criteria. The WAP spec is not in RDF to the degree that it suggests:

The constrainedBy link header on the response when dereferencing the Container SHOULD refer to a server specific set of constraints listing the types of content that are acceptable.

It MUST advertise that it imposes Annotation protocol specific constraints by including a link where the target IRI is http://www.w3.org/TR/annotation-protocol/, and the rel parameter value is the IRI http://www.w3.org/ns/ldp#constrainedBy.

however, the intention is the same. In Solid spec's case, this is actually feasible (as demonstrated by LDN).

Note also that WAP recommends:

Annotation Containers MUST return a Link header [rfc5988] on all responses with the following components:

which is what I've suggested earlier - with some exceptions on the kind of resources of course.

[bblfish]

I would like to be able to express that my server only allows creation of containers with PUT if the URL does not contain any dots. Ie it can create https://alice.name/photos/cat but not https://alice.name/photos.old/cat.acl
as that makes dealing with content negotiation very difficult.

[csarven]

With the exception of dot-segments, I think it'd be up to servers to whether a dot in a path segment is allowed. If server doesn't allow client to allocate a URI containing a dot in a path segment, it should probably respond with a 403. Unless the spec has something to say about the dots in path segment, in which case the URI reference can be the requirement in the spec, I don't think ldp:constrainedBy is necessary. Message in body might suffice.

Aside: PUT https://alice.name/photos/cat creates a non-container resource and PUT https://alice.name/photos/cat/ creates a container.

[bblfish]

I'd say whether a dot is allowed in the path segment or not is an implementation detail.

It is an implementation detail on the server. But for the protocol, we need the server to be able to communicate such details to the client.

We need a way to let clients know what type of names they can reliably use to PUT to a server, or else the only real option is POST. (Or is a client meant to try to guess the acceptable names?)
Furthermore this is something the client needs to know, as I don't see the human user entering some regex into a UI for the client to let it know of the restrictions...

[csarven]

To clarify, what you want to express is a unique implementation behaviour. Servers can describe their specific constraints using ldp:constrainedBy with their own identifiers and descriptions. Alternatively (but this is not what you want), indicate the contraints in the response body - #28 goes in the direction of structured error responses.

[csarven]

#185 resolves this issue.