solid / web-access-control-spec Goto Github PK

View Code? Open in Web Editor NEW

119.0 28.0 25.0 922 KB

Web Access Control (WAC)

Home Page: https://solid.github.io/web-access-control-spec/

License: MIT License

HTML 100.00%

specification

web-access-control-spec's Introduction

Web Access Control (WAC)

Web Access Control (WAC) is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization conditions on HTTP resources using the Access Control List (ACL) model.

WAC (as used by the Solid Project) is based on Tim Berners-Lee's May 2009 proposal, as originally captured, and subsequently evolved by the community, at Web Access Control Wiki. This spec is a particular subset of the options and extensions described in the wiki, as well as implementation experience.

Implementations are strongly encouraged to use existing approaches that provide an extension of the rules of Linked Data, eg. Solid Protocol, LDP.

Work Items

Latest published version: https://solidproject.org/TR/wac
Editor’s Draft: https://solid.github.io/web-access-control-spec/

Participation

All substantive contributors to any Work Items must be members of the Solid CG. It’s easy to join the CG if you’d like to contribute.

Anyone can join the chat.

Code of Conduct

All work and communication within the Solid CG is covered by the Solid Code of Conduct as well as the Positive Work Environment at W3C: Code of Ethics and Professional Conduct.

web-access-control-spec's People

Contributors

Stargazers

Watchers

web-access-control-spec's Issues

Clarify if multiple accessTo can be used

The spec currently speaks about accessTo in the plural form, suggesting that multiple accessTo's can be used in the same document or even authorization block. Contrary to that, I've heard in another issue, that only one accessTo is expect per acl document. I think it would be good to clarify this.

The acl:accessTo predicate specifies which resources you're giving access to, using their exact URLs as the objects.

Can one acl file be used for multiple individual resources?

We are currently rewriting the solid-file-client library and for deleting files the question came up, if multiple files can share the same .acl file. We know that this is possible by inheriting from a folder, but wonder if it is also possible by directly linking to the same file.

Example:

foo/first.ttl     <Link: <common.acl>; rel="acl"
foo/second.ttl    <Link: <common.acl>; rel="acl"
foo/common.acl

What does write access to a container mean?

On a container, I think:

acl:Read means you can list the container members ('GET')
acl:Append means you can add new resources into it ('POST')
acl:Control means you can create, update or delete that container's ACL document
acl:Write means you can do 'DELETE' on that container

For starters, it's not clear to me from the LDP spec whether deleting a container also deletes its members.

But apart from that, it's not clear to me from the WAC spec whether deleting a container also deletes its ACL document (especially since editing the ACL document without acl:Control access should be impossible, right?)

Delegated Requests

https://github.com/solid/solid/blob/auth-webid-delegation/proposals/auth-webid-delegation.md

