Skip to content

Commit c11b3b5

Browse files
author
Tim Berners-Lee
committed
See bug #2 and also add some discussion of CORS, but not add OriginClass
1 parent 4d99cc1 commit c11b3b5

File tree

1 file changed

+187
-112
lines changed

1 file changed

+187
-112
lines changed

‎README.md‎

Lines changed: 187 additions & 112 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ Next](https://www.w3.org/community/ldpnext/)) type systems, such as the
1212
[Solid](https://github.com/solid/solid) project (see also the parent
1313
[spec](https://github.com/solid/solid-spec)).
1414

15-
**Current Spec version:** `v.0.4.0` (see [CHANGELOG.md](CHANGELOG.md))
15+
**Current Spec version:** `v.0.5.0` (see [CHANGELOG.md](CHANGELOG.md))
1616

1717
## Table of Contents
1818

@@ -290,118 +290,11 @@ the following issues:
290290
requests for Group Listing documents on other servers?
291291
3. Infinite request loops during ACL resolution become possible, if an `.acl`
292292
points to a group listing on a different server.
293+
4. Therefore, for the moment, we suggest that all Group files which are used
294+
for group ACLs are public.
293295

294-
##### Group Listings - Authentication of External Requests
295-
296-
Group Listings via `acl:agentGroup` links introduce the possibility of an ACL
297-
checking engine having to make requests to other servers. Given that access to
298-
those external group listings can be protected, the question immediately arises:
299-
By what mechanism should the ACL checking engine authenticate its request to
300-
external servers?
301-
302-
For example: Alice sends a GET request to a resource on the server
303-
`https://a.com`. The ACL for that resource links to a group listing on an
304-
external server, `https://b.com`. In the process of resolving the ACL, `a.com`
305-
must send a request to `b.com`, to get that group listing. Note that it's not
306-
Alice herself (or her application) that is sending that request, it's actually
307-
`a.com` sending it (as part of trying to resolve its own ACL). How should
308-
`a.com` authenticate itself? Does it have its own credentials, or does it have
309-
a way to say that it's acting on behalf of Alice? Or both?
310-
311-
There are several implementation possibilities:
312-
313-
**No authentication**. The ACL checking engine sends *un-authenticated* requests
314-
to external servers (to fetch group listings). This is the simplest method to
315-
implement, but suffers from the limitation that those external group listings
316-
need to be public-readable.
317-
318-
**WebID-TLS Delegation**. If your implementation uses the WebID-TLS
319-
authentication method, it also needs to implement the ability to delegate its
320-
requests on behalf of the original user. For a discussion of such a capability,
321-
see the [Extending the WebID Protocol with Access
322-
Delegation](http://bblfish.net/tmp/2012/08/05/WebID_Delegation.pdf) paper.
323-
One thing to keep in mind is - if there are several hops (an ACL request chain
324-
across more than one other domain), how does this change the delegation
325-
confirmation algorithm? If the original server is explicitly authorized for
326-
delegation by the user, what about the subsequent ones?
327-
328-
**ID Tokens/Bearer Tokens**. If you're using a token-based authentication system
329-
such as OpenID Connect or OAuth2 Bearer Tokens, it will also need to implement
330-
the ability to delegate its ACL requests on behalf of the original user. See
331-
[PoP/RFC7800](https://tools.ietf.org/html/rfc7800) and [Authorization Cross
332-
Domain Code](http://openid.bitbucket.org/draft-acdc-01.html) specs for relevant
333-
examples.
334-
335-
##### Infinite Request Loops in Group Listings
336-
337-
Since Group Listings (which are linked to from ACL resources using
338-
the `acl:agentGroup` predicate) reside in regular documents, those documents
339-
will have their very own `.acl` resources that restrict which users (or groups)
340-
are allowed to access or change them. This fact, that `.acl`s point to Group
341-
Listings, which can have `.acl`s of their own, which can potentially also point
342-
to Group Listings, and so on, introduces the potential for infinite loops
343-
during ACL resolution.
344-
345-
Take the following situation with two different servers:
346-
347-
```
348-
https://a.com https://b.com
349-
------------- GET ---------------
350-
group-listA <------ group-listB.acl
351-
| ^ contains:
352-
| | agentGroup <a.com/group-ListA>
353-
v GET |
354-
group-listA.acl ------> group-listB
355-
contains:
356-
agentGroup <b.com/group-listB>
357-
```
358-
359-
The access to `group-listA` is controlled by `group-listA.acl`. So far so good.
360-
But if `group-listA.acl` contains any `acl:agentGroup` references to *another*
361-
group listing (say, points to `group-listB`), one runs into potential danger.
362-
In order to retrieve that other group listing, the ACL-checking engine on
363-
`https://b.com` will need to check the rules in `group-listB.acl`. And if
364-
`group-listB.acl` (by accident or malice) points back to `group-listA` a request
365-
will be made to access `group-listA` on the original server `https://a.com`,
366-
which would start an infinite cycle.
367-
368-
To guard against these loops, implementers have several options:
369-
370-
**A) Do not allow cross-domain Group Listing resolutions**.
371-
The simplest to implement (but also the most limited) option is to disallow
372-
cross-domain Group Listings resolution requests. That is, the ACL-checking code
373-
could detect `agentGroup` links pointing to external servers during ACL
374-
resolution time, and treat those uniformly (as errors, or as automatic "access
375-
denied").
376-
377-
**B) Treat Group Listings as special cases**.
378-
This assumes that the server has the ability to parse or query the contents of a
379-
Group Listing document *before* resolving ACL checks -- a design decision that
380-
some implementations may find unworkable. If the ACL checking engine can inspect
381-
the contents of a document and know that it's a Group Listing, it can put in
382-
various safeguards against loops. For example, it could validate ACLs when they
383-
are created, and disallow external Group Listing links, similar to option A
384-
above. Note that even if you wanted to ensure that no `.acl`s are allowed for
385-
Group Listings, and that all such documents would be public-readable, you would
386-
still have to be able to tell Group Listings apart from other documents, which
387-
would imply special-case treatment.
388-
389-
**C) Create and pass along a tracking/state parameter**.
390-
For each ACL check request beyond the original server, it would be possible to
391-
create a nonce-type tracking parameter and pass it along with each subsequent
392-
request. Servers would then be able to use this parameter to detect loops on
393-
each particular request chain. However, this is a spec-level solution (instead
394-
of an individual implementation level), since all implementations have to play
395-
along for this to work. See issue
396-
[solid/solid#8](https://github.com/solid/solid/issues/8) for further
397-
discussion).
398-
399-
**D) Ignore this issue and rely on timeouts.**
400-
It's worth noting that if an infinite group ACL loop was created by mistake,
401-
this will soon become apparent since requests for that resource will time out.
402-
If the loop was created by malicious actors, this is comparable to a very
403-
small, low volume DDOS attack, which experienced server operators know how to
404-
guard against. In either case, the consequences are not disastrous.
296+
Possible future methods for a server to find out whether a given agent is a
297+
member of s group are a matter for future research and possible addition here.
405298

406299
### Public Access (All Agents)
407300

@@ -455,6 +348,69 @@ An application of this feature is to throw a resource open to all logged on user
455348
for a specific amount of time, accumulate the list of those who case as a group,
456349
and then later restrict access to that group, to prevent spam.
457350

351+
### Referring to Origins, i.e. Web Apps
352+
353+
When a compliant server receives a request from a web application running
354+
in a browser, the brrowser will send an extra warning HTTP header, the Origin header.
355+
356+
```
357+
Origin: https://scripts.example.com:8080
358+
```
359+
Note that the origin comprises the protocol and the DNS and port but none of the path,
360+
and no trailing slash.
361+
All scripts running on the same origin are assumed to be run by the same
362+
social entity, and so trusted to the same extent.
363+
364+
*When an Origin header is present then BOTH the authenticated agent AND
365+
the origin MUST be allowed access*
366+
367+
As both the user and the web app get to read or write the data, then they most BOTH
368+
be trusted.
369+
370+
- If the requested mode is available to the public, then suceed `200 OK`.
371+
- If the user is *not* logged on, then fail `401 Unauthenticated`
372+
- Is the User authenticated is *not* allowed access required, AND the class AuthenticatedAgent is not allowed access, then fail `403 User Unauthorized`
373+
- If the Origin header is not present, the succeed `200 OK`
374+
- If the Origin is allowed by the ACL, then succeed `200 OK` with added CORS headers ACAO and ACAH
375+
- (In future proposed) Look up the user's webid to check for trusted apps declared there, and if match, succeed `200 OK`
376+
- Fail `403 Origin Unauthorized`
377+
378+
Note it is a really good idea to make it clear both in the text of the status message and in the body of
379+
the message the difference between the user not being allowed and the web app they are using
380+
not bing trusted.
381+
382+
#### Adding trusted web apps.
383+
384+
The authorization of trusted web app is a running battle between readers and writers on the web, and manevalent parties trying to break in to get unauthorized access. The history or Cross-Site Scripting attacks and the introduction of the Same Origin Policy is not detailed here, The CORS specification in general prevents any web app from accessing any data from or associated with a different origin. The web server can get around CORS. It is a pain to to do so, as it involves the server code echoing back the Orin header in the ACAO header, and also it must be done only when the web app in question actually is trustworthy.
385+
386+
In solid a maxim is, you have complete control of he data. Therefore it is up to the owner of the data, the publisher, the controller of the ACL, or more broadly the person running the solid server, to specify who gets access, be it people or apps. However another maxim is that you can chose which app you use. So of Alice publishes data, and Bob want to use his favorite app, then how does that happen?
387+
388+
##### Now:
389+
390+
- The web server can run with a given trusted domain created by the solid developers.
391+
- A specific ACL can be be made to allow a given app to access a given file or folder of files.
392+
393+
##### Possible future:
394+
- A writer could give in their profile a statement that they will allow readers to use a given app.
395+
396+
```
397+
<#me> acl:trusts <https://calendar.example.com>.
398+
<#me> acl:trustsForRead <https://contacts.example.com>.
399+
```
400+
401+
- A reader can ask to use a given app, by publishing the fact that she trusts a given app.
402+
403+
```
404+
<#me> acl:trustsForUse <https://calendar.example.com>.
405+
<#me> acl:trustsForUseForRead <https://contacts.example.com>.
406+
```
407+
408+
A writer could have also more sophisticated requirements, such as that any app Alice
409+
wants to use must be signed by developer from a given list, and so on.
410+
411+
Therefore, by pulling the profiles of the reader and/or the writer, and/or the Origin app itself,
412+
the system can be adjusted to allow new apps to be added without bad things happening
413+
458414
## Referring to Resources
459415

460416
The `acl:accessTo` predicate specifies *which resources* you're giving access
@@ -544,6 +500,125 @@ An example ACL for a container would look something like:
544500
`acl:default`, both in the specs and in implementing servers. The semantics, as
545501
described here, will remain the same
546502

503+
## Old discussion of access to group files
504+
505+
##### Group Listings - Authentication of External Requests
506+
507+
*This section is not normative*
508+
509+
Group Listings via `acl:agentGroup` links introduce the possibility of an ACL
510+
checking engine having to make requests to other servers. Given that access to
511+
those external group listings can be protected, the question immediately arises:
512+
By what mechanism should the ACL checking engine authenticate its request to
513+
external servers?
514+
515+
For example: Alice sends a GET request to a resource on the server
516+
`https://a.com`. The ACL for that resource links to a group listing on an
517+
external server, `https://b.com`. In the process of resolving the ACL, `a.com`
518+
must send a request to `b.com`, to get that group listing. Note that it's not
519+
Alice herself (or her application) that is sending that request, it's actually
520+
`a.com` sending it (as part of trying to resolve its own ACL). How should
521+
`a.com` authenticate itself? Does it have its own credentials, or does it have
522+
a way to say that it's acting on behalf of Alice? Or both?
523+
524+
There are several implementation possibilities:
525+
526+
**No authentication**. The ACL checking engine sends *un-authenticated* requests
527+
to external servers (to fetch group listings). This is the simplest method to
528+
implement, but suffers from the limitation that those external group listings
529+
need to be public-readable. THIS IS THE ONLY METHOD CURRENTLY IN USE
530+
531+
**WebID-TLS Delegation**. If your implementation uses the WebID-TLS
532+
authentication method, it also needs to implement the ability to delegate its
533+
requests on behalf of the original user.
534+
(No, the original requester may not be akllowed access -- you don't have to ableForto
535+
access a group to be in it)
536+
a discussion of such a capability,
537+
see the [Extending the WebID Protocol with Access
538+
Delegation](http://bblfish.net/tmp/2012/08/05/WebID_Delegation.pdf) paper.
539+
One thing to keep in mind is - if there are several hops (an ACL request chain
540+
across more than one other domain), how does this change the delegation
541+
confirmation algorithm? If the original server is explicitly authorized for
542+
delegation by the user, what about the subsequent ones?
543+
544+
**ID Tokens/Bearer Tokens**. If you're using a token-based authentication system
545+
such as OpenID Connect or OAuth2 Bearer Tokens, it will also need to implement
546+
the ability to delegate its ACL requests on behalf of the original user. See
547+
[PoP/RFC7800](https://tools.ietf.org/html/rfc7800) and [Authorization Cross
548+
Domain Code](http://openid.bitbucket.org/draft-acdc-01.html) specs for relevant
549+
examples.
550+
551+
##### Infinite Request Loops in Group Listings
552+
553+
Since Group Listings (which are linked to from ACL resources using
554+
the `acl:agentGroup` predicate) reside in regular documents, those documents
555+
will have their very own `.acl` resources that restrict which users (or groups)
556+
are allowed to access or change them. This fact, that `.acl`s point to Group
557+
Listings, which can have `.acl`s of their own, which can potentially also point
558+
to Group Listings, and so on, introduces the potential for infinite loops
559+
during ACL resolution.
560+
561+
Take the following situation with two different servers:
562+
563+
```
564+
https://a.com https://b.com
565+
------------- GET ---------------
566+
group-listA <------ group-listB.acl
567+
| ^ contains:
568+
| | agentGroup <a.com/group-ListA>
569+
v GET |
570+
group-listA.acl ------> group-listB
571+
contains:
572+
agentGroup <b.com/group-listB>
573+
```
574+
575+
The access to `group-listA` is controlled by `group-listA.acl`. So far so good.
576+
But if `group-listA.acl` contains any `acl:agentGroup` references to *another*
577+
group listing (say, points to `group-listB`), one runs into potential danger.
578+
In order to retrieve that other group listing, the ACL-checking engine on
579+
`https://b.com` will need to check the rules in `group-listB.acl`. And if
580+
`group-listB.acl` (by accident or malice) points back to `group-listA` a request
581+
will be made to access `group-listA` on the original server `https://a.com`,
582+
which would start an infinite cycle.
583+
584+
To guard against these loops, implementers have several options:
585+
586+
**A) Do not allow cross-domain Group Listing resolutions**.
587+
The simplest to implement (but also the most limited) option is to disallow
588+
cross-domain Group Listings resolution requests. That is, the ACL-checking code
589+
could detect `agentGroup` links pointing to external servers during ACL
590+
resolution time, and treat those uniformly (as errors, or as automatic "access
591+
denied").
592+
593+
**B) Treat Group Listings as special cases**.
594+
This assumes that the server has the ability to parse or query the contents of a
595+
Group Listing document *before* resolving ACL checks -- a design decision that
596+
some implementations may find unworkable. If the ACL checking engine can inspect
597+
the contents of a document and know that it's a Group Listing, it can put in
598+
various safeguards against loops. For example, it could validate ACLs when they
599+
are created, and disallow external Group Listing links, similar to option A
600+
above. Note that even if you wanted to ensure that no `.acl`s are allowed for
601+
Group Listings, and that all such documents would be public-readable, you would
602+
still have to be able to tell Group Listings apart from other documents, which
603+
would imply special-case treatment.
604+
605+
**C) Create and pass along a tracking/state parameter**.
606+
For each ACL check request beyond the original server, it would be possible to
607+
create a nonce-type tracking parameter and pass it along with each subsequent
608+
request. Servers would then be able to use this parameter to detect loops on
609+
each particular request chain. However, this is a spec-level solution (instead
610+
of an individual implementation level), since all implementations have to play
611+
along for this to work. See issue
612+
[solid/solid#8](https://github.com/solid/solid/issues/8) for further
613+
discussion).
614+
615+
**D) Ignore this issue and rely on timeouts.**
616+
It's worth noting that if an infinite group ACL loop was created by mistake,
617+
this will soon become apparent since requests for that resource will time out.
618+
If the loop was created by malicious actors, this is comparable to a very
619+
small, low volume DDOS attack, which experienced server operators know how to
620+
guard against. In either case, the consequences are not disastrous.
621+
547622
## Not Supported by Design
548623

549624
This section describes some features or acl-related terms that are not included

0 commit comments

Comments
 (0)