IANA registration of Link: rel="acl"

[acoburn]

Is there a plan to register the "acl" link relation with IANA?

acl is not currently registered: https://www.iana.org/assignments/link-relations/link-relations.xhtml

[RubenVerborgh]

Another angle: is acl really what we want?
Perhaps we want a URI instead as a relation, which would remove the need to go through IANA.

[acoburn]

@RubenVerborgh's suggestion to use a URI is also very good. This is what LDP does with the definition of ldp:constrainedBy. I don't have a particular opinion one way or the other, since both approaches allow for discovery of ACL resources by clients.

The advantage of defining a URI -- presumably in the ACL vocabulary -- is that it would not require registration through IANA. The disadvantage would be that existing servers and clients would need to adjust to using the new value.

Are there other thoughts one way or the other?

[csarven]

FWIW, LDN also uses a URI ( http://www.w3.org/ns/ldp#inbox ) in the case of discovery through Link header ( https://www.w3.org/TR/ldn/#discovery ). The reason for that decision was to have a single term that can be used in the HTTP header as well as in the RDF document. Not having to go through IANA was a bonus (but we had to go through W3C instead :))

The semantics of rel="acl" is okay but it only points to a document. There is no explicit FYN from the ACL Document to acl:Authorization (along the lines of foaf:primaryTopic or "doc contains authorization(s)" [1]). The implementations out there right now bake in that gap to discover the policies - nothing crazy, but still.

As for consequences of changing term "acl" to URI is valid, but none of this particularly spec'd beyond being experimental (I think). More like an "Unofficial Draft".

Off the top of my head, I'd support the use of URI for two reasons:

• Similar to LDN, the relation can be used in both the 1) headers (current practice) and in RDF (eg. 401/403 links to it) (makes this possible).

• WAC/ACL is not "standardised"... mark rel="acl" as testing or deprecated, give older implementations a chance to move to URI. New implementations will use URI. Older implementations may end up deciding to use both/... but that's just hypothetical at this point.

[1] I'd propose that the discovery of individual Authorization policies should be part of the spec - so that's a separate issue.

[acoburn]

@csarven this is really useful input. Related to your point about how the relation could be used in RDF, are you thinking of a 401/403 response body as RDF with that triple included? That is a very interesting suggestion -- with the LDP server that I have written, I'm not doing anything even remotely sophisticated with 401/403 response bodies.

[csarven]

Yes.

One use case is that the requester may want to know who to contact about accessing the resource. See related issues:

• Extend 403 template to request access nodeSolidServer/node-solid-server#992
• Creating a PATCH request solid#250
• 'Request Access' html on 401 responses #40

[bblfish]

One has to distinguish in an HTTP response between the metadata and the data. The metadata, ie the HTTP headers are about the content, how to interpret it, how it links to other resources, etc...
They are statements made by the web server.
Putting the same relation

<> :acl <doc.acl>

in the header and in the document are two different things: in the first case it is a statement made by the server, and the other a statement made by the author of the document. Indeed as one communicates with the server initially one is negotiating with a guard, as to what can be done with the resource, not with the owner of the document. The document may indeed not be visible, so there is no way one can get the acl from the document itself.

@csarven wrote:

The semantics of rel="acl" is okay but it only points to a document. There is no explicit FYN from the ACL Document to acl:Authorization (along the lines of foaf:primaryTopic or "doc contains authorization(s)" [1]).

Given that the header is in the ownership of the server, and so not editable, it makes sense that it links to the ACL document. If it had to link to a specific node in that document, it would complicate the setting of acls by the server very dramatically.

As for URIs for Iana declared Link relations, it may just be best to write up a short RFC on that topic.
The main problem the IETF and IANA have is that they fear that badly written clients keep requesting resources from their servers. In that case it may just be best to see if they can have a default URN for those acls. I think that is the most likely way to get something that satisfies both worlds. Not everything has to be linked data.

[csarven]

It is fine that rel="acl" links to a document and not individual policies. I agree it does complicate things otherwise. I meant that as a separate point about ACL docs in general. Once you're at the document, there is a "gap" in finding the Authorization policy. Perhaps that can be ironed out.