IMPORTANT: The reason why the delegatee must use its own identity (i.e. https://alice.example.org/agent#i) and credentials, is to avoid confusion as to who is actually performing the request. This is particularly important when applying access control policies, as we could imagine that certain resources may not be accessible for certain agents (delegatees).

I don't see in current draft any information on how to allow or disallow delegated requests.

access tickets

As discussed in inrupt/websockets-pubsub#2 (comment) the obvious way to pass a webid-oidc token to a websocket server (namely, same as for the WAC-LDP interface, wrap it into a bearer token in the Authorization header) is not possible when opening a WebSocket from the browser. I looked around for alternatives of how to give a WebSocket server a webid-oidc token from the browser, and options seem to be we can introduce a new scheme for this which the client should follow (that would be spec-breaking), or we can try to somehow configure the server in such a way that an authenticated client will open the WebSocket with proof of identity. One way to do that would be by setting a Cookie, but setting Cookies from an API is a bit ugly. So the other option would be to use a short-lived 'read capability' as the Updates-Via URL. So either the link from the Updates-Via header instructs the client to include their whole PoP token in the URL (but that's not best practice because of replay attacks), or the URL includes a short-lived proof of identity (much saner from a security perspective), which we can call an 'access ticket', and hopefully that ticket could also be a shorter string (although if that makes shared state between the wac-ldp server and the websockets-pubsub server necessary then the shortness of the string may not be worth it).

Atomicity of creating a resource and its ACL

With solid/specification#31 an ACL has to be created after the resource, and until it does, the inherited ACL is used. It may be problematic if more restrictive permissions is required when a resource is required in a permissive container.

Can ACL docs be in JSON-LD?

Since LDP officially supports JSON-LD as a 'SHOULD', it feels like the WAC spec should too, right? But when trying to write unit test for ACL docs in JSON-LD format, I ran into this problem:

 $ curl -H "Accept: application/ld+json" http://www.w3.org/ns/auth/acl
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>406 Not Acceptable</title>
</head><body>
<h1>Not Acceptable</h1>
<p>An appropriate representation of the requested resource /ns/auth/acl could not be found on this server.</p>
Available variants:
<ul>
<li><a href="acl.ttl">acl.ttl</a> , type text/turtle</li>
<li><a href="acl.rdf">acl.rdf</a> , type application/rdf+xml</li>
<li><a href="acl.n3">acl.n3</a> , type text/n3</li>
</ul>
</body></html>

Should we ask the webmasters of w3.org to publish a JSON-LD representation of http://www.w3.org/ns/auth/acl?

Clarify: 'acl' rel link is a naming hint, not always points to existing file

Add an explanation to the ACL Resource Discovery section that the rel="acl" link will be returned even if no actual individual .acl file is present. That is, it's a naming hint, and not necessarily a link to an existing ACL resource.

acl:accessTo and rel="acl"

Could acl:accessTo become optional for authorizations? This would allow reuse of permission sets. A document could reference any permission set with rel="acl" and all the authorizations which don't have explicit acl:accessTo would apply to the document which referenced it with rel="acl". Authorizations with statements using acl:accessTo would only apply to resources used as object in those statements, it could come helpful for adding authorizations on ACL resource itself.

For example

HEAD /profile HTTP/1.1
Host: dataset.alice.example

HTTP/1.1 200 OK
Link: </acl/public-read>; rel="acl"

# Contents of https://dataset.alice.example/acl/public-read
@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<#owner>
    a acl:Authorization;
    acl:agent <https://alice.example/>;  # Alice's WebID
    acl:mode
        acl:Read, acl:Write, acl:Control.
<#others>
    a acl:Authorization;
    acl:agentClass foaf:Agent;  # Alice's WebID
    acl:mode
        acl:Read .

dataset.alice.example would apply two authorizations above to any document which it serves with Link: </acl/public-read>; rel="acl"

I deleted my profile/card

Hi, I'm testing solid and I deleted the profile/card. How can I recover it?
My account is https://afi.solid.community/

Best regards.

Algorithm for finding authorizations in an ACL document?

The specification gives an algorithm for finding the appropriate ACL via inheritance but as far as I can see there is no explicit algorithm for finding the authorizations within the ACL document. In the examples it seems that each authorization is 1) given a hash-URI (fragment) in the ACL and 2) is identified with a type triple <#auth-uri> a acl:Authorization. Are either or both of these the requirements for identification of the authorizations within and ACL document?

(Context of this question is use of WAC on the Fedora Repository API specification)

Data that may be used in query answering but not projected

If we decide to have SPARQL on the server side, an interesting problem emerges:

The simplest way to evaluate a query is to only evaluate it over data that the user has been authorized to read. However, with server-side SPARQL, there is a difference between reading and exposing data, i.e., the query engine could evaluate a query over data that the user is not allowed to read, and the data would not be projected to the user. I.e. the SPARQL engine reads data just to evaluate a query, but the client doesn't see those data.

There are obviously risks to this, the client might be able to piece together the data that was used with the knowledge that it gained from queries that it was allowed to run. However, I think this calls for a new mode.

Precise definition of acl:default

The spec states "[...] if an Authorization contains acl:default, it will be applied by default to any resource in that container". Does that mean that value after acl:default doesn't make any difference?

