WAC-Allow vs Link: ... rel="http://www.w3.org/ns/solid/acp#allow" ...

[bblfish]

The new ACP: Enforcement & Propagation document has a Access Control Visibility section which proposes to do the same thing as the Solid Spec's WAC-Allow header but using Link headers instead.

I think an example of WAC-Allow is as follows

WAC-Allow: user="read append write"

The ACP version has this example:

Link : <http://www.w3.org/ns/solid/acp#Read> rel=http://www/w3.org/ns/solid/acp#allow",
       <http://www.w3.org/ns/solid/acp#Append> rel=http://www/w3.org/ns/solid/acp#allow",
       <http://www.w3.org/ns/solid/acp#Write> rel=http://www/w3.org/ns/solid/acp#allow"

[bblfish]

The Link header is a lot longer but has the advantage of not needing a special parser or new header field. Link headers can be conceived as RDF triples (indeed I wrote a Link Header Parser in rww-play that turned those into RDF graphs).

Thinking of it in terms of RDF does bring up a semantic question though: the subject of a Link header is by default the resource on which the request was made. The header above would then be saying that the requested resource is acp:allow relation to acp:Read, acp:Append, acp:Write mode:

</cat.jpg> acp:allow acp:Read, acp:Append, acp:Write .

But the acp ontology defines acp:allow as

acp:allow a rdf:Property ;
    rdfs:label "allow"@en ;
    rdfs:comment "The allow property identifies the access modes a Policy allows."@en ;
    rdfs:domain acp:Policy ;
    rdfs:range acp:AccessMode ;
    rdfs:isDefinedBy acp: .

Notably the domain of acp:allow is an acp:Policy. But the document that is the subject of the suggested Link relation need not be a Policy and indeed mostly will not be such a thing.