Working on web app authorization

Background.md

@@ -28,9 +28,9 @@ What could be done? The browser manufacturers implemented some hooks to allow da
 Access-control-allow-Origin: *
 ```
 At the same time they added a feature to allow the data publisher to specify other a limited set of other origins which would be allowed access. This makes running a bank easier if also the credit card company code can access your customers data.
-
+```
 Access-control-allow-Origin: credit card company.example.com
-
+```
 This meant that anyone publishing public data has to add
 
 ```
@@ -39,6 +39,24 @@ Access-control-allow-Origin: *
 in any response.  This meant a huge amount of work for random open data publishers
 all over the web, an effort which in many cases for many reasonable reasons was not done, leaving the data available to browsers, but unavailable to web apps.
 
+The browser actually looks for these headers not on the request itself, but in
+on a "Pre-flight" OPTIONS request which is inserted before the main request.  So while the developer may see in the browser console only the main request, the number of round trips has in fact increased.
+
+### Header blocking
+
+As well as blocking the data, the CORS system blocks headers from the server to the web app.
+To prevent this this, the server must send another  [header](https://www.w3.org/TR/cors/#access-control-allow-headers-response-header):
+```
+Access-Control-Allow-Headers: Authorization, User, Location, Link, Vary, Last-Modified, ETag, Accept-Patch, Accept-Post, Updates-Via, Allow, WAC-Allow, Content-Length, WWW-Authenticate
+```
+This must include things like the Link: header which are normal headers blocked by the browser, and also any new headers the app and serve are using for any purpose.
+
+### Method blocking
+
+### Example
+
+One solid server does CORS [this way](https://github.com/solid/node-solid-server/blob/master/lib/create-app.js#L26)
+
 ## The CORS twist
 
 The twist is that in fact the designers of CORS make it even more difficult.
@@ -142,6 +160,8 @@ It seems also that Firefox showed the same behavior for  in 2018-07
 ## References
 
 - [WXSS] [Wikipedia, "Cross-site scripting"](https://en.wikipedia.org/wiki/Cross-site_scripting)
+- [CORS] [Cross-Origin Resource Sharing
+W3C Recommendation](https://www.w3.org/TR/cors/)  16 January 2014
 - [WCORS][Cross-origin resource sharing](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing)
 - [WSOP] [Wikipedia, "
 Same-origin policy"](https://en.wikipedia.org/wiki/Same-origin_policy)

README.md

@@ -394,22 +394,29 @@ In solid a maxim is, you have complete control of he data. Therefore it is up to
 - A writer could give in their profile a statement that they will allow readers to use a given app.
 
 ```
- <#me> acl:trusts <https://calendar.example.com>.
- <#me> acl:trustsForRead  <https://contacts.example.com>.
+ <#me> acl:trustedApp  [acl:origin <https://calendar.example.com> acl:mode acl:Read , acl:Append].
+ <#me> acl:trustedApp [acl:origin  <https://contacts.example.com>  acl:mode acl:Read , acl:Write, acl:Control] .
 ```
 
- - A reader can ask to use a given app, by publishing the fact that she trusts a given app.
+We define the owners of the resource as people given explicit Control access to it.
+(Possible future change: also anyone with Control access, even through a group, as the group can be used as a role)
 
- ```
-  <#me> acl:trustsForUse <https://calendar.example.com>.
-  <#me> acl:trustsForUseForRead  <https://contacts.example.com>.
- ```
+For each owner x, the server looks up the (extended?) profile, and looks in it for a
+triple of the form
+
+```
+?x  acl:trustedApp ?y .
+```
+The set of trust objects is the accumulated set of ?y found in this way.
+
+For the app ?z to have access, for every mode of access ?m required
+there must be some trust object ?y such that
+```
+?y  acl:origin ?z ; acl:mode ?m .
+```
+Note access to different modes may be given in the same or different trust objects.
 
-A writer could have also more sophisticated requirements, such as that any app Alice
-wants to use must be signed by developer from a given list, and so on.
 
-Therefore, by pulling the profiles of the reader and/or the writer, and/or the Origin app itself,
-the system can be adjusted to allow new apps to be added without bad things happening
 
 ## Referring to Resources
 
@@ -500,6 +507,10 @@ An example ACL for a container would look something like:
 `acl:default`, both in the specs and in implementing servers. The semantics, as
 described here, will remain the same
 
+## See also
+
+[Background on CORS](https://sold.github.io/web-access-control-spec/Background)
+
 ## Old discussion of access to group files
 
 ##### Group Listings - Authentication of External Requests
@@ -619,6 +630,23 @@ If the loop was created by malicious actors, this is comparable to a very
 small, low volume DDOS attack, which experienced server operators know how to
 guard against. In either case, the consequences are not disastrous.
 
+
+### Other ideas about specifying trusted apps
+
+ - A reader can ask to use a given app, by publishing the fact that she trusts a given app.
+
+ ```
+ <#me> acl:trustsForUse  [acl:origin <https://calendar.example.com> acl:mode acl:Read , acl:Append].
+ <#me> acl:trustsForUse [acl:origin  <https://contacts.example.com>  acl:mode acl:Read , acl:Write, acl:Control] .
+ ```
+
+A writer could have also more sophisticated requirements, such as that any app Alice
+wants to use must be signed by developer from a given list, and so on.
+
+Therefore, by pulling the profiles of the reader and/or the writer, and/or the Origin app itself,
+the system can be adjusted to allow new apps to be added without bad things happening
+
+
 ## Not Supported by Design
 
 This section describes some features or acl-related terms that are not included