For instance should following statements be treated as equivalent?

<#1> acl:default <https://alice.databox.me/docs/>

<#1> acl:default <https://alice.databox.me/foo/bar/>

Class listing mentioned, but not defined

The spec mentions a "Class listing" twice, but the term is not defined.

I suppose that you'd use a group listing if a list was appropriate, for classes, you'd reason about class membership? Could this mention simply be removed?

Consider adding acl:originGroup

Just a thought, for symmetry with how acl:agentGroup can be used as a level of indirection between the ACL doc and the list of actual acl:agent webid's, maybe it would be powerful to have a similar level of indirection between the ACL doc and the list of actual acl:origin apps.

Add example of agentClass / Group usage

Add an example of what a resource listing the members of a group looks like.

say something about trailing slashes

In https://www.w3.org/TR/ldp-bp/#include-a-trailing-slash-in-container-uris it's recommended to refer to a container with a trailing slash, but i think it can be expected of a server to add that trailing slash if it's missing?
For instance I I write:

<#owner> acl:accessTo <https://mypod.com/foo> .

in https://mypod.com/foo/.acl then the server should interpret that as

<#owner> acl:accessTo <https://mypod.com/foo/> .

Express what expectations users should have of acl:AuthenticatedAgent

In solid-contrib/test-suite#36 , I found that a custom IDP that simply gave away bearer tokens without attempting to authenticate a user would best fulfill the needs of a test suite. Then, I had second thoughts, because the existence of such an IDP would subvert the mechanism of acl:AuthenticatedAgent. I figured we should therefore have some kind of shared secret between a test runner and the system under test. But then, I figured, if we can create such an IDP, so can anybody else.

We can certainly specify that an IDP must authorize an agent, there could even be laws against it in some jurisdictions, but we probably cannot make them go away entirely if there is value to some.

Thus, acl:AuthenticatedAgent does not mean acl:ReasonablyWellBehavedAndKnownAgent, it is marginally different from foaf:Agent, in that you could have agents with a valid bearer token that has been through no authentication process.

Whether this should make us re-evaluate whether acl:AuthenticatedAgent should exist at all, or if we should just adjust user's expectations towards it, I don't know, but it should be discussed.

acl:AuthenticatedAgent missing in RDF ontology

I can see that acl:AuthenticatedAgent class was recently added to the wiki [1], but it is still missing in the RDF version of the ontology [2].

[1] https://www.w3.org/wiki/WebAccessControl#Agents_and_classes
[2] http://www.w3.org/ns/auth/acl

Add preamble explaining that this spec is only one of four existing flavours of WAC

As @namedgraph pointed out, this is not the only WAC spec.

Does anybody know how and why this situation arose?

https://www.w3.org/wiki/index.php?title=WebAccessControl&action=history shows edits from @bblfish, @timbl and others over the period 2009-2018.

https://github.com/solid/web-access-control-spec/commits/master?after=6e7bc5130e47699618c807344b226719bf53db66+34 shows edits from @dmitrizagidulin, @deiu, @timbl, @kjetilk, @TallTed, @acoburn and @elf-pavlik over the period 2016-2019

Access by server to group listing is not on behalf od user

The current text:

"WebID-TLS Delegation. If your implementation uses the WebID-TLS authentication method, it also needs to implement the ability to delegate its requests on behalf of the original user."

The original user (the one requesting the resource whose access is to be checked, I assume) is not the one accessing the group file. The server itself needs to get access. It could have its own webid. You can imagine situations where the person accessing the resource does so because she is a Student but she does not have access to the list of all people in class Student.

Even the person writing the ACL could give access to people in class Student without being able to read the list. (We could decide to not support that feature, and make the server's access deemed to be a delegation of the resource owner's access. We could require the person setting the ACL to get a signed copy of the list -- signed by the owner of the file -- and hand it to the data store which then keeps it.)

Other possibilities are for servers to trust each other. Or for group lists to be copies by client code onto many servers.....

Circumventing Origin restriction with proxies

https://github.com/solid/web-access-control-spec#referring-to-origins-ie-web-apps

When a compliant server receives a request from a web application running in a browser, the browser will send an extra warning HTTP header, the Origin header.

What about cases where 'malicious' app running in a browser uses a proxy to change the Origin header? I think it might work differently with WebID-OIDC and WebID-TLS.

Malicious app still would need to know which 'allowed' origin to use but let's consider scenario where it knows that 'allowed' origin and proxy sets header to it.

Make explicit in spec that when a default resource is served for a container, server should check ACL for that resource

As a continuation of solid/solid-spec#134, we might want to make it explicit in this spec that the server should check the default resource's ACL.

Examples:

If serving index.html for a container, check index.html.acl (and traverse container ACLs as usual)
If serving index.ttl for a container, check index.ttl.acl (and traverse container ACLs as usual)
If serving the virtual resource for a container, there's no specific resource ACL to check, but traverse container ACLs as usual

Document origin and originClass

Add a section with examples illustrating acl:origin and acl:originClass predicates for filtering agents.

(Note to self: get example Turtle statements from @deiu or @timbl.)

IANA registration of Link: rel="acl"

Is there a plan to register the "acl" link relation with IANA?

acl is not currently registered: https://www.iana.org/assignments/link-relations/link-relations.xhtml

'Request Access' html on 401 responses

Similar to how you can request access to a document on Google Docs, we could invent a way such that a visitor could cause an email to be sent to the owners, so they can consider whether they want to add an ACL rule for the visitor's webid.

Control access on the container

While working on ACL tests, I had two tests that simply accessed the container's .acl, but with different permissions, one had:

  <#0>
  a <http://www.w3.org/ns/auth/acl#Authorization>;
  <http://www.w3.org/ns/auth/acl#default> <./> ;
  <http://www.w3.org/ns/auth/acl#agent> <https://tim.localhost:7777/profile/card#me> ;
<http://www.w3.org/ns/auth/acl#mode> <http://www.w3.org/ns/auth/acl#Write>, <http://www.w3.org/ns/auth/acl#Control>.

and the other:

<#Owner>
 a <http://www.w3.org/ns/auth/acl#Authorization> ;
 <http://www.w3.org/ns/auth/acl#accessTo> <./>;
 <http://www.w3.org/ns/auth/acl#agent> <https://tim.localhost:7777/profile/card#me>;
<http://www.w3.org/ns/auth/acl#mode> <http://www.w3.org/ns/auth/acl#Read>, <http://www.w3.org/ns/auth/acl#Write>, <http://www.w3.org/ns/auth/acl#Control> .

Now, I'm underslept due to being held awake by kids and coughing, so excuse me if I'm wrong, but this seems to be two different interpretations of what the ACL file is. In the first test, the .acl is a resource like the others, and so you grant Control to that. And that seems like a misunderstanding that I recently held too. My interpretation of this authorization is that you grant control to the resources in the container, not the container itself, and thus not Control to the container's ACL file.

In the latter case, Control is granted on the container, and therefore you can read and write .acl.

Given that both tests are testing access to the .acl, I'm inclined to say that the first tests is wrong, it needs a <http://www.w3.org/ns/auth/acl#accessTo> <./>; predicate-object in the ACL.

Alternatively, we could check for permissions viewing the .acl from both angles, so that both tests will pass as they stand.

I think it could use some detailing in the spec, thus this issue.

Update vocabulary

Related to #51, both wiki-flavoured and solid-flavoured WAC use the http://www.w3.org/ns/auth/acl vocabulary. Although it looks like it's more or less sufficient for wiki-flavoured WAC, there are definitely things missing from it that we do use here (like acl:trustedApp, for instance). We should either update the existing vocabulary or create a new one.

Questions about "document's container" and "container's parents container"

Hello!

I'm writing on behalf of the Fedora Repository project (https://github.com/fcrepo4) regarding an issue that was raised last week on our weekly tech call. We are in the process of aligning our reference implementation with the SOLID/WAC spec. In recent discussions questions have surfaced around the relationship between "container" in the SOLID/WAC vs LDP specs.

The SOLID WebAC spec describes the ACL inheritance algorithm in terms of a
"document's container" and the "container's parent container":

Use the document's own ACL resource if it exists (in which case, stop here).
Otherwise, look for authorizations to inherit from the ACL of the document's
container. If those are found, stop here.
Failing that, check the container's parent container to see if that has its
own ACL file, and see if there are any permissions to inherit.
Failing that, move up the container hierarchy until you find a container with
an existing ACL file, which has some permissions to inherit.
The root container of a user's account MUST have an ACL resource specified.
(If all else fails, the search stops there.)

[https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm]

For the purposes of implementing this algorithm in the context of LDP, we are
making the following assumption:

The terms "container" and "parent container" refer to LDP containment.

Given that assumption, in the case of basic containers the implementation is
straightforward. However, there appear to be complications in the case of
indirect containers, because of cases where a resource may have multiple parent
containers (by the definition of LDP containment).

Thus, we have the following questions about the ACL inheritance algorithm:

Are WebAC ACLs compatible with the concept of a resource having multiple
parent containers?
If so, how should the inheritance be resolved?
If not, should the ACL inheritance algorithm be interpeted as referring to
path-based containment? That is, is it operating solely on the level of URI
syntax, and not any semantics of the resource?

Your feedback/guidance on the issue would be most appreciated.

Clarify where new acl files should be created

The spec states where one can find acl files, but as far as I've seen it never says how the client could know where to create new acl files.

As mentioned in #8 it could be interpreted that the server also returns the acl link even if no acl file exists yet. If this behaviour is mandatory it could be used for deciding where to PUT new acl files.

But I wonder how this would work if I wanted to create a new acl file with multiple accessTo values. Just choosing one file at random and then pick its proposed acl link?

ACL Ontology Inaccuracies

The ACL Ontology provides a canonical source of information for Solid ACL processors. Thus, we need entity relationship types (relations) defined in the ontology to clearly inform said processors about the accepted domains and ranges of relations (rdf:Property class instances).

Currently, we have the following inaccuracy, with regards to property value ranges:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . 
@prefix acl: <http://www.w3.org/ns/auth/acl#> . 
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . 

acl:mode a rdf:Property ;
                    rdfs:range rdfs:Class .

Correction:

## Indicating that acl:mode is a relationship type (rdf:Property instance)
## that expects its object (value) to be 
## an instance of an acl:Access class

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . 
@prefix acl: <http://www.w3.org/ns/auth/acl#> . 
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . 

acl:mode a rdf:Property ;
                     rdfs:range acl:Access .

Compare webid-oidc to IndieAuth

See https://indieweb.org/How_is_IndieAuth_different_from_OpenID_Connect for inspiration

object of statements with acl:default predicate

https://github.com/solid/web-access-control-spec#default-inherited-authorizations

# [...]
<#authorization1>
    a acl:Authorization;
# [...]
    acl:accessTo <https://alice.databox.me/docs/>;
# [...]
    acl:defaultForNew <https://alice.databox.me/docs/>.