Unless I missed somewhere that 401/403 with RDF response is forbidden or an antipattern, is there an issue? That doesn't conflict with server's decision on whether to disclose the RDF response or not. Point being that, the author can provide say "default" contact information (or any useful data) for the resource - (yes, I get it that the resource is server's "property"). For the 'who to contact' use case, the server can alternatively (in addition to?) include Link: <http://example.org/inbox/>; rel="http://www.w3.org/ns/ldp#inbox" -- which may be the Inbox of the agent with Control privileges, or the default inbox of the server for these kind of inquiries.

Any way, that is a bit of a sidetrack of the original issue. I only wanted to highlight what URI instead of term "acl" could enable. Not refuting the use of rel="acl" in and itself.

[csarven]

Just to add... there is a whole RFC on Problem Details for HTTP APIs https://tools.ietf.org/html/rfc7807 doing practically what I've mentioned above in JSON, XML... with focus on 403.

[csarven]

To add another: while the server may make the final decision, the way WAC/ACL is applied in Solid context is that an agent with Control privileges more or less dictates what happens when clients interact with the resource. Server basically follows through. So, I think RDF doc indicating problems/help etc which is dictated by the Control agent is still within that "framework".

[bblfish]

yes, it makes sense to be able to agree on a standard mapping for HTTP headers to RDF:

• It would allow as you say to use them in HTTP error return documents, and elsewhere
• In writing servers or clients it can help to have a full RDF view on the headers and content, which in any case is needed since HTTP Link headers are barely disguised RDF. In my rww-play server I wrote a Link Header Parsers that could return triples, that would then be put together as a graph. And I played with thinking of the whole HTTP header that way...

Both use cases would mean that having a namespace for all the IANA link relations would be useful since those have the benefit of widespread agreement. So the need for having a namespace for iana will always crop up again and again. That is why I think one should try to bite the bullet and propose a namespace there, as well as register the acl relation.
It may be that in this case a URN for the namespace would be better than a URL...

[acoburn]

@bblfish the IANA link relations are already defined in such a way that they should be interpreted to exist within the http://www.iana.org/assignments/relation/ namespace. See, for example, RFC4287:

The value of "rel" MUST be a string that is non-empty and matches either the "isegment-nz-nc" or the "IRI" production in [RFC3987]. ... If a name is given, implementations MUST consider the link relation type equivalent to the same name registered within the IANA Registry of Link Relations (Section 7), and thus to the IRI that would be obtained by appending the value of the rel attribute to the string "http://www.iana.org/assignments/relation/".

You can see this in use in a non-normative section of the Web Annotation specification as well as in the JSON-LD context document published at http://www.w3.org/ns/anno.jsonld.

However, the IANA IRIs generated in that manner are not particularly useful from a linked data perspective, as they all redirect to a simple HTML page.

From my reading of this discussion, there are two issues here. The first is what value to use for the Link header relation (and where that should be defined -- with IANA or as an IRI in the ACL vocabulary). The second issue is how one might be able to use the semantics of that relation in an RDF document.

I don't have an opinion one way or the other on the first issue, but with the second issue I think @csarven makes a compelling case for using this relation as a predicate in RDF responses. As such, I would much rather use an IRI that is well-defined and dereferenceable in those contexts, which would suggest defining an IRI in the ACL vocabulary.

[csarven]

I wouldn't bet on the IANA ns w/ RDF definitions. Apparently tried in the past but didn't work out.. however, Tim maintains https://www.w3.org/ns/iana/link-relations/relation . (I use it because it is as good as it gets right now.) In any case, if "acl" goes through IANA, we can have it end up in W3C's ns (and consider using that if we take the IRI route). Otherwise, I agree, ACL vocab is best place.

[bblfish]

@acoburn wrote:

@bblfish the IANA link relations are already defined in such a way that they should be interpreted to exist within the http://www.iana.org/assignments/relation/ namespace. See, for example, RFC4287

That's a great find @acoburn! That makes it possible to consistently work with those link relations in RDF which is already one big step. And Tim's link pointed out by @csarven would be useful too as an owl:sameAs of the iana relation for those who want to dereference them, though I am not quite sure how much use that really is in all cases.

(I don't think that meaning is completely to be extracted from RDF or OWL specifications, but is mainly tied to use. OWL specs give some very useful restrictions to vocabularies).

But in any case it looks like one can have one's cake and eat it too.

1. the short "acl" link relation (to be registered) is a lot friendlier to explain to people than a url and makes for better examples in blog posts and documentation
2. If you put a URL instead you are likely to get all kinds of people not understand the point of the exercise, and make us look a bit weird. You know everything else works well with short names in HTTP, and we insist on putting URLs in those positions where it is not obviously needed. Especially for something as basic as an ACL.

The advantage of linked data linking can be gained later for when those are published on Tim's documentation page, but really in the mean time the html page from iana is quite good enough.
Decentralised ACLs are more important to have accepted than beautiful metadata about them.