From 2dabbe89495fe9785ff8f3f3144a8fde332a6c26 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Sun, 11 Apr 2021 15:10:04 +0200 Subject: [PATCH 001/310] Init Editor's Draft --- index.html | 293 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 293 insertions(+) create mode 100644 index.html diff --git a/index.html b/index.html new file mode 100644 index 00000000..98b681f9 --- /dev/null +++ b/index.html @@ -0,0 +1,293 @@ + + + + + Web Access Control + + + + + + +
+
+ +
+
+ +
+
+

Web Access Control

+

Editor’s Draft, 2021-03-29

+ +
+
This version
+
https://solidproject.org/TR/web-access-control
+
+ +
+
Latest Version
+
https://solid.github.io/web-access-control-spec/
+
+ +
+
+
Editors
+
Sarven Capadisli
+
+
+ +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +

MIT License. Copyright © 2021 W3C Solid Community Group.

+ +
+
+

Abstract

+
+

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 Lists (ACL) model.

+
+
+ +
+

Status of This Document

+
+

This section describes the status of this document at the time of its publication.

+ +

This document was published by the Solid Community Group as an Editor’s Draft. The sections that have been incorporated have been reviewed following the Solid process. However, the information in this document is still subject to change. You are invited to contribute any feedback, comments, or questions you might have.

+ +

Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

+ +

This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

+
+
+ + +
+
+
+ + + + + + + + From aef05bf5d41dafd3e0f37c4dfa18a04499287f25 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Sun, 11 Apr 2021 15:57:32 +0200 Subject: [PATCH 002/310] Init Introduction, add Conformance --- index.html | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/index.html b/index.html index 98b681f9..3c2df267 100644 --- a/index.html +++ b/index.html @@ -222,9 +222,29 @@

Table of Contents

  • Status of This Document
    • +
  • + 1 Introduction +
      +
    1. 1.3 Conformance
      2. +
    +
    • + +
    +

    Introduction

    +
    +
    +

    Conformance

    +
    +

    All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.

    + +

    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

    +
    +
    +
    +
    From f8577abd7606af7cb679cebc4cabffbd5f286fac Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Sun, 11 Apr 2021 15:58:14 +0200 Subject: [PATCH 003/310] Add Namespaces --- index.html | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/index.html b/index.html index 3c2df267..e6d3b257 100644 --- a/index.html +++ b/index.html @@ -225,6 +225,7 @@

    Table of Contents

  • 1 Introduction
      +
    1. 1.2 Namespaces
    2. 1.3 Conformance
    • @@ -235,6 +236,49 @@

    Table of Contents

    Introduction

    +
    +

    Namespaces

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Prefixes and Namespaces
    PrefixNamespaceDescription
    rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#[rdf-schema]
    solidhttp://www.w3.org/ns/solid/terms#Solid Terms
    pimhttp://www.w3.org/ns/pim/space#Workspace Ontology
    aclhttp://www.w3.org/ns/auth/acl#ACL Ontology
    foafhttp://http://xmlns.com/foaf/0.1/[Friend of a Friend (FOAF) vocabulary]
    +
    +
    +

    Conformance

    From f5120079b5d2bd87c67e20fbba87e41b4ae84c5a Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Sun, 11 Apr 2021 19:35:09 +0200 Subject: [PATCH 004/310] Add Definitions --- index.html | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/index.html b/index.html index e6d3b257..e92924d3 100644 --- a/index.html +++ b/index.html @@ -225,6 +225,7 @@

    Table of Contents

  • 1 Introduction
      +
    1. 1.1 Definitions
    2. 1.2 Namespaces
    3. 1.3 Conformance
    @@ -236,6 +237,21 @@

    Table of Contents

    Introduction

    +
    +

    Definitions

    +
    +

    An authorization is an abstract thing whose properties are defined in an ACL resource, indicating the access modes that are granted to agents to perform a set of operations on resources.

    + +

    An agent is a person, social entity or software identified by a dereferenceable URI.

    + +

    A resource is the target of an HTTP request identified by a URI [RFC7231].

    + +

    An ACL resource is a document that includes a set of authorization policies.

    + +

    An access mode denotes a class of operations that an agent can perform on one or more resources.

    +
    +
    +

    Namespaces

    From 0bdabff3f70c2065e5690e1bcd049404dd3b15b5 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Sun, 11 Apr 2021 22:10:52 +0200 Subject: [PATCH 005/310] Init References --- index.html | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/index.html b/index.html index e92924d3..e435a46c 100644 --- a/index.html +++ b/index.html @@ -230,6 +230,13 @@

    Table of Contents

  • 1.3 Conformance
    • +
  • + References +
      +
    1. Normative References
      2. +
    2. Informative References
      3. +
    +
    • @@ -305,6 +312,53 @@

    Conformance

    + +
    +

    References

    +
    +
    +

    Normative References

    +
    +
    +
    [FETCH]
    +
    Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
    +
    [RDF-SCHEMA]
    +
    RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
    +
    [RDF11-CONCEPTS]
    +
    RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
    +
    [RFC2119]
    +
    Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
    +
    [RFC3864]
    +
    Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864
    +
    [RFC3986]
    +
    Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986
    +
    [RFC5789]
    +
    PATCH Method for HTTP. L. Dusseault; J. Snell. IETF. March 2010. Proposed Standard. URL: https://httpwg.org/specs/rfc5789.html
    +
    [RFC6454]
    +
    The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454
    +
    [RFC7231]
    +
    Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
    +
    [RFC8274]
    +
    Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
    +
    [RFC8288]
    +
    Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
    +
    [Turtle]
    +
    RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
    +
    [WEBARCH]
    +
    Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/
    +
    [WEBID]
    +
    Web Identity and Discovery. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/
    +
    +
    +
    + +
    +

    Informative References

    +
    +
    +
    +
    +
    From 4f9972f8394d06977f994a11c973e0dfcb92aa20 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 12 Apr 2021 01:13:31 +0200 Subject: [PATCH 006/310] Change to Terminology and revise --- index.html | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/index.html b/index.html index e435a46c..0f8b0cd2 100644 --- a/index.html +++ b/index.html @@ -244,18 +244,24 @@

    Table of Contents

    Introduction

    -
    -

    Definitions

    +
    +

    Terminology

    -

    An authorization is an abstract thing whose properties are defined in an ACL resource, indicating the access modes that are granted to agents to perform a set of operations on resources.

    +

    This section is non-normative.

    -

    An agent is a person, social entity or software identified by a dereferenceable URI.

    +

    This section defines the terms used in this specification.

    + +

    A URI provides the means for identifying resources [RFC3986].

    A resource is the target of an HTTP request identified by a URI [RFC7231].

    -

    An ACL resource is a document that includes a set of authorization policies.

    +

    An ACL resource is an RDF document [RDF11-CONCEPTS] that includes authorization policies.

    + +

    An authorization is an abstract thing identified by a URI whose properties are defined in an ACL resource, eg. access modes granted to agents to perform operations on resources.

    + +

    An access mode is a class of operations that can be performed on one or more resources.

    -

    An access mode denotes a class of operations that an agent can perform on one or more resources.

    +

    An agent is a person, social entity or software identified by a URI, eg. a WebID denotes an agent [WEBID].

    From 0b75dcd720f2a8ac581ee0ed587b9e1d5512d5a0 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 12 Apr 2021 07:52:26 +0200 Subject: [PATCH 007/310] Add status-of-a-permission to Terminology --- index.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index 0f8b0cd2..fad23685 100644 --- a/index.html +++ b/index.html @@ -195,7 +195,7 @@

    Editor’s Draft, 2021-03-29

    Abstract

    -

    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 Lists (ACL) model.

    +

    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.

    @@ -262,6 +262,8 @@

    Terminology

    An access mode is a class of operations that can be performed on one or more resources.

    An agent is a person, social entity or software identified by a URI, eg. a WebID denotes an agent [WEBID].

    + +

    The status of a permission is either access is granted or denied.

    From 898018d6069ed1a7d5daca9e0e9e9f39e8d26146 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 12 Apr 2021 09:53:58 +0200 Subject: [PATCH 008/310] Expand Introduction stub --- index.html | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index fad23685..464a6d41 100644 --- a/index.html +++ b/index.html @@ -195,7 +195,7 @@

    Editor’s Draft, 2021-03-29

    Abstract

    -

    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.

    +

    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.

    @@ -244,6 +244,14 @@

    Table of Contents

    Introduction

    +

    Access controls within the storage layer helps to implement the social requirements of applications. The access control system can be enhanced by adding more inference or expressivity to express social constraints.

    + +

    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 uses the ACL ontology to describe authorization policies. Each request for a Web resource returns an HTTP document containing a Link header to an ACL resource which contains authorization policies. Any kind of access can be given to a resource as per the ACL ontology. This specification uses the access modes currently defined by the ACL ontology, such as the class of operations to read, write, append and control resources. The requirements for new access modes is explained in the Extending Access Modes section. An authorization may allow public access to resources or require agents to authenticate. Resources and agents can be on different origins.

    + +

    WAC is compatible with servers implementing the Solid Protocol [SOLID-PROTOCOL].

    +

    Terminology

    @@ -350,6 +358,8 @@

    Normative References

    Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
    [RFC8288]
    Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
    +
    [SOLID-PROTOCOL]
    +
    The Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo; Justin Bingham; Dmitri Zagidulin. W3C Solid Community Group. W3C Editor's Draft. URL: https://solidproject.org/TR/protocol
    [Turtle]
    RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
    [WEBARCH]
    From 65c316d52b0469f65466add19ba0f172c76429a3 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 12 Apr 2021 10:02:48 +0200 Subject: [PATCH 009/310] Init Considerations --- index.html | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/index.html b/index.html index 464a6d41..530d3ceb 100644 --- a/index.html +++ b/index.html @@ -329,6 +329,55 @@

    Conformance

    +
    +

    Considerations

    +
    +

    This section details security, privacy, accessibility and internationalization considerations.

    + +

    Some of the normative references with this specification point to documents with a Living Standard or Draft status, meaning their contents can still change over time. It is advised to monitor these documents, as such changes might have implications.

    + +
    +

    Security Considerations

    +
    +

    This section is non-normative.

    + +

    While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

    + + +

    In addition to above considerations, implementors should consider the Security Considerations in context of the Solid Protocol

    . +
    +
    + +
    +

    Privacy Considerations

    +
    +

    This section is non-normative.

    +
    +
    + +
    +

    Accessibility Considerations

    +
    +

    This section is non-normative.

    +
    +
    + +
    +

    Internationalization Considerations

    +
    +

    This section is non-normative.

    +
    +
    + +
    +

    Security and Privacy Review

    +
    +

    This section is non-normative.

    +
    +
    +
    +
    +

    References

    From 26b12d5a56bc6ec2e9ba66a020b6c5f2644cf1d9 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 12 Apr 2021 13:04:07 +0200 Subject: [PATCH 010/310] Add Considerations to nav --- index.html | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/index.html b/index.html index 530d3ceb..a2a2c48f 100644 --- a/index.html +++ b/index.html @@ -230,6 +230,16 @@

    Table of Contents

  • 1.3 Conformance
    • +
  • + 12 Considerations +
      +
    1. 12.1 Security Considerations
      2. +
    2. 12.2 Privacy Considerations
      3. +
    3. 12.3 Accessibility Considerations
      4. +
    4. 12.4 Internationalization Considerations
      5. +
    5. 12.5 Security and Privacy Review
      6. +
    +
  • References
      From 63971b5439cb99b0cde5602d6a5c1813f9ce6fee Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 12 Apr 2021 13:09:49 +0200 Subject: [PATCH 011/310] Mention the scope of trust on profile information --- index.html | 1 + 1 file changed, 1 insertion(+) diff --git a/index.html b/index.html index a2a2c48f..4f69bb6e 100644 --- a/index.html +++ b/index.html @@ -353,6 +353,7 @@

      Security Considerations

      While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

      +

      Servers are strongly discouraged from trusting the information returned by looking up an agent's WebID for access control purposes. The server operator can also provide the server with other trusted information to include in the search for a reason to give the requester the access.

      In addition to above considerations, implementors should consider the Security Considerations in context of the Solid Protocol

      .
    • From a81f15647059d4969e67cfd93ee5c715524dffca Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 12 Apr 2021 13:22:39 +0200 Subject: [PATCH 012/310] Add HTTP Definitions --- index.html | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/index.html b/index.html index 4f69bb6e..0fb31642 100644 --- a/index.html +++ b/index.html @@ -339,6 +339,41 @@

    Conformance

    +
    +

    HTTP Definitions

    +
    + +
    +
    +

    Considerations

    From 02c0dab9712160b7daa8ee9084c4de9642b4c400 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 12 Apr 2021 13:24:19 +0200 Subject: [PATCH 013/310] Init Extensions section --- index.html | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/index.html b/index.html index 0fb31642..c59ebe27 100644 --- a/index.html +++ b/index.html @@ -374,6 +374,20 @@

    acl

    +
    +

    Extensions

    +
    +

    ..

    + +
    +

    Extending Access Modes

    +
    +

    An extension to access modes is any mode that is not described in the Modes of Access section part of the ACL ontology. Consuming implementations that encounter unfamiliar access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.

    +
    +
    +
    +
    +

    Considerations

    From 20ca6d49b942c201359be534f60b68073525c3fc Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 12 Apr 2021 13:27:33 +0200 Subject: [PATCH 014/310] Init WAC-Allow --- index.html | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/index.html b/index.html index c59ebe27..10f4fb80 100644 --- a/index.html +++ b/index.html @@ -342,6 +342,46 @@

    Conformance

    HTTP Definitions

    +
    +

    WAC-Allow

    +
    +

    A resource can advertise an ACL document that is directly associated by using the HTTP Link header with a rel value of acl acl. [Source]

    + +

    In the event that a server can’t apply an ACL to a resource, it MUST deny access. [Source]

    + +

    Servers exposing client’s access privileges on a resource URL MUST advertise by including the WAC-Allow HTTP header in the response of HTTP HEAD and GET requests.

    + +

    The syntax for the WAC-Allow header, using the ABNF syntax defined in Section 1.2 of [RFC7231], is:

    + + 
    wac-allow        = "WAC-Allow" ":" OWS #access-param OWS
+access-param     = permission-group OWS "=" OWS access-modes
+permission-group = 1*ALPHA
+access-modes     = DQUOTE OWS *1(access-mode *(RWS access-mode)) OWS DQUOTE
+access-mode      = "read" / "write" / "append" / "control"
    + +

    The WAC-Allow HTTP header’s field-value is a comma-separated list of access-params. access-param is a whitespace-separated list of access-modes granted to a permission-group.

    + +

    Issue: Incorporate extensions.

    + +

    This specification defines the following permission-groups:

    + +
    +
    user
    +
    Permissions granted to the agent requesting the resource.
    +
    public
    +
    Permissions granted to the public.
    +
    + +

    access-mode corresponds to the modes of access as defined in the ACL ontology (acl:Read, acl:Write, acl:Append, acl:Control).

    + +

    Clients can discover access privileges on a resource by making an HTTP HEAD or GET request on the target URL, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group.

    + +

    Clients' parsing algorithm for the WAC-Allow header should incorporate error handling. When the received message fails to match an allowed pattern, finds unrecognised access parameters or access modes, clients MUST ignore the received WAC-Allow header-field.

    + +

    [Source] [Source] Source] Source]

    +
    +
    +
    From cd35af41cba93dfd5b21648c85a590dd68053a65 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 11:57:09 +0200 Subject: [PATCH 221/310] Add client-identification --- index.html | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/index.html b/index.html index cc407342..c7e67c06 100644 --- a/index.html +++ b/index.html @@ -570,6 +570,13 @@

    Issue: Origin Considerations

    acl:origin relies on the presence of the Origin header, irrespective to its authenticity (Subject Verification) and is not strongly associated with the client (Client Identification) that is making the HTTP request. [Issue].

    + +
    +

    Issue: Client Identification

    +
    +

    Distinguishing social entities and clients [Issue]. Resolving this may address Origin Proof and Considerations

    +
    +
    From 7e2a5b9f12350c0e5f33f103acac0c742b72a8ab Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 12:26:08 +0200 Subject: [PATCH 222/310] Minor --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index c7e67c06..89f74a9e 100644 --- a/index.html +++ b/index.html @@ -574,7 +574,7 @@

    Issue: Origin Considerations

    Issue: Client Identification

    -

    Distinguishing social entities and clients [Issue]. Resolving this may address Origin Proof and Considerations

    +

    Distinguishing social entities and clients [Issue]. Resolving this may address Origin Considerations

    From 858bd3ad80a6bd2df59c6057aa1f1d4f4c5509c6 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 12:38:19 +0200 Subject: [PATCH 223/310] Add some relations --- index.html | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/index.html b/index.html index 89f74a9e..561e45f0 100644 --- a/index.html +++ b/index.html @@ -429,7 +429,7 @@

    ACL Resource Discovery

    @@ -483,7 +483,7 @@

    Access Objects

    Issue: Access to Class

    -

    Whether acl:accessToClass is required by this specification or not [Issue]

    +

    Whether acl:accessToClass is required by this specification or not [Issue]

    @@ -494,7 +494,7 @@

    Issue: Access to Class

    Access Modes

    -

    The access modes described in this section are defined in the ACL ontology, such as the class of operations to read, write, append and control resources. The requirements for new access modes is explained in the Access Mode Extensions section.

    +

    The access modes described in this section are defined in the ACL ontology, such as the class of operations to read, write, append and control resources. The requirements for new access modes is explained in the Access Mode Extensions section.

    The acl:mode predicate denotes a class of operations that the agents can perform on a resource.

    @@ -524,7 +524,7 @@

    Note: Access Mode Classes

    Note: URI Ownership

    -

    URI ownership, as per Architecture of the World Wide Web [WEBARCH], is outside the scope of this specification, and thus cannot be changed by modifying Authorizations.

    +

    URI ownership, as per Architecture of the World Wide Web [WEBARCH], is outside the scope of this specification, and thus cannot be changed by modifying Authorizations.

    @@ -567,14 +567,14 @@

    Note: Subject Verification

    Issue: Origin Considerations

    -

    acl:origin relies on the presence of the Origin header, irrespective to its authenticity (Subject Verification) and is not strongly associated with the client (Client Identification) that is making the HTTP request. [Issue].

    +

    acl:origin relies on the presence of the Origin header, irrespective to its authenticity (Subject Verification) and is not strongly associated with the client (Client Identification) that is making the HTTP request. [Issue].

    Issue: Client Identification

    -

    Distinguishing social entities and clients [Issue]. Resolving this may address Origin Considerations

    +

    Distinguishing social entities and clients [Issue]. Resolving this may address Origin Considerations

    @@ -626,8 +626,8 @@

    Authorization Conformance

    • At least one rdf:type property whose object is acl:Authorization.
    • At least one acl:accessTo or acl:default property value (Access Objects).
      • -
    • At least one acl:mode property value (Access Modes).
      • -
    • At least one acl:agent, acl:agentGroup, acl:agentClass or acl:origin property value (Access Subjects).
      • +
    • At least one acl:mode property value (Access Modes).
      • +
    • At least one acl:agent, acl:agentGroup, acl:agentClass or acl:origin property value (Access Subjects).
    @@ -646,7 +646,7 @@

    Authorization Evaluation

    Reading and Writing Resources

    -

    Working alongside HTTP Interactions, WAC enables a standard set of operations which can be applied to different resource types for a given request based on the set of access modes which control those operations:

    +

    Working alongside HTTP Interactions, WAC enables a standard set of operations which can be applied to different resource types for a given request based on the set of access modes which control those operations:

    Generally, read operations attempt to know about the existence of a resource or view the contents of a resource. Write operations attempt to create, delete, or modify resources. Append operations attempt to create resources or add information to resources. Control operations attempt to create, delete, or modify ACL resources.

    @@ -682,7 +682,7 @@
    Note: HTTP Method and Access Mode Mappin

    As the HTTP PUT method requests to create or replace the resource state, the acl:Write access mode would be required.

    -

    As the processing of HTTP PATCH method requests depends on the request semantics and content eg. acl:Append can allow requests using SPARQL 1.1 Update's INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.

    +

    As the processing of HTTP PATCH method requests depends on the request semantics and content eg. acl:Append can allow requests using SPARQL 1.1 Update's INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.

    As the HTTP DELETE method requests to remove a resource, the acl:Write access mode would be required.

    @@ -719,12 +719,12 @@
    Note: Trusted Origins
    -

    Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (see WAC-Allow) in the response of HTTP GET and HEAD requests.

    +

    Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (see WAC-Allow) in the response of HTTP GET and HEAD requests.

    Note: Clients Discovering Access Privileges
    -

    Clients can discover access privileges on a resource by making an HTTP HEAD or GET request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (see WAC-Allow).

    +

    Clients can discover access privileges on a resource by making an HTTP HEAD or GET request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (see WAC-Allow).

    @@ -838,7 +838,7 @@

    wac-allow HTTP Header

    Permissions granted to the public.
    -

    access-mode corresponds to the Access Modes as defined in the ACL ontology (acl:Read, acl:Write, acl:Append, acl:Control).

    +

    access-mode corresponds to the Access Modes as defined in the ACL ontology (acl:Read, acl:Write, acl:Append, acl:Control).

    Clients' parsing algorithm for the WAC-Allow header should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (permission groups and access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    @@ -885,7 +885,7 @@

    Authorization Extensions

    Access Mode Extensions

    -

    An extension to access modes is any mode that is defined in the ACL ontology, ie. as a subclass of acl:Access, but not described in this specification (Access Modes). Consumers of Authorizations that encounter unrecognised access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.

    +

    An extension to access modes is any mode that is defined in the ACL ontology, ie. as a subclass of acl:Access, but not described in this specification (Access Modes). Consumers of Authorizations that encounter unrecognised access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.

    Foreign-namespaced access modes are allowed in ACL resources, but no behaviour is defined by this specification.

    From 345445378260c7d21dd24d08da7f67cd3c0e69ee Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 13:03:29 +0200 Subject: [PATCH 224/310] Minor --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 561e45f0..8f0238b4 100644 --- a/index.html +++ b/index.html @@ -565,14 +565,14 @@

    Note: Subject Verification

    -

    Issue: Origin Considerations

    +

    Issue: Origin Considerations

    acl:origin relies on the presence of the Origin header, irrespective to its authenticity (Subject Verification) and is not strongly associated with the client (Client Identification) that is making the HTTP request. [Issue].

    -

    Issue: Client Identification

    +

    Issue: Client Identification

    Distinguishing social entities and clients [Issue]. Resolving this may address Origin Considerations

    From c4f1417d60822b81a16ef44830ffb49ac93fc51d Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 13:05:46 +0200 Subject: [PATCH 225/310] Remove guard bit --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 8f0238b4..7884fdde 100644 --- a/index.html +++ b/index.html @@ -560,7 +560,7 @@

    Access Subjects

    Note: Subject Verification

    -

    Servers may accept different authentication protocols as well as credential verification methods. The guard verifies the claim that the agent is requesting the desired operation and verifies whether the applicable access permissions are granted for the operation.

    +

    Servers may accept different authentication protocols as well as credential verification methods.

    From 06f7e0a9c58c6e1ae9c6d2f9a8ab83e7abbba0a0 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 13:32:36 +0200 Subject: [PATCH 226/310] Update origin-considerations --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 7884fdde..ba6fd882 100644 --- a/index.html +++ b/index.html @@ -564,10 +564,10 @@

    Note: Subject Verification

    -
    -

    Issue: Origin Considerations

    +
    +

    Note: Origin Considerations

    -

    acl:origin relies on the presence of the Origin header, irrespective to its authenticity (Subject Verification) and is not strongly associated with the client (Client Identification) that is making the HTTP request. [Issue].

    +

    Typical Web browsers use origin based security. While it has many limitations, it is however ubiquitous.

    From 227b6c454c215929ba89ef5cef813280a75b07ea Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 13:34:10 +0200 Subject: [PATCH 227/310] Minor --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index ba6fd882..9fd2dc84 100644 --- a/index.html +++ b/index.html @@ -574,7 +574,7 @@

    Note: Origin Considerations

    Issue: Client Identification

    -

    Distinguishing social entities and clients [Issue]. Resolving this may address Origin Considerations

    +

    Distinguishing social entities and clients [Issue].

    From 605772eecdb9e4d59cae5bc12afedf82d1628732 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 14:21:49 +0200 Subject: [PATCH 228/310] Clarify behaviour for foreign-namespaced access modes --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 9fd2dc84..e5e5250d 100644 --- a/index.html +++ b/index.html @@ -887,7 +887,7 @@

    Access Mode Extensions

    An extension to access modes is any mode that is defined in the ACL ontology, ie. as a subclass of acl:Access, but not described in this specification (Access Modes). Consumers of Authorizations that encounter unrecognised access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.

    -

    Foreign-namespaced access modes are allowed in ACL resources, but no behaviour is defined by this specification.

    +

    Foreign-namespaced access modes are allowed in ACL resources, but they MUST NOT cause increased access.

    From dc4460afa0a863ff1b741852746484d80964c8db Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 15:57:55 +0200 Subject: [PATCH 229/310] Move accessToClass to authorization-extensions --- index.html | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/index.html b/index.html index e5e5250d..a051d735 100644 --- a/index.html +++ b/index.html @@ -480,13 +480,6 @@

    Access Objects

    The acl:accessTo property value is used to check if access is allowed for a specific resource. When an Authorization includes the acl:default property value (the container resource in context), then access permissions be applied to the original requested resource.

    -
    -

    Issue: Access to Class

    -
    -

    Whether acl:accessToClass is required by this specification or not [Issue]

    -
    -
    -

    Inheriting Authorizations from the most significant container's ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

    @@ -879,6 +872,9 @@

    Authorization Extensions

    This section is non-normative.

    As ACL resources are RDF sources, Authorizations descriptions may be extended or limited by constraints eg. temporal or spatial constraints, and duties eg. payments, may be imposed on permissions, but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

    + + +

    To allow access to a class of resources, implementations may want to use the acl:accessToClass predicate as defined in the ACL ontology.

    From 0b6dc16f2d2359424abd5557a52e12fdbcd295ca Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 16:00:01 +0200 Subject: [PATCH 230/310] Use wac as shortname --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index a051d735..85cbf331 100644 --- a/index.html +++ b/index.html @@ -133,7 +133,7 @@

    Editor’s Draft, 2021-06-15

    This version
    -
    https://solidproject.org/TR/web-access-control
    +
    https://solidproject.org/TR/wac
    From db84a218429feba58bd987c7ca064c0f7138e02a Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 15 Jun 2021 18:22:11 +0200 Subject: [PATCH 231/310] Add more sources --- index.html | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 85cbf331..0d4c0842 100644 --- a/index.html +++ b/index.html @@ -27,6 +27,7 @@ } div.issue h3, div.note h3, div.issue h4, div.note h4, +div.issue h5, div.note h5, div.issue h5, div.note h5 { margin:0; font-weight:normal; @@ -47,6 +48,12 @@ div.note h5 { color:#178217; } + +[rel~="cito:citesAsSourceDocument"], +[property~="cito:citesAsSourceDocument"] { +background-color:#e9f0fb; +} + figure .example-h { margin-top:0; text-align: left; @@ -402,6 +409,8 @@

    Conformance

    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

    + +

    Source: WebAccessControl, README.md

    @@ -452,6 +461,8 @@

    Note: URI Origin

    Clients MUST NOT derive the URI of the ACL resource through string operations on the URI of the resource.

    + +

    Source: issues/8, issues/62, issues/131, issues/176

    @@ -465,6 +476,8 @@

    ACL Resource Representation

    Servers who want a resource to inherit Authorizations (see Effective ACL Resource) from a container resource MUST NOT initialise the ACL resource that is associated with the resource with a representation. When an authorized HTTP GET or HEAD request targets an ACL resource without an existing representation, the server MUST respond with the 404 status code as per [RFC7231].

    The root container MUST have an ACL resource with a representation. The ACL resource of the root container MUST include an Authorization allowing the acl:Control access privilege (acl:Control access mode).

    + +

    Source: issues/45

    @@ -481,6 +494,8 @@

    Access Objects

    The acl:accessTo property value is used to check if access is allowed for a specific resource. When an Authorization includes the acl:default property value (the container resource in context), then access permissions be applied to the original requested resource.

    Inheriting Authorizations from the most significant container's ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

    + +

    Source: issues/59

    @@ -525,8 +540,12 @@

    Note: URI Ownership

    Note: Loss of Control Mitigation

    It is assumed that systems using WAC have mechanisms to mitigate loss of control of the resources eg. by ensuring valid ACL resources and Authorizations, providing administrative functions on the storage, or implicit control over all resources in a storage to owners.

    + +

    Source: issues/67, issues/153, pull/264

    + +

    Source: issues/33

    @@ -570,6 +589,8 @@

    Issue: Client Identification

    Distinguishing social entities and clients [Issue].

    + +

    Source: issues/34, issues/32, issues/59

    @@ -608,6 +629,8 @@

    Note: Effective ACL Resource Alternative

    This specification does not constrain alternative methods to determine the effective ACL resource of a resource.

    + +

    Source: issues/55, issues/106, issues/130, issues/257, issues/251

    @@ -622,6 +645,8 @@

    Authorization Conformance

  • At least one acl:mode property value (Access Modes).
  • At least one acl:agent, acl:agentGroup, acl:agentClass or acl:origin property value (Access Subjects).
    • + +

    Source: issues/56, issues/57, issues/169, issues/186, issues/193, issues/17, issues/18, issues/38, issues/68, issues/78, issues/145

    @@ -680,6 +705,8 @@
    Note: HTTP Method and Access Mode Mappin

    As the HTTP DELETE method requests to remove a resource, the acl:Write access mode would be required.

    + +

    Source: issues/47, issues/132, issues/197, issues/246

    @@ -835,7 +862,7 @@

    wac-allow HTTP Header

    Clients' parsing algorithm for the WAC-Allow header should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (permission groups and access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    -

    [Source] [Source] [Source] [Source]

    +

    Source: issues/171, issues/170, issues/181, 60101295d8bdab47395e6775

    @@ -855,7 +882,7 @@

    acl Link Relation

    Consumers of ACL resources should be aware of the source and chain of custody of the data.
    -

    [Source] [Source]

    +

    Source: issues/54, issues/21

    @@ -873,8 +900,9 @@

    Authorization Extensions

    As ACL resources are RDF sources, Authorizations descriptions may be extended or limited by constraints eg. temporal or spatial constraints, and duties eg. payments, may be imposed on permissions, but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

    -

    To allow access to a class of resources, implementations may want to use the acl:accessToClass predicate as defined in the ACL ontology.

    + +

    Source: issues/10, issues/22, pull/37, issues/20

    From 2ca3aec07abbbd563ec8177d36608f50f415fe5c Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 12:13:14 +0200 Subject: [PATCH 232/310] Update source/advisement --- index.html | 39 ++++++++++++++++----------------------- 1 file changed, 16 insertions(+), 23 deletions(-) diff --git a/index.html b/index.html index 0d4c0842..3f16996d 100644 --- a/index.html +++ b/index.html @@ -27,7 +27,6 @@ } div.issue h3, div.note h3, div.issue h4, div.note h4, -div.issue h5, div.note h5, div.issue h5, div.note h5 { margin:0; font-weight:normal; @@ -48,12 +47,6 @@ div.note h5 { color:#178217; } - -[rel~="cito:citesAsSourceDocument"], -[property~="cito:citesAsSourceDocument"] { -background-color:#e9f0fb; -} - figure .example-h { margin-top:0; text-align: left; @@ -136,7 +129,7 @@

    Web Access Control

    -

    Editor’s Draft, 2021-06-15

    +

    Editor’s Draft, 2021-06-16

    This version
    @@ -162,7 +155,7 @@

    Editor’s Draft, 2021-06-15

    Modified
    -
    +
    @@ -410,7 +403,7 @@

    Conformance

    -

    Source: WebAccessControl, README.md

    +

    Source: WebAccessControl, README.md

    @@ -462,7 +455,7 @@

    Note: URI Origin

    Clients MUST NOT derive the URI of the ACL resource through string operations on the URI of the resource.

    -

    Source: issues/8, issues/62, issues/131, issues/176

    +

    Source: issues/8, issues/62, issues/131, issues/176

    @@ -477,7 +470,7 @@

    ACL Resource Representation

    The root container MUST have an ACL resource with a representation. The ACL resource of the root container MUST include an Authorization allowing the acl:Control access privilege (acl:Control access mode).

    -

    Source: issues/45

    +

    Source: issues/45

    @@ -495,7 +488,7 @@

    Access Objects

    Inheriting Authorizations from the most significant container's ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

    -

    Source: issues/59

    +

    Source: issues/59

    @@ -541,11 +534,11 @@

    Note: Loss of Control Mitigation

    It is assumed that systems using WAC have mechanisms to mitigate loss of control of the resources eg. by ensuring valid ACL resources and Authorizations, providing administrative functions on the storage, or implicit control over all resources in a storage to owners.

    -

    Source: issues/67, issues/153, pull/264

    +

    Source: issues/67, issues/153, pull/264

    -

    Source: issues/33

    +

    Source: issues/33

    @@ -586,11 +579,11 @@

    Note: Origin Considerations

    Issue: Client Identification

    -

    Distinguishing social entities and clients [Issue].

    +

    Distinguishing social entities and clients [issues/81].

    -

    Source: issues/34, issues/32, issues/59

    +

    Source: issues/34, issues/32, issues/59

    @@ -630,7 +623,7 @@

    Note: Effective ACL Resource Alternative -

    Source: issues/55, issues/106, issues/130, issues/257, issues/251

    +

    Source: issues/55, issues/106, issues/130, issues/257, issues/251

    @@ -646,7 +639,7 @@

    Authorization Conformance

  • At least one acl:agent, acl:agentGroup, acl:agentClass or acl:origin property value (Access Subjects).
    • -

    Source: issues/56, issues/57, issues/169, issues/186, issues/193, issues/17, issues/18, issues/38, issues/68, issues/78, issues/145

    +

    Source: issues/56, issues/57, issues/169, issues/186, issues/193, issues/17, issues/18, issues/38, issues/68, issues/78, issues/145

    @@ -706,7 +699,7 @@
    Note: HTTP Method and Access Mode Mappin -

    Source: issues/47, issues/132, issues/197, issues/246

    +

    Source: issues/47, issues/132, issues/197, issues/246

    @@ -862,7 +855,7 @@

    wac-allow HTTP Header

    Clients' parsing algorithm for the WAC-Allow header should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (permission groups and access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    -

    Source: issues/171, issues/170, issues/181, 60101295d8bdab47395e6775

    +

    Source: issues/171, issues/170, issues/181, 60101295d8bdab47395e6775, pull/210

    @@ -882,7 +875,7 @@

    acl Link Relation

    Consumers of ACL resources should be aware of the source and chain of custody of the data.
    -

    Source: issues/54, issues/21

    +

    Source: issues/54, issues/21

    @@ -902,7 +895,7 @@

    Authorization Extensions

    To allow access to a class of resources, implementations may want to use the acl:accessToClass predicate as defined in the ACL ontology.

    -

    Source: issues/10, issues/22, pull/37, issues/20

    +

    Source: issues/10, issues/22, pull/37, issues/20

    From 9ac54236325189e51643a6f5e80b60bdee4fa2ae Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 12:39:28 +0200 Subject: [PATCH 233/310] Add wac-allow-access-modes issue --- index.html | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index 3f16996d..63326f9b 100644 --- a/index.html +++ b/index.html @@ -840,7 +840,12 @@

    wac-allow HTTP Header

    The WAC-Allow HTTP header’s field-value is a comma-separated list of access-params. access-param is a whitespace-separated list of access-modes granted to a permission-group.

    -

    Issue: Incorporate extensions.

    +
    +

    Issue: WAC-Allow Access Modes

    +
    +

    Allow any access mode issues/82.

    +
    +

    This specification defines the following permission-groups:

    From 0cda462e984f8c3b62fc3ca027865b586b4de7d0 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 13:46:30 +0200 Subject: [PATCH 234/310] Fix figure URIs --- index.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index 63326f9b..c86b684a 100644 --- a/index.html +++ b/index.html @@ -776,9 +776,9 @@

    Authorization Matching

    The following query is typically used in context of inheriting Authorizations (acl:default) from a container's ACL resource. The query also demonstrates matching Authorizations that use a superclass of the required access mode (Access Mode Classes):

    -
    +

    Example: Match an Authorization with a specific container resource, agent class membership and access mode.

    - 
    ASK {
+                        
    ASK {
   GRAPH $aclResource {
     {
       ?authorization
@@ -801,9 +801,9 @@ 
    Authorization Matching
    
 
                       
    The following query can be used to check if an agent is a member of any group that can access a resource:
    
 
-                      
    
+                      
    
                         
    Example: Match an Authorization with a specific resource, agent with any group membership, and specific access mode.
    
-                        
    ASK {
+                        
    ASK {
   GRAPH $aclResource {
     ?authorization
       a acl:Authorization ;

From 4154316d75c3b1dac6686f0e5038952bdf96b3e9 Mon Sep 17 00:00:00 2001
From: Sarven Capadisli 
Date: Wed, 16 Jun 2021 13:46:51 +0200
Subject: [PATCH 235/310] Update audience

---
 index.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/index.html b/index.html
index c86b684a..1e6646b2 100644
--- a/index.html
+++ b/index.html
@@ -290,9 +290,9 @@ 
    Note: Specification Orthogonality
    
 
               
    This specification is for:
    
 
-              
      
-                
    • Resource server owners who want to enable agents to obtain and control access to resources;
      • 
-                
    • Application developers who want to implement a client to obtain and control access to resources.
      • 
+              
 
               
      

From ca8444f7bcf732b29e68ac25f2e9dffb18e62033 Mon Sep 17 00:00:00 2001
From: Sarven Capadisli 
Date: Wed, 16 Jun 2021 14:00:39 +0200
Subject: [PATCH 236/310] Update reference relations

---
 index.html | 50 +++++++++++++++++++++++++-------------------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/index.html b/index.html
index 1e6646b2..602abc4a 100644
--- a/index.html
+++ b/index.html
@@ -693,7 +693,7 @@ 
      Note: HTTP Method and Access Mode Mappin
 
                           
      As the HTTP PUT method requests to create or replace the resource state, the acl:Write access mode would be required.
      
 
-                          
      As the processing of HTTP PATCH method requests depends on the request semantics and content eg. acl:Append can allow requests using SPARQL 1.1 Update's INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.
      
+                          
      As the processing of HTTP PATCH method requests depends on the request semantics and content eg. acl:Append can allow requests using SPARQL 1.1 Update's [SPARQL11-UPDATE] INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.
      
 
                           
      As the HTTP DELETE method requests to remove a resource, the acl:Write access mode would be required.
      
                         
@@ -750,7 +750,7 @@ 
      Authorization Matching
      
                     
      
                       
      This section is non-normative.
      
 
-                      
      This specification does not impose a storage system that can be used to store Authorizations. Similarly, mechanisms that can be used to find required RDF statements of Authorizations is deliberately unspecified to allow for a wide variety of use. This section exemplifies access check via SPARQL 1.1 Query Language's ASK form to test whether or not an Authorization pattern matches; returns boolean.
      
+                      
      This specification does not impose a storage system that can be used to store Authorizations. Similarly, mechanisms that can be used to find required RDF statements of Authorizations is deliberately unspecified to allow for a wide variety of use. This section exemplifies access check via SPARQL 1.1 Query Language's [SPARQL11-QUERY] ASK form to test whether or not an Authorization pattern matches; returns boolean.
      
 
                       
      The ASK queries below exemplify atomic graph patterns that can be executed against the default graph of an RDF dataset using named graphs for resources. The examples use query variables marked with "?" to indicate any value, and "$" to indicate inputs passed to the query, eg. <http://example.org/.acl> as the IRI reference of the effective ACL resource of a request replaces $aclResource in the query, and likewise, acl:Write as input is intended to replace $mode in the examples.
      
 
@@ -1003,41 +1003,39 @@ 
      Normative References
      
                 
      
                   
      
                     
      [FETCH]
      
-                    
      Fetch Standard. Anne van Kesteren.  WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
      
+                    
      Fetch Standard. Anne van Kesteren.  WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
      
                     
      [FOAF]
      
-                    
      FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller.  FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec
      
+                    
      FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller.  FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec
      
                     
      [INFRA]
      
-                    
      Infra Standard. Anne van Kesteren; Domenic Denicola.  WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
      
+                    
      Infra Standard. Anne van Kesteren; Domenic Denicola.  WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
      
                     
      [RDF-SCHEMA]
      
-                    
      RDF Schema 1.1. Dan Brickley; Ramanathan Guha.  W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
      
+                    
      RDF Schema 1.1. Dan Brickley; Ramanathan Guha.  W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
      
                     
      [RDF11-CONCEPTS]
      
-                    
      RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler.  W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
      
+                    
      RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler.  W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
      
                     
      [RFC2119]
      
-                    
      Key words for use in RFCs to Indicate Requirement Levels. S. Bradner.  IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
      
+                    
      Key words for use in RFCs to Indicate Requirement Levels. S. Bradner.  IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
      
                     
      [RFC3864]
      
-                    
      Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul.  IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864
      
+                    
      Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul.  IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864
      
                     
      [RFC3986]
      
-                    
      Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter.  IETF. January 2005. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986
      
+                    
      Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter.  IETF. January 2005. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986
      
                     
      [RFC5789]
      
-                    
      PATCH Method for HTTP. L. Dusseault; J. Snell.  IETF. March 2010. Proposed Standard. URL: https://httpwg.org/specs/rfc5789.html
      
+                    
      PATCH Method for HTTP. L. Dusseault; J. Snell.  IETF. March 2010. Proposed Standard. URL: https://httpwg.org/specs/rfc5789.html
      
                     
      [RFC6454]
      
-                    
      The Web Origin Concept. A. Barth.  IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454
      
+                    
      The Web Origin Concept. A. Barth.  IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454
      
                     
      [RFC7231]
      
-                    
      Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed..  IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
      
+                    
      Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed..  IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
      
                     
      [RFC8274]
      
-                    
      Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba.  IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
      
+                    
      Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba.  IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
      
                     
      [RFC8288]
      
-                    
      Web Linking. M. Nottingham.  IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
      
-                    
      [SOLID-PROTOCOL]
      
-                    
      Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo; Justin Bingham; Dmitri Zagidulin.  W3C Solid Community Group. W3C Editor's Draft. URL: https://solidproject.org/TR/protocol
      
+                    
      Web Linking. M. Nottingham.  IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
      
                     
      [TURTLE]
      
-                    
      RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers.  W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
      
+                    
      RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers.  W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
      
                     
      [VCARD-RDF]
      
-                    
      vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney.  W3C. 22 May 2014. W3C Note. URL: https://www.w3.org/TR/vcard-rdf/
      
+                    
      vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney.  W3C. 22 May 2014. W3C Note. URL: https://www.w3.org/TR/vcard-rdf/
      
                     
      [WEBARCH]
      
-                    
      Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh.  W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/
      
+                    
      Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh.  W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/
      
                     
      [WEBID]
      
-                    
      Web Identity and Discovery. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/
      
+                    
      WebID 1.0. Henry Story; Andrei Sambra; Stéphane Corlosquet.  W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/
      
                   
      
                 
      
               
      
@@ -1047,13 +1045,15 @@ 
      Informative References
      
                 
      
                   
      
                     
      [LDP]
      
-                    
      Linked Data Platform 1.0. Steve Speicher; John Arwe; Ashok Malhotra.  W3C. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/
      
+                    
      Linked Data Platform 1.0. Steve Speicher; John Arwe; Ashok Malhotra.  W3C. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/
      
                     
      [ODRL-MODEL]
      
-                    
      ODRL Information Model 2.2. Renato Iannella; Serena Villata.  W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-model/
      
+                    
      ODRL Information Model 2.2. Renato Iannella; Serena Villata.  W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-model/
      
+                    
      [SOLID-PROTOCOL]
      
+                    
      Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo; Justin Bingham; Dmitri Zagidulin.  W3C Solid Community Group. W3C Editor's Draft. URL: https://solidproject.org/TR/protocol
      
                     
      [SPARQL11-QUERY]
      
-                    
      SPARQL 1.1 Query Language. Steven Harris; Andy Seaborne.  W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-query/
      
+                    
      SPARQL 1.1 Query Language. Steven Harris; Andy Seaborne.  W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-query/
      
                     
      [SPARQL11-UPDATE]
      
-                    
      SPARQL 1.1 Update. Paula Gearon; Alexandre Passant; Axel Polleres.  W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-update/
      
+                    
      SPARQL 1.1 Update. Paula Gearon; Alexandre Passant; Axel Polleres.  W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-update/
      
                   
      
                 
      
               

From 096d982b64677c1415dbb95e018a937c7df89568 Mon Sep 17 00:00:00 2001
From: Sarven Capadisli 
Date: Wed, 16 Jun 2021 14:03:02 +0200
Subject: [PATCH 237/310] Remove status-of-a-permission

---
 index.html | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/index.html b/index.html
index 602abc4a..34f0efe6 100644
--- a/index.html
+++ b/index.html
@@ -277,7 +277,7 @@ 
      Intro
 
               
      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.
      
 
-              
      The WAC specification describes how to enable applications to discover Authorizations associated with a given resource, and to control such policies, as directed by an agent. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine the status of a permission of a requested resource. Any kind of access can be given to a resource as per the ACL ontology. This specification uses the access modes currently defined by the ACL ontology, such as the class of operations to read, write, append and control resources. An Authorization may allow public access to resources or place the requirement for authenticated agents. Resources and agents can be on different origins.
      
+              
      The WAC specification describes how to enable applications to discover Authorizations associated with a given resource, and to control such policies, as directed by an agent. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Any kind of access can be given to a resource as per the ACL ontology. This specification uses the access modes currently defined by the ACL ontology, such as the class of operations to read, write, append and control resources. An Authorization may allow public access to resources or place the requirement for authenticated agents. Resources and agents can be on different origins.
      
 
               
      
                 
      Note: Specification Orthogonality
      
@@ -302,7 +302,7 @@ 
      Terminology
      
 
                   
      The WAC specification defines the following terms. These terms are referenced throughout this specification.
      
 
-                  
+                  
 
                   
      
                     
      URI
      
@@ -337,9 +337,6 @@ 
      Terminology
      
 
                     
      origin
      
                     
      An origin indicates where an HTTP request originates from [RFC6454].
      
-
-                    
      status of a permission
      
-                    
      The status of a permission is either access is granted or denied.
      
                   
      
 
                   
      In addition to the terminology above, this specification also uses terminology from the [INFRA] specification. When INFRA terminology is used, such as string and boolean, it is linked directly to that specification.
      
@@ -594,7 +591,7 @@ 
      Authorization Process
      
             
      
               
      This section describes how implementations can determine the effective ACL resource of a resource and hence which set of conforming authorizations to use.
      
 
-              
      Servers process access requests by evaluating the Authorizations associated with referenced resources in order to determine whether the necessary access permissions are granted or denied for a particular request.
      
+              
      Servers process access requests by evaluating the Authorizations associated with referenced resources in order to determine whether the necessary access permissions are granted for a particular request.
      
 
               
      
                 
      Effective ACL Resource
      

From c6b898b498e2ef32e4088611e39269e35847d7f7 Mon Sep 17 00:00:00 2001
From: Sarven Capadisli 
Date: Wed, 16 Jun 2021 14:07:38 +0200
Subject: [PATCH 238/310] Remove unused namespaces

---
 index.html | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/index.html b/index.html
index 34f0efe6..2efffa77 100644
--- a/index.html
+++ b/index.html
@@ -356,21 +356,6 @@ 
      Namespaces
      
                       
                     
                     
-                      
-                        rdf
-                        http://www.w3.org/1999/02/22-rdf-syntax-ns#
-                        [rdf-schema]
-                      
-                      
-                        solid
-                        http://www.w3.org/ns/solid/terms#
-                        Solid Terms
-                      
-                      
-                        pim
-                        http://www.w3.org/ns/pim/space#
-                        Workspace Ontology
-                      
                       
                         acl
                         http://www.w3.org/ns/auth/acl#

From 599e0c493f365a7842924c64868da4ebd45bb9db Mon Sep 17 00:00:00 2001
From: Sarven Capadisli 
Date: Wed, 16 Jun 2021 14:17:03 +0200
Subject: [PATCH 239/310] Minor

---
 index.html | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/index.html b/index.html
index 2efffa77..ef58a897 100644
--- a/index.html
+++ b/index.html
@@ -394,14 +394,14 @@ 
      HTTP Interactions
      
             
      
               
      This section is non-normative.
      
 
-              
      Clients who want to perform read-write operations on ACL resources with respect to Authorizations which are stored on a server can do so within the framework of HTTP. This specification does not describe the HTTP interaction to read-write resources. It is assumed that servers have a mapping to handle HTTP requests and the required Authorizations to grant operations on resources. Implementations are strongly encouraged to use existing approaches that provide an extension of the rules of Linked Data, eg. [SOLID-PROTOCOL], [LDP].
      
+              
      Clients who want to perform read-write operations on ACL resources with respect to Authorizations which are stored on a server can do so within the framework of HTTP. This specification does not describe the HTTP interaction to read-write resources. It is assumed that servers have a mapping to handle HTTP requests and the required Authorizations to grant operations on resources. Implementations are strongly encouraged to use existing approaches that provide an extension of the rules of Linked Data, eg. [SOLID-PROTOCOL], [LDP].
      
             
      
           
      
 
           
      
             
      ACL Resources
      
             
      
-              
      This section describes ACL resource discovery and representation.
      
+              
      This section describes ACL resource discovery and representation.
      
 
               
      
                 
      ACL Resource Discovery
      
@@ -461,7 +461,7 @@ 
      ACL Resource Representation
      
           
      
             
      Authorization Rule
      
             
      
-              
      Authorization (instance of acl:Authorization) is the most fundamental unit of access control describing access permissions granted to agents the ability to perform operations on resources. Authorizations are described with RDF statements and may express any information. This section describes the following characteristics of an Authorization: access objects to specify what can be accessed, access modes to specify permissions, and access subjects to specify who can access the objects.
      
+              
      Authorization (instance of acl:Authorization) is the most fundamental unit of access control describing access permissions granted to agents the ability to perform operations on resources. Authorizations are described with RDF statements and may express any information. This section describes the following characteristics of an Authorization: access objects to specify what can be accessed, access modes to specify permissions, and access subjects to specify who can access the objects.
      
 
               
      
                 
      Access Objects
      
@@ -574,18 +574,18 @@ 
      Issue: Client Identification
      
           
      
             
      Authorization Process
      
             
      
-              
      This section describes how implementations can determine the effective ACL resource of a resource and hence which set of conforming authorizations to use.
      
+              
      This section describes how implementations can determine the effective ACL resource of a resource and hence which set of conforming authorizations to use.
      
 
-              
      Servers process access requests by evaluating the Authorizations associated with referenced resources in order to determine whether the necessary access permissions are granted for a particular request.
      
+              
      Servers process access requests by evaluating the Authorizations associated with referenced resources in order to determine whether the necessary access permissions are granted for a particular request.
      
 
               
      
                 
      Effective ACL Resource
      
                 
      
                   
      Servers enforce the effective ACL resource of a resource, whereas clients determine the effective ACL resource of a resource to perform read and write Authorizations.
      
 
-                  
      When an ACL resource associated with a resource has a representation (see ACL Resource Representation), it is the effective ACL resource of the requested resource.
      
+                  
      When an ACL resource associated with a resource has a representation (see ACL Resource Representation), it is the effective ACL resource of the requested resource.
      
 
-                  
      When an ACL resource associated with a resource does not have a representation (see ACL Resource Representation), no Authorizations can be immediately checked against the requested resource. In this case, a container resource's ACL resource may apply on every access to a member resource, in specifying Authorizations for the requested resource.
      
+                  
      When an ACL resource associated with a resource does not have a representation (see ACL Resource Representation), no Authorizations can be immediately checked against the requested resource. In this case, a container resource's ACL resource may apply on every access to a member resource, in specifying Authorizations for the requested resource.
      
 
                   
      WAC has the property of being recursive with respect to container hierarchy, meaning that a member resource inherits Authorizations from the closest container resource (heading toward the root container).
      
 
@@ -732,7 +732,7 @@ 
      Authorization Matching
      
                     
      
                       
      This section is non-normative.
      
 
-                      
      This specification does not impose a storage system that can be used to store Authorizations. Similarly, mechanisms that can be used to find required RDF statements of Authorizations is deliberately unspecified to allow for a wide variety of use. This section exemplifies access check via SPARQL 1.1 Query Language's [SPARQL11-QUERY] ASK form to test whether or not an Authorization pattern matches; returns boolean.
      
+                      
      This specification does not impose a storage system that can be used to store Authorizations. Similarly, mechanisms that can be used to find required RDF statements of Authorizations is deliberately unspecified to allow for a wide variety of use. This section exemplifies access check via SPARQL 1.1 Query Language's [SPARQL11-QUERY] ASK form to test whether or not an Authorization pattern matches; returns boolean.
      
 
                       
      The ASK queries below exemplify atomic graph patterns that can be executed against the default graph of an RDF dataset using named graphs for resources. The examples use query variables marked with "?" to indicate any value, and "$" to indicate inputs passed to the query, eg. <http://example.org/.acl> as the IRI reference of the effective ACL resource of a request replaces $aclResource in the query, and likewise, acl:Write as input is intended to replace $mode in the examples.
      
 

From ffa98458137f911a9c1e448216ac1ebfbd60be89 Mon Sep 17 00:00:00 2001
From: Sarven Capadisli 
Date: Wed, 16 Jun 2021 14:37:53 +0200
Subject: [PATCH 240/310] Add inlists motivation overview

---
 index.html | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/index.html b/index.html
index ef58a897..364177ff 100644
--- a/index.html
+++ b/index.html
@@ -273,13 +273,13 @@ 
      Intro
             
      
               
      This section is non-normative.
      
 
-              
      Unauthorized access or modification of Web resources could lead to unintended loss, damage or disclosure of data. To support read-write operations within the framework of HTTP, mechanisms for expressing and application of authorization conditions are needed to meet the social requirements of decentralised applications.
      
+              
      Unauthorized access or modification of Web resources could lead to unintended loss, damage or disclosure of data. To support read-write operations within the framework of HTTP, mechanisms for expressing and application of authorization conditions are needed to meet the social requirements of decentralised applications.
      
 
               
      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.
      
 
-              
      The WAC specification describes how to enable applications to discover Authorizations associated with a given resource, and to control such policies, as directed by an agent. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Any kind of access can be given to a resource as per the ACL ontology. This specification uses the access modes currently defined by the ACL ontology, such as the class of operations to read, write, append and control resources. An Authorization may allow public access to resources or place the requirement for authenticated agents. Resources and agents can be on different origins.
      
+              
      The WAC specification describes how to enable applications to discover Authorizations associated with a given resource, and to control such policies, as directed by an agent. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Any kind of access can be given to a resource as per the ACL ontology. This specification uses the access modes currently defined by the ACL ontology, such as the class of operations to read, write, append and control resources. An Authorization may allow public access to resources or place the requirement for authenticated agents. Resources and agents can be on different origins.
      
 
-              
      
+              
      
                 
      Note: Specification Orthogonality
      
                 
      
                   
      This specification does not specify mechanisms for authentication or methods to verify assertions. It is assumed that systems using WAC have the ability to apply authentication and verification techniques when desired.
      
@@ -421,14 +421,14 @@ 
      Issue: Link Relation Type
      
 
                   
      Clients can discover the ACL resource associated with a resource by making an HTTP request on the target URL, and checking the HTTP Link header with the rel parameter [RFC8288].
      
 
-                  
      
+                  
      
                     
      Note: ACL Resource URI Security
      
                     
      
                       
      The URI of an ACL resource does not in itself pose a security threat ([RFC3986] security considerations). This specification does not constrain the discoverability of ACL resources.
      
                     
      
                   
      
 
-                  
      
+                  
      
                     
      Note: URI Origin
      
                     
      
                       
      The resource and the associated ACL resource can be on different origins [RFC6454].
      
@@ -495,7 +495,7 @@ 
      Access Modes
      
                     
      Allows access to a class of read and write operations on an ACL resource associated with a resource.
    -
    +

    Note: Access Mode Classes

    acl:Access is a superclass where specific access modes (entailing a class of operations) can be subclassed. It is not intended to be used for setting or matching access privileges.

    @@ -504,14 +504,14 @@

    Note: Access Mode Classes

    -
    +

    Note: URI Ownership

    URI ownership, as per Architecture of the World Wide Web [WEBARCH], is outside the scope of this specification, and thus cannot be changed by modifying Authorizations.

    -
    +

    Note: Loss of Control Mitigation

    It is assumed that systems using WAC have mechanisms to mitigate loss of control of the resources eg. by ensuring valid ACL resources and Authorizations, providing administrative functions on the storage, or implicit control over all resources in a storage to owners.

    @@ -544,14 +544,14 @@

    Access Subjects

    The acl:origin predicate denotes the origin an HTTP request is being given the access permission.

    -
    +

    Note: Subject Verification

    Servers may accept different authentication protocols as well as credential verification methods.

    -
    +

    Note: Origin Considerations

    Typical Web browsers use origin based security. While it has many limitations, it is however ubiquitous.

    @@ -598,7 +598,7 @@

    Effective ACL Resource

  • Otherwise, repeat the steps using the container resource of resource.
    • -
    +

    Note: Effective ACL Resource Alternatives

    This specification does not constrain alternative methods to determine the effective ACL resource of a resource.

    @@ -653,7 +653,7 @@

    Reading and Writing Resources

    When an operation requests to delete a resource, the server MUST match Authorizations allowing the acl:Write access privilege on the resource and the containing container.

    -
    +
    Note: Reinstated Resource Permissions

    Implementations may perform cleanup tasks such as deleting ACL resources that are associated with a resource when the resource is deleted. As deleted resources may be reinstated with the same URI, access permissions on the reinstated resource may change as per determining the Effective ACL Resource.

    @@ -662,7 +662,7 @@
    Note: Reinstated Resource PermissionsWhen an operation requests to read and write an ACL resource, the server MUST match an Authorization allowing the acl:Control access privilege on the resource.

    -
    +
    Note: HTTP Method and Access Mode Mapping

    When the target of the HTTP request is the ACL resource, the operation can only be allowed with the acl:Control access mode.

    @@ -700,14 +700,14 @@

    Web Application Authorization

    When an authorization is granted to an HTTP request including the Origin header, the server MUST include the HTTP Access-Control-Allow-Origin and Access-Control-Allow-Headers headers in the response of the HTTP request.

    -
    +
    Note: Access Subject and Origin Rejection Reason

    Implementations are encouraged to describe reasons to reject the request in the HTTP response the difference between the access subject not being allowed and the origin associated with the HTTP request not being granted access.

    -
    +
    Note: Trusted Origins

    Implementations might implicitly allow a list of origins eg. the same-origin [RFC6454].

    @@ -716,7 +716,7 @@
    Note: Trusted Origins

    Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (see WAC-Allow) in the response of HTTP GET and HEAD requests.

    -
    +
    Note: Clients Discovering Access Privileges

    Clients can discover access privileges on a resource by making an HTTP HEAD or GET request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (see WAC-Allow).

    From 6125a3be5a471840b39ec6940a86d86b7559d30e Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 15:12:48 +0200 Subject: [PATCH 241/310] Add document-derived-from --- index.html | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 364177ff..f114c851 100644 --- a/index.html +++ b/index.html @@ -116,6 +116,11 @@ #acknowledgements li { display:inline; } #acknowledgements li:after { content: ", "; } #acknowledgements li:last-child:after { content: ""; } + +dl[id^="document-"] ul { +padding-left:0; +list-style-type:none; +} @@ -164,6 +169,17 @@

    Editor’s Draft, 2021-06-16

    Issues
    +
    +
    Derived From
    +
    + +
    +
    +

    MIT License. Copyright © 2021 W3C Solid Community Group.

    @@ -384,8 +400,6 @@

    Conformance

    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

    - -

    Source: WebAccessControl, README.md

    From 99830147895856be4affc988d03e57c3118a7a1d Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 15:54:20 +0200 Subject: [PATCH 242/310] Add language license status policy --- index.html | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 71 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index f114c851..27f402df 100644 --- a/index.html +++ b/index.html @@ -121,6 +121,13 @@ padding-left:0; list-style-type:none; } +dl [rel~="odrl:action"], +dl [rel~="odrl:action"] li { +display: inline; +} +dl [rel~="odrl:action"] li:after { +content: ","; +} @@ -180,7 +187,70 @@

    Editor’s Draft, 2021-06-16

    -

    MIT License. Copyright © 2021 W3C Solid Community Group.

    +
    +
    Language
    +
    English
    +
    + +
    +
    License
    +
    MIT License
    +
    + +
    +
    Document Status
    +
    Editor’s Draft
    +
    + +
    +
    Policy
    +
    +
    +
    Rule
    +
    Offer
    +
    Unique Identifier
    +
    https://solidproject.org/TR/wac#document-policy-offer
    +
    Target
    +
    https://solidproject.org/TR/wac
    +
    Permission
    +
    +
    +
    Assigner
    +
    W3C Solid Community Group
    +
    Action
    +
    + +
    +
    +
    +
    +
    +
    + +

    Copyright © 2021 W3C Solid Community Group.

    From a2b73f3fa0d9fdb97e30c01fa32d37949edcc55a Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 16:01:50 +0200 Subject: [PATCH 243/310] Add document-in-reply-to --- index.html | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/index.html b/index.html index 27f402df..1dc1984e 100644 --- a/index.html +++ b/index.html @@ -202,6 +202,11 @@

    Editor’s Draft, 2021-06-16

    Editor’s Draft
    +
    +
    In Reply To
    +
    About Solid
    +
    +
    Policy
    From 63cccb0d14ba45be2e86677bb30f072c03250d34 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 16:02:42 +0200 Subject: [PATCH 244/310] Include dokieli --- index.html | 2 ++ 1 file changed, 2 insertions(+) diff --git a/index.html b/index.html index 1dc1984e..0a1fa495 100644 --- a/index.html +++ b/index.html @@ -129,6 +129,8 @@ content: ","; } + + From b2e3e15286f953bc6cd3ed0118c0c0095315b845 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 16:07:21 +0200 Subject: [PATCH 245/310] Minor --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 0a1fa495..b0b803e5 100644 --- a/index.html +++ b/index.html @@ -128,6 +128,9 @@ dl [rel~="odrl:action"] li:after { content: ","; } +dl [rel~="odrl:action"] li:last-child:after { +content: ""; +} From f67a89f1c2a90fca33b27b4682d3b95f071878eb Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 16:08:43 +0200 Subject: [PATCH 246/310] Link to Solid Origin --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index b0b803e5..d94f5021 100644 --- a/index.html +++ b/index.html @@ -209,7 +209,7 @@

    Editor’s Draft, 2021-06-16

    In Reply To
    -
    About Solid
    +
    Solid Origin
    From 00dc81d0bb4e3ef157c75409731c35d3df52d0ba Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 16:48:23 +0200 Subject: [PATCH 247/310] Minor --- index.html | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/index.html b/index.html index d94f5021..2b836f18 100644 --- a/index.html +++ b/index.html @@ -459,7 +459,7 @@

    Namespaces

    foaf - http://http://xmlns.com/foaf/0.1/ + http://xmlns.com/foaf/0.1/ [Friend of a Friend (FOAF) vocabulary] @@ -562,7 +562,7 @@

    Access Objects

    The acl:accessTo property value is used to check if access is allowed for a specific resource. When an Authorization includes the acl:default property value (the container resource in context), then access permissions be applied to the original requested resource.

    -

    Inheriting Authorizations from the most significant container's ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

    +

    Inheriting Authorizations from the most significant container’s ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

    Source: issues/59

    @@ -679,7 +679,7 @@

    Effective ACL Resource

    When an ACL resource associated with a resource has a representation (see ACL Resource Representation), it is the effective ACL resource of the requested resource.

    -

    When an ACL resource associated with a resource does not have a representation (see ACL Resource Representation), no Authorizations can be immediately checked against the requested resource. In this case, a container resource's ACL resource may apply on every access to a member resource, in specifying Authorizations for the requested resource.

    +

    When an ACL resource associated with a resource does not have a representation (see ACL Resource Representation), no Authorizations can be immediately checked against the requested resource. In this case, a container resource’s ACL resource may apply on every access to a member resource, in specifying Authorizations for the requested resource.

    WAC has the property of being recursive with respect to container hierarchy, meaning that a member resource inherits Authorizations from the closest container resource (heading toward the root container).

    @@ -769,7 +769,7 @@
    Note: HTTP Method and Access Mode Mappin

    As the HTTP PUT method requests to create or replace the resource state, the acl:Write access mode would be required.

    -

    As the processing of HTTP PATCH method requests depends on the request semantics and content eg. acl:Append can allow requests using SPARQL 1.1 Update's [SPARQL11-UPDATE] INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.

    +

    As the processing of HTTP PATCH method requests depends on the request semantics and content eg. acl:Append can allow requests using SPARQL 1.1 Update’s [SPARQL11-UPDATE] INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.

    As the HTTP DELETE method requests to remove a resource, the acl:Write access mode would be required.

    @@ -788,7 +788,7 @@

    Web Application Authorization

    • an Authorization allowing access to the requesting agent (acl:agent, acl:agentGroup, acl:agentClass);
      • -
    • an Authorization with an acl:origin property value that of Origin's field-value; and
      • +
    • an Authorization with an acl:origin property value that of Origin’s field-value; and
    • the required access mode is allowed for the requesting agent and the origin.
    @@ -826,7 +826,7 @@

    Authorization Matching

    This section is non-normative.

    -

    This specification does not impose a storage system that can be used to store Authorizations. Similarly, mechanisms that can be used to find required RDF statements of Authorizations is deliberately unspecified to allow for a wide variety of use. This section exemplifies access check via SPARQL 1.1 Query Language's [SPARQL11-QUERY] ASK form to test whether or not an Authorization pattern matches; returns boolean.

    +

    This specification does not impose a storage system that can be used to store Authorizations. Similarly, mechanisms that can be used to find required RDF statements of Authorizations is deliberately unspecified to allow for a wide variety of use. This section exemplifies access check via SPARQL 1.1 Query Language’s [SPARQL11-QUERY] ASK form to test whether or not an Authorization pattern matches; returns boolean.

    The ASK queries below exemplify atomic graph patterns that can be executed against the default graph of an RDF dataset using named graphs for resources. The examples use query variables marked with "?" to indicate any value, and "$" to indicate inputs passed to the query, eg. <http://example.org/.acl> as the IRI reference of the effective ACL resource of a request replaces $aclResource in the query, and likewise, acl:Write as input is intended to replace $mode in the examples.

    @@ -850,7 +850,7 @@

    Authorization Matching

    From here on, PREFIXs in the query are assumed to be present.

    -

    The following query is typically used in context of inheriting Authorizations (acl:default) from a container's ACL resource. The query also demonstrates matching Authorizations that use a superclass of the required access mode (Access Mode Classes):

    +

    The following query is typically used in context of inheriting Authorizations (acl:default) from a container’s ACL resource. The query also demonstrates matching Authorizations that use a superclass of the required access mode (Access Mode Classes):

    Example: Match an Authorization with a specific container resource, agent class membership and access mode.

    @@ -934,7 +934,7 @@

    Issue: WAC-Allow Access Modes

    access-mode corresponds to the Access Modes as defined in the ACL ontology (acl:Read, acl:Write, acl:Append, acl:Control).

    -

    Clients' parsing algorithm for the WAC-Allow header should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (permission groups and access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    +

    Clients’ parsing algorithm for the WAC-Allow header should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (permission groups and access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    Source: issues/171, issues/170, issues/181, 60101295d8bdab47395e6775, pull/210

    @@ -1025,7 +1025,7 @@

    Security Considerations

    Implementations are encouraged to follow the security considerations that are found in URI Generic Syntax, HTTP/1.1 Message Syntax and Routing and Semantics and Content.

    -

    Servers are strongly discouraged from trusting the information returned by looking up an agent's WebID for access control purposes. The server operator can also provide the server with other trusted information to include in the search for a reason to give the requester the access.

    +

    Servers are strongly discouraged from trusting the information returned by looking up an agent’s WebID for access control purposes. The server operator can also provide the server with other trusted information to include in the search for a reason to give the requester the access.

    Transfer of Authorizations between a client and server over an open network creates the potential for those policies to be modified or disclosed without proper authorization. The requirements for the Web Access Control protocol discussed in this specification do not include cryptographic protection of Authorization information, because it is assumed that this protection can be provided through HTTP over TLS. The path between client and application may be composed of multiple independent TLS connections, thus for end-to-end integrity and authenticity of content within an HTTP message, implementers can use mechanisms such as Signing HTTP Messages. For cryptographic proof of Authorizations asserted by agents and protection from undetected modifications, implementers can use mechanisms such as Linked Data Security.

    @@ -1044,7 +1044,7 @@

    Privacy Considerations

    Access permission to append a new resource to a container resource is independently of access permission to read a container resource. Thus, servers are encouraged to prevent information leakage when a successful HTTP request appends a new resource to a container resource. For instance, while the knowledge of the URI-Reference in Location and Content-Location HTTP headers in the response of a POST does not in itself pose a security threat ([RFC3986]), servers should consider the risks when read access to the container is not granted to agents.

    -

    Access permission to update a resource is independently of access permission to read a resource. Thus, servers are encouraged to prevent information leakage when an attempt to delete information in a resource may reveal the existence of the information. For instance, when an HTTP PATCH request uses SPARQL Update's DELETE DATA operation, servers should consider the risks of disclosing information by the chosen status code when read access to the resource is not granted to agents.

    +

    Access permission to update a resource is independently of access permission to read a resource. Thus, servers are encouraged to prevent information leakage when an attempt to delete information in a resource may reveal the existence of the information. For instance, when an HTTP PATCH request uses SPARQL Update’s DELETE DATA operation, servers should consider the risks of disclosing information by the chosen status code when read access to the resource is not granted to agents.

    @@ -1111,7 +1111,7 @@

    Normative References

    [WEBARCH]
    Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/
    [WEBID]
    -
    WebID 1.0. Henry Story; Andrei Sambra; Stéphane Corlosquet. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/
    +
    WebID 1.0. Henry Story; Andrei Sambra; Stéphane Corlosquet. W3C Editor’s Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/
    @@ -1125,7 +1125,7 @@

    Informative References

    [ODRL-MODEL]
    ODRL Information Model 2.2. Renato Iannella; Serena Villata. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-model/
    [SOLID-PROTOCOL]
    -
    Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo; Justin Bingham; Dmitri Zagidulin. W3C Solid Community Group. W3C Editor's Draft. URL: https://solidproject.org/TR/protocol
    +
    Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo; Justin Bingham; Dmitri Zagidulin. W3C Solid Community Group. W3C Editor’s Draft. URL: https://solidproject.org/TR/protocol
    [SPARQL11-QUERY]
    SPARQL 1.1 Query Language. Steven Harris; Andy Seaborne. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-query/
    [SPARQL11-UPDATE]
    From 5b5770c367976063c9253309b65d9f62cec438bb Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 16:48:57 +0200 Subject: [PATCH 248/310] Add inbox --- index.html | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/index.html b/index.html index 2b836f18..89489b74 100644 --- a/index.html +++ b/index.html @@ -202,6 +202,11 @@

    Editor’s Draft, 2021-06-16

    MIT License
    +
    +
    Notifications Inbox
    +
    https://specs.solidcommunity.net/inbox/wac/
    +
    +
    Document Status
    Editor’s Draft
    From 3cfaa66194c90aa25c76fff73b825b7538967831 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 16 Jun 2021 23:24:20 +0200 Subject: [PATCH 249/310] Minor --- index.html | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/index.html b/index.html index 89489b74..f9fd252d 100644 --- a/index.html +++ b/index.html @@ -37,14 +37,10 @@ div.issue h5 > span, div.note h5 > span { text-transform: uppercase; } -div.issue h3, -div.issue h4, -div.issue h5 { +div.issue h3, div.issue h4, div.issue h5 { color:#ae1e1e; } -div.note h3, -div.note h4, -div.note h5 { +div.note h3, div.note h4, div.note h5 { color:#178217; } figure .example-h { @@ -104,19 +100,15 @@ section > h4:before { content:counter(section)"." counter(sub-section) "." counter(sub-sub-section) "\00a0"; } - -aside.note.do blockquote dl.published, -aside.note.do blockquote dl.license, -aside.note.do blockquote dl.rights { -top:-2em; -left:4.5em; -} - #acknowledgements ul { padding: 0; margin:0 } #acknowledgements li { display:inline; } #acknowledgements li:after { content: ", "; } #acknowledgements li:last-child:after { content: ""; } +aside.do { overflow:inherit; } +aside.do blockquote { +padding: 0; border: 0; margin: 0; +} dl[id^="document-"] ul { padding-left:0; list-style-type:none; From 231ce5eeb4c207e138e58f3971e0fc6b49599740 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:26:22 +0200 Subject: [PATCH 250/310] Init bib-security-privacy-questionnaire --- index.html | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/index.html b/index.html index f9fd252d..ef0e41bf 100644 --- a/index.html +++ b/index.html @@ -1063,6 +1063,8 @@

    Internationalization Considerations

    Security and Privacy Review

    This section is non-normative.

    + +

    These questions provide an overview of security and privacy considerations for this specification as guided by Self-Review Questionnaire: Security and Privacy.

    @@ -1121,6 +1123,8 @@

    Informative References

    Linked Data Platform 1.0. Steve Speicher; John Arwe; Ashok Malhotra. W3C. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/
    [ODRL-MODEL]
    ODRL Information Model 2.2. Renato Iannella; Serena Villata. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-model/
    +
    [SECURITY-PRIVACY-QUESTIONNAIRE]
    +
    Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
    [SOLID-PROTOCOL]
    Solid Protocol. Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo; Justin Bingham; Dmitri Zagidulin. W3C Solid Community Group. W3C Editor’s Draft. URL: https://solidproject.org/TR/protocol
    [SPARQL11-QUERY]
    From a150ddef0d33f8b620f64dcc82d2a166b14100a3 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:27:09 +0200 Subject: [PATCH 251/310] Add security-privacy-review-purpose --- index.html | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/index.html b/index.html index ef0e41bf..aba1e1ef 100644 --- a/index.html +++ b/index.html @@ -1065,6 +1065,11 @@

    Security and Privacy Review

    This section is non-normative.

    These questions provide an overview of security and privacy considerations for this specification as guided by Self-Review Questionnaire: Security and Privacy.

    + +
    +
    What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
    +
    There are no known security impacts of the features in this specification.
    +
    From 6d0e8bec6009f5f4201c39cf220e7f8c57ca8cd5 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:28:06 +0200 Subject: [PATCH 252/310] Add security-privacy-review-minimum-data --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index aba1e1ef..3b5db1c6 100644 --- a/index.html +++ b/index.html @@ -1069,6 +1069,9 @@

    Security and Privacy Review

    What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
    There are no known security impacts of the features in this specification.
    + +
    Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
    +
    Yes.
    From 5b2d77d00a19138f74e8731f3ec9a54766d2b2be Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:28:25 +0200 Subject: [PATCH 253/310] Add security-privacy-review-personal-data --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 3b5db1c6..8d1f41eb 100644 --- a/index.html +++ b/index.html @@ -1072,6 +1072,9 @@

    Security and Privacy Review

    Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
    Yes.
    + +
    How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
    +
    ACL resources may contain any data including that which identifies or refers to agents and agent groups. Access to ACL resources is only granted to Access Subjects with the acl:Control access mode, and thus by definition, meaningful consent to any personal data that agents include about themselves is extended to other agents with control access on the ACL resource. Group resources are subject to the same Authorization conditions as any resource (that is not an ACL resource), and thus information may be exposed.
    From 080bd876e27fead92d6b5897a37526d5a8890d0d Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:28:59 +0200 Subject: [PATCH 254/310] Add security-privacy-review-sensitive-data --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 8d1f41eb..74a1207d 100644 --- a/index.html +++ b/index.html @@ -1075,6 +1075,9 @@

    Security and Privacy Review

    How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
    ACL resources may contain any data including that which identifies or refers to agents and agent groups. Access to ACL resources is only granted to Access Subjects with the acl:Control access mode, and thus by definition, meaningful consent to any personal data that agents include about themselves is extended to other agents with control access on the ACL resource. Group resources are subject to the same Authorization conditions as any resource (that is not an ACL resource), and thus information may be exposed.
    + +
    How do the features in your specification deal with sensitive information?
    +
    Same implications as personal information and personally-identifiable information in ACL resources and group resources. In the case of including sensitive information, the sender should be aware that changes to a group resource can allow non-members or new members to view membership.
    From 618b96724cf385de1c22c413f623d8ef9e975f74 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:29:41 +0200 Subject: [PATCH 255/310] Add security-privacy-review-persistent-origin-specific-state --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 74a1207d..f19c37ff 100644 --- a/index.html +++ b/index.html @@ -1078,6 +1078,9 @@

    Security and Privacy Review

    How do the features in your specification deal with sensitive information?
    Same implications as personal information and personally-identifiable information in ACL resources and group resources. In the case of including sensitive information, the sender should be aware that changes to a group resource can allow non-members or new members to view membership.
    + +
    Do the features in your specification introduce new state for an origin that persists across browsing sessions?
    +
    No.
    From a8368bcb79f05f703527fef0270f84d582820394 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:29:56 +0200 Subject: [PATCH 256/310] Add security-privacy-review-underlying-platform-data --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index f19c37ff..2e52060d 100644 --- a/index.html +++ b/index.html @@ -1081,6 +1081,9 @@

    Security and Privacy Review

    Do the features in your specification introduce new state for an origin that persists across browsing sessions?
    No.
    + +
    Do the features in your specification expose information about the underlying platform to origins?
    +
    No.
    From 590b220e693c95055ba05abd6da423aadb7c5ca1 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:30:13 +0200 Subject: [PATCH 257/310] Add security-privacy-review-send-to-platform --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 2e52060d..6f5bebcd 100644 --- a/index.html +++ b/index.html @@ -1084,6 +1084,9 @@

    Security and Privacy Review

    Do the features in your specification expose information about the underlying platform to origins?
    No.
    + +
    Does this specification allow an origin to send data to the underlying platform?
    +
    No. ACL resources are described within the framework of HTTP as RDF documents represented with the Turtle syntax. Servers may be able to redirect ACL resources ie. the https: URLs to file:, data:, or blob: URLs, but no behaviour is defined by this specification.
    From bee3bd7321b5d95fb941d1f4f1996e47af3ce09c Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:30:27 +0200 Subject: [PATCH 258/310] Add security-privacy-review-sensor-data --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 6f5bebcd..49a6fd0f 100644 --- a/index.html +++ b/index.html @@ -1087,6 +1087,9 @@

    Security and Privacy Review

    Does this specification allow an origin to send data to the underlying platform?
    No. ACL resources are described within the framework of HTTP as RDF documents represented with the Turtle syntax. Servers may be able to redirect ACL resources ie. the https: URLs to file:, data:, or blob: URLs, but no behaviour is defined by this specification.
    + +
    Do features in this specification allow an origin access to sensors on a user’s device
    +
    No.
    From 32ad5621d4854ee73ea14394ee97801899baab1c Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:30:43 +0200 Subject: [PATCH 259/310] Add security-privacy-review-other-data --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 49a6fd0f..c136e312 100644 --- a/index.html +++ b/index.html @@ -1090,6 +1090,9 @@

    Security and Privacy Review

    Do features in this specification allow an origin access to sensors on a user’s device
    No.
    + +
    What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.
    +
    No detail about another origin’s state is exposed. As the association between a resource and its ACL resource is at the discretion of the resource server, they can be on different origins (see URI Origin). Similarly, when a server participates in the CORS protocol [FETCH], HTTP requests from different origins my be allowed. This feature does not add any new attack surface above and beyond what normal CORS requests, so no extra mitigation is deemed to be necessary.
    From e5fcf1ca0b6373739ae2686a98cc2b7a3aacbd88 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:30:59 +0200 Subject: [PATCH 260/310] Add security-privacy-review-string-to-script --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index c136e312..ac86a3cf 100644 --- a/index.html +++ b/index.html @@ -1093,6 +1093,9 @@

    Security and Privacy Review

    What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.
    No detail about another origin’s state is exposed. As the association between a resource and its ACL resource is at the discretion of the resource server, they can be on different origins (see URI Origin). Similarly, when a server participates in the CORS protocol [FETCH], HTTP requests from different origins my be allowed. This feature does not add any new attack surface above and beyond what normal CORS requests, so no extra mitigation is deemed to be necessary.
    + +
    Do features in this specification enable new script execution/loading mechanisms?
    +
    No.
    From f6c503bf61199d4bbb791e9c0bf4ac71461b962f Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:31:20 +0200 Subject: [PATCH 261/310] Add security-privacy-review-remote-device --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index ac86a3cf..a345cf8d 100644 --- a/index.html +++ b/index.html @@ -1096,6 +1096,9 @@

    Security and Privacy Review

    Do features in this specification enable new script execution/loading mechanisms?
    No.
    + +
    Do features in this specification allow an origin to access other devices?
    +
    No.
    From 0df341f284ce6a9b3ee69064fa1cd2566a8168ce Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:31:37 +0200 Subject: [PATCH 262/310] Add security-privacy-review-native-ui --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index a345cf8d..19d74c3b 100644 --- a/index.html +++ b/index.html @@ -1099,6 +1099,9 @@

    Security and Privacy Review

    Do features in this specification allow an origin to access other devices?
    No.
    + +
    Do features in this specification allow an origin some measure of control over a user agent’s native UI?
    +
    No.
    From 29d2f02f9d1606a7a3a139beb6fdbc820e999cae Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:32:35 +0200 Subject: [PATCH 263/310] Add security-privacy-review-temporary-id --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 19d74c3b..007abba0 100644 --- a/index.html +++ b/index.html @@ -1102,6 +1102,9 @@

    Security and Privacy Review

    Do features in this specification allow an origin some measure of control over a user agent’s native UI?
    No.
    + +
    What temporary identifiers do the features in this specification create or expose to the web?
    +
    None.
    From b8c6267bc795457dcd9f2afb0a4d06842ef8651e Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:32:54 +0200 Subject: [PATCH 264/310] Add security-privacy-review-first-third-party --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 007abba0..0cdc6ed5 100644 --- a/index.html +++ b/index.html @@ -1105,6 +1105,9 @@

    Security and Privacy Review

    What temporary identifiers do the features in this specification create or expose to the web?
    None.
    + +
    How does this specification distinguish between behaviour in first-party and third-party contexts?
    +
    When an HTTP request includes the Origin header (typical Web browsers use origin based security to warn servers), Authorizations are matched in context of the origin of the HTTP request in addition to requiring agent identification and allowed access modes. While the use of Origin is not intended as client identification, the implication is that unless servers have separate mechanisms to verify the original request made by an application, the Origin header’s field-value can differ. In order to distinguish social entities and clients supported by authentication protocols, an issue on client identification is filed.
    From ae7e2ec4408d7887c6730610813b0c5ea6e380bf Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:33:10 +0200 Subject: [PATCH 265/310] Add security-privacy-review-private-browsing --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index 0cdc6ed5..ebba4271 100644 --- a/index.html +++ b/index.html @@ -1108,6 +1108,9 @@

    Security and Privacy Review

    How does this specification distinguish between behaviour in first-party and third-party contexts?
    When an HTTP request includes the Origin header (typical Web browsers use origin based security to warn servers), Authorizations are matched in context of the origin of the HTTP request in addition to requiring agent identification and allowed access modes. While the use of Origin is not intended as client identification, the implication is that unless servers have separate mechanisms to verify the original request made by an application, the Origin header’s field-value can differ. In order to distinguish social entities and clients supported by authentication protocols, an issue on client identification is filed.
    + +
    How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
    +
    No different than browser’s 'normal' state.
    From 54809b17a0b086236202ab701995233fb7e65e99 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:33:22 +0200 Subject: [PATCH 266/310] Add security-privacy-review-considerations --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index ebba4271..eff6ad94 100644 --- a/index.html +++ b/index.html @@ -1111,6 +1111,9 @@

    Security and Privacy Review

    How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
    No different than browser’s 'normal' state.
    + +
    Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
    +
    Yes, in Security Considerations and Privacy Considerations.
    From 0c59327b3248df4e505c1c25a7b958f89b5064cc Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:33:35 +0200 Subject: [PATCH 267/310] Add security-privacy-review-relaxed-sop --- index.html | 3 +++ 1 file changed, 3 insertions(+) diff --git a/index.html b/index.html index eff6ad94..923bced5 100644 --- a/index.html +++ b/index.html @@ -1114,6 +1114,9 @@

    Security and Privacy Review

    Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
    Yes, in Security Considerations and Privacy Considerations.
    + +
    Do features in your specification enable origins to downgrade default security protections?
    +
    No.
    From a3adcb0d8e3a4f12558b6097ec9b0c2222070b82 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 12:48:53 +0200 Subject: [PATCH 268/310] Minor --- index.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index 923bced5..2db42bc6 100644 --- a/index.html +++ b/index.html @@ -138,7 +138,7 @@

    Web Access Control

    -

    Editor’s Draft, 2021-06-16

    +

    Editor’s Draft, 2021-06-17

    This version
    @@ -164,7 +164,7 @@

    Editor’s Draft, 2021-06-16

    Modified
    -
    +
    @@ -504,7 +504,7 @@

    ACL Resource Discovery

    @@ -652,7 +652,7 @@

    Note: Origin Considerations

    Issue: Client Identification

    -

    Distinguishing social entities and clients [issues/81].

    +

    Distinguishing social entities and clients: issues/81.

    From 9540095adcbf9ba5f04ef6072e500a7c6949f73c Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Thu, 17 Jun 2021 13:08:11 +0200 Subject: [PATCH 269/310] Update README --- README-v0.5.0.md | 713 ++++++++++++++++++++++++++++++++++++++++++++++ README.md | 727 ++--------------------------------------------- 2 files changed, 738 insertions(+), 702 deletions(-) create mode 100644 README-v0.5.0.md diff --git a/README-v0.5.0.md b/README-v0.5.0.md new file mode 100644 index 00000000..29ae614d --- /dev/null +++ b/README-v0.5.0.md @@ -0,0 +1,713 @@ +# Web Access Control (WAC) +[![](https://img.shields.io/badge/project-Solid-7C4DFF.svg?style=flat-square)](https://github.com/solid/solid) + +Web Access Control (WAC) specification (as used by the Solid project). It +is based on Tim Berners-Lee's May 2009 proposal, as originally captured, and +subsequently evolved by the community, at +[Web Access Control Wiki](https://www.w3.org/wiki/WebAccessControl). This spec +is a particular subset of the options and extensions described in the wiki. + +For use with [LDP](https://www.w3.org/TR/ldp/) (and [LDP +Next](https://www.w3.org/community/ldpnext/)) type systems, such as the +[Solid](https://github.com/solid/solid) project (see also the parent +[spec](https://github.com/solid/solid-spec)). + +**Current Spec version:** `v.0.5.0` (see [CHANGELOG.md](CHANGELOG.md)) + +## Table of Contents + +1. [Overview](#overview) +2. [Access Control List Resources](#access-control-list-resources) + * [Containers and Inherited ACLs](#containers-and-inherited-acls) + * [Individual Resource ACLs](#individual-resource-acls) + * [ACL Resource Location Discovery](#acl-resource-location-discovery) +3. [ACL Inheritance Algorithm](#acl-inheritance-algorithm) +4. [Representation Format](#representation-format) +5. [Example WAC Document](#example-wac-document) +6. [Describing Agents](#describing-agents) + * [Singular Agent](#singular-agent) + * [Groups](#groups-of-agents) + * [Public Access (all Agents)](#public-access-all-agents) + * [Anyone logged on (Authenticated Agents)](#authenticated-agents-anyone-logged-on) + * [Referring to Origins, i.e. Web Apps](#referring-to-origins-ie-web-apps) +7. [Referring to Resources](#referring-to-resources) +8. [Modes of Access](#modes-of-access) +9. [Default (Inherited) Authorizations](#default-inherited-authorizations) +10. [Not Supported by Design](#not-supported-by-design) + +## Overview + +Web Access Control (WAC) is a decentralized cross-domain access control system. +The main concepts should be familiar to developers, as they are similar to +access control schemes used in many file systems. It's concerned with giving +access to agents (users, groups and more) to perform various kinds of operations +(read, write, append, etc) on resources. WAC has several key features: + +1. The resources are identified by URLs, and can refer to any web documents or + resources. +2. It is *declarative* -- access control policies live in regular web documents, + which can be exported/backed easily, using the same mechanism as you would + for backing up the rest of your data. +3. Users and groups are also identified by URLs (specifically, by + [WebIDs](https://github.com/solid/solid-spec#identity)) +4. It is *cross-domain* -- all of its components, such as resources, agent + WebIDs, and even the documents containing the access control policies, can + potentially reside on separate domains. In other words, you can give access + to a resource on one site to users and groups hosted on another site. + +## Access Control List Resources + +In a system that uses Web Access Control, each web resource has a set of +*Authorization* statements describing: + +1. Who has access to that resource (that is, who the authorized *agents* are) +2. What types (or *modes*) of access they have + +These Authorizations are either explicitly set for an individual resource, or +(more often) inherited from that resource's parent folder or container. In +either case, the Authorization statements are placed into separate WAC +documents called *Access Control List Resources* (or simply *ACLs*). + +### Containers and Inherited ACLs + +The WAC system assumes that web documents are placed in hierarchical containers +or folders. For convenience, users do not have to specify permissions on each +individual resource -- they can simply set default permissions on a container using a +[`acl:default`](#default-inherited-authorizations) predicate and the exact container URI +as the object, and have all +of the resources in that container [inherit](#acl-inheritance-algorithm) those +permissions. + +### Individual Resource ACLs + +For fine-grained control, users can specify a set of permissions for each +individual resource (which overrides any permissions of its parent container). +See the [Example WAC Document](#example-wac-document) section to get an idea +for what that would look like. + +### ACL Resource Location Discovery + +Given a URL for an individual resource or container, a client can discover the +location of its corresponding ACL by performing a `HEAD` (or a `GET`) request +and parsing the `rel="acl"` link relation. + +Example request to discover the location of the ACL resource for a web document +at `http://example.org/docs/file1` is given below: + +```http +HEAD /docs/file1 HTTP/1.1 +Host: example.org + +HTTP/1.1 200 OK +Link: ; rel="acl" +``` + +The request to discover the location of a container's ACL resource looks +similar: + +```http +HEAD /docs/ HTTP/1.1 +Host: example.org + +HTTP/1.1 200 OK +Link: <.acl>; rel="acl" +``` + +Note that the `acl` link relation uses relative path URLs (the absolute URL of +the ACL resource in the above example would be `/docs/.acl`). + +Clients MUST NOT assume that the location of an ACL resource can be +deterministically derived from a document's URL. For example, given a document +with a URL of `/docs/file1`, clients cannot rely on the assumption that an ACL +resource exists at `/docs/file1.acl`, simply using `.acl` as a suffix. The +actual naming convention for ACL resources can differ for each individual +implementation (or even for each individual server). If one server locates the +ACL resource by appending the suffix `.acl`, another server could place the ACL +resources into a sub-container (locating it at `/docs/.acl/file1.acl` for the +example above). + +## ACL Schemas + +*This section is non-normative.* ( Issue: https://github.com/solid/specification/issues/169 ) + +The following schema excerpts use these namespace prefixes: +``` turtle +PREFIX acl: +PREFIX dc: +PREFIX vcard: +PREFIX xsd: +``` +### Authorization Schema +``` turtle +<#authShape> { + a [acl:Authorization] ; + acl:accessTo IRI ; + acl:mode [acl:Read acl:Write acl:Control]+ ; + ( acl:agent IRI ; + | acl:agentGroup @<#groupShape> + + ) ; +} +``` + +### Group Schema + +``` turtle +<#groupShape> { + a [vcard:Group] ; + vcard:hasUID IRI /^urn:uuid:/ ; + dc:created xsd:dateTime ? ; + dc:modified xsd:dateTime ? ; + vcard:hasMember IRI + ; +} +``` + +## ACL Inheritance Algorithm + +The following algorithm is used by servers to determine which ACL resources +(and hence which set of Authorization statements) apply to any given resource: + +1. Use the document's own ACL resource if it exists (in which case, stop here). +2. Otherwise, look for authorizations to inherit from the ACL of the document's + container. If those are found, stop here. +3. 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. +4. Failing that, move up the container hierarchy until you find a container + with an existing ACL file, which has some permissions to inherit. +5. The *root container* of a user's account MUST have an ACL resource specified. + (If all else fails, the search stops there.) + +It is considered an anti-pattern for a *client* to perform those steps, however. +A client may [discover](#acl-resource-location-discovery) and load a document's +individual resource (for example, for the purposes of editing its permissions). +If such a resource does not exist, a client SHOULD NOT search for, or interact +with, the inherited ACLs from an upstream container. + +### ACL Inheritance Algorithm Example + +*Note:* The server in the examples below is using the ACL naming convention of +appending `.acl` to resource URLs, for simplicity. As mentioned in the section +on [ACL discovery](#acl-resource-location-discovery), clients should not use +or assume any naming convention. + +A request (to read or write) has arrived for a document located at +`/documents/papers/paper1`. The server does as follows: + +1. First, it checks for the existence of an individual corresponding ACL + resource. (That is, it checks if `paper1.acl` exists.) If this individual ACL + resource exists, the server uses the Authorization statements in that ACL. No + other statements apply. +2. If no individual ACL exists, the server next checks to see if the + `/documents/papers/` container (in which the document resides) has its own + ACL resource (here, `/documents/papers/.acl`). If it finds that, the server + reads each authorization in the container's ACL, and if any of them contain an + `acl:default` predicate, the server will use them (as if they were + specified in `paper1.acl`). Again, if any such authorizations are found, the + process stops there and no other statements apply. +3. If the document's container has no ACL resource of its own, the search + continues upstream, in the *parent* container. The server would check if + `/documents/.acl` exists, and then `/.acl`, until it finds some authorizations + that contain `acl:default`. +4. Since the root container (here, `/`) MUST have its own ACL resource, the + server would use the authorizations there as a last resort. + +See the [Default (Inherited) Authorizations](#default-inherited-authorizations) +section below for an example of what a container's ACL resource might look like. + +## Representation Format + +The permissions in an ACL resource are stored in Linked Data format +([Turtle](http://www.w3.org/TR/turtle/) by default, but also available in other +serializations). + +*Note: A familiarity with Linked Data and +[RDF Concepts](http://www.w3.org/TR/rdf11-concepts/) helps with understanding +the terminology used in this spec.* + +WAC uses the [`http://www.w3.org/ns/auth/acl`](http://www.w3.org/ns/auth/acl) +ontology for its terms. Through the rest of the spec, the prefix `acl:` is +assumed to mean `@prefix acl: .` + +## Example WAC Document + +Below is an example ACL resource that specifies that Alice (as identified by her +WebID `https://alice.databox.me/profile/card#me`) has full access (Read, Write +and Control) to one of her web resources, located at +`https://alice.databox.me/docs/file1`. + +```ttl +# Contents of https://alice.databox.me/docs/file1.acl +@prefix acl: . + +<#authorization1> + a acl:Authorization; + acl:agent ; # Alice's WebID + acl:accessTo ; + acl:mode acl:Read, + acl:Write, + acl:Control. +``` + +## Describing Agents + +In WAC, we use the term *Agent* to identify *who* is allowed access to various +resources. In general, it is assumed to mean "someone or something that can +be referenced with a WebID", which covers users, groups (as well as companies +and organizations), and software agents such as applications or services. + +### Singular Agent + +An authorization may list any number of individual agents (that are being given +access) by using the `acl:agent` predicate, and using their WebID URIs as +objects. The example WAC document in a previous section grants access to Alice, +as denoted by her WebID URI, `https://alice.databox.me/profile/card#me`. + +### Groups of Agents + +To give access to a group of agents, use the `acl:agentGroup` predicate. +The object of an `agentGroup` statement is an instance of `vcard:Group`. +The WebIDs of group members are listed in it, using the +`vcard:hasMember` predicate. If a WebID is listed as member of that group, +it is given access. + +Example ACL resource, `shared-file1.acl`, containing a group permission: + +```ttl +# Contents of https://alice.databox.me/docs/shared-file1.acl +@prefix acl: . + +# Individual authorization - Alice has Read/Write/Control access +<#authorization1> + a acl:Authorization; + acl:accessTo ; + acl:mode acl:Read, + acl:Write, + acl:Control; + acl:agent . + +# Group authorization, giving Read/Write access to two groups, which are +# specified in the 'work-groups' document. +<#authorization2> + a acl:Authorization; + acl:accessTo ; + acl:mode acl:Read, + acl:Write; + acl:agentGroup ; + acl:agentGroup . +``` + +Corresponding `work-groups` Group Listing document: + +```ttl +# Contents of https://alice.example.com/work-groups +@prefix acl: . +@prefix dc: . +@prefix vcard: . +@prefix xsd: . + +<#Accounting> + a vcard:Group; + vcard:hasUID ; + dc:created "2013-09-11T07:18:19Z"^^xsd:dateTime; + dc:modified "2015-08-08T14:45:15Z"^^xsd:dateTime; + + # Accounting group members: + vcard:hasMember ; + vcard:hasMember . + +<#Management> + a vcard:Group; + vcard:hasUID ; + + # Management group members: + vcard:hasMember . +``` +[[test against schema](https://tinyurl.com/whcrhlo)] + +#### Group Listings - Implementation Notes + +When implementing support for `acl:agentGroup` and Group Listings, keep in mind +the following issues: + +1. Group Listings are regular documents (potentially each with its own `.acl`). +2. What authentication mechanism should the ACL checking engine use, when making + requests for Group Listing documents on other servers? +3. Infinite request loops during ACL resolution become possible, if an `.acl` + points to a group listing on a different server. +4. Therefore, for the moment, we suggest that all Group files which are used + for group ACLs are public. + +Possible future methods for a server to find out whether a given agent is a +member of a group are a matter for future research and possible addition here. + +### Public Access (All Agents) + +To specify that you're giving a particular mode of access to *everyone* +(for example, that your WebID Profile is public-readable), you can use +`acl:agentClass foaf:Agent` to denote that you're giving access to the class +of *all* agents (the general public). For example: + +```ttl +@prefix acl: . +@prefix foaf: . + +<#authorization2> + a acl:Authorization; + acl:agentClass foaf:Agent; # everyone + acl:mode acl:Read; # has Read-only access + acl:accessTo . # to the public profile +``` + +### Authenticated Agents (Anyone logged on) + +Authenticated access is a bit like public access +but it is not anonymous. Access is only given to people +who have logged on and provided a specific ID. +This allows the server to track the people who have used the resource. + +To specify that you're giving a particular mode of access to anyone *logged on* +(for example, that your collaborative page is open to anyone but you want to know who they are), +you can use +`acl:agentClass acl:AuthenticatedAgent` to denote that you're giving access to the class +of *all* authenticated agents. For example: + +```ttl +@prefix acl: . +@prefix foaf: . + +<#authorization2> + a acl:Authorization; + acl:agentClass acl:AuthenticatedAgent; # everyone + acl:mode acl:Read; # has Read-only access + acl:accessTo . # to the public profile +``` + +Note that this is a special case of `acl:agentClass` usage, since it doesn't +point to a Class Listing document that's meant to be de-referenced. + +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 access it within +that time as a group, and then later restrict access to that group, to prevent spam. + +### Referring to Origins, i.e. 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. + +``` +Origin: https://scripts.example.com:8080 +``` +(For background, see also [Backgrounder on Same Origin Policy and CORS](https://solid.github.io/web-access-control-spec/Background)) +Note that the origin comprises the protocol and the DNS and port but none of the path, +and no trailing slash. +All scripts running on the same origin are assumed to be run by the same +social entity, and so trusted to the same extent. + +*When an Origin header is present then BOTH the authenticated agent AND +the origin MUST be allowed access.* + +As both the user and the web app get to read or write (etc) the data, then they must BOTH +be trusted. This is the algorithm the server must go through. + + - If the requested mode is available to the public, then succeed `200 OK` with added CORS headers ACAO and ACAH. ** + - If the user is *not* logged on, then fail `401 Unauthenticated`. + - If the authenticated user is *not* allowed access, AND the class AuthenticatedAgent is not allowed access, then fail `403 User Unauthorized`. + - If the Origin header is not present, then succeed `200 OK`. + - If the Origin is allowed by the ACL, then succeed `200 OK` with added CORS headers ACAO and ACAH. + - (In future proposed) Look up the owner's webid(s) to check for trusted apps declared there, and if match, succeed `200 OK` with added CORS headers ACAO and ACAH. + - Fail `403 Origin Unauthorized`. + +Note it is a really good idea to make it clear both in the text of the status message and in the body of +the message the difference between the user not being allowed and the web app they are using +not being trusted. + +** Possible future alternative: Set ACAO header to `"*"` indicating that the document is public. This will though block in the browser any access made using credentials. + +#### Adding trusted web apps. + +** NB: this feature was only added recently and is still considered experimental. It's likely to change in the near future. ** + +The authorization of trusted web app is a running battle between readers and writers on the web, and malevolent 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 Origin header in the ACAO header, and also it must be done only when the web app in question actually is trustworthy. + +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? + + - A Web server MAY be configured such that a given list of origins is unconditionally trusted for incoming HTTP requests. The origin check is then bypassed for these domains, but all other access control mechanisms remain active. + - A specific ACL can be made to allow a given app to access a given file or folder of files, using `acl:origin`. + - Someone with `acl:Control` access to the resource could give in their profile a statement that they will allow users to use a given app. + +``` + <#me> acl:trustedApp [ acl:origin ; + acl:mode acl:Read, + acl:Append]. + <#me> acl:trustedApp [ acl:origin ; + acl:mode acl:Read, + acl:Write, + acl:Control]. +``` + +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) + +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. + +## Referring to Resources + +The `acl:accessTo` predicate specifies *which resources* you're giving access +to, using their exact URLs as the objects. + +### Referring to the ACL Resource Itself + +Since an ACL resource is a plain Web document in itself, what controls who +has access to *it*? While an ACL resource *could* in theory have its own +corresponding ACL document (for example, `file1.acl` controls access to `file1`, +and `file1.acl.acl` could potentially control access to `file1.acl`), one +quickly realizes that this recursion has to end somewhere. + +Instead, the [`acl:Control` access mode](#aclcontrol) is used (see below), to +specify who has access to alter (or even view) the ACL resource. + +## Modes of Access + +The `acl:mode` predicate denotes a class of operations that the agents can +perform on a resource. + +##### `acl:Read` +gives access to a class of operations that can be described as "Read +Access". In a typical REST API (such as the one used by +[Solid](https://github.com/solid/solid-spec#https-rest-api)), this includes +access to HTTP verbs `GET`, and `HEAD`. This also includes any kind of +QUERY or SEARCH verbs, if supported. + +##### `acl:Write` +gives access to a class of operations that can modify the resource. In a REST +API context, this would include `PUT`, `POST`, `DELETE` and `PATCH`. This also +includes the ability to perform SPARQL queries that perform updates, if those +are supported. + +##### `acl:Append` +gives a more limited ability to write to a resource -- Append-Only. This +generally includes the HTTP verb `POST`, although some implementations may +also extend this mode to cover non-overwriting `PUT`s, as well as the +`INSERT`-only portion of SPARQL-based `PATCH`es. A typical example of Append +mode usage would be a user's Inbox -- other agents can write (append) +notifications to the inbox, but cannot alter or read existing ones. + +##### `acl:Control` +is a special-case access mode that gives an agent the ability to *view and +modify the ACL of a resource*. Note that it doesn't automatically imply that the +agent has `acl:Read` or `acl:Write` access to the resource itself, just to its +corresponding ACL document. For example, a resource owner may disable their own +Write access (to prevent accidental over-writing of a resource by an app), but +be able to change their access levels at a later point (since they retain +`acl:Control` access). + +## Default (Inherited) Authorizations + +As previously mentioned, not every document needs its own individual ACL +resource and its own authorizations. Instead, one can can create an +Authorization for a container (in the container's own ACL resource), and then +use the `acl:default` predicate to denote that any resource within that +container will *inherit* that authorization. To put it another way, if an +Authorization contains `acl:default`, it will be applied *by default* to +any resource in that container. + +You can override the default inherited authorization for any resource by +creating an individual ACL just for that resource. + +An example ACL for a container would look something like: + +```ttl +# Contents of https://alice.databox.me/docs/.acl +@prefix acl: . + +<#authorization1> + a acl:Authorization; + + # These statements specify access rules for the /docs/ container itself: + acl:agent ; + acl:accessTo ; + acl:mode acl:Read, + acl:Write, + acl:Control; + + # default says: this authorization (the statements above) + # will also be inherited by any resource within that container + # that doesn't have its own ACL. + acl:default . +``` + +## See also + +[Background on CORS](https://solid.github.io/web-access-control-spec/Background) + +## Old discussion of access to group files + +##### Group Listings - Authentication of External Requests + +*This section is not normative* + +Group Listings via `acl:agentGroup` links introduce the possibility of an ACL +checking engine having to make requests to other servers. Given that access to +those external group listings can be protected, the question immediately arises: +By what mechanism should the ACL checking engine authenticate its request to +external servers? + +For example: Alice sends a GET request to a resource on the server +`https://a.com`. The ACL for that resource links to a group listing on an +external server, `https://b.com`. In the process of resolving the ACL, `a.com` +must send a request to `b.com`, to get that group listing. Note that it's not +Alice herself (or her application) that is sending that request, it's actually +`a.com` sending it (as part of trying to resolve its own ACL). How should +`a.com` authenticate itself? Does it have its own credentials, or does it have +a way to say that it's acting on behalf of Alice? Or both? + +There are several implementation possibilities: + +**No authentication**. The ACL checking engine sends *un-authenticated* requests +to external servers (to fetch group listings). This is the simplest method to +implement, but suffers from the limitation that those external group listings +need to be public-readable. THIS IS THE ONLY METHOD CURRENTLY IN USE + +**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. +(No, the original requester may not be allowed access -- you don't have to able to +access a group to be in it) +For a discussion of such a capability, +see the [Extending the WebID Protocol with Access +Delegation](http://bblfish.net/tmp/2012/08/05/WebID_Delegation.pdf) paper. +One thing to keep in mind is - if there are several hops (an ACL request chain +across more than one other domain), how does this change the delegation +confirmation algorithm? If the original server is explicitly authorized for +delegation by the user, what about the subsequent ones? + +**ID Tokens/Bearer Tokens**. If you're using a token-based authentication system +such as OpenID Connect or OAuth2 Bearer Tokens, it will also need to implement +the ability to delegate its ACL requests on behalf of the original user. See +[PoP/RFC7800](https://tools.ietf.org/html/rfc7800) and [Authorization Cross +Domain Code](http://openid.bitbucket.org/draft-acdc-01.html) specs for relevant +examples. + +##### Infinite Request Loops in Group Listings + +Since Group Listings (which are linked to from ACL resources using +the `acl:agentGroup` predicate) reside in regular documents, those documents +will have their very own `.acl` resources that restrict which users (or groups) +are allowed to access or change them. This fact, that `.acl`s point to Group +Listings, which can have `.acl`s of their own, which can potentially also point +to Group Listings, and so on, introduces the potential for infinite loops +during ACL resolution. + +Take the following situation with two different servers: + +``` +https://a.com https://b.com +------------- GET --------------- +group-listA <------ group-listB.acl + | ^ contains: + | | agentGroup + v GET | +group-listA.acl ------> group-listB + contains: + agentGroup +``` + +The access to `group-listA` is controlled by `group-listA.acl`. So far so good. +But if `group-listA.acl` contains any `acl:agentGroup` references to *another* +group listing (say, points to `group-listB`), one runs into potential danger. +In order to retrieve that other group listing, the ACL-checking engine on +`https://b.com` will need to check the rules in `group-listB.acl`. And if +`group-listB.acl` (by accident or malice) points back to `group-listA` a request +will be made to access `group-listA` on the original server `https://a.com`, +which would start an infinite cycle. + +To guard against these loops, implementers have several options: + +**A) Do not allow cross-domain Group Listing resolutions**. +The simplest to implement (but also the most limited) option is to disallow +cross-domain Group Listings resolution requests. That is, the ACL-checking code +could detect `agentGroup` links pointing to external servers during ACL +resolution time, and treat those uniformly (as errors, or as automatic "access +denied"). + +**B) Treat Group Listings as special cases**. +This assumes that the server has the ability to parse or query the contents of a +Group Listing document *before* resolving ACL checks -- a design decision that +some implementations may find unworkable. If the ACL checking engine can inspect +the contents of a document and know that it's a Group Listing, it can put in +various safeguards against loops. For example, it could validate ACLs when they +are created, and disallow external Group Listing links, similar to option A +above. Note that even if you wanted to ensure that no `.acl`s are allowed for +Group Listings, and that all such documents would be public-readable, you would +still have to be able to tell Group Listings apart from other documents, which +would imply special-case treatment. + +**C) Create and pass along a tracking/state parameter**. +For each ACL check request beyond the original server, it would be possible to +create a nonce-type tracking parameter and pass it along with each subsequent +request. Servers would then be able to use this parameter to detect loops on +each particular request chain. However, this is a spec-level solution (instead +of an individual implementation level), since all implementations have to play +along for this to work. See issue +[solid/solid#8](https://github.com/solid/solid/issues/8) for further +discussion). + +**D) Ignore this issue and rely on timeouts.** +It's worth noting that if an infinite group ACL loop was created by mistake, +this will soon become apparent since requests for that resource will time out. +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 ; + acl:mode acl:Read, + acl:Append]. + <#me> acl:trustsForUse [ acl:origin ; + 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 +in this spec by design. + +##### Resource Owners +WAC has no formal notion of a resource owner, and no explicit Owner access mode. +For convenience/UI purposes, it may be assumed that Owners are agents that have +Read, Write and Control permissions. + +##### acl:accessToClass +The predicate `acl:accessToClass` is not supported. + +##### Regular Expressions +The use of regular expressions in statements such as `acl:agentClass` is not +supported. diff --git a/README.md b/README.md index 29ae614d..1890fdd9 100644 --- a/README.md +++ b/README.md @@ -1,713 +1,36 @@ # Web Access Control (WAC) [![](https://img.shields.io/badge/project-Solid-7C4DFF.svg?style=flat-square)](https://github.com/solid/solid) -Web Access Control (WAC) specification (as used by the Solid project). It -is based on Tim Berners-Lee's May 2009 proposal, as originally captured, and -subsequently evolved by the community, at -[Web Access Control Wiki](https://www.w3.org/wiki/WebAccessControl). This spec -is a particular subset of the options and extensions described in the wiki. +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. -For use with [LDP](https://www.w3.org/TR/ldp/) (and [LDP -Next](https://www.w3.org/community/ldpnext/)) type systems, such as the -[Solid](https://github.com/solid/solid) project (see also the parent -[spec](https://github.com/solid/solid-spec)). +WAC (as used by the [Solid Project](https://solidproject.org/)) is based on +Tim Berners-Lee's May 2009 proposal, as originally captured, and subsequently +evolved by the community, +at [Web Access Control Wiki](https://www.w3.org/wiki/WebAccessControl). +This spec is a particular subset of the options and extensions described in +the wiki, as well as implementation experience. -**Current Spec version:** `v.0.5.0` (see [CHANGELOG.md](CHANGELOG.md)) +Implementations are strongly encouraged to use existing approaches that +provide an extension of the rules of Linked Data, eg. +[Solid Protocol](https://solidproject.org/TR/protocol), +[LDP](https://www.w3.org/TR/ldp/). -## Table of Contents +## Current version +[Editor’s Draft](https://solid.github.io/web-access-control-spec/) -1. [Overview](#overview) -2. [Access Control List Resources](#access-control-list-resources) - * [Containers and Inherited ACLs](#containers-and-inherited-acls) - * [Individual Resource ACLs](#individual-resource-acls) - * [ACL Resource Location Discovery](#acl-resource-location-discovery) -3. [ACL Inheritance Algorithm](#acl-inheritance-algorithm) -4. [Representation Format](#representation-format) -5. [Example WAC Document](#example-wac-document) -6. [Describing Agents](#describing-agents) - * [Singular Agent](#singular-agent) - * [Groups](#groups-of-agents) - * [Public Access (all Agents)](#public-access-all-agents) - * [Anyone logged on (Authenticated Agents)](#authenticated-agents-anyone-logged-on) - * [Referring to Origins, i.e. Web Apps](#referring-to-origins-ie-web-apps) -7. [Referring to Resources](#referring-to-resources) -8. [Modes of Access](#modes-of-access) -9. [Default (Inherited) Authorizations](#default-inherited-authorizations) -10. [Not Supported by Design](#not-supported-by-design) +## Participation -## Overview +All substantive contributors to any Work Items must be members of the Solid +CG. It’s easy to [join the CG](https://www.w3.org/community/solid/join) if +you’d like to contribute. -Web Access Control (WAC) is a decentralized cross-domain access control system. -The main concepts should be familiar to developers, as they are similar to -access control schemes used in many file systems. It's concerned with giving -access to agents (users, groups and more) to perform various kinds of operations -(read, write, append, etc) on resources. WAC has several key features: +Anyone can join the [chat](https://gitter.im/solid/specification). -1. The resources are identified by URLs, and can refer to any web documents or - resources. -2. It is *declarative* -- access control policies live in regular web documents, - which can be exported/backed easily, using the same mechanism as you would - for backing up the rest of your data. -3. Users and groups are also identified by URLs (specifically, by - [WebIDs](https://github.com/solid/solid-spec#identity)) -4. It is *cross-domain* -- all of its components, such as resources, agent - WebIDs, and even the documents containing the access control policies, can - potentially reside on separate domains. In other words, you can give access - to a resource on one site to users and groups hosted on another site. +## Code of Conduct -## Access Control List Resources - -In a system that uses Web Access Control, each web resource has a set of -*Authorization* statements describing: - -1. Who has access to that resource (that is, who the authorized *agents* are) -2. What types (or *modes*) of access they have - -These Authorizations are either explicitly set for an individual resource, or -(more often) inherited from that resource's parent folder or container. In -either case, the Authorization statements are placed into separate WAC -documents called *Access Control List Resources* (or simply *ACLs*). - -### Containers and Inherited ACLs - -The WAC system assumes that web documents are placed in hierarchical containers -or folders. For convenience, users do not have to specify permissions on each -individual resource -- they can simply set default permissions on a container using a -[`acl:default`](#default-inherited-authorizations) predicate and the exact container URI -as the object, and have all -of the resources in that container [inherit](#acl-inheritance-algorithm) those -permissions. - -### Individual Resource ACLs - -For fine-grained control, users can specify a set of permissions for each -individual resource (which overrides any permissions of its parent container). -See the [Example WAC Document](#example-wac-document) section to get an idea -for what that would look like. - -### ACL Resource Location Discovery - -Given a URL for an individual resource or container, a client can discover the -location of its corresponding ACL by performing a `HEAD` (or a `GET`) request -and parsing the `rel="acl"` link relation. - -Example request to discover the location of the ACL resource for a web document -at `http://example.org/docs/file1` is given below: - -```http -HEAD /docs/file1 HTTP/1.1 -Host: example.org - -HTTP/1.1 200 OK -Link: ; rel="acl" -``` - -The request to discover the location of a container's ACL resource looks -similar: - -```http -HEAD /docs/ HTTP/1.1 -Host: example.org - -HTTP/1.1 200 OK -Link: <.acl>; rel="acl" -``` - -Note that the `acl` link relation uses relative path URLs (the absolute URL of -the ACL resource in the above example would be `/docs/.acl`). - -Clients MUST NOT assume that the location of an ACL resource can be -deterministically derived from a document's URL. For example, given a document -with a URL of `/docs/file1`, clients cannot rely on the assumption that an ACL -resource exists at `/docs/file1.acl`, simply using `.acl` as a suffix. The -actual naming convention for ACL resources can differ for each individual -implementation (or even for each individual server). If one server locates the -ACL resource by appending the suffix `.acl`, another server could place the ACL -resources into a sub-container (locating it at `/docs/.acl/file1.acl` for the -example above). - -## ACL Schemas - -*This section is non-normative.* ( Issue: https://github.com/solid/specification/issues/169 ) - -The following schema excerpts use these namespace prefixes: -``` turtle -PREFIX acl: -PREFIX dc: -PREFIX vcard: -PREFIX xsd: -``` -### Authorization Schema -``` turtle -<#authShape> { - a [acl:Authorization] ; - acl:accessTo IRI ; - acl:mode [acl:Read acl:Write acl:Control]+ ; - ( acl:agent IRI ; - | acl:agentGroup @<#groupShape> + - ) ; -} -``` - -### Group Schema - -``` turtle -<#groupShape> { - a [vcard:Group] ; - vcard:hasUID IRI /^urn:uuid:/ ; - dc:created xsd:dateTime ? ; - dc:modified xsd:dateTime ? ; - vcard:hasMember IRI + ; -} -``` - -## ACL Inheritance Algorithm - -The following algorithm is used by servers to determine which ACL resources -(and hence which set of Authorization statements) apply to any given resource: - -1. Use the document's own ACL resource if it exists (in which case, stop here). -2. Otherwise, look for authorizations to inherit from the ACL of the document's - container. If those are found, stop here. -3. 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. -4. Failing that, move up the container hierarchy until you find a container - with an existing ACL file, which has some permissions to inherit. -5. The *root container* of a user's account MUST have an ACL resource specified. - (If all else fails, the search stops there.) - -It is considered an anti-pattern for a *client* to perform those steps, however. -A client may [discover](#acl-resource-location-discovery) and load a document's -individual resource (for example, for the purposes of editing its permissions). -If such a resource does not exist, a client SHOULD NOT search for, or interact -with, the inherited ACLs from an upstream container. - -### ACL Inheritance Algorithm Example - -*Note:* The server in the examples below is using the ACL naming convention of -appending `.acl` to resource URLs, for simplicity. As mentioned in the section -on [ACL discovery](#acl-resource-location-discovery), clients should not use -or assume any naming convention. - -A request (to read or write) has arrived for a document located at -`/documents/papers/paper1`. The server does as follows: - -1. First, it checks for the existence of an individual corresponding ACL - resource. (That is, it checks if `paper1.acl` exists.) If this individual ACL - resource exists, the server uses the Authorization statements in that ACL. No - other statements apply. -2. If no individual ACL exists, the server next checks to see if the - `/documents/papers/` container (in which the document resides) has its own - ACL resource (here, `/documents/papers/.acl`). If it finds that, the server - reads each authorization in the container's ACL, and if any of them contain an - `acl:default` predicate, the server will use them (as if they were - specified in `paper1.acl`). Again, if any such authorizations are found, the - process stops there and no other statements apply. -3. If the document's container has no ACL resource of its own, the search - continues upstream, in the *parent* container. The server would check if - `/documents/.acl` exists, and then `/.acl`, until it finds some authorizations - that contain `acl:default`. -4. Since the root container (here, `/`) MUST have its own ACL resource, the - server would use the authorizations there as a last resort. - -See the [Default (Inherited) Authorizations](#default-inherited-authorizations) -section below for an example of what a container's ACL resource might look like. - -## Representation Format - -The permissions in an ACL resource are stored in Linked Data format -([Turtle](http://www.w3.org/TR/turtle/) by default, but also available in other -serializations). - -*Note: A familiarity with Linked Data and -[RDF Concepts](http://www.w3.org/TR/rdf11-concepts/) helps with understanding -the terminology used in this spec.* - -WAC uses the [`http://www.w3.org/ns/auth/acl`](http://www.w3.org/ns/auth/acl) -ontology for its terms. Through the rest of the spec, the prefix `acl:` is -assumed to mean `@prefix acl: .` - -## Example WAC Document - -Below is an example ACL resource that specifies that Alice (as identified by her -WebID `https://alice.databox.me/profile/card#me`) has full access (Read, Write -and Control) to one of her web resources, located at -`https://alice.databox.me/docs/file1`. - -```ttl -# Contents of https://alice.databox.me/docs/file1.acl -@prefix acl: . - -<#authorization1> - a acl:Authorization; - acl:agent ; # Alice's WebID - acl:accessTo ; - acl:mode acl:Read, - acl:Write, - acl:Control. -``` - -## Describing Agents - -In WAC, we use the term *Agent* to identify *who* is allowed access to various -resources. In general, it is assumed to mean "someone or something that can -be referenced with a WebID", which covers users, groups (as well as companies -and organizations), and software agents such as applications or services. - -### Singular Agent - -An authorization may list any number of individual agents (that are being given -access) by using the `acl:agent` predicate, and using their WebID URIs as -objects. The example WAC document in a previous section grants access to Alice, -as denoted by her WebID URI, `https://alice.databox.me/profile/card#me`. - -### Groups of Agents - -To give access to a group of agents, use the `acl:agentGroup` predicate. -The object of an `agentGroup` statement is an instance of `vcard:Group`. -The WebIDs of group members are listed in it, using the -`vcard:hasMember` predicate. If a WebID is listed as member of that group, -it is given access. - -Example ACL resource, `shared-file1.acl`, containing a group permission: - -```ttl -# Contents of https://alice.databox.me/docs/shared-file1.acl -@prefix acl: . - -# Individual authorization - Alice has Read/Write/Control access -<#authorization1> - a acl:Authorization; - acl:accessTo ; - acl:mode acl:Read, - acl:Write, - acl:Control; - acl:agent . - -# Group authorization, giving Read/Write access to two groups, which are -# specified in the 'work-groups' document. -<#authorization2> - a acl:Authorization; - acl:accessTo ; - acl:mode acl:Read, - acl:Write; - acl:agentGroup ; - acl:agentGroup . -``` - -Corresponding `work-groups` Group Listing document: - -```ttl -# Contents of https://alice.example.com/work-groups -@prefix acl: . -@prefix dc: . -@prefix vcard: . -@prefix xsd: . - -<#Accounting> - a vcard:Group; - vcard:hasUID ; - dc:created "2013-09-11T07:18:19Z"^^xsd:dateTime; - dc:modified "2015-08-08T14:45:15Z"^^xsd:dateTime; - - # Accounting group members: - vcard:hasMember ; - vcard:hasMember . - -<#Management> - a vcard:Group; - vcard:hasUID ; - - # Management group members: - vcard:hasMember . -``` -[[test against schema](https://tinyurl.com/whcrhlo)] - -#### Group Listings - Implementation Notes - -When implementing support for `acl:agentGroup` and Group Listings, keep in mind -the following issues: - -1. Group Listings are regular documents (potentially each with its own `.acl`). -2. What authentication mechanism should the ACL checking engine use, when making - requests for Group Listing documents on other servers? -3. Infinite request loops during ACL resolution become possible, if an `.acl` - points to a group listing on a different server. -4. Therefore, for the moment, we suggest that all Group files which are used - for group ACLs are public. - -Possible future methods for a server to find out whether a given agent is a -member of a group are a matter for future research and possible addition here. - -### Public Access (All Agents) - -To specify that you're giving a particular mode of access to *everyone* -(for example, that your WebID Profile is public-readable), you can use -`acl:agentClass foaf:Agent` to denote that you're giving access to the class -of *all* agents (the general public). For example: - -```ttl -@prefix acl: . -@prefix foaf: . - -<#authorization2> - a acl:Authorization; - acl:agentClass foaf:Agent; # everyone - acl:mode acl:Read; # has Read-only access - acl:accessTo . # to the public profile -``` - -### Authenticated Agents (Anyone logged on) - -Authenticated access is a bit like public access -but it is not anonymous. Access is only given to people -who have logged on and provided a specific ID. -This allows the server to track the people who have used the resource. - -To specify that you're giving a particular mode of access to anyone *logged on* -(for example, that your collaborative page is open to anyone but you want to know who they are), -you can use -`acl:agentClass acl:AuthenticatedAgent` to denote that you're giving access to the class -of *all* authenticated agents. For example: - -```ttl -@prefix acl: . -@prefix foaf: . - -<#authorization2> - a acl:Authorization; - acl:agentClass acl:AuthenticatedAgent; # everyone - acl:mode acl:Read; # has Read-only access - acl:accessTo . # to the public profile -``` - -Note that this is a special case of `acl:agentClass` usage, since it doesn't -point to a Class Listing document that's meant to be de-referenced. - -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 access it within -that time as a group, and then later restrict access to that group, to prevent spam. - -### Referring to Origins, i.e. 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. - -``` -Origin: https://scripts.example.com:8080 -``` -(For background, see also [Backgrounder on Same Origin Policy and CORS](https://solid.github.io/web-access-control-spec/Background)) -Note that the origin comprises the protocol and the DNS and port but none of the path, -and no trailing slash. -All scripts running on the same origin are assumed to be run by the same -social entity, and so trusted to the same extent. - -*When an Origin header is present then BOTH the authenticated agent AND -the origin MUST be allowed access.* - -As both the user and the web app get to read or write (etc) the data, then they must BOTH -be trusted. This is the algorithm the server must go through. - - - If the requested mode is available to the public, then succeed `200 OK` with added CORS headers ACAO and ACAH. ** - - If the user is *not* logged on, then fail `401 Unauthenticated`. - - If the authenticated user is *not* allowed access, AND the class AuthenticatedAgent is not allowed access, then fail `403 User Unauthorized`. - - If the Origin header is not present, then succeed `200 OK`. - - If the Origin is allowed by the ACL, then succeed `200 OK` with added CORS headers ACAO and ACAH. - - (In future proposed) Look up the owner's webid(s) to check for trusted apps declared there, and if match, succeed `200 OK` with added CORS headers ACAO and ACAH. - - Fail `403 Origin Unauthorized`. - -Note it is a really good idea to make it clear both in the text of the status message and in the body of -the message the difference between the user not being allowed and the web app they are using -not being trusted. - -** Possible future alternative: Set ACAO header to `"*"` indicating that the document is public. This will though block in the browser any access made using credentials. - -#### Adding trusted web apps. - -** NB: this feature was only added recently and is still considered experimental. It's likely to change in the near future. ** - -The authorization of trusted web app is a running battle between readers and writers on the web, and malevolent 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 Origin header in the ACAO header, and also it must be done only when the web app in question actually is trustworthy. - -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? - - - A Web server MAY be configured such that a given list of origins is unconditionally trusted for incoming HTTP requests. The origin check is then bypassed for these domains, but all other access control mechanisms remain active. - - A specific ACL can be made to allow a given app to access a given file or folder of files, using `acl:origin`. - - Someone with `acl:Control` access to the resource could give in their profile a statement that they will allow users to use a given app. - -``` - <#me> acl:trustedApp [ acl:origin ; - acl:mode acl:Read, - acl:Append]. - <#me> acl:trustedApp [ acl:origin ; - acl:mode acl:Read, - acl:Write, - acl:Control]. -``` - -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) - -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. - -## Referring to Resources - -The `acl:accessTo` predicate specifies *which resources* you're giving access -to, using their exact URLs as the objects. - -### Referring to the ACL Resource Itself - -Since an ACL resource is a plain Web document in itself, what controls who -has access to *it*? While an ACL resource *could* in theory have its own -corresponding ACL document (for example, `file1.acl` controls access to `file1`, -and `file1.acl.acl` could potentially control access to `file1.acl`), one -quickly realizes that this recursion has to end somewhere. - -Instead, the [`acl:Control` access mode](#aclcontrol) is used (see below), to -specify who has access to alter (or even view) the ACL resource. - -## Modes of Access - -The `acl:mode` predicate denotes a class of operations that the agents can -perform on a resource. - -##### `acl:Read` -gives access to a class of operations that can be described as "Read -Access". In a typical REST API (such as the one used by -[Solid](https://github.com/solid/solid-spec#https-rest-api)), this includes -access to HTTP verbs `GET`, and `HEAD`. This also includes any kind of -QUERY or SEARCH verbs, if supported. - -##### `acl:Write` -gives access to a class of operations that can modify the resource. In a REST -API context, this would include `PUT`, `POST`, `DELETE` and `PATCH`. This also -includes the ability to perform SPARQL queries that perform updates, if those -are supported. - -##### `acl:Append` -gives a more limited ability to write to a resource -- Append-Only. This -generally includes the HTTP verb `POST`, although some implementations may -also extend this mode to cover non-overwriting `PUT`s, as well as the -`INSERT`-only portion of SPARQL-based `PATCH`es. A typical example of Append -mode usage would be a user's Inbox -- other agents can write (append) -notifications to the inbox, but cannot alter or read existing ones. - -##### `acl:Control` -is a special-case access mode that gives an agent the ability to *view and -modify the ACL of a resource*. Note that it doesn't automatically imply that the -agent has `acl:Read` or `acl:Write` access to the resource itself, just to its -corresponding ACL document. For example, a resource owner may disable their own -Write access (to prevent accidental over-writing of a resource by an app), but -be able to change their access levels at a later point (since they retain -`acl:Control` access). - -## Default (Inherited) Authorizations - -As previously mentioned, not every document needs its own individual ACL -resource and its own authorizations. Instead, one can can create an -Authorization for a container (in the container's own ACL resource), and then -use the `acl:default` predicate to denote that any resource within that -container will *inherit* that authorization. To put it another way, if an -Authorization contains `acl:default`, it will be applied *by default* to -any resource in that container. - -You can override the default inherited authorization for any resource by -creating an individual ACL just for that resource. - -An example ACL for a container would look something like: - -```ttl -# Contents of https://alice.databox.me/docs/.acl -@prefix acl: . - -<#authorization1> - a acl:Authorization; - - # These statements specify access rules for the /docs/ container itself: - acl:agent ; - acl:accessTo ; - acl:mode acl:Read, - acl:Write, - acl:Control; - - # default says: this authorization (the statements above) - # will also be inherited by any resource within that container - # that doesn't have its own ACL. - acl:default . -``` - -## See also - -[Background on CORS](https://solid.github.io/web-access-control-spec/Background) - -## Old discussion of access to group files - -##### Group Listings - Authentication of External Requests - -*This section is not normative* - -Group Listings via `acl:agentGroup` links introduce the possibility of an ACL -checking engine having to make requests to other servers. Given that access to -those external group listings can be protected, the question immediately arises: -By what mechanism should the ACL checking engine authenticate its request to -external servers? - -For example: Alice sends a GET request to a resource on the server -`https://a.com`. The ACL for that resource links to a group listing on an -external server, `https://b.com`. In the process of resolving the ACL, `a.com` -must send a request to `b.com`, to get that group listing. Note that it's not -Alice herself (or her application) that is sending that request, it's actually -`a.com` sending it (as part of trying to resolve its own ACL). How should -`a.com` authenticate itself? Does it have its own credentials, or does it have -a way to say that it's acting on behalf of Alice? Or both? - -There are several implementation possibilities: - -**No authentication**. The ACL checking engine sends *un-authenticated* requests -to external servers (to fetch group listings). This is the simplest method to -implement, but suffers from the limitation that those external group listings -need to be public-readable. THIS IS THE ONLY METHOD CURRENTLY IN USE - -**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. -(No, the original requester may not be allowed access -- you don't have to able to -access a group to be in it) -For a discussion of such a capability, -see the [Extending the WebID Protocol with Access -Delegation](http://bblfish.net/tmp/2012/08/05/WebID_Delegation.pdf) paper. -One thing to keep in mind is - if there are several hops (an ACL request chain -across more than one other domain), how does this change the delegation -confirmation algorithm? If the original server is explicitly authorized for -delegation by the user, what about the subsequent ones? - -**ID Tokens/Bearer Tokens**. If you're using a token-based authentication system -such as OpenID Connect or OAuth2 Bearer Tokens, it will also need to implement -the ability to delegate its ACL requests on behalf of the original user. See -[PoP/RFC7800](https://tools.ietf.org/html/rfc7800) and [Authorization Cross -Domain Code](http://openid.bitbucket.org/draft-acdc-01.html) specs for relevant -examples. - -##### Infinite Request Loops in Group Listings - -Since Group Listings (which are linked to from ACL resources using -the `acl:agentGroup` predicate) reside in regular documents, those documents -will have their very own `.acl` resources that restrict which users (or groups) -are allowed to access or change them. This fact, that `.acl`s point to Group -Listings, which can have `.acl`s of their own, which can potentially also point -to Group Listings, and so on, introduces the potential for infinite loops -during ACL resolution. - -Take the following situation with two different servers: - -``` -https://a.com https://b.com -------------- GET --------------- -group-listA <------ group-listB.acl - | ^ contains: - | | agentGroup - v GET | -group-listA.acl ------> group-listB - contains: - agentGroup -``` - -The access to `group-listA` is controlled by `group-listA.acl`. So far so good. -But if `group-listA.acl` contains any `acl:agentGroup` references to *another* -group listing (say, points to `group-listB`), one runs into potential danger. -In order to retrieve that other group listing, the ACL-checking engine on -`https://b.com` will need to check the rules in `group-listB.acl`. And if -`group-listB.acl` (by accident or malice) points back to `group-listA` a request -will be made to access `group-listA` on the original server `https://a.com`, -which would start an infinite cycle. - -To guard against these loops, implementers have several options: - -**A) Do not allow cross-domain Group Listing resolutions**. -The simplest to implement (but also the most limited) option is to disallow -cross-domain Group Listings resolution requests. That is, the ACL-checking code -could detect `agentGroup` links pointing to external servers during ACL -resolution time, and treat those uniformly (as errors, or as automatic "access -denied"). - -**B) Treat Group Listings as special cases**. -This assumes that the server has the ability to parse or query the contents of a -Group Listing document *before* resolving ACL checks -- a design decision that -some implementations may find unworkable. If the ACL checking engine can inspect -the contents of a document and know that it's a Group Listing, it can put in -various safeguards against loops. For example, it could validate ACLs when they -are created, and disallow external Group Listing links, similar to option A -above. Note that even if you wanted to ensure that no `.acl`s are allowed for -Group Listings, and that all such documents would be public-readable, you would -still have to be able to tell Group Listings apart from other documents, which -would imply special-case treatment. - -**C) Create and pass along a tracking/state parameter**. -For each ACL check request beyond the original server, it would be possible to -create a nonce-type tracking parameter and pass it along with each subsequent -request. Servers would then be able to use this parameter to detect loops on -each particular request chain. However, this is a spec-level solution (instead -of an individual implementation level), since all implementations have to play -along for this to work. See issue -[solid/solid#8](https://github.com/solid/solid/issues/8) for further -discussion). - -**D) Ignore this issue and rely on timeouts.** -It's worth noting that if an infinite group ACL loop was created by mistake, -this will soon become apparent since requests for that resource will time out. -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 ; - acl:mode acl:Read, - acl:Append]. - <#me> acl:trustsForUse [ acl:origin ; - 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 -in this spec by design. - -##### Resource Owners -WAC has no formal notion of a resource owner, and no explicit Owner access mode. -For convenience/UI purposes, it may be assumed that Owners are agents that have -Read, Write and Control permissions. - -##### acl:accessToClass -The predicate `acl:accessToClass` is not supported. - -##### Regular Expressions -The use of regular expressions in statements such as `acl:agentClass` is not -supported. +All work and communication within the Solid CG is covered by the +[Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md) +as well as the +[Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). From 666308a60e956accb5b1e9d5ae4b7ba7685d1fb3 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 11:39:23 +0200 Subject: [PATCH 270/310] Fix example query --- index.html | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 2db42bc6..1c486ace 100644 --- a/index.html +++ b/index.html @@ -862,9 +862,13 @@

    Authorization Matching

    } UNION { - ?authorization acl:mode ?mode . + ?authorization + a acl:Authorization ; + acl:default $containerResource ; + acl:agentClass $agentClass ; + acl:mode ?mode . GRAPH $aclOntologyResource { - $requiredMode rdfs:subClassOf* ?mode . + $requiredMode rdfs:subClassOf+ ?mode . } } } From 2bef8a1cfb840f2e56b89f749dbeac9c9742ff04 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 12:15:55 +0200 Subject: [PATCH 271/310] Minor --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 1c486ace..4bf25fae 100644 --- a/index.html +++ b/index.html @@ -138,7 +138,7 @@

    Web Access Control

    -

    Editor’s Draft, 2021-06-17

    +

    Editor’s Draft, 2021-06-18

    This version
    @@ -164,7 +164,7 @@

    Editor’s Draft, 2021-06-17

    Modified
    -
    +
    @@ -504,7 +504,7 @@

    ACL Resource Discovery

    From db1dc81f3efed5bc1c1f4ae5214c85f04858d4a5 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 12:20:25 +0200 Subject: [PATCH 272/310] Fix nav numbering --- index.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/index.html b/index.html index 4bf25fae..59c6122d 100644 --- a/index.html +++ b/index.html @@ -341,13 +341,13 @@

    Table of Contents

  • - 12 Considerations + 8 Considerations
      -
    1. 12.1 Security Considerations
      2. -
    2. 12.2 Privacy Considerations
      3. -
    3. 12.3 Accessibility Considerations
      4. -
    4. 12.4 Internationalization Considerations
      5. -
    5. 12.5 Security and Privacy Review
      6. +
    6. 8.1 Security Considerations
      7. +
    7. 8.2 Privacy Considerations
      8. +
    8. 8.3 Accessibility Considerations
      9. +
    9. 8.4 Internationalization Considerations
      10. +
    10. 8.5 Security and Privacy Review
  • From 74cbbdc298c462daa2fcb84fc80472ea5ba3dabd Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 16:39:10 +0200 Subject: [PATCH 273/310] Reinclude rdf-schema in namespaces --- index.html | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 59c6122d..2e570bea 100644 --- a/index.html +++ b/index.html @@ -449,6 +449,11 @@

    Namespaces

    + + rdf + http://www.w3.org/1999/02/22-rdf-syntax-ns# + [RDF-SCHEMA] + acl http://www.w3.org/ns/auth/acl# @@ -457,12 +462,12 @@

    Namespaces

    foaf http://xmlns.com/foaf/0.1/ - [Friend of a Friend (FOAF) vocabulary] + [FOAF] vcard http://www.w3.org/2006/vcard/ns# - [vCard Ontology] + [VCARD-RDF] From 0b9b32ddfd40285bef3547c7166c8114fe9ea8a0 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 16:46:11 +0200 Subject: [PATCH 274/310] Wrap prefixes with code --- index.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index 2e570bea..613387f4 100644 --- a/index.html +++ b/index.html @@ -450,22 +450,22 @@

    Namespaces

    - rdf + rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# [RDF-SCHEMA] - acl + acl http://www.w3.org/ns/auth/acl# - ACL Ontology + ACL ontology - foaf + foaf http://xmlns.com/foaf/0.1/ [FOAF] - vcard + vcard http://www.w3.org/2006/vcard/ns# [VCARD-RDF] From 9437c922cb3870b106525b33376643e2ea91f80c Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 16:49:09 +0200 Subject: [PATCH 275/310] List only MUST and MUST NOT in Conformance --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 613387f4..adfa2052 100644 --- a/index.html +++ b/index.html @@ -479,7 +479,7 @@

    Conformance

    All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.

    -

    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

    +

    The key words “MUST” and “MUST NOT” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

    • From 42bbf5a7994d416c2adb461a2cbd3e05c577347a Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 16:49:45 +0200 Subject: [PATCH 276/310] Clarify parsing algorithm for field-value --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index adfa2052..bd9265a5 100644 --- a/index.html +++ b/index.html @@ -940,7 +940,7 @@

    Issue: WAC-Allow Access Modes

    access-mode corresponds to the Access Modes as defined in the ACL ontology (acl:Read, acl:Write, acl:Append, acl:Control).

    -

    Clients’ parsing algorithm for the WAC-Allow header should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (permission groups and access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    +

    Clients’ parsing algorithm for WAC-Allow header's field-value should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (permission groups and access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    Source: issues/171, issues/170, issues/181, 60101295d8bdab47395e6775, pull/210

    From 510a5f16a4dcfb5415f576bbc3a4ac0ede1e5ebd Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 16:54:13 +0200 Subject: [PATCH 277/310] Clarify Control operation including view --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index bd9265a5..0cefde35 100644 --- a/index.html +++ b/index.html @@ -737,7 +737,7 @@

    Reading and Writing Resources

    Working alongside HTTP Interactions, WAC enables a standard set of operations which can be applied to different resource types for a given request based on the set of access modes which control those operations:

    -

    Generally, read operations attempt to know about the existence of a resource or view the contents of a resource. Write operations attempt to create, delete, or modify resources. Append operations attempt to create resources or add information to resources. Control operations attempt to create, delete, or modify ACL resources.

    +

    Generally, read operations attempt to know about the existence of a resource or view the contents of a resource. Write operations attempt to create, delete, or modify resources. Append operations attempt to create resources or add information to resources. Control operations attempt to view, create, delete, or modify ACL resources.

    As container resources and member resources are hierarchically organised, requests to perform operations on resources are in the context of the applicable container (effective ACL resource).

    From 09aa7dbc67370ff916bdf6622afbc965a0101f49 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 16:55:54 +0200 Subject: [PATCH 278/310] Link to effective-acl-resource --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 0cefde35..0ecc1eb2 100644 --- a/index.html +++ b/index.html @@ -739,7 +739,7 @@

    Reading and Writing Resources

    Generally, read operations attempt to know about the existence of a resource or view the contents of a resource. Write operations attempt to create, delete, or modify resources. Append operations attempt to create resources or add information to resources. Control operations attempt to view, create, delete, or modify ACL resources.

    -

    As container resources and member resources are hierarchically organised, requests to perform operations on resources are in the context of the applicable container (effective ACL resource).

    +

    As container resources and member resources are hierarchically organised, requests to perform operations on resources are in the context of the applicable container (Effective ACL Resource).

    When an operation requests to read a resource, the server MUST match an Authorization allowing the acl:Read access privilege on the resource.

    From c970116c15751faf51d1b892b7b58302982dc875 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 16:56:59 +0200 Subject: [PATCH 279/310] Remove 'see ' --- index.html | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/index.html b/index.html index 0ecc1eb2..f5932d2f 100644 --- a/index.html +++ b/index.html @@ -544,7 +544,7 @@

    ACL Resource Representation

    Servers MUST accept an HTTP GET request targeting an ACL resource when the value of the Accept header requests a representation in text/turtle [TURTLE].

    -

    Servers who want a resource to inherit Authorizations (see Effective ACL Resource) from a container resource MUST NOT initialise the ACL resource that is associated with the resource with a representation. When an authorized HTTP GET or HEAD request targets an ACL resource without an existing representation, the server MUST respond with the 404 status code as per [RFC7231].

    +

    Servers who want a resource to inherit Authorizations (Effective ACL Resource) from a container resource MUST NOT initialise the ACL resource that is associated with the resource with a representation. When an authorized HTTP GET or HEAD request targets an ACL resource without an existing representation, the server MUST respond with the 404 status code as per [RFC7231].

    The root container MUST have an ACL resource with a representation. The ACL resource of the root container MUST include an Authorization allowing the acl:Control access privilege (acl:Control access mode).

    @@ -679,9 +679,9 @@

    Effective ACL Resource

    Servers enforce the effective ACL resource of a resource, whereas clients determine the effective ACL resource of a resource to perform read and write Authorizations.

    -

    When an ACL resource associated with a resource has a representation (see ACL Resource Representation), it is the effective ACL resource of the requested resource.

    +

    When an ACL resource associated with a resource has a representation (ACL Resource Representation), it is the effective ACL resource of the requested resource.

    -

    When an ACL resource associated with a resource does not have a representation (see ACL Resource Representation), no Authorizations can be immediately checked against the requested resource. In this case, a container resource’s ACL resource may apply on every access to a member resource, in specifying Authorizations for the requested resource.

    +

    When an ACL resource associated with a resource does not have a representation (ACL Resource Representation), no Authorizations can be immediately checked against the requested resource. In this case, a container resource’s ACL resource may apply on every access to a member resource, in specifying Authorizations for the requested resource.

    WAC has the property of being recursive with respect to container hierarchy, meaning that a member resource inherits Authorizations from the closest container resource (heading toward the root container).

    @@ -739,7 +739,7 @@

    Reading and Writing Resources

    Generally, read operations attempt to know about the existence of a resource or view the contents of a resource. Write operations attempt to create, delete, or modify resources. Append operations attempt to create resources or add information to resources. Control operations attempt to view, create, delete, or modify ACL resources.

    -

    As container resources and member resources are hierarchically organised, requests to perform operations on resources are in the context of the applicable container (Effective ACL Resource).

    +

    As container resources and member resources are hierarchically organised, requests to perform operations on resources are in the context of the applicable container (Effective ACL Resource).

    When an operation requests to read a resource, the server MUST match an Authorization allowing the acl:Read access privilege on the resource.

    @@ -810,12 +810,12 @@
    Note: Trusted Origins
    -

    Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (see WAC-Allow) in the response of HTTP GET and HEAD requests.

    +

    Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (WAC-Allow) in the response of HTTP GET and HEAD requests.

    Note: Clients Discovering Access Privileges
    -

    Clients can discover access privileges on a resource by making an HTTP HEAD or GET request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (see WAC-Allow).

    +

    Clients can discover access privileges on a resource by making an HTTP HEAD or GET request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (WAC-Allow).

    @@ -1101,7 +1101,7 @@

    Security and Privacy Review

    No.
    What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.
    -
    No detail about another origin’s state is exposed. As the association between a resource and its ACL resource is at the discretion of the resource server, they can be on different origins (see URI Origin). Similarly, when a server participates in the CORS protocol [FETCH], HTTP requests from different origins my be allowed. This feature does not add any new attack surface above and beyond what normal CORS requests, so no extra mitigation is deemed to be necessary.
    +
    No detail about another origin’s state is exposed. As the association between a resource and its ACL resource is at the discretion of the resource server, they can be on different origins (URI Origin). Similarly, when a server participates in the CORS protocol [FETCH], HTTP requests from different origins my be allowed. This feature does not add any new attack surface above and beyond what normal CORS requests, so no extra mitigation is deemed to be necessary.
    Do features in this specification enable new script execution/loading mechanisms?
    No.
    From d0c072a611f1d006145013c343bbb3784bd56796 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 18 Jun 2021 17:36:26 +0200 Subject: [PATCH 280/310] Minor --- index.html | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/index.html b/index.html index f5932d2f..aa9185e8 100644 --- a/index.html +++ b/index.html @@ -368,7 +368,7 @@

    Intro

    Unauthorized access or modification of Web resources could lead to unintended loss, damage or disclosure of data. To support read-write operations within the framework of HTTP, mechanisms for expressing and application of authorization conditions are needed to meet the social requirements of decentralised applications.

    -

    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.

    +

    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.

    The WAC specification describes how to enable applications to discover Authorizations associated with a given resource, and to control such policies, as directed by an agent. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Any kind of access can be given to a resource as per the ACL ontology. This specification uses the access modes currently defined by the ACL ontology, such as the class of operations to read, write, append and control resources. An Authorization may allow public access to resources or place the requirement for authenticated agents. Resources and agents can be on different origins.

    @@ -479,7 +479,7 @@

    Conformance

    All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.

    -

    The key words “MUST” and “MUST NOT” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

    +

    The key words “MUST” and “MUST NOT” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

    @@ -502,7 +502,7 @@

    ACL Resources

    ACL Resource Discovery

    -

    When a server wants to enable applications to discover Authorizations associated with a given resource, the server MUST advertise the ACL resource that is associated with a resource by responding to an HTTP request including a Link header with the rel value of acl (acl Link Relation type) and the ACL resource as link target.

    +

    When a server wants to enable applications to discover Authorizations associated with a given resource, the server MUST advertise the ACL resource that is associated with a resource by responding to an HTTP request including a Link header with the rel value of acl (acl Link Relation) and the ACL resource as link target.

    ACL Resource Discovery is used towards determining the Effective ACL Resource of a resource.

    @@ -579,13 +579,13 @@

    Access Modes

    acl:Read
    -
    Allows access to a class of read operations on a resource eg. to view the contents of a resource on HTTP GET requests.
    +
    Allows access to a class of read operations on a resource, eg. to view the contents of a resource on HTTP GET requests.
    acl:Write
    -
    Allows access to a class of write operations on a resource eg. to create, delete or modify resources on HTTP PUT, POST, PATCH, DELETE requests.
    +
    Allows access to a class of write operations on a resource, eg. to create, delete or modify resources on HTTP PUT, POST, PATCH, DELETE requests.
    acl:Append
    -
    Allows access to a class of append operations on a resource eg. to add information but not remove information on HTTP POST, PATCH requests.
    +
    Allows access to a class of append operations on a resource, eg. to add information but not remove information on HTTP POST, PATCH requests.
    acl:Control
    Allows access to a class of read and write operations on an ACL resource associated with a resource.
    @@ -610,7 +610,7 @@

    Note: URI Ownership

    Note: Loss of Control Mitigation

    -

    It is assumed that systems using WAC have mechanisms to mitigate loss of control of the resources eg. by ensuring valid ACL resources and Authorizations, providing administrative functions on the storage, or implicit control over all resources in a storage to owners.

    +

    It is assumed that systems using WAC have mechanisms to mitigate loss of control of the resources, eg. by ensuring valid ACL resources and Authorizations, providing administrative functions on the storage, or implicit control over all resources in a storage to owners.

    Source: issues/67, issues/153, pull/264

    @@ -771,7 +771,7 @@
    Note: HTTP Method and Access Mode Mappin

    As the HTTP PUT method requests to create or replace the resource state, the acl:Write access mode would be required.

    -

    As the processing of HTTP PATCH method requests depends on the request semantics and content eg. acl:Append can allow requests using SPARQL 1.1 Update’s [SPARQL11-UPDATE] INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.

    +

    As the processing of HTTP PATCH method requests depends on the request semantics and content, eg. acl:Append can allow requests using SPARQL 1.1 Update’s [SPARQL11-UPDATE] INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.

    As the HTTP DELETE method requests to remove a resource, the acl:Write access mode would be required.

    @@ -806,7 +806,7 @@
    Note: Access Subject and Origin Rejectio
    Note: Trusted Origins
    -

    Implementations might implicitly allow a list of origins eg. the same-origin [RFC6454].

    +

    Implementations might implicitly allow a list of origins, eg. the same-origin [RFC6454].

    @@ -940,7 +940,7 @@

    Issue: WAC-Allow Access Modes

    access-mode corresponds to the Access Modes as defined in the ACL ontology (acl:Read, acl:Write, acl:Append, acl:Control).

    -

    Clients’ parsing algorithm for WAC-Allow header's field-value should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (permission groups and access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    +

    Clients’ parsing algorithm for WAC-Allow header’s field-value should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (permission groups and access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    Source: issues/171, issues/170, issues/181, 60101295d8bdab47395e6775, pull/210

    @@ -978,7 +978,7 @@

    Authorization Extensions

    This section is non-normative.

    -

    As ACL resources are RDF sources, Authorizations descriptions may be extended or limited by constraints eg. temporal or spatial constraints, and duties eg. payments, may be imposed on permissions, but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

    +

    As ACL resources are RDF sources, Authorizations descriptions may be extended or limited by constraints, eg. temporal or spatial constraints, and duties, eg. payments, may be imposed on permissions, but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

    To allow access to a class of resources, implementations may want to use the acl:accessToClass predicate as defined in the ACL ontology.

    @@ -1009,7 +1009,7 @@

    Distinct Effective ACL Resource Extensions

    This section is non-normative.

    -

    This specification describes the use of acl link relation for ACL Resource Discovery and the algorithm to determine the Effective ACL Resource of a resource. To enable clients to perform discovery faster, separate link relation type targeting the effective ACL resource is allowed, but no behaviour is defined by this specification.

    +

    This specification describes the use of acl Link Relation for ACL Resource Discovery and the algorithm to determine the Effective ACL Resource of a resource. To enable clients to perform discovery faster, separate link relation type targeting the effective ACL resource is allowed, but no behaviour is defined by this specification.

    @@ -1037,7 +1037,7 @@

    Security Considerations

    Implementations are encouraged to use mechanisms to record activities about ACL resources for the purpose of accountability and integrity, eg. by having audit trails, notification of changes, reasons for change, preserving provenance information.

    -

    Implementations that want to allow a class of write or control operations on resources are encouraged to require agents to be authenticated eg. for provenance records or accountability purposes.

    +

    Implementations that want to allow a class of write or control operations on resources are encouraged to require agents to be authenticated, eg. for provenance records or accountability purposes.

    @@ -1073,7 +1073,7 @@

    Security and Privacy Review

    This section is non-normative.

    -

    These questions provide an overview of security and privacy considerations for this specification as guided by Self-Review Questionnaire: Security and Privacy.

    +

    These questions provide an overview of security and privacy considerations for this specification as guided by [SECURITY-PRIVACY-QUESTIONNAIRE].

    What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
    @@ -1086,7 +1086,7 @@

    Security and Privacy Review

    ACL resources may contain any data including that which identifies or refers to agents and agent groups. Access to ACL resources is only granted to Access Subjects with the acl:Control access mode, and thus by definition, meaningful consent to any personal data that agents include about themselves is extended to other agents with control access on the ACL resource. Group resources are subject to the same Authorization conditions as any resource (that is not an ACL resource), and thus information may be exposed.
    How do the features in your specification deal with sensitive information?
    -
    Same implications as personal information and personally-identifiable information in ACL resources and group resources. In the case of including sensitive information, the sender should be aware that changes to a group resource can allow non-members or new members to view membership.
    +
    Same implications as personal information and personally-identifiable information in ACL resources and group resources. In the case of including sensitive information, the sender should be aware that changes to a group resource’s ACL resource may allow non-members or new members to view membership.
    Do the features in your specification introduce new state for an origin that persists across browsing sessions?
    No.
    @@ -1095,7 +1095,7 @@

    Security and Privacy Review

    No.
    Does this specification allow an origin to send data to the underlying platform?
    -
    No. ACL resources are described within the framework of HTTP as RDF documents represented with the Turtle syntax. Servers may be able to redirect ACL resources ie. the https: URLs to file:, data:, or blob: URLs, but no behaviour is defined by this specification.
    +
    No. ACL resources are described within the framework of HTTP as RDF documents represented with the Turtle syntax. Servers may be able to redirect ACL resources, ie. the https: URLs to file:, data:, or blob: URLs, but no behaviour is defined by this specification.
    Do features in this specification allow an origin access to sensors on a user’s device
    No.
    @@ -1116,10 +1116,10 @@

    Security and Privacy Review

    None.
    How does this specification distinguish between behaviour in first-party and third-party contexts?
    -
    When an HTTP request includes the Origin header (typical Web browsers use origin based security to warn servers), Authorizations are matched in context of the origin of the HTTP request in addition to requiring agent identification and allowed access modes. While the use of Origin is not intended as client identification, the implication is that unless servers have separate mechanisms to verify the original request made by an application, the Origin header’s field-value can differ. In order to distinguish social entities and clients supported by authentication protocols, an issue on client identification is filed.
    +
    When an HTTP request includes the Origin header (typical Web browsers use origin based security to warn servers), Authorizations are matched in context of the origin of the HTTP request in addition to requiring agent identification and allowed access modes. While the use of Origin is not intended as client identification, the implication is that unless servers have separate mechanisms to verify the original request made by an application, the Origin header’s field-value can differ. In order to distinguish social entities and clients supported by authentication protocols, an issue on client identification is filed.
    How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
    -
    No different than browser’s 'normal' state.
    +
    No different than browser’s 'normal' state.
    Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
    Yes, in Security Considerations and Privacy Considerations.
    From f87f9ecf964d43cbc94b92b4204f662183fed6c8 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 21 Jun 2021 16:12:38 +0200 Subject: [PATCH 281/310] Minor --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index aa9185e8..0c13f71d 100644 --- a/index.html +++ b/index.html @@ -752,7 +752,7 @@

    Reading and Writing Resources

    Note: Reinstated Resource Permissions
    -

    Implementations may perform cleanup tasks such as deleting ACL resources that are associated with a resource when the resource is deleted. As deleted resources may be reinstated with the same URI, access permissions on the reinstated resource may change as per determining the Effective ACL Resource.

    +

    Implementations may perform cleanup tasks such as deleting the ACL resource that is associated with a resource when the resource is deleted. As deleted resources may be reinstated with the same URI, access permissions on the reinstated resource may change as per determining the Effective ACL Resource.

    From aa190b488b1935bbb079dde5701b2d85e9d700a5 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 21 Jun 2021 22:40:59 +0200 Subject: [PATCH 282/310] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 0c13f71d..836e665c 100644 --- a/index.html +++ b/index.html @@ -610,7 +610,7 @@

    Note: URI Ownership

    Note: Loss of Control Mitigation

    -

    It is assumed that systems using WAC have mechanisms to mitigate loss of control of the resources, eg. by ensuring valid ACL resources and Authorizations, providing administrative functions on the storage, or implicit control over all resources in a storage to owners.

    +

    It is assumed that systems using WAC have mechanisms to mitigate loss of control of the resources, such as by ensuring valid ACL resources and Authorizations, by providing administrative functions on the storage, or by implicitly granting control over all resources in a storage to owners.

    Source: issues/67, issues/153, pull/264

    From a77b6973594fbc1e14d566d9850197fa2a654819 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 21 Jun 2021 22:41:30 +0200 Subject: [PATCH 283/310] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 836e665c..d93202f2 100644 --- a/index.html +++ b/index.html @@ -737,7 +737,7 @@

    Reading and Writing Resources

    Working alongside HTTP Interactions, WAC enables a standard set of operations which can be applied to different resource types for a given request based on the set of access modes which control those operations:

    -

    Generally, read operations attempt to know about the existence of a resource or view the contents of a resource. Write operations attempt to create, delete, or modify resources. Append operations attempt to create resources or add information to resources. Control operations attempt to view, create, delete, or modify ACL resources.

    +

    Generally: read operations attempt to confirm the existence of a resource or to view the contents of a resource; write operations attempt to create, delete, or modify resources; append operations attempt to create resources or add information to existing resources; and control operations attempt to view, create, delete, or modify ACL resources.

    As container resources and member resources are hierarchically organised, requests to perform operations on resources are in the context of the applicable container (Effective ACL Resource).

    From 6336a263c284ce738cf2f11f99cc1b7cb63072d3 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 21 Jun 2021 22:42:50 +0200 Subject: [PATCH 284/310] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index d93202f2..175429f1 100644 --- a/index.html +++ b/index.html @@ -752,7 +752,7 @@

    Reading and Writing Resources

    Note: Reinstated Resource Permissions
    -

    Implementations may perform cleanup tasks such as deleting the ACL resource that is associated with a resource when the resource is deleted. As deleted resources may be reinstated with the same URI, access permissions on the reinstated resource may change as per determining the Effective ACL Resource.

    +

    Implementations may perform cleanup tasks such as deleting the ACL resource that is associated with a resource when the resource is deleted. As deleted resources may be replaced by new resources with the same URI, access permissions on the new resource may differ when the Effective ACL Resource is determined.

    From 16d1a629c5d1c486f14eaa34666a08126ce8ea94 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 21 Jun 2021 22:43:30 +0200 Subject: [PATCH 285/310] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 175429f1..ede6c2d1 100644 --- a/index.html +++ b/index.html @@ -771,7 +771,7 @@
    Note: HTTP Method and Access Mode Mappin

    As the HTTP PUT method requests to create or replace the resource state, the acl:Write access mode would be required.

    -

    As the processing of HTTP PATCH method requests depends on the request semantics and content, eg. acl:Append can allow requests using SPARQL 1.1 Update’s [SPARQL11-UPDATE] INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.

    +

    As the processing of HTTP PATCH method requests depends on the request semantics and content, acl:Append can allow requests using SPARQL 1.1 Update’s [SPARQL11-UPDATE] INSERT DATA operation but not DELETE DATA, whereas acl:Write would allow both operations.

    As the HTTP DELETE method requests to remove a resource, the acl:Write access mode would be required.

    From df5cdf3f7d63abfc5308940991d407aeebfc3b04 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 21 Jun 2021 22:43:52 +0200 Subject: [PATCH 286/310] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index ede6c2d1..905999c5 100644 --- a/index.html +++ b/index.html @@ -1086,7 +1086,7 @@

    Security and Privacy Review

    ACL resources may contain any data including that which identifies or refers to agents and agent groups. Access to ACL resources is only granted to Access Subjects with the acl:Control access mode, and thus by definition, meaningful consent to any personal data that agents include about themselves is extended to other agents with control access on the ACL resource. Group resources are subject to the same Authorization conditions as any resource (that is not an ACL resource), and thus information may be exposed.
    How do the features in your specification deal with sensitive information?
    -
    Same implications as personal information and personally-identifiable information in ACL resources and group resources. In the case of including sensitive information, the sender should be aware that changes to a group resource’s ACL resource may allow non-members or new members to view membership.
    +
    Same implications as personal information and personally-identifiable information in ACL resources and group resources. When including sensitive information, the sender should be aware that changes to a group resource’s ACL resource may allow non-members or new members to view membership details.
    Do the features in your specification introduce new state for an origin that persists across browsing sessions?
    No.
    From c919dd4eef72fe8a32a0ae9f3f68845b761d8b29 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 21 Jun 2021 22:44:09 +0200 Subject: [PATCH 287/310] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 905999c5..50c38d79 100644 --- a/index.html +++ b/index.html @@ -1101,7 +1101,7 @@

    Security and Privacy Review

    No.
    What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.
    -
    No detail about another origin’s state is exposed. As the association between a resource and its ACL resource is at the discretion of the resource server, they can be on different origins (URI Origin). Similarly, when a server participates in the CORS protocol [FETCH], HTTP requests from different origins my be allowed. This feature does not add any new attack surface above and beyond what normal CORS requests, so no extra mitigation is deemed to be necessary.
    +
    No detail about another origin’s state is exposed. As the association between a resource and its ACL resource is at the discretion of the resource server, they can be on different origins (URI Origin). Similarly, when a server participates in the CORS protocol [FETCH], HTTP requests from different origins my be allowed. This feature does not add any new attack surface above and beyond normal CORS requests, so no extra mitigation is deemed necessary.
    Do features in this specification enable new script execution/loading mechanisms?
    No.
    From db9cfe5676e5c9150add9ccff615343ec6b63b9e Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 21 Jun 2021 22:44:35 +0200 Subject: [PATCH 288/310] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 50c38d79..d15fc2fd 100644 --- a/index.html +++ b/index.html @@ -806,7 +806,7 @@
    Note: Access Subject and Origin Rejectio
    Note: Trusted Origins
    -

    Implementations might implicitly allow a list of origins, eg. the same-origin [RFC6454].

    +

    Implementations might implicitly allow a list of origins, such as the same-origin [RFC6454].

    From e5b64c609f5974a0cc1d937d09cf4b28dd5b82d9 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 21 Jun 2021 22:45:12 +0200 Subject: [PATCH 289/310] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index d15fc2fd..7e62187b 100644 --- a/index.html +++ b/index.html @@ -940,7 +940,7 @@

    Issue: WAC-Allow Access Modes

    access-mode corresponds to the Access Modes as defined in the ACL ontology (acl:Read, acl:Write, acl:Append, acl:Control).

    -

    Clients’ parsing algorithm for WAC-Allow header’s field-value should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (permission groups and access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    +

    Client parsing algorithms for WAC-Allow header field-values should incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (such as permission groups or access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

    Source: issues/171, issues/170, issues/181, 60101295d8bdab47395e6775, pull/210

    From 71ea14406995a069d862e88e908a4b5184745124 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 21 Jun 2021 23:26:49 +0200 Subject: [PATCH 290/310] Suggestions from @TallTed but with BrE use --- index.html | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/index.html b/index.html index 7e62187b..02b7568d 100644 --- a/index.html +++ b/index.html @@ -414,13 +414,13 @@

    Terminology

    An ACL resource is represented by an RDF document [RDF11-CONCEPTS] that includes Authorizations to access resources.
    Authorization
    -
    An Authorization is an abstract thing identified by a URI whose properties are defined in an ACL resource, eg. access modes granted to agents the ability to perform operations on resources.
    +
    An Authorization is an abstract thing identified by a URI whose properties are defined in an ACL resource, e.g. access modes granted to agents the ability to perform operations on resources.
    access mode
    An access mode is a class of operations that can be performed on one or more resources.
    agent
    -
    An agent is a person, social entity or software identified by a URI, eg. a WebID denotes an agent [WEBID].
    +
    An agent is a person, social entity or software identified by a URI, e.g. a WebID denotes an agent [WEBID].
    agent group
    An agent group is a group of persons or entities identified by a URI.
    @@ -490,7 +490,7 @@

    HTTP Interactions

    This section is non-normative.

    -

    Clients who want to perform read-write operations on ACL resources with respect to Authorizations which are stored on a server can do so within the framework of HTTP. This specification does not describe the HTTP interaction to read-write resources. It is assumed that servers have a mapping to handle HTTP requests and the required Authorizations to grant operations on resources. Implementations are strongly encouraged to use existing approaches that provide an extension of the rules of Linked Data, eg. [SOLID-PROTOCOL], [LDP].

    +

    Clients who want to perform read-write operations on ACL resources with respect to Authorizations which are stored on a server can do so within the framework of HTTP. This specification does not describe the HTTP interaction to read-write resources. It is assumed that servers have a mapping to handle HTTP requests and the required Authorizations to grant operations on resources. Implementations are strongly encouraged to use existing approaches that provide an extension of the rules of Linked Data, e.g. [SOLID-PROTOCOL], [LDP].

    @@ -509,7 +509,7 @@

    ACL Resource Discovery

    @@ -579,13 +579,13 @@

    Access Modes

    acl:Read
    -
    Allows access to a class of read operations on a resource, eg. to view the contents of a resource on HTTP GET requests.
    +
    Allows access to a class of read operations on a resource, e.g. to view the contents of a resource on HTTP GET requests.
    acl:Write
    -
    Allows access to a class of write operations on a resource, eg. to create, delete or modify resources on HTTP PUT, POST, PATCH, DELETE requests.
    +
    Allows access to a class of write operations on a resource, e.g. to create, delete or modify resources on HTTP PUT, POST, PATCH, DELETE requests.
    acl:Append
    -
    Allows access to a class of append operations on a resource, eg. to add information but not remove information on HTTP POST, PATCH requests.
    +
    Allows access to a class of append operations on a resource, e.g. to add information, but not remove, information on HTTP POST, PATCH requests.
    acl:Control
    Allows access to a class of read and write operations on an ACL resource associated with a resource.
    @@ -830,7 +830,7 @@

    Authorization Matching

    This specification does not impose a storage system that can be used to store Authorizations. Similarly, mechanisms that can be used to find required RDF statements of Authorizations is deliberately unspecified to allow for a wide variety of use. This section exemplifies access check via SPARQL 1.1 Query Language’s [SPARQL11-QUERY] ASK form to test whether or not an Authorization pattern matches; returns boolean.

    -

    The ASK queries below exemplify atomic graph patterns that can be executed against the default graph of an RDF dataset using named graphs for resources. The examples use query variables marked with "?" to indicate any value, and "$" to indicate inputs passed to the query, eg. <http://example.org/.acl> as the IRI reference of the effective ACL resource of a request replaces $aclResource in the query, and likewise, acl:Write as input is intended to replace $mode in the examples.

    +

    The ASK queries below exemplify atomic graph patterns that can be executed against the default graph of an RDF dataset using named graphs for resources. The examples use query variables marked with "?" to indicate any value, and "$" to indicate inputs passed to the query, e.g. <http://example.org/.acl> as the IRI reference of the effective ACL resource of a request replaces $aclResource in the query, and likewise, acl:Write as input is intended to replace $mode in the examples.

    Example: Match an Authorization with a specific resource, agent and access mode.

    @@ -978,7 +978,7 @@

    Authorization Extensions

    This section is non-normative.

    -

    As ACL resources are RDF sources, Authorizations descriptions may be extended or limited by constraints, eg. temporal or spatial constraints, and duties, eg. payments, may be imposed on permissions, but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

    +

    As ACL resources are RDF sources; Authorization descriptions may be extended or limited by constraints, e.g. temporal or spatial constraints; and duties, e.g. payments, may be imposed on permissions; but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

    To allow access to a class of resources, implementations may want to use the acl:accessToClass predicate as defined in the ACL ontology.

    @@ -1035,9 +1035,9 @@

    Security Considerations

    Transfer of Authorizations between a client and server over an open network creates the potential for those policies to be modified or disclosed without proper authorization. The requirements for the Web Access Control protocol discussed in this specification do not include cryptographic protection of Authorization information, because it is assumed that this protection can be provided through HTTP over TLS. The path between client and application may be composed of multiple independent TLS connections, thus for end-to-end integrity and authenticity of content within an HTTP message, implementers can use mechanisms such as Signing HTTP Messages. For cryptographic proof of Authorizations asserted by agents and protection from undetected modifications, implementers can use mechanisms such as Linked Data Security.

    -

    Implementations are encouraged to use mechanisms to record activities about ACL resources for the purpose of accountability and integrity, eg. by having audit trails, notification of changes, reasons for change, preserving provenance information.

    +

    Implementations are encouraged to use mechanisms to record activities about ACL resources for the purpose of accountability and integrity, e.g. by having audit trails, notification of changes, reasons for change, preserving provenance information.

    -

    Implementations that want to allow a class of write or control operations on resources are encouraged to require agents to be authenticated, eg. for provenance records or accountability purposes.

    +

    Implementations that want to allow a class of write or control operations on resources are encouraged to require agents to be authenticated, e.g. for purposes of provenance or accountability.

    @@ -1095,7 +1095,7 @@

    Security and Privacy Review

    No.
    Does this specification allow an origin to send data to the underlying platform?
    -
    No. ACL resources are described within the framework of HTTP as RDF documents represented with the Turtle syntax. Servers may be able to redirect ACL resources, ie. the https: URLs to file:, data:, or blob: URLs, but no behaviour is defined by this specification.
    +
    No. ACL resources are described within the framework of HTTP as RDF documents represented with the Turtle syntax. Servers may be able to redirect ACL resources, (e.g. the https: URLs to file:, data:, or blob: URLs), but no behaviour is defined by this specification.
    Do features in this specification allow an origin access to sensors on a user’s device
    No.
    From b38e2c2f961130f7ef585f08af776b37eca898d0 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 22 Jun 2021 09:49:37 +0200 Subject: [PATCH 291/310] Good ol' commas after e.g. and i.e. --- index.html | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/index.html b/index.html index 02b7568d..93bde0cb 100644 --- a/index.html +++ b/index.html @@ -414,13 +414,13 @@

    Terminology

    An ACL resource is represented by an RDF document [RDF11-CONCEPTS] that includes Authorizations to access resources.
    Authorization
    -
    An Authorization is an abstract thing identified by a URI whose properties are defined in an ACL resource, e.g. access modes granted to agents the ability to perform operations on resources.
    +
    An Authorization is an abstract thing identified by a URI whose properties are defined in an ACL resource, e.g., access modes granted to agents the ability to perform operations on resources.
    access mode
    An access mode is a class of operations that can be performed on one or more resources.
    agent
    -
    An agent is a person, social entity or software identified by a URI, e.g. a WebID denotes an agent [WEBID].
    +
    An agent is a person, social entity or software identified by a URI, e.g., a WebID denotes an agent [WEBID].
    agent group
    An agent group is a group of persons or entities identified by a URI.
    @@ -490,7 +490,7 @@

    HTTP Interactions

    This section is non-normative.

    -

    Clients who want to perform read-write operations on ACL resources with respect to Authorizations which are stored on a server can do so within the framework of HTTP. This specification does not describe the HTTP interaction to read-write resources. It is assumed that servers have a mapping to handle HTTP requests and the required Authorizations to grant operations on resources. Implementations are strongly encouraged to use existing approaches that provide an extension of the rules of Linked Data, e.g. [SOLID-PROTOCOL], [LDP].

    +

    Clients who want to perform read-write operations on ACL resources with respect to Authorizations which are stored on a server can do so within the framework of HTTP. This specification does not describe the HTTP interaction to read-write resources. It is assumed that servers have a mapping to handle HTTP requests and the required Authorizations to grant operations on resources. Implementations are strongly encouraged to use existing approaches that provide an extension of the rules of Linked Data, e.g., [SOLID-PROTOCOL], [LDP].

    @@ -509,7 +509,7 @@

    ACL Resource Discovery

    @@ -579,13 +579,13 @@

    Access Modes

    acl:Read
    -
    Allows access to a class of read operations on a resource, e.g. to view the contents of a resource on HTTP GET requests.
    +
    Allows access to a class of read operations on a resource, e.g., to view the contents of a resource on HTTP GET requests.
    acl:Write
    -
    Allows access to a class of write operations on a resource, e.g. to create, delete or modify resources on HTTP PUT, POST, PATCH, DELETE requests.
    +
    Allows access to a class of write operations on a resource, e.g., to create, delete or modify resources on HTTP PUT, POST, PATCH, DELETE requests.
    acl:Append
    -
    Allows access to a class of append operations on a resource, e.g. to add information, but not remove, information on HTTP POST, PATCH requests.
    +
    Allows access to a class of append operations on a resource, e.g., to add information, but not remove, information on HTTP POST, PATCH requests.
    acl:Control
    Allows access to a class of read and write operations on an ACL resource associated with a resource.
    @@ -830,7 +830,7 @@

    Authorization Matching

    This specification does not impose a storage system that can be used to store Authorizations. Similarly, mechanisms that can be used to find required RDF statements of Authorizations is deliberately unspecified to allow for a wide variety of use. This section exemplifies access check via SPARQL 1.1 Query Language’s [SPARQL11-QUERY] ASK form to test whether or not an Authorization pattern matches; returns boolean.

    -

    The ASK queries below exemplify atomic graph patterns that can be executed against the default graph of an RDF dataset using named graphs for resources. The examples use query variables marked with "?" to indicate any value, and "$" to indicate inputs passed to the query, e.g. <http://example.org/.acl> as the IRI reference of the effective ACL resource of a request replaces $aclResource in the query, and likewise, acl:Write as input is intended to replace $mode in the examples.

    +

    The ASK queries below exemplify atomic graph patterns that can be executed against the default graph of an RDF dataset using named graphs for resources. The examples use query variables marked with "?" to indicate any value, and "$" to indicate inputs passed to the query, e.g., <http://example.org/.acl> as the IRI reference of the effective ACL resource of a request replaces $aclResource in the query, and likewise, acl:Write as input is intended to replace $mode in the examples.

    Example: Match an Authorization with a specific resource, agent and access mode.

    @@ -978,7 +978,7 @@

    Authorization Extensions

    This section is non-normative.

    -

    As ACL resources are RDF sources; Authorization descriptions may be extended or limited by constraints, e.g. temporal or spatial constraints; and duties, e.g. payments, may be imposed on permissions; but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

    +

    As ACL resources are RDF sources; Authorization descriptions may be extended or limited by constraints, e.g., temporal or spatial constraints; and duties, e.g., payments, may be imposed on permissions; but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

    To allow access to a class of resources, implementations may want to use the acl:accessToClass predicate as defined in the ACL ontology.

    @@ -989,7 +989,7 @@

    Authorization Extensions

    Access Mode Extensions

    -

    An extension to access modes is any mode that is defined in the ACL ontology, ie. as a subclass of acl:Access, but not described in this specification (Access Modes). Consumers of Authorizations that encounter unrecognised access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.

    +

    An extension to access modes is any mode that is defined in the ACL ontology, i.e., as a subclass of acl:Access, but not described in this specification (Access Modes). Consumers of Authorizations that encounter unrecognised access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.

    Foreign-namespaced access modes are allowed in ACL resources, but they MUST NOT cause increased access.

    @@ -1035,9 +1035,9 @@

    Security Considerations

    Transfer of Authorizations between a client and server over an open network creates the potential for those policies to be modified or disclosed without proper authorization. The requirements for the Web Access Control protocol discussed in this specification do not include cryptographic protection of Authorization information, because it is assumed that this protection can be provided through HTTP over TLS. The path between client and application may be composed of multiple independent TLS connections, thus for end-to-end integrity and authenticity of content within an HTTP message, implementers can use mechanisms such as Signing HTTP Messages. For cryptographic proof of Authorizations asserted by agents and protection from undetected modifications, implementers can use mechanisms such as Linked Data Security.

    -

    Implementations are encouraged to use mechanisms to record activities about ACL resources for the purpose of accountability and integrity, e.g. by having audit trails, notification of changes, reasons for change, preserving provenance information.

    +

    Implementations are encouraged to use mechanisms to record activities about ACL resources for the purpose of accountability and integrity, e.g., by having audit trails, notification of changes, reasons for change, preserving provenance information.

    -

    Implementations that want to allow a class of write or control operations on resources are encouraged to require agents to be authenticated, e.g. for purposes of provenance or accountability.

    +

    Implementations that want to allow a class of write or control operations on resources are encouraged to require agents to be authenticated, e.g., for purposes of provenance or accountability.

    @@ -1095,7 +1095,7 @@

    Security and Privacy Review

    No.
    Does this specification allow an origin to send data to the underlying platform?
    -
    No. ACL resources are described within the framework of HTTP as RDF documents represented with the Turtle syntax. Servers may be able to redirect ACL resources, (e.g. the https: URLs to file:, data:, or blob: URLs), but no behaviour is defined by this specification.
    +
    No. ACL resources are described within the framework of HTTP as RDF documents represented with the Turtle syntax. Servers may be able to redirect ACL resources, (e.g., the https: URLs to file:, data:, or blob: URLs), but no behaviour is defined by this specification.
    Do features in this specification allow an origin access to sensors on a user’s device
    No.
    From b8be211c535eea72b3389d1b21857559f7d455bc Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 22 Jun 2021 11:40:44 +0200 Subject: [PATCH 292/310] Add links to authorization-conformance authorization-evaluation --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 93bde0cb..6c48a039 100644 --- a/index.html +++ b/index.html @@ -557,7 +557,7 @@

    ACL Resource Representation

    Authorization Rule

    -

    Authorization (instance of acl:Authorization) is the most fundamental unit of access control describing access permissions granted to agents the ability to perform operations on resources. Authorizations are described with RDF statements and may express any information. This section describes the following characteristics of an Authorization: access objects to specify what can be accessed, access modes to specify permissions, and access subjects to specify who can access the objects.

    +

    Authorization (instance of acl:Authorization) is the most fundamental unit of access control describing access permissions granted to agents the ability to perform operations on resources. Authorizations are described with RDF statements and may express any information. This section describes the following characteristics of an Authorization: access objects to specify what can be accessed, access modes to specify permissions, and access subjects to specify who can access the objects. See the Authorization Conformance section for applicable Authorizations towards Authorization Evaluation.

    Access Objects

    From b51c52d85670eed0a86ecbeee1f34fdcdf0e51c7 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 22 Jun 2021 11:42:49 +0200 Subject: [PATCH 293/310] Minor --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 6c48a039..fd55692b 100644 --- a/index.html +++ b/index.html @@ -638,7 +638,7 @@

    Access Subjects

    The acl:agentGroup predicate denotes a group of agents being given the access permission. The object of an acl:agentGroup statement is an instance of vcard:Group, where the members of the group are specified with the vcard:hasMember predicate.

    -

    The acl:origin predicate denotes the origin an HTTP request is being given the access permission.

    +

    The acl:origin predicate denotes the origin of an HTTP request is being given the access permission.

    Note: Subject Verification

    From 89cde2b7843d69c18ec9ae4b8757b80b51a0d4a2 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 22 Jun 2021 16:32:19 +0200 Subject: [PATCH 294/310] Clarify why clients need effective ACL resource --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index fd55692b..814b0dae 100644 --- a/index.html +++ b/index.html @@ -677,7 +677,7 @@

    Authorization Process

    Effective ACL Resource

    -

    Servers enforce the effective ACL resource of a resource, whereas clients determine the effective ACL resource of a resource to perform read and write Authorizations.

    +

    Servers enforce the effective ACL resource of a resource, whereas clients determine the effective ACL resource of a resource to perform write operations on ACL resources.

    When an ACL resource associated with a resource has a representation (ACL Resource Representation), it is the effective ACL resource of the requested resource.

    From d284d3845574f8d7d2c3c1ae380fffe8a2d939c8 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 22 Jun 2021 16:33:15 +0200 Subject: [PATCH 295/310] Minor --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 814b0dae..1d9b367b 100644 --- a/index.html +++ b/index.html @@ -677,7 +677,7 @@

    Authorization Process

    Effective ACL Resource

    -

    Servers enforce the effective ACL resource of a resource, whereas clients determine the effective ACL resource of a resource to perform write operations on ACL resources.

    +

    Servers enforce the effective ACL resource of a resource, whereas clients determine the effective ACL resource of a resource to perform write operations.

    When an ACL resource associated with a resource has a representation (ACL Resource Representation), it is the effective ACL resource of the requested resource.

    From 2fd1533ab1b672175f4781449b69a35ed9815b58 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 23 Jun 2021 14:10:52 +0200 Subject: [PATCH 296/310] Clarify client's reason to determine efective-acl-resource: control operation --- index.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index 1d9b367b..4602b5fd 100644 --- a/index.html +++ b/index.html @@ -138,7 +138,7 @@

    Web Access Control

    -

    Editor’s Draft, 2021-06-18

    +

    Editor’s Draft, 2021-06-23

    This version
    @@ -164,7 +164,7 @@

    Editor’s Draft, 2021-06-18

    Modified
    -
    +
    @@ -677,13 +677,13 @@

    Authorization Process

    Effective ACL Resource

    -

    Servers enforce the effective ACL resource of a resource, whereas clients determine the effective ACL resource of a resource to perform write operations.

    +

    Servers enforce the effective ACL resource of a resource, whereas clients determine the effective ACL resource of a resource to perform control operations.

    When an ACL resource associated with a resource has a representation (ACL Resource Representation), it is the effective ACL resource of the requested resource.

    When an ACL resource associated with a resource does not have a representation (ACL Resource Representation), no Authorizations can be immediately checked against the requested resource. In this case, a container resource’s ACL resource may apply on every access to a member resource, in specifying Authorizations for the requested resource.

    -

    WAC has the property of being recursive with respect to container hierarchy, meaning that a member resource inherits Authorizations from the closest container resource (heading toward the root container).

    +

    WAC has the property of being recursive with respect to container hierarchy, meaning that a member resource inherits Authorizations from the closest container resource (heading towards the root container).

    To determine the effective ACL resource of a resource, perform the following steps. Returns string (the URI of an ACL Resource).

    From 31fee9eae7c3e5b878df8a8eba109b4bf235ffb5 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 23 Jun 2021 14:21:00 +0200 Subject: [PATCH 297/310] Link to web-application-authorization --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 4602b5fd..daf81448 100644 --- a/index.html +++ b/index.html @@ -730,7 +730,7 @@

    Authorization Evaluation

    When a request requires an access mode (acl:mode) which is a limitation of another access mode, then access is granted if either mode is allowed by an Authorization. For example, when a request requires acl:Append, then access will be granted to agents having acl:Write.

    -

    The presence of the acl:origin property and its value is taken into account in the evaluation only when the HTTP request includes the Origin header.

    +

    The presence of the acl:origin property and its value is taken into account in the evaluation only when the HTTP request includes the Origin header (Web Application Authorization).

    Reading and Writing Resources

    From 54118e7791fdbda300cedaf7b5dcd0eb8995fc94 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 25 Jun 2021 12:03:54 +0200 Subject: [PATCH 298/310] Add container-permissions --- index.html | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index daf81448..dc751080 100644 --- a/index.html +++ b/index.html @@ -138,7 +138,7 @@

    Web Access Control

    -

    Editor’s Draft, 2021-06-23

    +

    Editor’s Draft, 2021-06-25

    This version
    @@ -164,7 +164,7 @@

    Editor’s Draft, 2021-06-23

    Modified
    -
    +
    @@ -749,6 +749,15 @@

    Reading and Writing Resources

    When an operation requests to delete a resource, the server MUST match Authorizations allowing the acl:Write access privilege on the resource and the containing container.

    +
    +
    Note: Container Permissions
    +
    +

    When a server supports the creation of intermediate containers in the process of creating a resource, the server must match Authorization policies allowing acl:Write on each container.

    + +

    When a server supports the recursive deletion of a container, the server must match Authorization policies allowing acl:Write on each member resource.

    +
    +
    +
    Note: Reinstated Resource Permissions
    From d431ef03037a497ca01de886d0af32c1057df16a Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 28 Jun 2021 11:17:21 +0200 Subject: [PATCH 299/310] Rename to web-origin-authorization --- index.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/index.html b/index.html index dc751080..0d6111f0 100644 --- a/index.html +++ b/index.html @@ -138,7 +138,7 @@

    Web Access Control

    -

    Editor’s Draft, 2021-06-25

    +

    Editor’s Draft, 2021-06-28

    This version
    @@ -164,7 +164,7 @@

    Editor’s Draft, 2021-06-25

    Modified
    -
    +
    @@ -730,7 +730,7 @@

    Authorization Evaluation

    When a request requires an access mode (acl:mode) which is a limitation of another access mode, then access is granted if either mode is allowed by an Authorization. For example, when a request requires acl:Append, then access will be granted to agents having acl:Write.

    -

    The presence of the acl:origin property and its value is taken into account in the evaluation only when the HTTP request includes the Origin header (Web Application Authorization).

    +

    The presence of the acl:origin property and its value is taken into account in the evaluation only when the HTTP request includes the Origin header (Web Origin Authorization).

    Reading and Writing Resources

    @@ -790,8 +790,8 @@
    Note: HTTP Method and Access Mode Mappin
    -
    -

    Web Application Authorization

    +
    +

    Web Origin Authorization

    User agents include the HTTP Origin header field to isolate different origins and permit controlled communication between origins. The Origin header warns the server that a possibly untrusted Web application is being used.

    @@ -1125,7 +1125,7 @@

    Security and Privacy Review

    None.
    How does this specification distinguish between behaviour in first-party and third-party contexts?
    -
    When an HTTP request includes the Origin header (typical Web browsers use origin based security to warn servers), Authorizations are matched in context of the origin of the HTTP request in addition to requiring agent identification and allowed access modes. While the use of Origin is not intended as client identification, the implication is that unless servers have separate mechanisms to verify the original request made by an application, the Origin header’s field-value can differ. In order to distinguish social entities and clients supported by authentication protocols, an issue on client identification is filed.
    +
    When an HTTP request includes the Origin header (typical Web browsers use origin based security to warn servers), Authorizations are matched in context of the origin of the HTTP request in addition to requiring agent identification and allowed access modes. While the use of Origin is not intended as client identification, the implication is that unless servers have separate mechanisms to verify the original request made by an application, the Origin header’s field-value can differ. In order to distinguish social entities and clients supported by authentication protocols, an issue on client identification is filed.
    How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
    No different than browser’s 'normal' state.
    From ee67b7543e446f8efc81636d2873abc0e9eb8c4b Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 28 Jun 2021 18:34:45 +0200 Subject: [PATCH 300/310] Minor --- index.html | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index 0d6111f0..79bf62d9 100644 --- a/index.html +++ b/index.html @@ -544,7 +544,9 @@

    ACL Resource Representation

    Servers MUST accept an HTTP GET request targeting an ACL resource when the value of the Accept header requests a representation in text/turtle [TURTLE].

    -

    Servers who want a resource to inherit Authorizations (Effective ACL Resource) from a container resource MUST NOT initialise the ACL resource that is associated with the resource with a representation. When an authorized HTTP GET or HEAD request targets an ACL resource without an existing representation, the server MUST respond with the 404 status code as per [RFC7231].

    +

    Servers who want a resource to inherit Authorizations (Effective ACL Resource) from a container resource MUST NOT initialise the ACL resource that is associated with the resource with a representation.

    + +

    When an authorized HTTP GET or HEAD request targets an ACL resource without an existing representation, the server MUST respond with the 404 status code as per [RFC7231].

    The root container MUST have an ACL resource with a representation. The ACL resource of the root container MUST include an Authorization allowing the acl:Control access privilege (acl:Control access mode).

    @@ -562,7 +564,9 @@

    Authorization Rule

    Access Objects

    -

    The acl:accessTo property value is used to check if access is allowed for a specific resource. When an Authorization includes the acl:default property value (the container resource in context), then access permissions be applied to the original requested resource.

    +

    The acl:accessTo property value is used to check if access is allowed for a specific resource.

    + +

    When an Authorization includes the acl:default property value (the container resource in context), then access permissions be applied to the original requested resource.

    Inheriting Authorizations from the most significant container’s ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

    @@ -573,7 +577,7 @@

    Access Objects

    Access Modes

    -

    The access modes described in this section are defined in the ACL ontology, such as the class of operations to read, write, append and control resources. The requirements for new access modes is explained in the Access Mode Extensions section.

    +

    The access modes described in this section are defined in the ACL ontology, such as the class of operations to read, write, append and control resources. The requirements for new access modes is explained in the Access Mode Extensions section.

    The acl:mode predicate denotes a class of operations that the agents can perform on a resource.

    @@ -770,7 +774,7 @@
    Note: Reinstated Resource Permissions
    Note: HTTP Method and Access Mode Mapping
    -

    When the target of the HTTP request is the ACL resource, the operation can only be allowed with the acl:Control access mode.

    +

    When the target of the HTTP request is the ACL resource, the operation can only be allowed with the acl:Control access mode.

    Having acl:Control does not imply that the agent has acl:Read or acl:Write access to the resource itself, just to its corresponding ACL resource. For example, an agent with control access may disable their own write access (to prevent accidental over-writing of a resource by an application), but be able to change their access levels at a later point (since they retain acl:Control access).

    @@ -1042,7 +1046,7 @@

    Security Considerations

    Servers are strongly discouraged from trusting the information returned by looking up an agent’s WebID for access control purposes. The server operator can also provide the server with other trusted information to include in the search for a reason to give the requester the access.

    -

    Transfer of Authorizations between a client and server over an open network creates the potential for those policies to be modified or disclosed without proper authorization. The requirements for the Web Access Control protocol discussed in this specification do not include cryptographic protection of Authorization information, because it is assumed that this protection can be provided through HTTP over TLS. The path between client and application may be composed of multiple independent TLS connections, thus for end-to-end integrity and authenticity of content within an HTTP message, implementers can use mechanisms such as Signing HTTP Messages. For cryptographic proof of Authorizations asserted by agents and protection from undetected modifications, implementers can use mechanisms such as Linked Data Security.

    +

    Transfer of Authorizations between a client and server over an open network creates the potential for those policies to be modified or disclosed without proper authorization. The requirements for the WAC protocol discussed in this specification do not include cryptographic protection of Authorization information, because it is assumed that this protection can be provided through HTTP over TLS. The path between client and application may be composed of multiple independent TLS connections, thus for end-to-end integrity and authenticity of content within an HTTP message, implementers can use mechanisms such as Signing HTTP Messages. For cryptographic proof of Authorizations asserted by agents and protection from undetected modifications, implementers can use mechanisms such as Linked Data Security.

    Implementations are encouraged to use mechanisms to record activities about ACL resources for the purpose of accountability and integrity, e.g., by having audit trails, notification of changes, reasons for change, preserving provenance information.

    From 2fc39553e92ce2bbc5370785c92f1022eee6d084 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 28 Jun 2021 18:35:25 +0200 Subject: [PATCH 301/310] Clarify web-origin-authorization --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 79bf62d9..c02a59a8 100644 --- a/index.html +++ b/index.html @@ -803,11 +803,11 @@

    Web Origin Authorization

    • an Authorization allowing access to the requesting agent (acl:agent, acl:agentGroup, acl:agentClass);
      • -
    • an Authorization with an acl:origin property value that of Origin’s field-value; and
      • +
    • an Authorization with an acl:origin property value that of Origin’s field-value, when the required access mode is not available to all agents (acl:agentClass foaf:Agent); and
    • the required access mode is allowed for the requesting agent and the origin.
    -

    When an authorization is granted to an HTTP request including the Origin header, the server MUST include the HTTP Access-Control-Allow-Origin and Access-Control-Allow-Headers headers in the response of the HTTP request.

    +

    When a server participates in the CORS protocol [FETCH] and authorization is granted to an HTTP request including the Origin header, the server MUST include the HTTP Access-Control-Allow-Origin and Access-Control-Allow-Headers headers in the response of the HTTP request.

    Note: Access Subject and Origin Rejection Reason
    From bd4e5050f334684d34926dea1e88ef0cb53366cf Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 28 Jun 2021 18:39:51 +0200 Subject: [PATCH 302/310] Minor --- index.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index c02a59a8..2c6f66dc 100644 --- a/index.html +++ b/index.html @@ -542,7 +542,7 @@

    ACL Resource Representation

    An ACL resource is an RDF document [RDF11-CONCEPTS] that can hold any information, typically comprises an unordered set of Authorizations, any of which could permit an attempted access.

    -

    Servers MUST accept an HTTP GET request targeting an ACL resource when the value of the Accept header requests a representation in text/turtle [TURTLE].

    +

    Servers MUST accept an HTTP GET and HEAD request targeting an ACL resource when the value of the Accept header requests a representation in text/turtle [TURTLE].

    Servers who want a resource to inherit Authorizations (Effective ACL Resource) from a container resource MUST NOT initialise the ACL resource that is associated with the resource with a representation.

    @@ -566,7 +566,7 @@

    Access Objects

    The acl:accessTo property value is used to check if access is allowed for a specific resource.

    -

    When an Authorization includes the acl:default property value (the container resource in context), then access permissions be applied to the original requested resource.

    +

    The acl:default property value (the container resource in context) is used to apply the Authorization to the original requested resource.

    Inheriting Authorizations from the most significant container’s ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

    @@ -634,9 +634,9 @@

    Access Subjects

    The acl:agentClass predicate denotes a class of agents being given the access permission.

    -
    foaf:Agent
    +
    foaf:Agent
    Allows access to any agent.
    -
    acl:AuthenticatedAgent
    +
    acl:AuthenticatedAgent
    Allows access to any authenticated agent.
    From 674f74890d03ed09fd3290da2b861a756821c335 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 28 Jun 2021 18:40:50 +0200 Subject: [PATCH 303/310] Add some ids --- index.html | 92 ++++++++++++++++++++++++++++-------------------------- 1 file changed, 47 insertions(+), 45 deletions(-) diff --git a/index.html b/index.html index 2c6f66dc..243400e3 100644 --- a/index.html +++ b/index.html @@ -502,7 +502,7 @@

    ACL Resources

    ACL Resource Discovery

    -

    When a server wants to enable applications to discover Authorizations associated with a given resource, the server MUST advertise the ACL resource that is associated with a resource by responding to an HTTP request including a Link header with the rel value of acl (acl Link Relation) and the ACL resource as link target.

    +

    ACL Resource Discovery is used towards determining the Effective ACL Resource of a resource.

    @@ -513,9 +513,9 @@

    Issue: Link Relation Type

    -

    Servers MUST NOT directly associate more than one ACL resource to a resource.

    +

    Servers MUST NOT directly associate more than one ACL resource to a resource.

    -

    Clients can discover the ACL resource associated with a resource by making an HTTP request on the target URL, and checking the HTTP Link header with the rel parameter [RFC8288].

    +

    Note: ACL Resource URI Security

    @@ -531,7 +531,7 @@

    Note: URI Origin

    -

    Clients MUST NOT derive the URI of the ACL resource through string operations on the URI of the resource.

    +

    Clients MUST NOT derive the URI of the ACL resource through string operations on the URI of the resource.

    Source: issues/8, issues/62, issues/131, issues/176

    @@ -542,13 +542,15 @@

    ACL Resource Representation

    An ACL resource is an RDF document [RDF11-CONCEPTS] that can hold any information, typically comprises an unordered set of Authorizations, any of which could permit an attempted access.

    -

    Servers MUST accept an HTTP GET and HEAD request targeting an ACL resource when the value of the Accept header requests a representation in text/turtle [TURTLE].

    +

    Servers MUST accept an HTTP GET and HEAD request targeting an ACL resource when the value of the Accept header requests a representation in text/turtle [TURTLE].

    -

    Servers who want a resource to inherit Authorizations (Effective ACL Resource) from a container resource MUST NOT initialise the ACL resource that is associated with the resource with a representation.

    +

    Servers who want a resource to inherit Authorizations (Effective ACL Resource) from a container resource MUST NOT initialise the ACL resource that is associated with the resource with a representation.

    -

    When an authorized HTTP GET or HEAD request targets an ACL resource without an existing representation, the server MUST respond with the 404 status code as per [RFC7231].

    +

    When an authorized HTTP GET or HEAD request targets an ACL resource without an existing representation, the server MUST respond with the 404 status code as per [RFC7231].

    -

    The root container MUST have an ACL resource with a representation. The ACL resource of the root container MUST include an Authorization allowing the acl:Control access privilege (acl:Control access mode).

    +

    The root container MUST have an ACL resource with a representation.

    + +

    The ACL resource of the root container MUST include an Authorization allowing the acl:Control access privilege (acl:Control access mode).

    Source: issues/45

    @@ -564,9 +566,9 @@

    Authorization Rule

    Access Objects

    -

    The acl:accessTo property value is used to check if access is allowed for a specific resource.

    +

    The acl:accessTo property value is used to check if access is allowed for a specific resource.

    -

    The acl:default property value (the container resource in context) is used to apply the Authorization to the original requested resource.

    +

    The acl:default property value (the container resource in context) is used to apply the Authorization to the original requested resource.

    Inheriting Authorizations from the most significant container’s ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

    @@ -579,7 +581,7 @@

    Access Modes

    The access modes described in this section are defined in the ACL ontology, such as the class of operations to read, write, append and control resources. The requirements for new access modes is explained in the Access Mode Extensions section.

    -

    The acl:mode predicate denotes a class of operations that the agents can perform on a resource.

    +

    The acl:mode predicate denotes a class of operations that the agents can perform on a resource.

    acl:Read
    @@ -629,9 +631,9 @@

    Access Subjects

    The ability of a subject to access a resource can be granted to identifiable agents, a class of agents, a group of agents, or an origin.

    -

    The acl:agent predicate denotes an agent being given the access permission.

    +

    The acl:agent predicate denotes an agent being given the access permission.

    -

    The acl:agentClass predicate denotes a class of agents being given the access permission.

    +

    The acl:agentClass predicate denotes a class of agents being given the access permission.

    foaf:Agent
    @@ -640,9 +642,9 @@

    Access Subjects

    Allows access to any authenticated agent.
    -

    The acl:agentGroup predicate denotes a group of agents being given the access permission. The object of an acl:agentGroup statement is an instance of vcard:Group, where the members of the group are specified with the vcard:hasMember predicate.

    +

    The acl:agentGroup predicate denotes a group of agents being given the access permission. The object of an acl:agentGroup statement is an instance of vcard:Group, where the members of the group are specified with the vcard:hasMember predicate.

    -

    The acl:origin predicate denotes the origin of an HTTP request is being given the access permission.

    +

    The acl:origin predicate denotes the origin of an HTTP request is being given the access permission.

    Note: Subject Verification

    @@ -683,15 +685,15 @@

    Effective ACL Resource

    Servers enforce the effective ACL resource of a resource, whereas clients determine the effective ACL resource of a resource to perform control operations.

    -

    When an ACL resource associated with a resource has a representation (ACL Resource Representation), it is the effective ACL resource of the requested resource.

    +

    When an ACL resource associated with a resource has a representation (ACL Resource Representation), it is the effective ACL resource of the requested resource.

    -

    When an ACL resource associated with a resource does not have a representation (ACL Resource Representation), no Authorizations can be immediately checked against the requested resource. In this case, a container resource’s ACL resource may apply on every access to a member resource, in specifying Authorizations for the requested resource.

    +

    When an ACL resource associated with a resource does not have a representation (ACL Resource Representation), no Authorizations can be immediately checked against the requested resource. In this case, a container resource’s ACL resource may apply on every access to a member resource, in specifying Authorizations for the requested resource.

    -

    WAC has the property of being recursive with respect to container hierarchy, meaning that a member resource inherits Authorizations from the closest container resource (heading towards the root container).

    +

    WAC has the property of being recursive with respect to container hierarchy, meaning that a member resource inherits Authorizations from the closest container resource (heading towards the root container).

    To determine the effective ACL resource of a resource, perform the following steps. Returns string (the URI of an ACL Resource).

    -
      +
      1. Let resource be the resource.
      2. Let aclResource be the ACL resource of resource.
      3. If resource has an associated aclResource with a representation, return aclResource.
        4. @@ -728,30 +730,30 @@

        Authorization Conformance

        Authorization Evaluation

        -

        The evaluation of an authorization is concerned with finding Authorizations that match the required parameters of an operation (Authorization Conformance). Evaluation stops when all access permission requests have been granted by one or more Authorizations. Authorizations that do not match a required access permission have no effect on the outcome of the evaluation. Access is granted when conforming Authorizations are matched, otherwise access is denied.

        +

        The evaluation of an authorization is concerned with finding Authorizations that match the required parameters of an operation (Authorization Conformance). Evaluation stops when all access permission requests have been granted by one or more Authorizations. Authorizations that do not match a required access permission have no effect on the outcome of the evaluation. Access is granted when conforming Authorizations are matched, otherwise access is denied.

        -

        As per determining the Effective ACL Resource of a resource, an Authorization can be evaluated explicitly (via acl:accessTo) or inherited (via acl:default) against a particular request.

        +

        As per determining the Effective ACL Resource of a resource, an Authorization can be evaluated explicitly (via acl:accessTo) or inherited (via acl:default) against a particular request.

        -

        When a request requires an access mode (acl:mode) which is a limitation of another access mode, then access is granted if either mode is allowed by an Authorization. For example, when a request requires acl:Append, then access will be granted to agents having acl:Write.

        +

        When a request requires an access mode (acl:mode) which is a limitation of another access mode, then access is granted if either mode is allowed by an Authorization. For example, when a request requires acl:Append, then access will be granted to agents having acl:Write.

        -

        The presence of the acl:origin property and its value is taken into account in the evaluation only when the HTTP request includes the Origin header (Web Origin Authorization).

        +

        The presence of the acl:origin property and its value is taken into account in the evaluation only when the HTTP request includes the Origin header (Web Origin Authorization).

        Reading and Writing Resources

        Working alongside HTTP Interactions, WAC enables a standard set of operations which can be applied to different resource types for a given request based on the set of access modes which control those operations:

        -

        Generally: read operations attempt to confirm the existence of a resource or to view the contents of a resource; write operations attempt to create, delete, or modify resources; append operations attempt to create resources or add information to existing resources; and control operations attempt to view, create, delete, or modify ACL resources.

        +

        Generally: read operations attempt to confirm the existence of a resource or to view the contents of a resource; write operations attempt to create, delete, or modify resources; append operations attempt to create resources or add information to existing resources; and control operations attempt to view, create, delete, or modify ACL resources.

        As container resources and member resources are hierarchically organised, requests to perform operations on resources are in the context of the applicable container (Effective ACL Resource).

        -

        When an operation requests to read a resource, the server MUST match an Authorization allowing the acl:Read access privilege on the resource.

        +

        When an operation requests to read a resource, the server MUST match an Authorization allowing the acl:Read access privilege on the resource.

        -

        When an operation requests to create a resource as a member of a container resource, the server MUST match an Authorization allowing the acl:Append or acl:Write access privilege on the container for new members.

        +

        When an operation requests to create a resource as a member of a container resource, the server MUST match an Authorization allowing the acl:Append or acl:Write access privilege on the container for new members.

        -

        When an operation requests to update a resource, the server MUST match an Authorization allowing the acl:Append or acl:Write access privilege on the resource.

        +

        When an operation requests to update a resource, the server MUST match an Authorization allowing the acl:Append or acl:Write access privilege on the resource.

        -

        When an operation requests to delete a resource, the server MUST match Authorizations allowing the acl:Write access privilege on the resource and the containing container.

        +

        When an operation requests to delete a resource, the server MUST match Authorizations allowing the acl:Write access privilege on the resource and the containing container.

        Note: Container Permissions
        @@ -769,7 +771,7 @@
        Note: Reinstated Resource Permissions
        -

        When an operation requests to read and write an ACL resource, the server MUST match an Authorization allowing the acl:Control access privilege on the resource.

        +

        When an operation requests to read and write an ACL resource, the server MUST match an Authorization allowing the acl:Control access privilege on the resource.

        Note: HTTP Method and Access Mode Mapping
        @@ -799,7 +801,7 @@

        Web Origin Authorization

        User agents include the HTTP Origin header field to isolate different origins and permit controlled communication between origins. The Origin header warns the server that a possibly untrusted Web application is being used.

        -

        When an HTTP request includes the Origin header, the requested operation is granted on the target resource when there is a match for:

        +

        When an HTTP request includes the Origin header, the requested operation is granted on the target resource when there is a match for:

        • an Authorization allowing access to the requesting agent (acl:agent, acl:agentGroup, acl:agentClass);
          • @@ -807,7 +809,7 @@

          Web Origin Authorization

        • the required access mode is allowed for the requesting agent and the origin.
        -

        When a server participates in the CORS protocol [FETCH] and authorization is granted to an HTTP request including the Origin header, the server MUST include the HTTP Access-Control-Allow-Origin and Access-Control-Allow-Headers headers in the response of the HTTP request.

        +

        When a server participates in the CORS protocol [FETCH] and authorization is granted to an HTTP request including the Origin header, the server MUST include the HTTP Access-Control-Allow-Origin and Access-Control-Allow-Headers headers in the response of the HTTP request.

        Note: Access Subject and Origin Rejection Reason
        @@ -823,7 +825,7 @@
        Note: Trusted Origins
        -

        Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (WAC-Allow) in the response of HTTP GET and HEAD requests.

        +

        Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (WAC-Allow) in the response of HTTP GET and HEAD requests.

        Note: Clients Discovering Access Privileges
        @@ -832,7 +834,7 @@
        Note: Clients Discovering Access Privile
        -

        When a server participates in the CORS protocol [FETCH], the server MUST include WAC-Allow in the Access-Control-Expose-Headers field-value in the HTTP response.

        +

        When a server participates in the CORS protocol [FETCH], the server MUST include WAC-Allow in the Access-Control-Expose-Headers field-value in the HTTP response.

        @@ -991,9 +993,9 @@

        Authorization Extensions

        This section is non-normative.

        -

        As ACL resources are RDF sources; Authorization descriptions may be extended or limited by constraints, e.g., temporal or spatial constraints; and duties, e.g., payments, may be imposed on permissions; but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

        +

        As ACL resources are RDF sources; Authorization descriptions may be extended or limited by constraints, e.g., temporal or spatial constraints; and duties, e.g., payments, may be imposed on permissions; but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

        -

        To allow access to a class of resources, implementations may want to use the acl:accessToClass predicate as defined in the ACL ontology.

        +

        To allow access to a class of resources, implementations may want to use the acl:accessToClass predicate as defined in the ACL ontology.

        Source: issues/10, issues/22, pull/37, issues/20

        @@ -1002,7 +1004,7 @@

        Authorization Extensions

        Access Mode Extensions

        -

        An extension to access modes is any mode that is defined in the ACL ontology, i.e., as a subclass of acl:Access, but not described in this specification (Access Modes). Consumers of Authorizations that encounter unrecognised access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.

        +

        An extension to access modes is any mode that is defined in the ACL ontology, i.e., as a subclass of acl:Access, but not described in this specification (Access Modes). Consumers of Authorizations that encounter unrecognised access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.

        Foreign-namespaced access modes are allowed in ACL resources, but they MUST NOT cause increased access.

        @@ -1013,7 +1015,7 @@

        Permission Inheritance Extensions

        This section is non-normative.

        -

        This specification describes permission inheritance based on determining the Effective ACL Resource of a resource. Alternative strategies such as cumulative permissions (union of all the permissions from each ACL resource inherited from the ancestors of a resource) are allowed, but no behaviour is defined by this specification.

        +

        This specification describes permission inheritance based on determining the Effective ACL Resource of a resource. Alternative strategies such as cumulative permissions (union of all the permissions from each ACL resource inherited from the ancestors of a resource) are allowed, but no behaviour is defined by this specification.

        @@ -1022,7 +1024,7 @@

        Distinct Effective ACL Resource Extensions

        This section is non-normative.

        -

        This specification describes the use of acl Link Relation for ACL Resource Discovery and the algorithm to determine the Effective ACL Resource of a resource. To enable clients to perform discovery faster, separate link relation type targeting the effective ACL resource is allowed, but no behaviour is defined by this specification.

        +

        This specification describes the use of acl Link Relation for ACL Resource Discovery and the algorithm to determine the Effective ACL Resource of a resource. To enable clients to perform discovery faster, separate link relation type targeting the effective ACL resource is allowed, but no behaviour is defined by this specification.

    @@ -1042,15 +1044,15 @@

    Security Considerations

    While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

    -

    Implementations are encouraged to follow the security considerations that are found in URI Generic Syntax, HTTP/1.1 Message Syntax and Routing and Semantics and Content.

    +

    Implementations are encouraged to follow the security considerations that are found in URI Generic Syntax, HTTP/1.1 Message Syntax and Routing and Semantics and Content.

    -

    Servers are strongly discouraged from trusting the information returned by looking up an agent’s WebID for access control purposes. The server operator can also provide the server with other trusted information to include in the search for a reason to give the requester the access.

    +

    Servers are strongly discouraged from trusting the information returned by looking up an agent’s WebID for access control purposes. The server operator can also provide the server with other trusted information to include in the search for a reason to give the requester the access.

    -

    Transfer of Authorizations between a client and server over an open network creates the potential for those policies to be modified or disclosed without proper authorization. The requirements for the WAC protocol discussed in this specification do not include cryptographic protection of Authorization information, because it is assumed that this protection can be provided through HTTP over TLS. The path between client and application may be composed of multiple independent TLS connections, thus for end-to-end integrity and authenticity of content within an HTTP message, implementers can use mechanisms such as Signing HTTP Messages. For cryptographic proof of Authorizations asserted by agents and protection from undetected modifications, implementers can use mechanisms such as Linked Data Security.

    +

    Transfer of Authorizations between a client and server over an open network creates the potential for those policies to be modified or disclosed without proper authorization. The requirements for the WAC protocol discussed in this specification do not include cryptographic protection of Authorization information, because it is assumed that this protection can be provided through HTTP over TLS. The path between client and application may be composed of multiple independent TLS connections, thus for end-to-end integrity and authenticity of content within an HTTP message, implementers can use mechanisms such as Signing HTTP Messages. For cryptographic proof of Authorizations asserted by agents and protection from undetected modifications, implementers can use mechanisms such as Linked Data Security.

    -

    Implementations are encouraged to use mechanisms to record activities about ACL resources for the purpose of accountability and integrity, e.g., by having audit trails, notification of changes, reasons for change, preserving provenance information.

    +

    Implementations are encouraged to use mechanisms to record activities about ACL resources for the purpose of accountability and integrity, e.g., by having audit trails, notification of changes, reasons for change, preserving provenance information.

    -

    Implementations that want to allow a class of write or control operations on resources are encouraged to require agents to be authenticated, e.g., for purposes of provenance or accountability.

    +

    Implementations that want to allow a class of write or control operations on resources are encouraged to require agents to be authenticated, e.g., for purposes of provenance or accountability.

    @@ -1061,9 +1063,9 @@

    Privacy Considerations

    The class of read and write operations require discrete access permissions:

    -

    Access permission to append a new resource to a container resource is independently of access permission to read a container resource. Thus, servers are encouraged to prevent information leakage when a successful HTTP request appends a new resource to a container resource. For instance, while the knowledge of the URI-Reference in Location and Content-Location HTTP headers in the response of a POST does not in itself pose a security threat ([RFC3986]), servers should consider the risks when read access to the container is not granted to agents.

    +

    Access permission to append a new resource to a container resource is independently of access permission to read a container resource. Thus, servers are encouraged to prevent information leakage when a successful HTTP request appends a new resource to a container resource. For instance, while the knowledge of the URI-Reference in Location and Content-Location HTTP headers in the response of a POST does not in itself pose a security threat ([RFC3986]), servers should consider the risks when read access to the container is not granted to agents.

    -

    Access permission to update a resource is independently of access permission to read a resource. Thus, servers are encouraged to prevent information leakage when an attempt to delete information in a resource may reveal the existence of the information. For instance, when an HTTP PATCH request uses SPARQL Update’s DELETE DATA operation, servers should consider the risks of disclosing information by the chosen status code when read access to the resource is not granted to agents.

    +

    Access permission to update a resource is independently of access permission to read a resource. Thus, servers are encouraged to prevent information leakage when an attempt to delete information in a resource may reveal the existence of the information. For instance, when an HTTP PATCH request uses SPARQL Update’s DELETE DATA operation, servers should consider the risks of disclosing information by the chosen status code when read access to the resource is not granted to agents.

    From 9ad594d4307356bfd3e4808115e354297ab8ba60 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 28 Jun 2021 18:41:58 +0200 Subject: [PATCH 304/310] Fix typo --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 243400e3..fd35dbde 100644 --- a/index.html +++ b/index.html @@ -370,7 +370,7 @@

    Intro

    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.

    -

    The WAC specification describes how to enable applications to discover Authorizations associated with a given resource, and to control such policies, as directed by an agent. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Any kind of access can be given to a resource as per the ACL ontology. This specification uses the access modes currently defined by the ACL ontology, such as the class of operations to read, write, append and control resources. An Authorization may allow public access to resources or place the requirement for authenticated agents. Resources and agents can be on different origins.

    +

    The WAC specification describes how to enable applications to discover Authorizations associated with a given resource, and to control such policies, as directed by an agent. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Any kind of access can be given to a resource as per the ACL ontology. This specification uses the access modes currently defined by the ACL ontology, such as the class of operations to read, write, append and control resources. An Authorization may allow public access to resources or place the requirement for authenticated agents. Resources and agents can be on different origins.

    Note: Specification Orthogonality

    @@ -995,7 +995,7 @@

    Authorization Extensions

    As ACL resources are RDF sources; Authorization descriptions may be extended or limited by constraints, e.g., temporal or spatial constraints; and duties, e.g., payments, may be imposed on permissions; but no behaviour is defined by this specification. For example, the ODRL Information Model can be used to set obligations required to be met by agents prior to accessing a resource.

    -

    To allow access to a class of resources, implementations may want to use the acl:accessToClass predicate as defined in the ACL ontology.

    +

    To allow access to a class of resources, implementations may want to use the acl:accessToClass predicate as defined in the ACL ontology.

    Source: issues/10, issues/22, pull/37, issues/20

    @@ -1004,7 +1004,7 @@

    Authorization Extensions

    Access Mode Extensions

    -

    An extension to access modes is any mode that is defined in the ACL ontology, i.e., as a subclass of acl:Access, but not described in this specification (Access Modes). Consumers of Authorizations that encounter unrecognised access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.

    +

    An extension to access modes is any mode that is defined in the ACL ontology, i.e., as a subclass of acl:Access, but not described in this specification (Access Modes). Consumers of Authorizations that encounter unrecognised access modes MUST NOT stop processing or signal an error and MUST continue processing the access modes as if those properties were not present.

    Foreign-namespaced access modes are allowed in ACL resources, but they MUST NOT cause increased access.

    From cad7a7942e83033501e9f6c08761e6f14bafec44 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 30 Jun 2021 00:29:48 +0200 Subject: [PATCH 305/310] Apply suggestions from code review Co-authored-by: Matthieu Bosquet --- index.html | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index fd35dbde..dc000ac3 100644 --- a/index.html +++ b/index.html @@ -411,7 +411,7 @@

    Terminology

    A root container is a container resource that is at the highest level of the collection hierarchy.
    ACL resource
    -
    An ACL resource is represented by an RDF document [RDF11-CONCEPTS] that includes Authorizations to access resources.
    +
    An ACL resource is represented by an RDF document [RDF11-CONCEPTS] that includes Authorizations determining access to resources.
    Authorization
    An Authorization is an abstract thing identified by a URI whose properties are defined in an ACL resource, e.g., access modes granted to agents the ability to perform operations on resources.
    @@ -561,7 +561,7 @@

    ACL Resource Representation

    Authorization Rule

    -

    Authorization (instance of acl:Authorization) is the most fundamental unit of access control describing access permissions granted to agents the ability to perform operations on resources. Authorizations are described with RDF statements and may express any information. This section describes the following characteristics of an Authorization: access objects to specify what can be accessed, access modes to specify permissions, and access subjects to specify who can access the objects. See the Authorization Conformance section for applicable Authorizations towards Authorization Evaluation.

    +

    Authorization (instance of acl:Authorization) is the most fundamental unit of access control describing access permissions granting to agents the ability to perform operations on resources. Authorizations are described with RDF statements and may express any information. This section describes the following characteristics of an Authorization: access objects to specify what can be accessed, access modes to specify permissions, and access subjects to specify who can access the objects. See the Authorization Conformance section for applicable Authorizations towards Authorization Evaluation.

    Access Objects

    @@ -635,6 +635,7 @@

    Access Subjects

    The acl:agentClass predicate denotes a class of agents being given the access permission.

    +

    Two agent classes are defined here:

    foaf:Agent
    Allows access to any agent.
    @@ -1063,9 +1064,9 @@

    Privacy Considerations

    The class of read and write operations require discrete access permissions:

    -

    Access permission to append a new resource to a container resource is independently of access permission to read a container resource. Thus, servers are encouraged to prevent information leakage when a successful HTTP request appends a new resource to a container resource. For instance, while the knowledge of the URI-Reference in Location and Content-Location HTTP headers in the response of a POST does not in itself pose a security threat ([RFC3986]), servers should consider the risks when read access to the container is not granted to agents.

    +

    Access permission to append a new resource to a container resource is independent of access permission to read a container resource. Thus, servers are encouraged to prevent information leakage when a successful HTTP request appends a new resource to a container resource. For instance, while the knowledge of the URI-Reference in Location and Content-Location HTTP headers in the response of a POST does not in itself pose a security threat ([RFC3986]), servers should consider the risks when read access to the container is not granted to agents.

    -

    Access permission to update a resource is independently of access permission to read a resource. Thus, servers are encouraged to prevent information leakage when an attempt to delete information in a resource may reveal the existence of the information. For instance, when an HTTP PATCH request uses SPARQL Update’s DELETE DATA operation, servers should consider the risks of disclosing information by the chosen status code when read access to the resource is not granted to agents.

    +

    Access permission to update a resource is independent of access permission to read a resource. Thus, servers are encouraged to prevent information leakage when an attempt to delete information in a resource may reveal the existence of the information. For instance, when an HTTP PATCH request uses SPARQL Update’s DELETE DATA operation, servers should consider the risks of disclosing information by the chosen status code when read access to the resource is not granted to agents.

    From dd2c28faea1daf575cee63c7175e3621f7f68be7 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 30 Jun 2021 00:41:23 +0200 Subject: [PATCH 306/310] Add access-privileges including WAC-Allow --- index.html | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/index.html b/index.html index dc000ac3..8072a220 100644 --- a/index.html +++ b/index.html @@ -138,7 +138,7 @@
    - -

    Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (WAC-Allow) in the response of HTTP GET and HEAD requests.

    - -
    -
    Note: Clients Discovering Access Privileges
    -
    -

    Clients can discover access privileges on a resource by making an HTTP HEAD or GET request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (WAC-Allow).

    -
    -
    - -

    When a server participates in the CORS protocol [FETCH], the server MUST include WAC-Allow in the Access-Control-Expose-Headers field-value in the HTTP response.

    @@ -917,6 +907,22 @@

    Authorization Matching

    + +
    +

    Access Privileges

    +
    +

    Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (WAC-Allow) in the response of HTTP GET and HEAD requests.

    + +
    +
    Note: Clients Discovering Access Privileges
    +
    +

    Clients can discover access privileges on a resource by making an HTTP HEAD or GET request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (WAC-Allow).

    +
    +
    + +

    When a server participates in the CORS protocol [FETCH], the server MUST include WAC-Allow in the Access-Control-Expose-Headers field-value in the HTTP response.

    +
    +
    From 173654fd4318078d2bcfac4ee95c2450aa17d18f Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 30 Jun 2021 01:06:41 +0200 Subject: [PATCH 307/310] Editorial suggestions from @matthieubosquet with some updates --- index.html | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/index.html b/index.html index 8072a220..31f28238 100644 --- a/index.html +++ b/index.html @@ -415,7 +415,7 @@

    Terminology

    An ACL resource is represented by an RDF document [RDF11-CONCEPTS] that includes Authorizations determining access to resources.
    Authorization
    -
    An Authorization is an abstract thing identified by a URI whose properties are defined in an ACL resource, e.g., access modes granted to agents the ability to perform operations on resources.
    +
    An Authorization is an abstract thing which is identified by a URI and whose properties are defined in an ACL resource, e.g., access modes granted to agents the ability to perform operations on resources.
    access mode
    An access mode is a class of operations that can be performed on one or more resources.
    @@ -567,9 +567,9 @@

    Authorization Rule

    Access Objects

    -

    The acl:accessTo property value is used to check if access is allowed for a specific resource.

    +

    The acl:accessTo predicate denotes the resource to which access is being granted.

    -

    The acl:default property value (the container resource in context) is used to apply the Authorization to the original requested resource.

    +

    The acl:default predicate denotes the container resource to which an Authorization can be applied to a resource lower in the collection hierarchy.

    Inheriting Authorizations from the most significant container’s ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

    @@ -636,17 +636,18 @@

    Access Subjects

    The acl:agentClass predicate denotes a class of agents being given the access permission.

    -

    Two agent classes are defined here:

    +

    Two agent classes are defined here:

    +
    foaf:Agent
    -
    Allows access to any agent.
    +
    Allows access to any agent, i.e., the public.
    acl:AuthenticatedAgent
    Allows access to any authenticated agent.

    The acl:agentGroup predicate denotes a group of agents being given the access permission. The object of an acl:agentGroup statement is an instance of vcard:Group, where the members of the group are specified with the vcard:hasMember predicate.

    -

    The acl:origin predicate denotes the origin of an HTTP request is being given the access permission.

    +

    The acl:origin predicate denotes the origin of an HTTP request that is being given the access permission.

    Note: Subject Verification

    From ee960983b8143c9c103d63f24cd3b72c6feb6995 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 30 Jun 2021 07:51:56 +0200 Subject: [PATCH 308/310] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 31f28238..53061270 100644 --- a/index.html +++ b/index.html @@ -569,7 +569,7 @@

    Access Objects

    The acl:accessTo predicate denotes the resource to which access is being granted.

    -

    The acl:default predicate denotes the container resource to which an Authorization can be applied to a resource lower in the collection hierarchy.

    +

    The acl:default predicate denotes the container resource whose Authorization can be applied to a resource lower in the collection hierarchy.

    Inheriting Authorizations from the most significant container’s ACL resource is useful to avoid individually managing an ACL resource for each resource, as well as to define access control for resources that do not exist yet.

    From 6be582092d3dc72b60841a073024f0bead08bfe9 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 30 Jun 2021 09:49:31 +0200 Subject: [PATCH 309/310] Minor --- index.html | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/index.html b/index.html index 53061270..8806752d 100644 --- a/index.html +++ b/index.html @@ -138,7 +138,7 @@

    Web Access Control

    -

    Editor’s Draft, 2021-06-29

    +

    Editor’s Draft, 2021-06-30

    This version
    @@ -164,7 +164,7 @@

    Editor’s Draft, 2021-06-29

    Modified
    -
    +
    @@ -503,7 +503,7 @@

    ACL Resources

    ACL Resource Discovery

    - +

    ACL Resource Discovery is used towards determining the Effective ACL Resource of a resource.

    @@ -516,7 +516,7 @@

    Issue: Link Relation Type

    Servers MUST NOT directly associate more than one ACL resource to a resource.

    - +

    Note: ACL Resource URI Security

    @@ -914,12 +914,7 @@

    Access Privileges

    Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (WAC-Allow) in the response of HTTP GET and HEAD requests.

    -
    -
    Note: Clients Discovering Access Privileges
    -
    -

    Clients can discover access privileges on a resource by making an HTTP HEAD or GET request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (WAC-Allow).

    -
    -
    +

    Clients can discover access privileges on a resource by making an HTTP GET or HEAD request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (WAC-Allow).

    When a server participates in the CORS protocol [FETCH], the server MUST include WAC-Allow in the Access-Control-Expose-Headers field-value in the HTTP response.

    From 7c61e0ace3d75ee62e63f2d54bce397dd0437f41 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Wed, 30 Jun 2021 22:12:34 +0200 Subject: [PATCH 310/310] Use ED URLs for the ED version --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 8806752d..91edce68 100644 --- a/index.html +++ b/index.html @@ -142,7 +142,7 @@

    Editor’s Draft, 2021-06-30

    This version
    -
    https://solidproject.org/TR/wac
    +
    https://solid.github.io/web-access-control-spec/
    @@ -216,9 +216,9 @@

    Editor’s Draft, 2021-06-30

    Rule
    Offer
    Unique Identifier
    -
    https://solidproject.org/TR/wac#document-policy-offer
    +
    https://solid.github.io/web-access-control-spec/#document-policy-offer
    Target
    -
    https://solidproject.org/TR/wac
    +
    https://solid.github.io/web-access-control-spec/
    Permission