You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal solves the 2n+1 request cost problem for finding the effective ACL of a resource, reducing it down to a max of 2, while being fully compatible with the current spec. I have implemented this in Solid-Control Pr25 and have built a crawler script in SolidCtrl App repo.
The idea is simple: A server can add a defaultAccessContainer link to a resource, pointing to the effective ACL container, which will point using the acl link to the effective acl. This is similar to the proposal in #325, which pointed directly to the effective acl. The problem with that proposal became apparent implementing a client. Fetching the direct acl for a resource makes it difficult for later requests on subresources of the default container to search their own cache for a potential default ACL candidate.
Short description
We want a client to make as few requests as possible. So if it is crawling a Linked Data Event Stream or blogs on a server, it should, ideally once it has found the default ACL for one resource, be able to guess that all the other resources located in that container or subcontainers can be accessed using the same authentication mechanism. Meaning that if the LDES stream is 100 resources it would only need to make
a request to the resource R1 and receive a 401 with link to the default ACL dir using link type "defaultAccessContainer" to the ../../ which resolves to Cd
HEAD on default ACL dir Cd which points to ACL Ar
fetch ACL Ar
fetch R1 with signed header successfully
fetch 99 other resources successfully, as long as they are in that container. (it is possible that some subcontainers have different access rules, but then a client would just start at 1 above again)
so the total number of requests would be 100+3
The direct link to the ACL reduces that by 1 to 100+2,
but it means that a client cache that presumably is following links around the web does not have information in its DB going directly from the container with the effective acl to the acl. That means that basic caches cannot be used, but one needs to enhance those with information about incoming links.
(Note: I have been thinking this through in this document The Cache)
Detailed description
GET /ldes/defaultCF/stream HTTP/1.1Host: localhost:8080Accept: text/turtle, application/n-triples, application/rdf+xml, application/ld+jsonDate: Sat, 03 Jun 2023 16:16:33 GMTConnection: keep-aliveUser-Agent: http4s-ember/1.0.0-M39
This returns a response containing an
acl link to the resource that currently does not exist but that the client can edit to create a specialised access control rule for that resource.
a defaultAccessContainer link to the container that contains an existing acl with a default rule.
With that information, the client can then authenticate with a signed request using HTTP-Sig in this case
GET /ldes/defaultCF/stream HTTP/1.1Host: localhost:8080Accept: text/turtle, application/n-triples, application/rdf+xml, application/ld+jsonSignature-Input: sig1=();created=1685808993;keyid="http://localhost:8080/rfcKey#"Signature: sig1=:iKfT6OcNPWegDWjHQbsjJ+1ELopixW5FXDMyPYJHQDr2P4duHHDIcjI9Y4S6/bgODK/v1y+aQqzN17ETUFvHh8ULBp2ABcWwjfnk96+fwXjA5WAsF0RaE813GjJMIstWLITHvqQBQHa84BqhGKr5R8fQCKKeehedINvD59rn4zmvQx8WXYvSOxTMdGvtAb59nUXY2n7+Hb7pvCGj3P09Zl23kcMkOKSq1Sz/OIse/7MQAaULsOW8931rGb9RQVhbsyGIuDtuPrlYVz0jO0gnk2hDKFJL7gXAEKQ8UokwMyiZghXOKRpROsS4vRgvTirEEtV2aOaTTfCummeUjaidgQ==:Authorization: HttpSig proof=sig1Date: Sat, 03 Jun 2023 16:16:33 GMTConnection: keep-aliveUser-Agent: http4s-ember/1.0.0-M39
If a client wants to make a request later to /ldes/defaultCF/2023/06/06/00_08, the client can search through the local cache hierarchy all the way down to /ldes/defaultCF/ following reverse ldp:contains links or just the directory structure, and from there find the link to the effective acl, that will also be in the cache due to the interaction above. That can be done very efficiently as it requires no internet communication. (see also #528 ), allowing the client to sign the next request immediately.
The text was updated successfully, but these errors were encountered:
This proposal solves the 2n+1 request cost problem for finding the effective ACL of a resource, reducing it down to a max of 2, while being fully compatible with the current spec. I have implemented this in Solid-Control Pr25 and have built a crawler script in SolidCtrl App repo.
The idea is simple: A server can add a
defaultAccessContainer
link to a resource, pointing to the effective ACL container, which will point using theacl
link to the effective acl. This is similar to the proposal in #325, which pointed directly to the effective acl. The problem with that proposal became apparent implementing a client. Fetching the direct acl for a resource makes it difficult for later requests on subresources of the default container to search their own cache for a potential default ACL candidate.Short description
We want a client to make as few requests as possible. So if it is crawling a Linked Data Event Stream or blogs on a server, it should, ideally once it has found the default ACL for one resource, be able to guess that all the other resources located in that container or subcontainers can be accessed using the same authentication mechanism. Meaning that if the LDES stream is 100 resources it would only need to make
R1
and receive a 401 with link to the default ACL dir using link type "defaultAccessContainer" to the../../
which resolves toCd
Cd
which points to ACLAr
Ar
R1
with signed header successfullyso the total number of requests would be 100+3
The direct link to the ACL reduces that by 1 to 100+2,
but it means that a client cache that presumably is following links around the web does not have information in its DB going directly from the container with the effective acl to the acl. That means that basic caches cannot be used, but one needs to enhance those with information about incoming links.
(Note: I have been thinking this through in this document The Cache)
Detailed description
This returns a response containing an
acl
link to the resource that currently does not exist but that the client can edit to create a specialised access control rule for that resource.defaultAccessContainer
link to the container that contains an existing acl with a default rule.Seeing the
defaultAccessControl
link, the client follows that link with a HEAD to find the effectiveacl
link.From that, the client can find the
acl
rulesWith that information, the client can then authenticate with a signed request using HTTP-Sig in this case
If a client wants to make a request later to
/ldes/defaultCF/2023/06/06/00_08
, the client can search through the local cache hierarchy all the way down to/ldes/defaultCF/
following reverseldp:contains
links or just the directory structure, and from there find the link to the effective acl, that will also be in the cache due to the interaction above. That can be done very efficiently as it requires no internet communication. (see also #528 ), allowing the client to sign the next request immediately.The text was updated successfully, but these errors were encountered: