Access Control Resource discovery

[matthieubosquet]

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:

1. 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 acl would correspond to the IRI https://www.w3.org/ns/iana/link-relations/relation#acl.
2. Support one IRI that would be a property in the most relevant ontology.

Two approaches on access control resource discovery could be used:

1. 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+)
2. 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 Link header on HEAD and GET requests?

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 acl could 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-control relation name is more adequate than acl
• [ ] 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)

[elf-pavlik]

For example, a registered relation name acl would correspond to the IRI https://www.w3.org/ns/iana/link-relations/relation#acl

I think we should clarify how that impacts conformance criteria for different classes of implementations. To be more specific:

• Does server have to include both link relation in response header or either one?
• Does client have to anticipate server using either one - so support both, or client can support either one if server has to include both.

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]

@elf-pavlik I think you are right, we should settle on one and only one standard link relation name.

My preference lies with access-control for 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:

A server MUST advertise access control resources via a HTTP link header with the relation name access-control, (that is, rel="access-control"). Note: This is not equivalent to the presence of a "subject-URI, rel:access-control, access-control-resource-URI" triple in a resource."

[bblfish]

Note: This is not equivalent to the presence of a "subject-URI, rel:access-control, access-control-resource-URI" triple in a resource."

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

<> <https://www.w3.org/ns/iana/link-relations/relation#access-control> $acl .

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:accessControl relation, directing people to use the iana link relation.

[matthieubosquet]

Currently, the acl:accessControl property 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.

It does seem to be equivalent to such a triple, though, and it is very helpful to think of it that way.

Absolutely, I just think that:

1. In an RDF resource representation, potentially, anyone can say anything which is not very suited to the purpose of access control discovery
2. Some resources wouldn't even have an RDF representation

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:

Note: This relationship between a resource and its access control may be denoted in RDF by the triple <> <https://www.w3.org/ns/iana/link-relations/relation#access-control> $acl .. However, relying on such a triple as an authoritative indicator would be problematic for: resources that don't have an RDF representation, clients that don't parse RDF, and servers that don't want to server manage/restrict usage of that predicate.

[bblfish]

@bblfish wrote

It does seem to be equivalent to such a triple, though, and it is very helpful to think of it that way.

@matthieubosquet answered:

Absolutely, I just think that:

1. In a resource representation, potentially, anyone can say anything which is not very suited to the purpose of access control discovery
2. Some resources wouldn't even have an RDF representation

• Regarding 2: The body 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.
• Regarding 1:
  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" or rel="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 Link header 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-control resource, 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]

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.

Now the HTTP header as a document format is not special because it syntactically restricts what can be said. Actually, with the Link header it can express pretty much any RDF - not in the most elegant way perhaps, but nevertheless...

With exception of rev being deprecated so one can't use predicates in reverse directions.

[bblfish]

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]

@bblfish I completely agree that the Link header 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:

rel (reserved word | CURIE): See the reserved values list in @rel/@rev Attribute Values

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:

1. There is precedent in transliterating a link relation reserved word using a specific namespace
2. The web linking standard does point to a process for registering standard relation types and the mere existence of a "https://www.w3.org/ns/iana/link-relations/relation#" namespace seems like an implicit RDF equivalence even if I miss a standard saying that the IANA reserved words translate to RDF

But why registering a standard relation type?

1. It gives visibility
2. It is a standard process described in the web linking spec
3. It needs not be bound to rdf and there might be a standard way to transliterate

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 https://github.com/solid/web-access-control-spec/issues/21#issuecomment-480277228 linking to the Atom Syndication Format RFC4287 section on the "rel" attribute, which states:

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

Which seems, if anything, to add to the confusion of translating IANA registered types to IRIs with three known forms:

• The W3C namespace: https://www.w3.org/ns/iana/link-relations/relation#
• The XHTML vocabulary W3C namespace, via RDFa: http://www.w3.org/1999/xhtml/vocab#
• The IANA namespace, via Atom: http://www.iana.org/assignments/relation/"

[elf-pavlik]

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.

It has no official standing. There is a 100 comments thread which went nowhere https://github.com/mnot/I-D/issues/140

2. It is a standard process described in the web linking spec

Only if one doesn't use an IRI.

3. It needs not be bound to rdf and there might be a standard way to transliterate

There is not.

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.

When IRI is getting used as link relation it simply doesn't need to be registered.

[matthieubosquet]

@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 https://github.com/mnot/I-D/issues/140 thread alone goes on for months) and that your concerns are valid and also echoed. I also see the concern about acl not 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:

1. Use one standard relation type for all access control systems, and,
2. Denote the specific type of access control system an access control resource uses through a link type header?

[matthieubosquet]

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

Historically, registered relation types have been identified with a URI [RFC3986] by prefixing their names with an application-defined base URI (e.g., see Appendix A.2). This practice is NOT RECOMMENDED, because the resulting strings will not be considered equivalent to the registered relation types by other applications. Applications that do use such URIs internally MUST NOT use them in link serialisations that do not explicitly accommodate them.

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: https://github.com/solid/web-access-control-spec/issues/21#issuecomment-480277228