Repository navigation
Access Control Resource discovery #228
Description
On proposal
ACP, WAC, WAC+...
Details
An Access Control Resource is discovered via a Link header on HEAD and GET requests to the resource over which it mandates access.
The initial editor draft of the WAC specification proposes registering the IANA Link Relation name acl.
Two main strands of link relation names are discussed:
- Having a standard IANA registered link relation name for access control resources & supporting both the short relation name and its corresponding IRI on the client. For example, a registered relation name
aclwould correspond to the IRIhttps://www.w3.org/ns/iana/link-relations/relation#acl. - Support one IRI that would be a property in the most relevant ontology.
Two approaches on access control resource discovery could be used:
- Denoting the type of access control system in use in the link relation name, which would mean having a specific relation name for each authorization system (for example, WAC, ACP, WAC+)
- Denoting the type of access control system in a link type header when dereferencing the Access Control Resource
The latter seems more ideal, first and foremost because it allows the use of a standard header accross the whole Solid ecosystem for access control resource discovery.
One additional point would be good to clarify:
- Should an Access Control Resource mandating control over itself follow the same Access Control Resource discovery mechanism and therefore reference itself via the chosen
Linkheader onHEADandGETrequests?
We could maybe consider registering a standard IANA link relation:
| Relation name | Description | Reference |
|---|---|---|
| access-control | Refers to a resource mandating access over the link's context. | Solid Protocol |
Reasons for spelling out "access control" instead of using "acl" could include:
- The specificity seems more adequate, that is, a resource that is not strictly speaking an
aclcould mandate control over the current context - The currently registered standard relationships are not acronyms and it seems to me that the clear and explicit spelling "access-control" for a link relation would have positive effects on adoption (potentially beyond Solid and generally for access control discovery)
- It would eliminate the conflation of (or clarify the difference between) access control discovery and access control system
Acceptance criteria
What actions are needed to resolve this issue? (checklist)
- Discuss whether the
access-controlrelation name is more adequate thanacl - Agree on the reason for registering a standard IANA relation name
- Agree on denoting the type of access control system in a link type header
- Agree on standard self-referencing for access control resources mandating access over themselves
- Reflect the decision in the relevant specifications (Solid protocol, ACP, WAC)
Activity
elf-pavlik commentedon Jun 17, 2021
I think we should clarify how that impacts conformance criteria for different classes of implementations. To be more specific:
IMO if client has to support both link relations, it doesn't make sense to define registered one and we should only use the full IRI. I can see argument that if server has to include both link relations, some clients may not implement the full IRI one.
matthieubosquet commentedon Jun 18, 2021
@elf-pavlik I think you are right, we should settle on one and only one standard link relation name.
My preference lies with
access-controlfor the aforementioned reasons.The way I see it, if we go forward with the IANA registration, then full IRIs will be only relevant to resource representations, but I would leave that to be implementation specific and non-normative. Similarly to what is done in advertising LDP resources, I would say:
bblfish commentedon Jun 18, 2021
It does seem to be equivalent to such a triple, though, and it is very helpful to think of it that way.
The relation would be equivalent to
with $acl replaced with the URL of the access-control resource.
Perhaps it would be better to make the positive statement that it is such a server asserted metadata triple (since it appears in the header).
If that is accepted then one could deprecate the
acl:accessControlrelation, directing people to use the iana link relation.matthieubosquet commentedon Jun 18, 2021
Currently, the
acl:accessControlproperty is defined as follows:acl:accessControl a rdf:Property ; rdfs:subPropertyOf rdfs:seeAlso ; rdfs:domain gen:InformationResource ; rdfs:range gen:InformationResource ; rdfs:isDefinedBy <http://www.w3.org/ns/auth/acl#> ; rdfs:label "access control"@en ; rdfs:comment "The Access Control file for this information resource. This may of course be a virtual resource implemented by the access control system. Note also HTTP's header Link: foo.meta ;rel=meta can be used for this."@en .I'm wondering if instead of deprecating it, we might make it a subproperty of
rel:access-control.Absolutely, I just think that:
Therefore, both server and client should rely on the Link header, hence the "equivalence" comment
Definitely not the best wording, I agree, because yes, I absolutely think that the relationship would translate to that triple in RDF. It's just that the relationship would authoritatively be denoted solely by the Link header, which I think is the important bit to clarify. I'm not against stating the relationship between the statement and the header though.
What about:
bblfish commentedon Jun 18, 2021
@bblfish wrote
@matthieubosquet answered:
we are not concerned here about the body of the HTTP Message, but about the headers. The headers is the place for metadata provided by the server.
HTTP/2.0 has moved to a binary format, showing that it is not the syntax that is important.
So we could put our RDF goggles on and see the headers as a special case of RDF, especially the Link header.
And that is what I mean by equivalent: We can translate the link header with the
rel="acl"orrel="access-control"header as an an RDF triple.Pragmatics
Now the HTTP header as a document format is not special because it syntactically restricts what can be said. Actually, with the
Linkheader it can express pretty much any RDF - not in the most elegant way perhaps, but nevertheless...What is special about the header when it is in a response to a GET, PUT, ... request on a resource, is that it is the expression of the web server. As part of that response event, it is attributable to the Web server to which the request was made. Since that Web Server is responsible for the name space it is authoritative in its answers. So if the Web Server says: this is the
access-controlresource, then it has made it the case by stating it.This is known in linguistics as Pragmatics, and especially as a speech act. That is why I called those Document Acts in my 2nd year report. Note that it took about 50 years before it was realized that syntax/semantics was not enough to explain meaning, but that one also needed pragmatics.
elf-pavlik commentedon Jun 18, 2021
I have very simple question:
Since we want to be able to make statements using that relation in RDF, which means we need an iRI, why we don't simply use that IRI as link relation?
Registered link relations are in no way more important or appropriate than using a full IRI. I really don't get why would we get into: If you want to include this information in link header use this and if you want to include this information in RDF use something else. While using the same predicate in both places is completely valid.
With exception of
revbeing deprecated so one can't use predicates in reverse directions.bblfish commentedon Jun 18, 2021
You are right, @elf-pavlik: we should try to think of this in a principled way. Is the principle you are invoking that "we should not have two ways of expressing something when we can do with one?"
matthieubosquet commentedon Jun 18, 2021
@bblfish I completely agree that the
Linkheader being the expression of the web server is what makes it special and authoritative. I'll leave that for a moment before trying to reformulate the note because I think @elf-pavlik's question supersedes this matter.The question of transliteration of link relations to RDF made me wonder what actually exists in the space in the form of a standard. I don't see a mention of RDF equivalence in the RFC8288 on web linking. The most relevant specification seems to be RDFa, which uses the XHTML vocab namespace (http://www.w3.org/1999/xhtml/vocab#) to translate reserved relation names:
Which makes me wonder where the translation of link relation types to RDF using the "https://www.w3.org/ns/iana/link-relations/relation#" namespace is specified.
Did I miss a standard?
However, this prompts two thoughts:
But why registering a standard relation type?
I do agree, as I've stated in my previous answer to your question @elf-pavlik that those concerns and reasons for registering a relation type with IANA over using from the get go a URI are relatively subjective and maybe strategic in their nature. I can't think of a specific and purely technical reason to not use a URI. But then, I don't think that given the history and best current practice we have a purely technical reason not to register a standard relation type at IANA either.
EDIT:
See also comment solid/web-access-control-spec#21 (comment) linking to the Atom Syndication Format RFC4287 section on the "rel" attribute, which states:
Which seems, if anything, to add to the confusion of translating IANA registered types to IRIs with three known forms:
elf-pavlik commentedon Jun 18, 2021
It has no official standing. There is a 100 comments thread which went nowhere mnot/I-D#140
Only if one doesn't use an IRI.
There is not.
When IRI is getting used as link relation it simply doesn't need to be registered.
matthieubosquet commentedon Jun 21, 2021
@elf-pavlik I can see this matter has been discussed at length already. I understand your preference for IRIs. I agree that there is no well defined and unique way of extending an IANA registered relation to an IRI which is problematic. I see that Henry has previously invoked similar reasons to mine for nonetheless going the IANA route but I appreciate that you have been advocating on the issue for years (the mnot/I-D#140 thread alone goes on for months) and that your concerns are valid and also echoed. I also see the concern about
aclnot being generic enough already mentioned. Finally, the fairly recent resolution of the IANA registration thread with linked stated intent to start the registration process seems to acknowledge the strategic value of moving forward and the open question of where the relation should live as well as the unknown "Will the registration process even succeed?"...Thanks for helping me get my head around the issue.
I'll try to gather more information and come back to it once the main question is answered, namely, can we:
matthieubosquet commentedon Jun 29, 2021
@elf-pavlik, to your argument, I just discovered that identifying registered relation types with a URI is explicitly discouraged by the Web Linking RFC8288 in its Registered Relation Types section:
Reading the Extension Relation Types section of the Web Linking spec makes me lean even more towards your point of view.
That being said, I don't think that even Extension Relation Types have a well defined mapping to RDF when used as link headers (even though pretty obvious). And I would suggest that maybe it would be good to bridge this gap.
cc @acoburn re: solid/web-access-control-spec#21 (comment)