IANA registration of Link: rel="acl" about web-access-control-spec HOT 24 CLOSED

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.

from web-access-control-spec.

Yes.

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

• nodeSolidServer/node-solid-server#992
• solid/solid#250
• #40

from web-access-control-spec.

@bblfish LDP 4.2.1.6 mentions "... a link relation of http://www.w3.org/ns/ldp#constrainedBy ..."

from web-access-control-spec.

@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?

from web-access-control-spec.

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.

from web-access-control-spec.

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

from web-access-control-spec.

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.

from web-access-control-spec.

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.

from web-access-control-spec.

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.

from web-access-control-spec.

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

from web-access-control-spec.

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

from web-access-control-spec.

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

from web-access-control-spec.

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.

from web-access-control-spec.

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

from web-access-control-spec.

via @nickshanks:

"acl" is not an IANA-registered link relation, used on https://github.com/solid/solid-spec/blob/master/content-representation.md
It needs to either be registereed, or changed to a custom URI as the link relation. ("describedby" is registered, FWIW, and I presume you are using it in the context it was registered for)
Also, I suspect that "access" would be a better link relation to register, as it is more technology agnostic and so could cover more use cases.

from web-access-control-spec.

Thank you for re-focusing attention on this issue. To recap: at a high level, there are two viable paths for resolving this and we just need to come to a consensus on which path is most desirable:

1. Settle on an IANA-based link relation (e.g. acl) and formally register that relation with IANA. (n.b. @nickshanks suggests using a different term here)

2. Use a full IRI for the link relation and update the ACL vocabulary to include that IRI.

There has been some active discussion related to the decision-making process for Solid; can that inform a best path forward for resolving this issue?

from web-access-control-spec.

In scenarios where client application would like to create specific acl relation between two resources, having full IRI would come useful in defining interface for such operation.

Also having full IRI makes it easier if someone wants to include that acl relation directly in RDFSource's representation.

from web-access-control-spec.

@elf-pavlik we already settled that it is possible to have iana and full URLs.
The iana route would be good because it adds the shorter way of writing the header, which makes for writing out much simpler and cleaner examples. If we don't do it, somone else will, and then if we start with the URL route we would end up with 2 urls for the acl to deal with plus the short form.

from web-access-control-spec.

I agree that it is possible to have IANA terms and full URLs; however, that translation is anything but obvious (unless you happen to be familiar a particular sub-point within the ATOM RFC).

I would argue that the full IRI route is more in line with linked data principles; this is also the path taken by LDP and LDN. This change also has a significant downside in that the term changes for all existing implementations. That said, this is also now the time to step back and decide what is the best path for the future.

from web-access-control-spec.

There is nothing unnatural with relative or prefix base URLs in RDF. One just has to think of acl as a prefix based URL with a hidden prefix. Nothing special.

from web-access-control-spec.

I agree that it is possible to have IANA terms and full URLs; however, that translation is anything but obvious (unless you happen to be familiar a particular sub-point within the ATOM RFC).

Based on long conversation in mnot/I-D#140 I wouldn't put much faith in IANA to provide stable IRIs for link relations. Also even if they would one couldn't use those full IRIs in HTTP headers since most, probably all implementations wouldn't do any 'expansion of hidden prefixes'.

I think slight esthetics of examples don't justify possibly opening a can of worms with trying to use registered with IANA link relation strings and full IRIs interchangeably.

from web-access-control-spec.

Btw. there is an important difference between LDP URI usage and acl. The ldp:BasicContainer appear in object position and so cannot be shortened. The type relation was felt not to be clearly enough defined and would have in any case forced an owl:sameAs relation to the one RDF uses, so that it would not have simplified anything.

With acl on the other hand we already have deployments, it clearly is related to protocols, and so it make sense to register it. Having a mapping to RDF cannot affect in any way the protocols, so that there is not much that the IETF folks can say against it really.

The use cases for acl as URIs are also for the moment quite hypothetical. They assume a result value for HTTP headers that has not been defined yet, and would be an efficiency improvement over the current functioning rather than providing a new feature. For those hypothetical use cases the transformation of acl to a URI is a good option.

from web-access-control-spec.

Closing this as per definition of acl link relation type in Solid Protocol ( solid/specification#199 ) - and to be followed up with IANA depending on uptake in Solid and elsewhere.

Aside: for the time being, the definition of the relation is in Solid Protocol spec but it can move into the WAC spec... TBD.

Noting that http://www.w3.org/ns/auth/acl#accessControl is already defined in the ACL Ontology that can be used as an extension relation type. Alternate: https://www.w3.org/ns/iana/link-relations/relation will exist regardless and if/when acl makes it into IANA, there'll be https://www.w3.org/ns/iana/link-relations/relation#acl available that can be used as an extension relation type complementing the registered type.

So many choices. So little time.

from web-access-control-spec.

Request to register "acl" link relation type: protocol-registries/link-relations#32

from web-access-control-spec.