Can statements with subject <#authorization1> and predicates acl:accessTo and acl:defaultForNew can have different objects?
When this authorization gets applied to a document which object of acl:accessTo have ldp:contains relationship with. It seems that we get mismatch of acl:accessTo object (see #17 )
Can instead instance of ldp:Container itself use predicate like acl:default with an object of ACL document that documents which this container relates to via 'ldp:contains' and within don't have dedicated ACL will inherit.

[Question] Enforcement

Hello,

I've been reading through the spec and cannot find any mention on who enforces the WAC nor how.

The assumptions here (I haven't read all the specs, so I hope I'm wrong) are:

user data is encrypted
user data is distributed across multiple pods
each pod can mirror another
when a pod goes down or is otherwise perturbed, a user can access their data using any other pod in the system

If these assumptions are true, then how would the system be pod ecosystem protect itself against evil actors that provide pods (or clients) ignoring WACs?

Links to further reading are very welcome.

Cheers

Status of planned `acl:defaultForNew` to `acl:default` change

The note:

Note: The acl:defaultForNew predicate will soon be renamed to acl:default, both in the specs and in implementing servers. The semantics, as described here, will remain the same

was added in April 2016 and I see referenced in solid/solid#100 created at the same time.

Do you have any idea of the likely timeline for this change to be implemented? We'd like to use the correct term in the Fedora API specification but also agree that acl:default is much less misleading than acl:defaultForNew.

acl:accessToClass exclusion and pattern substitutes

Can the spec editors elaborate on the exclusion (by design) of the acl:accessToClass predicate? Is it a problem of entailment? Are there substitute patterns for simplifying ACL structures in SOLID? We have an open issue on its support in a downstream spec, and would like to offer an alternative (or an explanation).

remove "possible future" label from `acl:trustedApp` paragraph

In today's community meeting, we decided to go ahead with the acl:trustedApp system, so we should reword https://github.com/solid/web-access-control-spec#possible-future to say that it's currently part of the spec.

Create acl and resource at the same time

Afaik, we currently have to create a resource, then check the link header for the acl location and then create the acl file for it. If the acl file creation fails (or just takes a longer period of time), the resource will be visible to others who shouldn't be able to access it.

To prevent this, I think we would need to make the acl file before or at least at the same time as the resource. I'd suggest making them simultaneously, because then it can't happen that one succeeds and the other fails.

Document WAC-Allow header

Clarify "case as a group"

In the README there is the following sentence:

An application of this feature is to throw a resource open to all logged on users for a specific amount of time, accumulate the list of those who case as a group, and then later restrict access to that group, to prevent spam.

The question here is around the use of the word "case". Is it a typo or meant in the sense of "to examine or survey"? If the latter, I would suggest changing this wording as it sounds strange to my ear, er, looks strange to my eye. :)

[discuss] should we switch to requiring container-write instead of resource-write permissions for delete?

This spec clearly states that it requires acl:Write on the resource, but in nodeSolidServer/node-solid-server#729 NSS diverged from the spec.

In nodeSolidServer/node-solid-server#729 (comment) @dmitrizagidulin correctly remarked that this should be made into a spec-level discussion, but it seem that his remark was ignored?

So let's have the discussion now!

Pro change:

NSS implementers have already diverged from the spec at this point, and even though they didn't follow process, it would be practical to retro-actively agree with them
It aligns WAC more with how the Linux file system works

Con change:

All changes cost work, and this one is no exception
even though NSS may have made this change, inrupt/pod-server has not, so for the current implementations it's 1 against 1. @acoburn what does your Trellis extension for WAC do on this topic?
As remarked in nodeSolidServer/node-solid-server#729 (comment), and I agree, the current spec makes more sense.
It's weird if DELETE requires different permissions than PUT
If we do want to separate the two, it would make more sense to split acl:Write into acl:Create, acl:Update, and acl:Delete.
Now that I write this, I realize that the distinction is not just update/delete, it's create/update/delete, which makes it.

Mention how to use `acl:origin` in an authorization

The text explains you can add origins as well as agents in ACL rules. There is a section explaining that for agents you use acl:agent but I did not find an explicit reference to say origins are added to an ACL rule with acl: origin (at least that's the predicate NSS looks for)

definition and purpose of acl:GroupListing

https://github.com/solid/web-access-control-spec#groups-of-agents

Class acl:GroupListing doesn't seem to have any purpose, all groups have WebID (IRI denoting the instance of vcard:Group) and giving additional class to foaf:Document which has as its topic / describes one or more instances of vcard:Group doesn't seem to have any advantages.

The object of an agentGroup statement is a link to a Group Listing document.

It seems that WebID of a group gets used

    acl:agentGroup <https://alice.example.com/work-groups#Accounting>;
    acl:agentGroup <https://alice.example.com/work-groups#Management>.

and not the URL of the document <https://alice.example.com/work-groups>

"if" should be "is" in namespace :comment of acl:default

Logging here because I can find no better place to do so.

In http://www.w3.org/ns/auth/acl
the :comment of acl:default has --

access to the resource if given by the ACL

-- which should be --

access to the resource is given by the ACL

Tangentially, I strongly suggest that some information be added to the ontology doc, that helps others raise concerns and/or submit patches when other errors/issues are discovered.

Add section on inheritance - `default` vs `defaultForNew`

Add an explanation for the ACL inheritance mechanism (currently defaultForNew, to be renamed to default).

HTTP-Signature Auth for Solid?

HTTP-Signatures is an IETF draft standard that is pretty simple way to authenticate over HTTP using a public key. (Indeed both could work together by simply giving a key in a WebID profile a fragment-identifier based URL)

It could be used with a logic very similar to WebID by passing a WebID along with the signature. It could also work with DID's as I see, follow quite similar logic - as I see DID's try to create a distance between the key publication and the ID. And it could be a good base of Verifiable Claims too.

I wrote up some libraries in Scala Akka-Http-Signature and these could also be compiled to Scala-JS (and so used with JS) with a bit of work. I also wrote code that used this for authentication in a client app rww-scala-js using JavaScrypt Crypto library 4 years ago.

This would be as efficient as WebID-TLS.
The advantage over TLS is that it does not cross HTTP layers, and so should fit very well with HTTP2.0 (SPDY). It does not have the UI support of browsers on the other hand that WebID-TLS has (though that is not so good).

I suppose it would be interesting to check the advantages this would have over other authentication protocols used in SoliD, and to understand where this stands.

Add time constraints to WAC rules

The current Web Access Control Spec lets you create rules to control whether an agent or group of agents can access resources, and to specify specific modes of access (read, write, append, control). However, it doesn't allow for the specification of when these accesses are permitted.

In the simplest (and perhaps most useful) use case, this would allow for expiry of a given authorization rule. For example, a user wants to grant temporary access to someone, and creates an authorization rule that expires in twenty-four hours. However, other use cases could call for the ability to specify when the rule activates, or involve the ability to limit access to a certain time window each day, etc.

Add Implementation Notes section, mention ACL groups infinite loops issue

Add an Implementation Notes section. Discuss the various solutions to the ACL Groups infinite loops problem.

request for clarification: access to resources in container you don't have access to

on its face, the spec implies that a resource can have an individual ACL that can grant access even if the user doesn't have access to traverse through container(s) to where the resource is. specifically:

For fine-grained control, users can specify a set of permissions for each individual resource (which overrides any permissions of its parent container).

ACL Inheritance Algorithm...

in other words, there could be a resource in a container (maybe several levels deep) where the user has no access on the containers at all, but an acl on the resource could punch a hole to allow access (you could also imagine it as a wormhole or quantum tunneling).

it makes more sense to me that a user should at least have read permission to all containers down to the resource in order to access the resource. this is consistent with the Unix directory model (although in Unix you just need the "search" (via the "execute" bit) permission to traverse a directory, and the "read" permission to list its contents, but there's no distinct "search" in WAC).

if the "hole punch/wormhole/tunnel" semantics is intentional, please call it out as intentional, as it is surprising and inconsistent with peoples' normal experience and intuition with containers/folders/directories. otherwise if this case is an oversight, please correct it.

in my own implementation of WAC, any access of a resource requires read permission for all containers down to the resource, plus the required permission for the resource access itself.

ACL Expiry

Adding a new triple to an authorization with predicate acl:validTill is probably a needed use case. It says an authorization rule is valid till a particular time. The ACL resource should be cleaned removing expired aurthorizations.

solid / web-access-control-spec Goto Github PK

web-access-control-spec's Introduction

Web Access Control (WAC)

Work Items

Participation

Code of Conduct

web-access-control-spec's People

Contributors

Stargazers

Watchers

Forkers

web-access-control-spec's Issues

Recommend Projects

Recommend Topics

Recommend Org