From 2d6214cecd5ddceccfd09fd1e8c64545b60bfd87 Mon Sep 17 00:00:00 2001 From: Aaron Coburn Date: Fri, 13 May 2022 15:43:17 -0400 Subject: [PATCH 1/9] Propose the Access Control Policy authorization mechanism for inclusion in the Solid specification --- 2022/acp-20220513.html | 3018 ++++++++++++++++++++++++++++++ 2022/acp-code-20220513.css | 289 +++ 2022/acp-data-model-20220513.svg | 1 + 2022/acp-main-20220513.css | 136 ++ index.html | 2 +- 5 files changed, 3445 insertions(+), 1 deletion(-) create mode 100644 2022/acp-20220513.html create mode 100644 2022/acp-code-20220513.css create mode 100644 2022/acp-data-model-20220513.svg create mode 100644 2022/acp-main-20220513.css diff --git a/2022/acp-20220513.html b/2022/acp-20220513.html new file mode 100644 index 00000000..84d7f5ac --- /dev/null +++ b/2022/acp-20220513.html @@ -0,0 +1,3018 @@ + + + + + + + Access Control Policy (ACP) + + + + + +
+ +

Access Control Policy (ACP)

+

+ Version 0.9.0, + +

+
+ More details about this document +
+
This version
+
+ https://solidproject.org/TR/2022/acp-20220513 +
+
Latest version
+
+ https://solidproject.org/TR/acp +
+
Editor's draft
+
+ https://solid.github.io/authorization-panel/acp-specification +
+
Source repository
+
+ https://github.com/solid/authorization-panel +
+
Issue tracking
+
+ https://github.com/solid/authorization-panel/issues +
+
License
+
+ MIT License +
+
Editors
+
+ +
+
+
+ +
+ +
+

Abstract

+

+ This document defines the + Access Control Policy Language (ACP). + ACP is a language for describing, controlling and granting access to + resources. +

+
+ +
+

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. +

+
+ +
+
+

+ 1. Introduction +

+

+ This section introduces ACP with an overview of key terminology, an + explanation of the conventions used in this document, example graphs + to illustrate basic concepts of resource access description and + validation, a diagram representing the main elements of the ACP data + model, and a non-normative RDF representation of the ACP ontology. +

+ +
+

+ 1.1. RDF terminology +

+

+ This document uses the terms + resource, + property, + RDF vocabulary, + namespace, + namespace IRI, + namespace prefix, + RDF graph, + RDF triple, + IRI, + literal, + blank node, + node + of an RDF graph, + RDF term, + subject, + predicate, and + object + of RDF triples, + datatype, and + IRI + and + literal term equality + as defined in RDF 1.1 Concepts and Abstract Syntax + RDF11 CONCEPTS. +

+
+ +
+

+ 1.2. RDF vocabularies and namespace IRIs +

+

+ This document uses the following RDF vocabularies and corresponding + namespace prefix bindings: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PrefixNamespace
+ acp: + + http://www.w3.org/ns/solid/acp# +
acl: + http://www.w3.org/ns/auth/acl# +
ex: + https://example.org/ +
ldp: + http://www.w3.org/ns/ldp# +
rdf: + http://www.w3.org/1999/02/22-rdf-syntax-ns# +
rdfs: + http://www.w3.org/2000/01/rdf-schema# +
owl: + http://www.w3.org/2002/07/owl# +
+
+ +
+

+ 1.3. ACP terminology +

+

This section is non-normative.

+ +
+
Context graph
+
+ Context graphs describe the + attributes of resource access instances. Those attributes can be + matched to sets of conditions defined in the form of an + authorization graph + in order to determine Access Modes granted over resources. +
+
Authorization graph
+
+ Authorization graphs + authoritatively define the conditions for granting Access Modes + over resources through Access Controls, Policies and Matchers. The + result of applying an authorization graph to a described instance + of resource access is an + access grant graph. +
+
Access grant graph
+
+ Access grant graphs describe + sets of granted access modes over resources in the context of + resource access instances. +
+
+
+ +
+

+ 1.4. Example graphs +

+

This section is non-normative.

+ +

+ Throughout this document, color-coded boxes contain the RDF + representation of example context graphs, authorization graphs, and + access grant graphs serialized in Turtle. Those graphs use a mix of + IRIs and blank nodes where applicable to better show the range of + possible representations. +

+ +

+ The following example + context graph describes an + instance of resource access and could be translated as: + "Bob is trying to access resource X using client application Y + with his identity asserted by identity provider Z.". +

+ + 
+# This box contains a context graph
+# It describes an instance of resource access  
+
+[]
+  acp:agent ex:Bob ;
+  acp:target ex:resourceX ;
+  acp:client ex:ClientApplicationY ;
+  acp:issuer ex:IdentityProviderZ .
+
+ +

+ The following example + authorization graph + authoritatively defines the conditions of access to resource X and + could be translated as: + "Access to resource X is mandated by one Access Control that + applies one Policy which allows access mode + acl:Read when the agent matcher is satisfied that + Alice or Bob are the agent trying to access resource X.". +

+ + 
+# This box contains an authorization graph
+# It describes the conditions required for accessing a resource  
+
+[]
+  a acp:AccessControlResource ;
+  acp:resource ex:resourceX ;
+  acp:accessControl [
+    a acp:AccessControl ;
+    acp:apply [
+      a acp:Policy ;
+      acp:allow acl:Read ;
+      acp:anyOf [
+        a acp:AgentMatcher ;
+        acp:agent ex:Alice, ex:Bob ;
+      ]
+    ]
+  ] .
+
+ +

+ The following example + access grant graph is + the result of applying the previous example authorization graph + which defines access to resource X to the previous example context + graph which describes an instance of access to target resource X. + Bob is matched as the context agent and since it defines no further + restrictions, the policy allowing acl:Read is + satisfied. The following access grant graph could be read as: + "The access mode acl:Read is granted to Bob whom + requested access to resource X using client application Y and + whose identity was asserted by identity provider Z.". +

+ + 
+# This box contains an access grant graph
+# It describes in context the granted access over a resource  
+
+[]
+  acp:grant acl:Read ;
+  acp:context [
+    acp:agent ex:Bob ;
+    acp:target ex:resourceX ;
+    acp:client ex:ClientApplicationY ;
+    acp:issuer ex:IdentityProviderZ ;
+  ] .
+
+
+ +
+

+ 1.5. Data model +

+

This section is non-normative.

+

The following diagram illustrates the main elements of ACP.

+ ACP Data Model +
+ +
+

+ 1.6. Ontology +

+

+ All terms defined by the Access Control Policy Language are present + in a non-normative RDF representation of the + ACP ontology serialized in turtle. +

+
+
+ +
+

+ 2. Conformance +

+

+ All assertions, diagrams, examples, pseudocode 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 defined in + RFC 2119. +

+ +

+ Only UPPERCASE usage of the key words defined in RFC 2119 have special + meanings, as per + RFC 8174. +

+
+ +
+

+ 3. Context Graph +

+

+ This section introduces the ACP terms used to describe instances of + resource access. +

+ +
+

+ 3.1. Context +

+
+
+ acp:Context +
+
+ Instances of the Context class + describe instances of resource access. +
+ +
+ acp:attribute +
+
+ The attribute properties + defined by ACP describe + instances + of + resource + access. +
+ +
+ acp:target +
+
+ The target + attribute + describes requested resources. +
+ +
+ acp:mode +
+
+ The mode + attribute + describes requested modes of access. +
+ +
+ acp:agent +
+
+ The agent + attribute + describes agents initiating requests. +
+ +
+ acp:creator +
+
+ The creator + attribute + describes creators of requested resources. +
+ +
+ acp:owner +
+
+ The owner + attribute + describes owners of requested resources. +
+ +
+ acp:client +
+
+ The client + attribute + describes client applications used to request resources. +
+ +
+ acp:issuer +
+
+ The issuer + attribute + describes identity providers used to assert the identity of agents + requesting resources. +
+ +
+ acp:time +
+
+ The time + attribute + describes times of resource access requests. +
+ +
+ acp:vc +
+
+ The vc + attribute + describes verifiable credentials presented as part of resource + access requests. +
+
+ +
+

+ 3.1.1. Example Context +

+ +

+ The following example context graph denotes instances of resource + access over resource X initiated by Bob. +

+ + 
+[]
+  a acp:Context ;
+  acp:agent ex:Bob .  
+
+ +

+ The following example context graph denotes instances of resource + access over resource X initiated by Bob using client application Y + where Bob's identity is asserted by identity provider Z, Bob is + the owner of resource X, and Alice is the creator of resource X. +

+ + 
+ex:contextA
+  acp:agent ex:Bob ;
+  acp:target ex:resourceX ;
+  acp:owner ex:Bob ;
+  acp:creator ex:Alice ;
+  acp:client ex:ClientApplicationY ;  
+  acp:issuer ex:IdentityProviderZ .
+
+ +

+ The following example context graph denotes instances of resource + access where client application X or client application Y are used + and identity is asserted by identity provider Z. +

+ + 
+[
+  acp:client ex:ClientApplicationX, ex:ClientApplicationY ;  
+  acp:issuer ex:IdentityProviderZ ;
+] .
+
+
+
+ +
+

+ 3.2. Context extensibility +

+

+ Sub-properties of acp:attribute can be created to fit + the specific resource access description requirements of + applications. +

+ +
+

+ 3.2.1. Example Context extension +

+

+ Let's imagine a property ex:tag defined as a an + rdfs:subPropertyOf acp:attribute that would describe + tags applied to requested resources. If such a property was + defined, then the following example context graph would denote + instances of resource access over resource X initiated by Bob + where resource X was tagged ex:Music and + ex:FavouriteRecord. +

+ + 
+ex:contextA
+  acp:agent ex:Bob ;
+  acp:target ex:resourceX ;
+  ex:tag ex:Music, ex:FavouriteRecord .  
+
+
+
+
+ +
+

+ 4. Authorization Graph +

+

+ This section introduces the ACP terms used to control access to + resources. +

+ +
+

+ 4.1. Access Control Resource +

+
+
+ acp:AccessControlResource +
+
+ Instances of the + Access Control Resource (ACR) + class connect resources to their Access Controls. +
+ +
+ acp:resource +
+
+ The resource property connects + ACRs + to + resources + they control. It is the inverse of + acp:accessControlResource. +
+ +
+ acp:accessControl +
+
+ The access control property + connects + ACRs + to + Access Controls. +
+ +
+ acp:memberAccessControl +
+
+ The + member access control property + transitively connects + ACRs + of member resources to + Access Controls. +
+
+ +
+

+ 4.1.1. Example Access Control Resource +

+

+ The following example authorization graph means that access to + resource X is controlled by both Access Controls B and C; + furthermore, access to members of resource X is controlled by + Access Control D. +

+ + 
+ex:accessControlResourceA
+  acp:resource ex:resourceX ;
+  acp:accessControl ex:accessControlB, ex:accessControlC ;  
+  acp:memberAccessControl ex:accessControlD .
+
+
+
+ +
+

+ 4.2. Access Control +

+
+
+ acp:AccessControl +
+
+ Instances of the + Access Control class connect + Access Control Resources to their Policies. +
+ +
+ acp:apply +
+
+ The apply property connects + Access Controls + to the + Policies + they apply to resources. +
+
+ +
+

+ 4.2.1. Example Access Control +

+

+ The following example authorization graph means that access to + resource X is controlled by Policy C. +

+ + 
+ex:accessControlResourceA
+  acp:resource ex:resourceX ;  
+  acp:accessControl [
+    acp:apply ex:policyC ;
+  ] .
+
+ +

+ The following two example authorization graphs mean that access to + resource X is controlled by Policy D and Policy E. +

+ + 
+ex:accessControlResourceA
+  acp:resource ex:resourceX ;
+  acp:accessControl ex:accessControlB, ex:accessControlC .  
+
+ex:accessControlB
+  acp:apply ex:policyD .
+
+ex:accessControlC
+  acp:apply ex:policyE .
+
+ + 
+[]
+  acp:resource ex:resourceX ;
+  acp:accessControl ex:accessControlF .  
+
+ex:accessControlF
+  acp:apply ex:policyD, ex:policyE .
+
+
+
+ +
+

+ 4.3. Policy +

+
+
+ acp:Policy +
+
+ Instances of the Policy class + connect Access Controls to allowed and denied Access Modes as well + as sets of Matchers describing instances of resource access. +
+ +
+ acp:allow +
+
+ The allow property connects + Policies + to the + Access Modes + they allow if satisfied. +
+ +
+ acp:deny +
+
+ The deny property connects + Policies + to the + Access Modes + they deny if satisfied. +
+ +
+ acp:allOf +
+
+ The all of property connects + Policies + to the set of + Matchers + all of which MUST must be satisfied for the Policy to be + satisfied. +
+ +
+ acp:anyOf +
+
+ The any of property connects + Policies + to the set of + Matchers + at least one of which MUST be satisfied for the Policy to be + satisfied. +
+ +
+ acp:noneOf +
+
+ The none of property connects + Policies + to the set of + Matchers + all of which MUST NOT be satisfied for the Policy to be satisfied. +
+
+ +
+

+ 4.3.1. Example Policy +

+

+ The following example authorization graph means that Policy A will + allow Read for instances of resource access satisfying both + Matcher B and Matcher C. +

+ + 
+ex:policyA
+  acp:allow acl:Read ;
+  acp:allOf ex:matcherB, ex:matcherC .  
+
+ +

+ The following example authorization graph means that a Policy will + deny Write for instances of resource access satisfying either + Matcher B or Matcher C. +

+ + 
+[]
+  acp:deny acl:Write ;
+  acp:anyOf ex:matcherB, ex:matcherC .  
+
+ +

+ The following example authorization graph means that Reading and + Writing resource X will be allowed for instances of resource + access satisfying Matcher A and not Matcher B. +

+ + 
+[
+  acp:resource ex:resourceX ;
+  acp:accessControl [
+    acp:apply [
+      acp:allow acl:Read, acl:Write ;  
+      acp:anyOf ex:matcherA ;
+      acp:noneOf ex:matcherB ;
+    ] ;
+  ] ;
+] .
+
+
+
+ +
+

+ 4.4. Matcher +

+
+
+ acp:Matcher +
+
+ Instances of the Matcher class + are descriptions of matching resource access Contexts. To satisfy + a Matcher, every described resource access attribute must match + the resource access Context. +
+ +
+ acp:agent +
+
+ The agent attribute used in a Matcher defines a set of agents, at + least one of which MUST match the resource access Context for the + agent restriction to be satisfied. +
+ +
+ acp:PublicAgent +
+
+ The Public Agent named + individual used in an agent restriction means that the restriction + is always satisfied. +
+ +
+ acp:AuthenticatedAgent +
+
+ The Authenticated Agent named + individual used in an agent restriction means that any agent in + the Context satisfies the restriction. +
+ +
+ acp:CreatorAgent +
+
+ The Creator Agent named + individual used in an agent restriction means that the restriction + is satisfied if the Context contains an agent that is also a + creator. +
+ +
+ acp:OwnerAgent +
+
+ The Owner Agent named + individual used in an agent restriction means that the restriction + is satisfied if the Context contains an agent that is also an + owner. +
+ +
+ acp:client +
+
+ The client attribute used in a Matcher defines a set of clients, + at least one of which MUST match the resource access Context for + the client restriction to be satisfied. +
+ +
+ acp:PublicClient +
+
+ The Public Client named + individual used in a client restriction means that the restriction + is always satisfied. +
+ +
+ acp:issuer +
+
+ The issuer attribute used in a Matcher defines a set of issuers, + at least one of which MUST match the resource access Context for + the issuer restriction to be satisfied. +
+ +
+ acp:PublicIssuer +
+
+ The Public Issuer named + individual used in an issuer restriction means that the + restriction is always satisfied. +
+ +
+ acp:time +
+
+ The time attribute used in a Matcher defines a set of times, at + least one of which MUST match the resource access Context for the + time restriction is satisfied. +
+ +
+ acp:vc +
+
+ The vc attribute used in a Matcher defines a set of types of + Verifiable Credentials + (VC), at least one of which MUST match the resource access Context + for the vc restriction to be satisfied. +
+ +
+ acp:AlwaysSatisfiedRestriction +
+
+ Defined instances of the + Always Satisfied Restriction + class are used in Matcher restrictions to indicate that the + restriction is always satisfied. The default behaviour of a + Matcher is to not be satisfied, so this is the only way to make a + Matcher always satisfied. +
+
+ +
+

+ 4.4.1. Example Matcher +

+

+ The following example authorization graph means that Agent Matcher + A will be satisfied when either Alice or the owner of the access + controlled resource are requesting access. +

+ + 
+ex:matcherA
+  a acp:Matcher ;
+  acp:agent ex:Alice, acp:OwnerAgent .  
+
+ +

+ The following example authorization graph means that the defined + Client Matcher will be satisfied when matched against a context + graph where the client used to access the access controlled + resource is client B. +

+ + 
+[
+  a acp:Matcher ;
+  acp:client ex:clientB ;  
+] .
+
+ +

+ The following example authorization graph means that Issuer + Matcher A will be satisfied when matched against a context graph + where the identity provider used to assert the identity of the + agent requesting access to the access controlled resource is + issuer B. +

+ + 
+ex:matcherA
+  a acp:Matcher ;
+  acp:issuer ex:issuerB .  
+
+ +

+ The following example authorization graph means that the defined + Verifiable Credentials (VC) Matcher A will be satisfied when + matched against a context graph where one of the presented + verifiable credentials is an instance of credential B, is valid + and has been issued to the agent requesting the resource. +

+ + 
+[]
+  a acp:Matcher ;
+  acp:vc ex:credentialB .  
+
+ +

+ The following example authorization graph means that matcher A + will be satisfied only if either Alice or Bob are the agent + requesting resource access and their identity was asserted by + Identity Provider B. +

+ + 
+ex:matcherA
+  a acp:Matcher ;
+  acp:agent ex:Bob, ex:Alice ;
+  acp:issuer ex:IdentityProviderB .  
+
+ +

+ The following example authorization graph means that the defined + matcher will be satisfied only if Alice, whose identity is + asserted by Identity Provider B, is the agent requesting resource + access and is doing so presenting a VC that is a verified instance + of credential A issued to Alice. +

+ + 
+[
+  a acp:Matcher ;
+  acp:agent ex:Alice ;
+  acp:issuer ex:IdentityProviderB ;  
+  acp:vc ex:credentialA ;
+] .
+
+ +

+ The following example authorization graph means that Policy A + denies Read and Write access to all clients but client C and + policy B allows read to all clients. If Policy A and B control + access to a resource, then anyone using client C will have Read + access to that resource. +

+ + 
+ex:policyA
+  acp:deny acl:Read, acl:Write ;
+  acp:anyOf [
+    acp:client acp:PublicClient ;  
+  ] ,
+  acp:noneOf [
+    acp:client ex:clientC
+  ] .
+
+ex:policyB
+  acp:allow acl:Read ;
+  acp:anyOf [
+    acp:client:PublicClient ;
+  ] .
+
+
+
+ +
+

+ 4.5. Matcher extensibility +

+

+ All sub-properties of acp:attribute correspond + implicitly to their own type of Matcher restriction. If applications + support additional sub-properties of + acp:attribute other than the ones defined by ACP, then, + they MUST also implement corresponding matching algorithms. +

+ +
+

+ 4.5.1. Example Matcher extension +

+

+ Given the property ex:tag previously defined in the + example context extension + as a an rdfs:subPropertyOf acp:attribute that + describes tags applied to requested resources; the following + example context graph would mean that Policy 1 allows Read and is + satisfied by instances of resource access initiated over a + resource that was tagged ex:FavouriteRecord or + ex:Wishlist. +

+ + 
+ex:policy1
+  acp:allow acl:Read ;
+  acp:anyOf [
+    ex:tag ex:FavouriteRecord, ex:Wishlist ;  
+  ] .
+
+
+
+
+ +
+

+ 5. Access Grant Graph +

+

+ This section introduces the ACP terms used to grant access to + resources. +

+ +
+

+ 5.1. Access Grant +

+
+
+ acp:AccessGrant +
+
+ Instances of the + Access Grant class define sets + of Access Modes granted in particular Contexts. +
+ +
+ acp:context +
+
+ The context property connects + Access Grants + to the + Contexts + in which they're given. +
+ +
+ acp:grant +
+
+ The grant property connects + Access Grants + to the + Access Modes + they grant. +
+
+ +
+

+ 5.1.1. Example Access Grant +

+

+ The following example access grant graph means that Access Modes + acl:Read and acl:Write have been granted + to Bob for accessing resource X. +

+ + 
+[]
+  acp:grant acl:Read, acl:Write ;  
+  acp:context [
+    acp:agent ex:Bob ;
+    acp:target ex:resourceX ;
+  ] .
+
+
+
+ +
+

+ 5.2. Access Mode extensibility +

+
+
+ acp:AccessMode +
+
+ The ACP specification does not define specific Access Modes. + Instead, any Access Mode granted is an instance of the + Access Mode class. Access Modes + and their granularity can be tailored to the needs of an + application. Access Modes defined in other vocabularies (for example ACL) can also be used. +
+
+ +
+

+ 5.2.1. Example Access Mode +

+

+ The following example access grant graph means that + acl:Read and ex:Delete are Access Modes; + furthermore, it means that acl:Read and + ex:Delete have been granted to Bob for accessing + resource X. +

+ + 
+[]
+  acp:grant acl:Read, ex:Delete ;  
+  acp:context [
+    acp:agent ex:Bob ;
+    acp:target ex:resourceX ;
+  ] .
+
+
+
+
+ +
+

+ 6. Access Control resolution +

+

+ This section introduces the ACP access control resolution algorithm + for resolving permissions to access controlled resources. +

+ +
+

+ 6.1. Effective Policies +

+

+ Both the acp:resource property and its inverse + acp:accessControlResource MUST be taken into account in + determining the Access Control Resources controlling access to + resources. +

+ +

+ All Access Controls controlling member resources access via the + acp:memberAccessControl property MUST be included in + the set of Access Controls linked as + acp:accessControl in the effective authorization graph + of a resource. +

+ +

+ The set of Policies controlling access to a resource MUST contain + all Policies that are linked to a resource via the + property path + acp:accessControlResource/acp:accessControl/acp:apply + SPARQL11 QUERY. +

+ +
+

+ 6.1.1. Effective Policies example +

+

+ The following example authorization graph means that access to + resource X is controlled by both Access Controls B and C, access + to resource X is therefore controlled by Policy E and Policy F. + The member Access Controls are not taken into account at this + level. Member Access Control D will be included in the effective + authorization graph of resource X's members' ACRs both as an + Access Control and a member Access Control. Therefore, Policy G + will be part of the set of effective Policies controlling access + to resource X's members and transitively to further members of + member resources. +

+ + 
+  ex:accessControlResourceA
+    acp:resource ex:X ;
+    acp:accessControl ex:accessControlB, ex:accessControlC ;  
+    acp:memberAccessControl ex:accessControlD .
+
+  ex:accessControlB
+    acp:apply ex:PolicyE .
+
+  ex:accessControlC
+    acp:apply ex:PolicyF .
+
+  ex:accessControlD
+    acp:apply ex:PolicyG .
+
+
+
+ +
+

+ 6.2. Granted Access Modes +

+
+

+ An Access Mode MUST be granted over a resource if and only if in + the set of Policies controlling access to it: +

+
    +
  • A satisfied policy allows the Access Mode; and
    • +
  • No satisfied policy denies the Access Mode.
    • +
+
+ +
+

+ 6.2.1. Granted Access Modes example +

+

+ The following example authorization graph means that access to + resource X is controlled by Policy B and Policy C. Depending on + the satisfaction of Policies B and C, different access modes will + be granted. +

+
    +
  • + If only Policy B is satisfied, then Access Modes + acl:Read and acl:Write will be + granted. +
    • +
  • + If both Policy B and Policy C are satisfied, then only Access + Mode acl:Read will be granted. +
    • +
  • + If only Policy C is satisfied, then no Access Mode will be + granted. +
    • +
+ + 
+[
+  acp:resource ex:X ;
+  acp:accessControl [
+    acp:apply ex:policyB, ex:policyC ;  
+  ]
+] .
+
+ex:policyB
+  acp:allow acl:Read, acl:Write .
+
+ex:policyC
+  acp:deny acl:Write .
+
+
+ +
+

+ 6.2.2. Granted Access Modes pseudocode +

+ 
function grantAccessModes(policies, context) {
+  const allow = new Set, deny = new Set
+
+  // Gather allowed and denied access modes from satisfied policies  
+  for (const policy of policies)
+      if (isSatisfiedPolicy(policy, context)) {
+          for (const mode of policy.allow)
+              allow.add(mode)
+
+          for (const mode of policy.deny)
+              deny.add(mode)
+      }
+
+  // Deny overrules allow.
+  for (const mode of deny)
+      allow.delete(mode)
+
+  return allow
+}
+
+
+
+ +
+

+ 6.3. Satisfied Policy +

+

+ Policies are satisfied via the acp:allOf, + acp:anyOf and acp:noneOf properties which + act respectively as intersection, union and exclusion operators. +

+ +
+

A Policy MUST be considered satisfied if and only if:

+
    +
  • + It references at least one Matcher via a + acp:allOf or acp:anyOf property; and +
    • +
  • + At least one Matcher it references matches the given resource + access description; and +
    • +
  • + The acp:allOf, acp:anyOf and + acp:noneOf of conditions it defines are satisfied. +
    • +
+
+ +

+ Given that the acp:noneOf condition excludes matches, a + policy without a satisfied acp:allOf or + acp:anyOf condition is never satisfied. +

+ +
+

+ 6.3.1. Satisfied Policy example +

+

+ The following example authorization graph means that access to + resource X is controlled by Policy A. Depending on the + satisfaction of Matchers B, C, D, E and F, Policy A will be + satisfied or not. +

+
    +
  • + If either Matcher B or Matcher C are not satisfied, then Policy + A will not be satisfied. +
    • +
  • + If both Matcher D and Matcher E are not satisfied, then Policy A + will not be satisfied. +
    • +
  • + If Matcher F is satisfied, then Policy A will not be satisfied. +
    • +
  • + If both Matcher B and Matcher C are satisfied, and, either + Matcher D or Matcher E are satisfied, and, Matcher F is not + satisfied, then Policy A will be satisfied. +
    • +
+ + 
+[
+  acp:resource ex:X ;
+  acp:accessControl [
+    acp:apply ex:policyA ;
+  ]
+] .
+
+ex:policyA
+  acp:allOf ex:matcherB, ex:matcherC ;  
+  acp:anyOf ex:matcherD, matcherE ;
+  acp:noneOf ex:matcherF .
+
+
+ +
+

+ 6.3.2. Satisfied Policy pseudocode +

+ 
function isSatisfiedPolicy(policy, context) {
+  // If any 'none of' matcher is satisfied then the policy is not satisfied.
+  for (const matcher of policy.noneOf)
+      if (isSatisfiedMatcher(matcher, context))
+          return false
+
+  // If any 'all of' matcher is not satisfied then the policy is not satisfied.  
+  for (const matcher of policy.allOf)
+      if (!isSatisfiedMatcher(matcher, context))
+          return false
+
+  // If any 'any of' matcher is satisfied then the policy is satisfied.
+  for (const matcher of policy.anyOf)
+      if (isSatisfiedMatcher(matcher, context))
+          return true
+
+  // At this point there are
+  // - no satisfied 'none of' matchers,
+  // - no unsatisfied 'all of' matchers and
+  // - no satisfied 'any of' matchers.
+
+  // Hence, the policy is satisfied if it has
+  // - an 'all of' condition and
+  // - no 'any of' condition.
+  return policy.allOf.size !== 0 && policy.anyOf.size === 0
+}
+
+
+
+ +
+

+ 6.4. Satisfied Matcher +

+

+ The default operation of matching is based on + IRI + and + literal term equality + as defined in the RDF 1.1 Concepts and Abstract Syntax + RDF11 CONCEPTS. +

+ +
+

A Matcher MUST be considered satisfied if and only if:

+
    +
  • It defines at least one matching attribute; and
    • +
  • + All the attributes defined find a match in the given resource + access description. +
    • +
+
+ +
+

+ 6.4.1. Satisfied Matcher example +

+
+ +
+

+ 6.4.2. Satisfied Matcher pseudocode +

+
+
+
+ +
+

+ 7. Server implementation +

+

+ This section introduces ACP server capability and ACR discovery, as + well as ACR editing, and ACP resources lifecycle management. +

+ +
+

+ 7.1. Capability discovery +

+

+ When a server wants to enable applications to discover its ACP + capabilities, it MUST do so via link headers. +

+ +

+ The server MUST advertise the access modes it supports by responding + to HTTP OPTIONS requests over ACP access control resources including + a Link header with the rel value of + http://www.w3.org/ns/solid/acp#grant and the full URI + of an access mode as link target [RFC8288]. The server MUST produce + one such Link header for each access mode it supports. +

+ +

+ For example, if a server supports the ACL read, write and append + access modes, it should advertise it by responding to HTTP OPTIONS + requests over ACP access control resources including three link + headers with rel value of + http://www.w3.org/ns/solid/acp#grant and respectively + targets of http://www.w3.org/ns/auth/acl#Read, + http://www.w3.org/ns/auth/acl#Write and + http://www.w3.org/ns/auth/acl#Append in order to make + it explicit which set of access modes are understood and relevant + when editing ACP policies. +

+ +

+ The server MUST advertise the request attributes it supports by + responding to HTTP OPTIONS requests over ACP access control + resources including a Link header with the rel value of + http://www.w3.org/ns/solid/acp#attribute and the full + URI of an acp attribute as link target [RFC8288]. The server MUST + produce one such Link header for each request attribute it supports. +

+ +

+ For example, if a server supports the ACP agent, client and issuer + request attributes, it should advertise it by responding to HTTP + OPTIONS requests over ACP access control resources including three + link headers with rel value of + http://www.w3.org/ns/solid/acp#attribute and + respectively targets of + http://www.w3.org/ns/solid/acp#agent, + http://www.w3.org/ns/solid/acp#client and + http://www.w3.org/ns/solid/acp#issuer in order to make + it explicit which set of request attributes are understood and + relevant when editing ACP matchers. +

+
+ +
+

+ 7.2. ACR discovery +

+

+ When a server wants to enable applications to discover the ACP + access control resource associated with a given resource, the server + MUST advertise the ACP access control resource that is associated + with that resource by responding to HTTP requests over the resource + including a Link header with the rel value + of acl (acl Link Relation) and the ACP access control + resource as the link target [RFC8288]. The same mechanism is used in + Web Access Control resource discovery. +

+

+ A server responding to an HTTP request over an ACP access control + resource MUST include a Link header with the + rel value of type and the + acp:AccessControlResource URI as link target. +

+
+ +
+

+ 7.3. ACR editing +

+

+ The owner of a storage is implicitly considered an owner of all the + resources in the URI space corresponding to the storage. +

+ +

+ An owner of a resource is implicitly considered an owner of its + associated Access Control Resource. +

+ +

+ An owner of an Access Control Resource implicitly has full read and + write access over it. +

+ +

+ To add or remove an Access Control from an ACR, agents that are not + owners of said ACR need read and write access to both the ACR itself + and to the resource where said Access Control is defined. In other + words, Access Controls defined as part of a separate resource can be + protected from unwanted edits in and out of ACRs by setting adequate + permissions in their own ACR. +

+
+ +
+

+ 7.4. Resource management +

+

Access Control Resources MUST be server managed.

+ +

+ There is a one to one relationship between a resource and its + authoritative source of access control. Therefore, when resources + are created or deleted, the corresponding ACRs MUST be created or + deleted accordingly. +

+ +

+ Access Controls, Policies and Matchers MAY all be access controlled + via their own ACR. +

+ +

+ As long as an Access Control, a Policy or a Matcher is referenced by + an ACR, it MUST not be deleted. However, if such consistency failed + to be enforced or if an Access Control, a Policy or a Matcher is not + accessible for any other reason, then access permissions resolution + MUST fail to its default behaviour of only granting read and write + access to the invalid ACR to its owners; read and write access MUST + not be implicitly granted to a resource whose access control + resolution fails, even to owners of that resource. +

+
+
+
+ +
+

Acknowledgements

+

This section is non-normative.

+
+ +
+

References

+ +
+

Normative references

+
+
[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. +
+
[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. +
+
[SPARQL11-QUERY]
+
+ SPARQL 1.1 Query. Steve Harris; Andy Seaborne; Eric Prud'hommeaux. W3C. 21 March + 2013. W3C Recommendation. URL: + https://www.w3.org/TR/sparql11-query/. +
+
+
+ +
+

Informative references

+
+
+ + + + + + diff --git a/2022/acp-code-20220513.css b/2022/acp-code-20220513.css new file mode 100644 index 00000000..a24f809d --- /dev/null +++ b/2022/acp-code-20220513.css @@ -0,0 +1,289 @@ +.highlight table td { + padding: 5px; +} + +.highlight table pre { + margin: 0; +} + +.highlight .cm { + color: #999988; + font-style: italic; +} + +.highlight .cp { + color: #999999; + font-weight: bold; +} + +.highlight .c1 { + color: #999988; + font-style: italic; +} + +.highlight .cs { + color: #999999; + font-weight: bold; + font-style: italic; +} + +.highlight .c, +.highlight .ch, +.highlight .cd, +.highlight .cpf { + color: #999988; + font-style: italic; +} + +.highlight .err { + color: #a61717; + background-color: #e3d2d2; +} + +.highlight .gd { + color: #000000; + background-color: #ffdddd; +} + +.highlight .ge { + color: #000000; + font-style: italic; +} + +.highlight .gr { + color: #aa0000; +} + +.highlight .gh { + color: #999999; +} + +.highlight .gi { + color: #000000; + background-color: #ddffdd; +} + +.highlight .go { + color: #888888; +} + +.highlight .gp { + color: #555555; +} + +.highlight .gs { + font-weight: bold; +} + +.highlight .gu { + color: #aaaaaa; +} + +.highlight .gt { + color: #aa0000; +} + +.highlight .kc { + color: #000000; + font-weight: bold; +} + +.highlight .kd { + color: #000000; + font-weight: bold; +} + +.highlight .kn { + color: #000000; + font-weight: bold; +} + +.highlight .kp { + color: #000000; + font-weight: bold; +} + +.highlight .kr { + color: #000000; + font-weight: bold; +} + +.highlight .kt { + color: #445588; + font-weight: bold; +} + +.highlight .k, +.highlight .kv { + color: #000000; + font-weight: bold; +} + +.highlight .mf { + color: #009999; +} + +.highlight .mh { + color: #009999; +} + +.highlight .il { + color: #009999; +} + +.highlight .mi { + color: #009999; +} + +.highlight .mo { + color: #009999; +} + +.highlight .m, +.highlight .mb, +.highlight .mx { + color: #009999; +} + +.highlight .sa { + color: #000000; + font-weight: bold; +} + +.highlight .sb { + color: #d14; +} + +.highlight .sc { + color: #d14; +} + +.highlight .sd { + color: #d14; +} + +.highlight .s2 { + color: #d14; +} + +.highlight .se { + color: #d14; +} + +.highlight .sh { + color: #d14; +} + +.highlight .si { + color: #d14; +} + +.highlight .sx { + color: #d14; +} + +.highlight .sr { + color: #009926; +} + +.highlight .s1 { + color: #d14; +} + +.highlight .ss { + color: #990073; +} + +.highlight .s, +.highlight .dl { + color: #d14; +} + +.highlight .na { + color: #008080; +} + +.highlight .bp { + color: #999999; +} + +.highlight .nb { + color: #0086B3; +} + +.highlight .nc { + color: #445588; + font-weight: bold; +} + +.highlight .no { + color: #008080; +} + +.highlight .nd { + color: #3c5d5d; + font-weight: bold; +} + +.highlight .ni { + color: #800080; +} + +.highlight .ne { + color: #990000; + font-weight: bold; +} + +.highlight .nf, +.highlight .fm { + color: #990000; + font-weight: bold; +} + +.highlight .nl { + color: #990000; + font-weight: bold; +} + +.highlight .nn { + color: #555555; +} + +.highlight .nt { + color: #000080; +} + +.highlight .vc { + color: #008080; +} + +.highlight .vg { + color: #008080; +} + +.highlight .vi { + color: #008080; +} + +.highlight .nv, +.highlight .vm { + color: #008080; +} + +.highlight .ow { + color: #000000; + font-weight: bold; +} + +.highlight .o { + color: #000000; + font-weight: bold; +} + +.highlight .w { + color: #bbbbbb; +} + +.highlight { + background-color: #f8f8f8; +} diff --git a/2022/acp-data-model-20220513.svg b/2022/acp-data-model-20220513.svg new file mode 100644 index 00000000..8be693cc --- /dev/null +++ b/2022/acp-data-model-20220513.svg @@ -0,0 +1 @@ + diff --git a/2022/acp-main-20220513.css b/2022/acp-main-20220513.css new file mode 100644 index 00000000..f6421438 --- /dev/null +++ b/2022/acp-main-20220513.css @@ -0,0 +1,136 @@ +:root { + --lightest-yellow: hsl(47, 100%, 97%); + --lighter-yellow: hsl(47, 100%, 87%); + --light-yellow: hsl(47, 100%, 77%); + --light-green: #b6fdad; + --light-red: #ffdede; +} + +h1 { + font-size: 220%; + font-weight: bold; + margin: 0 0 .1em; +} + +header { + border-bottom: 1px solid; +} + +header li { + margin: 0; +} + +dl dd { + margin: 0 0 .5em 2em; +} + +dd ul { + padding: 0; +} + +dd li { + list-style: none; +} + +table { + border-collapse: collapse; + border-color: #000000; +} + +td, +th { + border-width: 1px; + border-style: solid; + padding: 0.4em 0.6em; +} + +.bibref::before { + content: "["; +} + +.bibref::after { + content: "]"; +} + +.heading { + position: relative; +} + +.self-link { + border: none; + font-size: 83%; + height: 2em; + left: calc(-1 * (3.5rem - 26px)); + opacity: .5; + position: absolute; + text-align: center; + top: 0; + transition: opacity .2s; + width: calc(3.5rem - 26px); +} + +.self-link:hover { + opacity: 1; +} + +.self-link::before { + content: "§"; +} + +.rfc2119 { + text-transform: lowercase; + font-style: normal; + color: #900; +} + +.example, +.pseudocode { + border: 1px solid #999; + margin-left: 0; + margin-top: 1.5em; + padding: 2em; +} + +.example::before, .pseudocode::before { + background: white; + border: 1px solid #bbb; + color: #666; + display: block; + font-family: sans-serif; + margin: -2em 0 1em -2em; + padding: 0.2em 2em; + text-transform: none; + width: 14em; +} + +.pseudocode::before { + content: "Example JavaScript code"; +} + +.example-context-graph { + background-color: var(--lightest-yellow); +} + +.example-context-graph::before { + content: "Example context graph"; +} + +.example-authorization-graph { + background-color: var(--lighter-yellow); +} + +.example-authorization-graph::before { + content: "Example authorization graph"; +} + +.example-access-grant-graph { + background-color: var(--light-yellow); +} + +.example-access-grant-graph::before { + content: "Example access grant graph"; +} + +.example-well-known::before { + content: "Example well known configuration"; +} diff --git a/index.html b/index.html index a28f8031..2f4c06be 100644 --- a/index.html +++ b/index.html @@ -150,7 +150,7 @@

Work Items

- Access Control Policy + Access Control Policy https://github.com/solid/authorization-panel Editor’s Draft Ecosystem Proposal From ff8d6c18692833c16e1d7b1ab6f45355628c9e4f Mon Sep 17 00:00:00 2001 From: Aaron Coburn Date: Sat, 14 May 2022 08:16:59 -0400 Subject: [PATCH 2/9] Add unversioned HTML document, update SVG diagram --- 2022/acp-data-model-20220513.svg | 2 +- acp.html | 3018 ++++++++++++++++++++++++++++++ 2 files changed, 3019 insertions(+), 1 deletion(-) create mode 100644 acp.html diff --git a/2022/acp-data-model-20220513.svg b/2022/acp-data-model-20220513.svg index 8be693cc..57717ec9 100644 --- a/2022/acp-data-model-20220513.svg +++ b/2022/acp-data-model-20220513.svg @@ -1 +1 @@ - + \ No newline at end of file diff --git a/acp.html b/acp.html new file mode 100644 index 00000000..ade86308 --- /dev/null +++ b/acp.html @@ -0,0 +1,3018 @@ + + + + + + + Access Control Policy (ACP) + + + + + +
+ +

Access Control Policy (ACP)

+

+ Version 0.9.0, + +

+
+ More details about this document +
+
This version
+
+ https://solidproject.org/TR/2022/acp-20220513 +
+
Latest version
+
+ https://solidproject.org/TR/acp +
+
Editor's draft
+
+ https://solid.github.io/authorization-panel/acp-specification +
+
Source repository
+
+ https://github.com/solid/authorization-panel +
+
Issue tracking
+
+ https://github.com/solid/authorization-panel/issues +
+
License
+
+ MIT License +
+
Editors
+
+ +
+
+
+ +
+ +
+

Abstract

+

+ This document defines the + Access Control Policy Language (ACP). + ACP is a language for describing, controlling and granting access to + resources. +

+
+ +
+

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. +

+
+ +
+
+

+ 1. Introduction +

+

+ This section introduces ACP with an overview of key terminology, an + explanation of the conventions used in this document, example graphs + to illustrate basic concepts of resource access description and + validation, a diagram representing the main elements of the ACP data + model, and a non-normative RDF representation of the ACP ontology. +

+ +
+

+ 1.1. RDF terminology +

+

+ This document uses the terms + resource, + property, + RDF vocabulary, + namespace, + namespace IRI, + namespace prefix, + RDF graph, + RDF triple, + IRI, + literal, + blank node, + node + of an RDF graph, + RDF term, + subject, + predicate, and + object + of RDF triples, + datatype, and + IRI + and + literal term equality + as defined in RDF 1.1 Concepts and Abstract Syntax + RDF11 CONCEPTS. +

+
+ +
+

+ 1.2. RDF vocabularies and namespace IRIs +

+

+ This document uses the following RDF vocabularies and corresponding + namespace prefix bindings: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PrefixNamespace
+ acp: + + http://www.w3.org/ns/solid/acp# +
acl: + http://www.w3.org/ns/auth/acl# +
ex: + https://example.org/ +
ldp: + http://www.w3.org/ns/ldp# +
rdf: + http://www.w3.org/1999/02/22-rdf-syntax-ns# +
rdfs: + http://www.w3.org/2000/01/rdf-schema# +
owl: + http://www.w3.org/2002/07/owl# +
+
+ +
+

+ 1.3. ACP terminology +

+

This section is non-normative.

+ +
+
Context graph
+
+ Context graphs describe the + attributes of resource access instances. Those attributes can be + matched to sets of conditions defined in the form of an + authorization graph + in order to determine Access Modes granted over resources. +
+
Authorization graph
+
+ Authorization graphs + authoritatively define the conditions for granting Access Modes + over resources through Access Controls, Policies and Matchers. The + result of applying an authorization graph to a described instance + of resource access is an + access grant graph. +
+
Access grant graph
+
+ Access grant graphs describe + sets of granted access modes over resources in the context of + resource access instances. +
+
+
+ +
+

+ 1.4. Example graphs +

+

This section is non-normative.

+ +

+ Throughout this document, color-coded boxes contain the RDF + representation of example context graphs, authorization graphs, and + access grant graphs serialized in Turtle. Those graphs use a mix of + IRIs and blank nodes where applicable to better show the range of + possible representations. +

+ +

+ The following example + context graph describes an + instance of resource access and could be translated as: + "Bob is trying to access resource X using client application Y + with his identity asserted by identity provider Z.". +

+ + 
+# This box contains a context graph
+# It describes an instance of resource access  
+
+[]
+  acp:agent ex:Bob ;
+  acp:target ex:resourceX ;
+  acp:client ex:ClientApplicationY ;
+  acp:issuer ex:IdentityProviderZ .
+
+ +

+ The following example + authorization graph + authoritatively defines the conditions of access to resource X and + could be translated as: + "Access to resource X is mandated by one Access Control that + applies one Policy which allows access mode + acl:Read when the agent matcher is satisfied that + Alice or Bob are the agent trying to access resource X.". +

+ + 
+# This box contains an authorization graph
+# It describes the conditions required for accessing a resource  
+
+[]
+  a acp:AccessControlResource ;
+  acp:resource ex:resourceX ;
+  acp:accessControl [
+    a acp:AccessControl ;
+    acp:apply [
+      a acp:Policy ;
+      acp:allow acl:Read ;
+      acp:anyOf [
+        a acp:AgentMatcher ;
+        acp:agent ex:Alice, ex:Bob ;
+      ]
+    ]
+  ] .
+
+ +

+ The following example + access grant graph is + the result of applying the previous example authorization graph + which defines access to resource X to the previous example context + graph which describes an instance of access to target resource X. + Bob is matched as the context agent and since it defines no further + restrictions, the policy allowing acl:Read is + satisfied. The following access grant graph could be read as: + "The access mode acl:Read is granted to Bob whom + requested access to resource X using client application Y and + whose identity was asserted by identity provider Z.". +

+ + 
+# This box contains an access grant graph
+# It describes in context the granted access over a resource  
+
+[]
+  acp:grant acl:Read ;
+  acp:context [
+    acp:agent ex:Bob ;
+    acp:target ex:resourceX ;
+    acp:client ex:ClientApplicationY ;
+    acp:issuer ex:IdentityProviderZ ;
+  ] .
+
+
+ +
+

+ 1.5. Data model +

+

This section is non-normative.

+

The following diagram illustrates the main elements of ACP.

+ ACP Data Model +
+ +
+

+ 1.6. Ontology +

+

+ All terms defined by the Access Control Policy Language are present + in a non-normative RDF representation of the + ACP ontology serialized in turtle. +

+
+
+ +
+

+ 2. Conformance +

+

+ All assertions, diagrams, examples, pseudocode 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 defined in + RFC 2119. +

+ +

+ Only UPPERCASE usage of the key words defined in RFC 2119 have special + meanings, as per + RFC 8174. +

+
+ +
+

+ 3. Context Graph +

+

+ This section introduces the ACP terms used to describe instances of + resource access. +

+ +
+

+ 3.1. Context +

+
+
+ acp:Context +
+
+ Instances of the Context class + describe instances of resource access. +
+ +
+ acp:attribute +
+
+ The attribute properties + defined by ACP describe + instances + of + resource + access. +
+ +
+ acp:target +
+
+ The target + attribute + describes requested resources. +
+ +
+ acp:mode +
+
+ The mode + attribute + describes requested modes of access. +
+ +
+ acp:agent +
+
+ The agent + attribute + describes agents initiating requests. +
+ +
+ acp:creator +
+
+ The creator + attribute + describes creators of requested resources. +
+ +
+ acp:owner +
+
+ The owner + attribute + describes owners of requested resources. +
+ +
+ acp:client +
+
+ The client + attribute + describes client applications used to request resources. +
+ +
+ acp:issuer +
+
+ The issuer + attribute + describes identity providers used to assert the identity of agents + requesting resources. +
+ +
+ acp:time +
+
+ The time + attribute + describes times of resource access requests. +
+ +
+ acp:vc +
+
+ The vc + attribute + describes verifiable credentials presented as part of resource + access requests. +
+
+ +
+

+ 3.1.1. Example Context +

+ +

+ The following example context graph denotes instances of resource + access over resource X initiated by Bob. +

+ + 
+[]
+  a acp:Context ;
+  acp:agent ex:Bob .  
+
+ +

+ The following example context graph denotes instances of resource + access over resource X initiated by Bob using client application Y + where Bob's identity is asserted by identity provider Z, Bob is + the owner of resource X, and Alice is the creator of resource X. +

+ + 
+ex:contextA
+  acp:agent ex:Bob ;
+  acp:target ex:resourceX ;
+  acp:owner ex:Bob ;
+  acp:creator ex:Alice ;
+  acp:client ex:ClientApplicationY ;  
+  acp:issuer ex:IdentityProviderZ .
+
+ +

+ The following example context graph denotes instances of resource + access where client application X or client application Y are used + and identity is asserted by identity provider Z. +

+ + 
+[
+  acp:client ex:ClientApplicationX, ex:ClientApplicationY ;  
+  acp:issuer ex:IdentityProviderZ ;
+] .
+
+
+
+ +
+

+ 3.2. Context extensibility +

+

+ Sub-properties of acp:attribute can be created to fit + the specific resource access description requirements of + applications. +

+ +
+

+ 3.2.1. Example Context extension +

+

+ Let's imagine a property ex:tag defined as a an + rdfs:subPropertyOf acp:attribute that would describe + tags applied to requested resources. If such a property was + defined, then the following example context graph would denote + instances of resource access over resource X initiated by Bob + where resource X was tagged ex:Music and + ex:FavouriteRecord. +

+ + 
+ex:contextA
+  acp:agent ex:Bob ;
+  acp:target ex:resourceX ;
+  ex:tag ex:Music, ex:FavouriteRecord .  
+
+
+
+
+ +
+

+ 4. Authorization Graph +

+

+ This section introduces the ACP terms used to control access to + resources. +

+ +
+

+ 4.1. Access Control Resource +

+
+
+ acp:AccessControlResource +
+
+ Instances of the + Access Control Resource (ACR) + class connect resources to their Access Controls. +
+ +
+ acp:resource +
+
+ The resource property connects + ACRs + to + resources + they control. It is the inverse of + acp:accessControlResource. +
+ +
+ acp:accessControl +
+
+ The access control property + connects + ACRs + to + Access Controls. +
+ +
+ acp:memberAccessControl +
+
+ The + member access control property + transitively connects + ACRs + of member resources to + Access Controls. +
+
+ +
+

+ 4.1.1. Example Access Control Resource +

+

+ The following example authorization graph means that access to + resource X is controlled by both Access Controls B and C; + furthermore, access to members of resource X is controlled by + Access Control D. +

+ + 
+ex:accessControlResourceA
+  acp:resource ex:resourceX ;
+  acp:accessControl ex:accessControlB, ex:accessControlC ;  
+  acp:memberAccessControl ex:accessControlD .
+
+
+
+ +
+

+ 4.2. Access Control +

+
+
+ acp:AccessControl +
+
+ Instances of the + Access Control class connect + Access Control Resources to their Policies. +
+ +
+ acp:apply +
+
+ The apply property connects + Access Controls + to the + Policies + they apply to resources. +
+
+ +
+

+ 4.2.1. Example Access Control +

+

+ The following example authorization graph means that access to + resource X is controlled by Policy C. +

+ + 
+ex:accessControlResourceA
+  acp:resource ex:resourceX ;  
+  acp:accessControl [
+    acp:apply ex:policyC ;
+  ] .
+
+ +

+ The following two example authorization graphs mean that access to + resource X is controlled by Policy D and Policy E. +

+ + 
+ex:accessControlResourceA
+  acp:resource ex:resourceX ;
+  acp:accessControl ex:accessControlB, ex:accessControlC .  
+
+ex:accessControlB
+  acp:apply ex:policyD .
+
+ex:accessControlC
+  acp:apply ex:policyE .
+
+ + 
+[]
+  acp:resource ex:resourceX ;
+  acp:accessControl ex:accessControlF .  
+
+ex:accessControlF
+  acp:apply ex:policyD, ex:policyE .
+
+
+
+ +
+

+ 4.3. Policy +

+
+
+ acp:Policy +
+
+ Instances of the Policy class + connect Access Controls to allowed and denied Access Modes as well + as sets of Matchers describing instances of resource access. +
+ +
+ acp:allow +
+
+ The allow property connects + Policies + to the + Access Modes + they allow if satisfied. +
+ +
+ acp:deny +
+
+ The deny property connects + Policies + to the + Access Modes + they deny if satisfied. +
+ +
+ acp:allOf +
+
+ The all of property connects + Policies + to the set of + Matchers + all of which MUST must be satisfied for the Policy to be + satisfied. +
+ +
+ acp:anyOf +
+
+ The any of property connects + Policies + to the set of + Matchers + at least one of which MUST be satisfied for the Policy to be + satisfied. +
+ +
+ acp:noneOf +
+
+ The none of property connects + Policies + to the set of + Matchers + all of which MUST NOT be satisfied for the Policy to be satisfied. +
+
+ +
+

+ 4.3.1. Example Policy +

+

+ The following example authorization graph means that Policy A will + allow Read for instances of resource access satisfying both + Matcher B and Matcher C. +

+ + 
+ex:policyA
+  acp:allow acl:Read ;
+  acp:allOf ex:matcherB, ex:matcherC .  
+
+ +

+ The following example authorization graph means that a Policy will + deny Write for instances of resource access satisfying either + Matcher B or Matcher C. +

+ + 
+[]
+  acp:deny acl:Write ;
+  acp:anyOf ex:matcherB, ex:matcherC .  
+
+ +

+ The following example authorization graph means that Reading and + Writing resource X will be allowed for instances of resource + access satisfying Matcher A and not Matcher B. +

+ + 
+[
+  acp:resource ex:resourceX ;
+  acp:accessControl [
+    acp:apply [
+      acp:allow acl:Read, acl:Write ;  
+      acp:anyOf ex:matcherA ;
+      acp:noneOf ex:matcherB ;
+    ] ;
+  ] ;
+] .
+
+
+
+ +
+

+ 4.4. Matcher +

+
+
+ acp:Matcher +
+
+ Instances of the Matcher class + are descriptions of matching resource access Contexts. To satisfy + a Matcher, every described resource access attribute must match + the resource access Context. +
+ +
+ acp:agent +
+
+ The agent attribute used in a Matcher defines a set of agents, at + least one of which MUST match the resource access Context for the + agent restriction to be satisfied. +
+ +
+ acp:PublicAgent +
+
+ The Public Agent named + individual used in an agent restriction means that the restriction + is always satisfied. +
+ +
+ acp:AuthenticatedAgent +
+
+ The Authenticated Agent named + individual used in an agent restriction means that any agent in + the Context satisfies the restriction. +
+ +
+ acp:CreatorAgent +
+
+ The Creator Agent named + individual used in an agent restriction means that the restriction + is satisfied if the Context contains an agent that is also a + creator. +
+ +
+ acp:OwnerAgent +
+
+ The Owner Agent named + individual used in an agent restriction means that the restriction + is satisfied if the Context contains an agent that is also an + owner. +
+ +
+ acp:client +
+
+ The client attribute used in a Matcher defines a set of clients, + at least one of which MUST match the resource access Context for + the client restriction to be satisfied. +
+ +
+ acp:PublicClient +
+
+ The Public Client named + individual used in a client restriction means that the restriction + is always satisfied. +
+ +
+ acp:issuer +
+
+ The issuer attribute used in a Matcher defines a set of issuers, + at least one of which MUST match the resource access Context for + the issuer restriction to be satisfied. +
+ +
+ acp:PublicIssuer +
+
+ The Public Issuer named + individual used in an issuer restriction means that the + restriction is always satisfied. +
+ +
+ acp:time +
+
+ The time attribute used in a Matcher defines a set of times, at + least one of which MUST match the resource access Context for the + time restriction is satisfied. +
+ +
+ acp:vc +
+
+ The vc attribute used in a Matcher defines a set of types of + Verifiable Credentials + (VC), at least one of which MUST match the resource access Context + for the vc restriction to be satisfied. +
+ +
+ acp:AlwaysSatisfiedRestriction +
+
+ Defined instances of the + Always Satisfied Restriction + class are used in Matcher restrictions to indicate that the + restriction is always satisfied. The default behaviour of a + Matcher is to not be satisfied, so this is the only way to make a + Matcher always satisfied. +
+
+ +
+

+ 4.4.1. Example Matcher +

+

+ The following example authorization graph means that Agent Matcher + A will be satisfied when either Alice or the owner of the access + controlled resource are requesting access. +

+ + 
+ex:matcherA
+  a acp:Matcher ;
+  acp:agent ex:Alice, acp:OwnerAgent .  
+
+ +

+ The following example authorization graph means that the defined + Client Matcher will be satisfied when matched against a context + graph where the client used to access the access controlled + resource is client B. +

+ + 
+[
+  a acp:Matcher ;
+  acp:client ex:clientB ;  
+] .
+
+ +

+ The following example authorization graph means that Issuer + Matcher A will be satisfied when matched against a context graph + where the identity provider used to assert the identity of the + agent requesting access to the access controlled resource is + issuer B. +

+ + 
+ex:matcherA
+  a acp:Matcher ;
+  acp:issuer ex:issuerB .  
+
+ +

+ The following example authorization graph means that the defined + Verifiable Credentials (VC) Matcher A will be satisfied when + matched against a context graph where one of the presented + verifiable credentials is an instance of credential B, is valid + and has been issued to the agent requesting the resource. +

+ + 
+[]
+  a acp:Matcher ;
+  acp:vc ex:credentialB .  
+
+ +

+ The following example authorization graph means that matcher A + will be satisfied only if either Alice or Bob are the agent + requesting resource access and their identity was asserted by + Identity Provider B. +

+ + 
+ex:matcherA
+  a acp:Matcher ;
+  acp:agent ex:Bob, ex:Alice ;
+  acp:issuer ex:IdentityProviderB .  
+
+ +

+ The following example authorization graph means that the defined + matcher will be satisfied only if Alice, whose identity is + asserted by Identity Provider B, is the agent requesting resource + access and is doing so presenting a VC that is a verified instance + of credential A issued to Alice. +

+ + 
+[
+  a acp:Matcher ;
+  acp:agent ex:Alice ;
+  acp:issuer ex:IdentityProviderB ;  
+  acp:vc ex:credentialA ;
+] .
+
+ +

+ The following example authorization graph means that Policy A + denies Read and Write access to all clients but client C and + policy B allows read to all clients. If Policy A and B control + access to a resource, then anyone using client C will have Read + access to that resource. +

+ + 
+ex:policyA
+  acp:deny acl:Read, acl:Write ;
+  acp:anyOf [
+    acp:client acp:PublicClient ;  
+  ] ,
+  acp:noneOf [
+    acp:client ex:clientC
+  ] .
+
+ex:policyB
+  acp:allow acl:Read ;
+  acp:anyOf [
+    acp:client:PublicClient ;
+  ] .
+
+
+
+ +
+

+ 4.5. Matcher extensibility +

+

+ All sub-properties of acp:attribute correspond + implicitly to their own type of Matcher restriction. If applications + support additional sub-properties of + acp:attribute other than the ones defined by ACP, then, + they MUST also implement corresponding matching algorithms. +

+ +
+

+ 4.5.1. Example Matcher extension +

+

+ Given the property ex:tag previously defined in the + example context extension + as a an rdfs:subPropertyOf acp:attribute that + describes tags applied to requested resources; the following + example context graph would mean that Policy 1 allows Read and is + satisfied by instances of resource access initiated over a + resource that was tagged ex:FavouriteRecord or + ex:Wishlist. +

+ + 
+ex:policy1
+  acp:allow acl:Read ;
+  acp:anyOf [
+    ex:tag ex:FavouriteRecord, ex:Wishlist ;  
+  ] .
+
+
+
+
+ +
+

+ 5. Access Grant Graph +

+

+ This section introduces the ACP terms used to grant access to + resources. +

+ +
+

+ 5.1. Access Grant +

+
+
+ acp:AccessGrant +
+
+ Instances of the + Access Grant class define sets + of Access Modes granted in particular Contexts. +
+ +
+ acp:context +
+
+ The context property connects + Access Grants + to the + Contexts + in which they're given. +
+ +
+ acp:grant +
+
+ The grant property connects + Access Grants + to the + Access Modes + they grant. +
+
+ +
+

+ 5.1.1. Example Access Grant +

+

+ The following example access grant graph means that Access Modes + acl:Read and acl:Write have been granted + to Bob for accessing resource X. +

+ + 
+[]
+  acp:grant acl:Read, acl:Write ;  
+  acp:context [
+    acp:agent ex:Bob ;
+    acp:target ex:resourceX ;
+  ] .
+
+
+
+ +
+

+ 5.2. Access Mode extensibility +

+
+
+ acp:AccessMode +
+
+ The ACP specification does not define specific Access Modes. + Instead, any Access Mode granted is an instance of the + Access Mode class. Access Modes + and their granularity can be tailored to the needs of an + application. Access Modes defined in other vocabularies (for example ACL) can also be used. +
+
+ +
+

+ 5.2.1. Example Access Mode +

+

+ The following example access grant graph means that + acl:Read and ex:Delete are Access Modes; + furthermore, it means that acl:Read and + ex:Delete have been granted to Bob for accessing + resource X. +

+ + 
+[]
+  acp:grant acl:Read, ex:Delete ;  
+  acp:context [
+    acp:agent ex:Bob ;
+    acp:target ex:resourceX ;
+  ] .
+
+
+
+
+ +
+

+ 6. Access Control resolution +

+

+ This section introduces the ACP access control resolution algorithm + for resolving permissions to access controlled resources. +

+ +
+

+ 6.1. Effective Policies +

+

+ Both the acp:resource property and its inverse + acp:accessControlResource MUST be taken into account in + determining the Access Control Resources controlling access to + resources. +

+ +

+ All Access Controls controlling member resources access via the + acp:memberAccessControl property MUST be included in + the set of Access Controls linked as + acp:accessControl in the effective authorization graph + of a resource. +

+ +

+ The set of Policies controlling access to a resource MUST contain + all Policies that are linked to a resource via the + property path + acp:accessControlResource/acp:accessControl/acp:apply + SPARQL11 QUERY. +

+ +
+

+ 6.1.1. Effective Policies example +

+

+ The following example authorization graph means that access to + resource X is controlled by both Access Controls B and C, access + to resource X is therefore controlled by Policy E and Policy F. + The member Access Controls are not taken into account at this + level. Member Access Control D will be included in the effective + authorization graph of resource X's members' ACRs both as an + Access Control and a member Access Control. Therefore, Policy G + will be part of the set of effective Policies controlling access + to resource X's members and transitively to further members of + member resources. +

+ + 
+  ex:accessControlResourceA
+    acp:resource ex:X ;
+    acp:accessControl ex:accessControlB, ex:accessControlC ;  
+    acp:memberAccessControl ex:accessControlD .
+
+  ex:accessControlB
+    acp:apply ex:PolicyE .
+
+  ex:accessControlC
+    acp:apply ex:PolicyF .
+
+  ex:accessControlD
+    acp:apply ex:PolicyG .
+
+
+
+ +
+

+ 6.2. Granted Access Modes +

+
+

+ An Access Mode MUST be granted over a resource if and only if in + the set of Policies controlling access to it: +

+
    +
  • A satisfied policy allows the Access Mode; and
    • +
  • No satisfied policy denies the Access Mode.
    • +
+
+ +
+

+ 6.2.1. Granted Access Modes example +

+

+ The following example authorization graph means that access to + resource X is controlled by Policy B and Policy C. Depending on + the satisfaction of Policies B and C, different access modes will + be granted. +

+
    +
  • + If only Policy B is satisfied, then Access Modes + acl:Read and acl:Write will be + granted. +
    • +
  • + If both Policy B and Policy C are satisfied, then only Access + Mode acl:Read will be granted. +
    • +
  • + If only Policy C is satisfied, then no Access Mode will be + granted. +
    • +
+ + 
+[
+  acp:resource ex:X ;
+  acp:accessControl [
+    acp:apply ex:policyB, ex:policyC ;  
+  ]
+] .
+
+ex:policyB
+  acp:allow acl:Read, acl:Write .
+
+ex:policyC
+  acp:deny acl:Write .
+
+
+ +
+

+ 6.2.2. Granted Access Modes pseudocode +

+ 
function grantAccessModes(policies, context) {
+  const allow = new Set, deny = new Set
+
+  // Gather allowed and denied access modes from satisfied policies  
+  for (const policy of policies)
+      if (isSatisfiedPolicy(policy, context)) {
+          for (const mode of policy.allow)
+              allow.add(mode)
+
+          for (const mode of policy.deny)
+              deny.add(mode)
+      }
+
+  // Deny overrules allow.
+  for (const mode of deny)
+      allow.delete(mode)
+
+  return allow
+}
+
+
+
+ +
+

+ 6.3. Satisfied Policy +

+

+ Policies are satisfied via the acp:allOf, + acp:anyOf and acp:noneOf properties which + act respectively as intersection, union and exclusion operators. +

+ +
+

A Policy MUST be considered satisfied if and only if:

+
    +
  • + It references at least one Matcher via a + acp:allOf or acp:anyOf property; and +
    • +
  • + At least one Matcher it references matches the given resource + access description; and +
    • +
  • + The acp:allOf, acp:anyOf and + acp:noneOf of conditions it defines are satisfied. +
    • +
+
+ +

+ Given that the acp:noneOf condition excludes matches, a + policy without a satisfied acp:allOf or + acp:anyOf condition is never satisfied. +

+ +
+

+ 6.3.1. Satisfied Policy example +

+

+ The following example authorization graph means that access to + resource X is controlled by Policy A. Depending on the + satisfaction of Matchers B, C, D, E and F, Policy A will be + satisfied or not. +

+
    +
  • + If either Matcher B or Matcher C are not satisfied, then Policy + A will not be satisfied. +
    • +
  • + If both Matcher D and Matcher E are not satisfied, then Policy A + will not be satisfied. +
    • +
  • + If Matcher F is satisfied, then Policy A will not be satisfied. +
    • +
  • + If both Matcher B and Matcher C are satisfied, and, either + Matcher D or Matcher E are satisfied, and, Matcher F is not + satisfied, then Policy A will be satisfied. +
    • +
+ + 
+[
+  acp:resource ex:X ;
+  acp:accessControl [
+    acp:apply ex:policyA ;
+  ]
+] .
+
+ex:policyA
+  acp:allOf ex:matcherB, ex:matcherC ;  
+  acp:anyOf ex:matcherD, matcherE ;
+  acp:noneOf ex:matcherF .
+
+
+ +
+

+ 6.3.2. Satisfied Policy pseudocode +

+ 
function isSatisfiedPolicy(policy, context) {
+  // If any 'none of' matcher is satisfied then the policy is not satisfied.
+  for (const matcher of policy.noneOf)
+      if (isSatisfiedMatcher(matcher, context))
+          return false
+
+  // If any 'all of' matcher is not satisfied then the policy is not satisfied.  
+  for (const matcher of policy.allOf)
+      if (!isSatisfiedMatcher(matcher, context))
+          return false
+
+  // If any 'any of' matcher is satisfied then the policy is satisfied.
+  for (const matcher of policy.anyOf)
+      if (isSatisfiedMatcher(matcher, context))
+          return true
+
+  // At this point there are
+  // - no satisfied 'none of' matchers,
+  // - no unsatisfied 'all of' matchers and
+  // - no satisfied 'any of' matchers.
+
+  // Hence, the policy is satisfied if it has
+  // - an 'all of' condition and
+  // - no 'any of' condition.
+  return policy.allOf.size !== 0 && policy.anyOf.size === 0
+}
+
+
+
+ +
+

+ 6.4. Satisfied Matcher +

+

+ The default operation of matching is based on + IRI + and + literal term equality + as defined in the RDF 1.1 Concepts and Abstract Syntax + RDF11 CONCEPTS. +

+ +
+

A Matcher MUST be considered satisfied if and only if:

+
    +
  • It defines at least one matching attribute; and
    • +
  • + All the attributes defined find a match in the given resource + access description. +
    • +
+
+ +
+

+ 6.4.1. Satisfied Matcher example +

+
+ +
+

+ 6.4.2. Satisfied Matcher pseudocode +

+
+
+
+ +
+

+ 7. Server implementation +

+

+ This section introduces ACP server capability and ACR discovery, as + well as ACR editing, and ACP resources lifecycle management. +

+ +
+

+ 7.1. Capability discovery +

+

+ When a server wants to enable applications to discover its ACP + capabilities, it MUST do so via link headers. +

+ +

+ The server MUST advertise the access modes it supports by responding + to HTTP OPTIONS requests over ACP access control resources including + a Link header with the rel value of + http://www.w3.org/ns/solid/acp#grant and the full URI + of an access mode as link target [RFC8288]. The server MUST produce + one such Link header for each access mode it supports. +

+ +

+ For example, if a server supports the ACL read, write and append + access modes, it should advertise it by responding to HTTP OPTIONS + requests over ACP access control resources including three link + headers with rel value of + http://www.w3.org/ns/solid/acp#grant and respectively + targets of http://www.w3.org/ns/auth/acl#Read, + http://www.w3.org/ns/auth/acl#Write and + http://www.w3.org/ns/auth/acl#Append in order to make + it explicit which set of access modes are understood and relevant + when editing ACP policies. +

+ +

+ The server MUST advertise the request attributes it supports by + responding to HTTP OPTIONS requests over ACP access control + resources including a Link header with the rel value of + http://www.w3.org/ns/solid/acp#attribute and the full + URI of an acp attribute as link target [RFC8288]. The server MUST + produce one such Link header for each request attribute it supports. +

+ +

+ For example, if a server supports the ACP agent, client and issuer + request attributes, it should advertise it by responding to HTTP + OPTIONS requests over ACP access control resources including three + link headers with rel value of + http://www.w3.org/ns/solid/acp#attribute and + respectively targets of + http://www.w3.org/ns/solid/acp#agent, + http://www.w3.org/ns/solid/acp#client and + http://www.w3.org/ns/solid/acp#issuer in order to make + it explicit which set of request attributes are understood and + relevant when editing ACP matchers. +

+
+ +
+

+ 7.2. ACR discovery +

+

+ When a server wants to enable applications to discover the ACP + access control resource associated with a given resource, the server + MUST advertise the ACP access control resource that is associated + with that resource by responding to HTTP requests over the resource + including a Link header with the rel value + of acl (acl Link Relation) and the ACP access control + resource as the link target [RFC8288]. The same mechanism is used in + Web Access Control resource discovery. +

+

+ A server responding to an HTTP request over an ACP access control + resource MUST include a Link header with the + rel value of type and the + acp:AccessControlResource URI as link target. +

+
+ +
+

+ 7.3. ACR editing +

+

+ The owner of a storage is implicitly considered an owner of all the + resources in the URI space corresponding to the storage. +

+ +

+ An owner of a resource is implicitly considered an owner of its + associated Access Control Resource. +

+ +

+ An owner of an Access Control Resource implicitly has full read and + write access over it. +

+ +

+ To add or remove an Access Control from an ACR, agents that are not + owners of said ACR need read and write access to both the ACR itself + and to the resource where said Access Control is defined. In other + words, Access Controls defined as part of a separate resource can be + protected from unwanted edits in and out of ACRs by setting adequate + permissions in their own ACR. +

+
+ +
+

+ 7.4. Resource management +

+

Access Control Resources MUST be server managed.

+ +

+ There is a one to one relationship between a resource and its + authoritative source of access control. Therefore, when resources + are created or deleted, the corresponding ACRs MUST be created or + deleted accordingly. +

+ +

+ Access Controls, Policies and Matchers MAY all be access controlled + via their own ACR. +

+ +

+ As long as an Access Control, a Policy or a Matcher is referenced by + an ACR, it MUST not be deleted. However, if such consistency failed + to be enforced or if an Access Control, a Policy or a Matcher is not + accessible for any other reason, then access permissions resolution + MUST fail to its default behaviour of only granting read and write + access to the invalid ACR to its owners; read and write access MUST + not be implicitly granted to a resource whose access control + resolution fails, even to owners of that resource. +

+
+
+
+ +
+

Acknowledgements

+

This section is non-normative.

+
+ +
+

References

+ +
+

Normative references

+
+
[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. +
+
[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. +
+
[SPARQL11-QUERY]
+
+ SPARQL 1.1 Query. Steve Harris; Andy Seaborne; Eric Prud'hommeaux. W3C. 21 March + 2013. W3C Recommendation. URL: + https://www.w3.org/TR/sparql11-query/. +
+
+
+ +
+

Informative references

+
+
+ + + + + + From 9060f65d651358b29be4f93800ea4db9593b302b Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 18 May 2022 02:50:56 +0100 Subject: [PATCH 3/9] ACP version 0.9 fully reviewed 2022-05-18 --- 2022/{acp-20220513.html => acp-20220518.html} | 1108 ++++++++++------- 2022/acp-20220518.ttl | 285 +++++ ...ode-20220513.css => acp-code-20220518.css} | 0 2022/acp-data-model-20220513.svg | 1 - 2022/acp-data-model-20220518.svg | 1 + ...ain-20220513.css => acp-main-20220518.css} | 0 acp.html | 1108 ++++++++++------- 7 files changed, 1556 insertions(+), 947 deletions(-) rename 2022/{acp-20220513.html => acp-20220518.html} (69%) create mode 100644 2022/acp-20220518.ttl rename 2022/{acp-code-20220513.css => acp-code-20220518.css} (100%) delete mode 100644 2022/acp-data-model-20220513.svg create mode 100644 2022/acp-data-model-20220518.svg rename 2022/{acp-main-20220513.css => acp-main-20220518.css} (100%) diff --git a/2022/acp-20220513.html b/2022/acp-20220518.html similarity index 69% rename from 2022/acp-20220513.html rename to 2022/acp-20220518.html index 84d7f5ac..64e6407e 100644 --- a/2022/acp-20220513.html +++ b/2022/acp-20220518.html @@ -1,50 +1,51 @@ - + Access Control Policy (ACP) - - + +
-

Access Control Policy (ACP)

Version 0.9.0, - +

More details about this document
This version
- https://solidproject.org/TR/2022/acp-20220513 + https://solidproject.org/TR/2022/acp-20220518
Latest version
@@ -97,7 +98,7 @@

2022 W3C Solid Community Group.

@@ -116,7 +117,7 @@

Abstract

>Access Control Policy Language (ACP). ACP is a language for describing, controlling and granting access to + >ACP is a language for describing, controlling, and granting access to resources.

@@ -376,30 +377,53 @@

Table of Contents

6Access Control resolution +
    +
  1. + 6.1Resolved Access Control +
      +
    1. + 6.1.1Resolved Access Control + pseudocode +
      2. +
    +
    2. +
  1. 6.1Effective Policies6.2Effective Policies
    1. 6.1.1Effective Policies + >6.2.1Effective Policies example
    +
      +
    1. + 6.2.2Effective Policies + pseudocode +
      2. +
  1. 6.2Granted Access Modes6.3Granted Access Modes
    1. 6.2.1Granted Access Modes + >6.3.1Granted Access Modes example
      2. @@ -407,7 +431,7 @@

      Table of Contents

      1. 6.2.2Granted Access Modes + >6.3.2Granted Access Modes pseudocode
        2. @@ -417,19 +441,19 @@

        Table of Contents

        1. 6.3Satisfied Policy6.4Satisfied Policy
          1. 6.3.1Satisfied Policy example6.4.1Satisfied Policy example
          1. 6.3.2Satisfied Policy + >6.4.2Satisfied Policy pseudocode
            2. @@ -439,12 +463,12 @@

            Table of Contents

            1. 6.4Satisfied Matcher6.5Satisfied Matcher
              1. 6.4.1Satisfied Matcher + >6.5.1Satisfied Matcher example
                2. @@ -452,7 +476,7 @@

                Table of Contents

                1. 6.4.2Satisfied Matcher + >6.5.2Satisfied Matcher pseudocode
                  2. @@ -466,29 +490,15 @@

                  Table of Contents

                  >
                  1. - 7.1Capability discovery -
                    2. -
                  -
                    -
                  1. - 7.2ACR discovery -
                    2. -
                  -
                    -
                  1. - 7.3ACR editing7.1Conforming resource server
                  1. - 7.4Resource management7.2Conforming ACP server
                  @@ -531,7 +541,7 @@

                  explanation of the conventions used in this document, example graphs to illustrate basic concepts of resource access description and validation, a diagram representing the main elements of the ACP data - model, and a non-normative RDF representation of the ACP ontology. + model, and an RDF representation of the ACP ontology.

                  >namespace prefix, RDF graph, - RDF triplegraph, IRI >, node - of an RDF graph, - RDF term, - subjectterm, - predicate, and - object - of RDF triples, - datatype, and IRIIRI equality and

                  This section is non-normative.

                  -
                  Context graph
                  +
                  Context graph
                  Context graphs describe the - attributes of resource access instances. Those attributes can be - matched to sets of conditions defined in the form of an - authorization graph + attributes of resource access instances. An access request's + attributes can be matched to sets of conditions defined in the + form of an + authorization graph in order to determine Access Modes granted over resources.
                  -
                  Authorization graph
                  + +
                  + Authorization graph +
                  Authorization graphs authoritatively define the conditions for granting Access Modes - over resources through Access Controls, Policies and Matchers. The - result of applying an authorization graph to a described instance - of resource access is an - access grant graph. + over resources through Access Control Resources, Access Controls, + Policies and Matchers. The result of applying an authorization + graph to a described instance of resource access is an + access grant graph.
                  -
                  Access grant graph
                  + +
                  Access grant graph
                  Access grant graphs describe - sets of granted access modes over resources in the context of - resource access instances. + sets of Access Modes granted over resources in the context of + resource access requests. Access grants are the result of + access control resolution. +
                  + +
                  + Access control resolution +
                  +
                  + Access control resolution + describes the algorithm used to apply an authorization graph to a + context graph in order to obtain an access grant graph.
                  @@ -773,18 +787,22 @@

                  Throughout this document, color-coded boxes contain the RDF representation of example context graphs, authorization graphs, and - access grant graphs serialized in Turtle. Those graphs use a mix of - IRIs and blank nodes where applicable to better show the range of - possible representations. + access grant graphs serialized in + turtle + RDF11-TURTLE. Those graphs use a mix of IRIs and blank nodes where applicable + to better show the range of possible representations.

                  The following example - context graph describes an - instance of resource access and could be translated as: + context graph describes + an instance of resource access and could be translated as: "Bob is trying to access resource X using client application Y - with his identity asserted by identity provider Z.""Bob is trying to read resource X using client application Y with + their identity asserted by identity provider Z.".

                  @@ -793,23 +811,26 @@

                  # It describes an instance of resource access   [] - acp:agent ex:Bob ; acp:target ex:resourceX ; - acp:client ex:ClientApplicationY ; - acp:issuer ex:IdentityProviderZ . + acp:agent ex:Bob ; + acp:mode acl:Read ; + acp:client ex:clientApplicationY ; + acp:issuer ex:identityProviderZ .

                  The following example - authorization graph - authoritatively defines the conditions of access to resource X and - could be translated as: + authorization graph + defines the conditions of access to resource X and could be + translated as: "Access to resource X is mandated by one Access Control that applies one Policy which allows access mode - acl:Read when the agent matcher is satisfied that - Alice or Bob are the agent trying to access resource X."acl:Read when Alice or Bob are the agent trying to + access resource X.".

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

                  a acp:Policy ; acp:allow acl:Read ; acp:anyOf [ - a acp:AgentMatcher ; + a acp:Matcher ; acp:agent ex:Alice, ex:Bob ; ] ] @@ -839,17 +860,19 @@

                  The following example - access grant graph is - the result of applying the previous example authorization graph - which defines access to resource X to the previous example context - graph which describes an instance of access to target resource X. - Bob is matched as the context agent and since it defines no further - restrictions, the policy allowing acl:Read is + access grant graph + is the result of + applying + the previous example authorization graph which defines access to + resource X to the previous example context graph which describes a + read access request to target resource X. Bob is matched as the + context agent and since the policy allowing + acl:Read defines no further restrictions, it is satisfied. The following access grant graph could be read as: "The access mode acl:Read is granted to Bob whom - requested access to resource X using client application Y and - whose identity was asserted by identity provider Z.""The access mode acl:Read is granted to Bob who + requested read access to resource X using client application Y + with their identity asserted by identity provider Z.".

                  @@ -865,6 +888,7 @@

                  acp:context [ acp:agent ex:Bob ; acp:target ex:resourceX ; + acp:mode acl:Read ; acp:client ex:ClientApplicationY ; acp:issuer ex:IdentityProviderZ ; ] . @@ -887,7 +911,7 @@

                  The following diagram illustrates the main elements of ACP.

                  ACP Data Model @@ -905,7 +929,7 @@

                  All terms defined by the Access Control Policy Language are present in a non-normative RDF representation of the - ACP ontology serialized in turtle. + ACP ontology serialized in turtle.

                  @@ -1021,16 +1045,11 @@

                  acp:attribute
                  - The attribute properties - defined by ACP describe + Sub-properties of ACP + attribute are used to describe instances - of - resource - access. + >instances of resource access.
                  attribute - describes requested resources. + describes + requested resources.

requesting resources. -
- acp:time -
-
- The time - attribute - describes times of resource access requests. -
-
attribute - describes verifiable credentials presented as part of resource - access requests. + describes types of Verifiable Credentials (VC) presented as part + of resource access requests.
@@ -1203,7 +1208,7 @@

The following example context graph denotes instances of resource - access over resource X initiated by Bob. + access initiated by Bob. 

@@ -1214,20 +1219,20 @@ 

             >
 
             

-              The following example context graph denotes instances of resource
-              access over resource X initiated by Bob using client application Y
-              where Bob's identity is asserted by identity provider Z, Bob is
-              the owner of resource X, and Alice is the creator of resource X.
+              The following example context graph means that Bob requests access
+              to resource X using client application Y and with their identity
+              asserted by identity provider Z; furthermore, resource X was
+              created by Alice and is owned by Bob.
             

 
             
 ex:contextA
-  acp:agent ex:Bob ;
   acp:target ex:resourceX ;
-  acp:owner ex:Bob ;
-  acp:creator ex:Alice ;
+  acp:agent ex:Bob ;
   acp:client ex:ClientApplicationY ;  
-  acp:issuer ex:IdentityProviderZ .
+  acp:issuer ex:IdentityProviderZ ;
+  acp:owner ex:Bob ;
+  acp:creator ex:Alice .
 

 
@@ -1260,8 +1265,7 @@ 

           

           

             Sub-properties of acp:attribute can be created to fit
-            the specific resource access description requirements of
-            applications.
+            the specific access control requirements of applications.
           

 
           

               class="example example-context-graph"
             >
 ex:contextA
-  acp:agent ex:Bob ;
   acp:target ex:resourceX ;
+  acp:agent ex:Bob ;
   ex:tag ex:Music, ex:FavouriteRecord .  
@@ -1328,7 +1332,7 @@

The following example authorization graph means that access to resource X is controlled by both Access Controls B and C; furthermore, access to members of resource X is controlled by - Access Control D. + Access Control D; furthermore, member control is transitive, + therefore, further members of member resources will also be + controlled by Access Control D. 

             >
 
             

-              The following two example authorization graphs mean that access to
-              resource X is controlled by Policy D and Policy E.
+              The following two example authorization graphs both mean that
+              access to resource X is controlled by Policy D and Policy E.
             

 
             
             

               The all of property connects
               Policies
-              to the set of
+              to a set of
               Matchers
-              all of which MUST must be satisfied for the Policy to be
-              satisfied.
+              all of which MUST be satisfied for the Policy to be satisfied.
             

 
             

             

               The any of property connects
               Policies
-              to the set of
+              to a set of
               Matchers
               at least one of which MUST be satisfied for the Policy to be
               satisfied.
@@ -1666,7 +1671,7 @@ 

             

               The none of property connects
               Policies
-              to the set of
+              to a set of
               Matchers
               all of which MUST NOT be satisfied for the Policy to be satisfied.
             

@@ -1685,8 +1690,8 @@ 

             

             

               The following example authorization graph means that Policy A will
-              allow Read for instances of resource access satisfying both
-              Matcher B and Matcher C.
+              allow acl:Read for instances of resource access
+              satisfying both Matcher B and Matcher C.
             

 
             
 
             

               The following example authorization graph means that a Policy will
-              deny Write for instances of resource access satisfying either
-              Matcher B or Matcher C.
+              deny acl:Write for instances of resource access
+              satisfying either Matcher B or Matcher C.
             

 
             
             >
 
             

-              The following example authorization graph means that Reading and
-              Writing resource X will be allowed for instances of resource
+              The following example authorization graph means that reading and
+              writing resource X will be allowed for instances of resource
               access satisfying Matcher A and not Matcher B.
             

 
@@ -1762,18 +1767,16 @@
Instances of the Matcher class - are descriptions of matching resource access Contexts. To satisfy - a Matcher, every described resource access attribute must match - the resource access Context. + are descriptions of matching Contexts.
acp:agent
- The agent attribute used in a Matcher defines a set of agents, at - least one of which MUST match the resource access Context for the - agent restriction to be satisfied. + In a Matcher, agent attributes define a set of agents, at least + one of which MUST match the Context for the Matcher to be + satisfied.
acp:PublicAgent
- The Public Agent named - individual used in an agent restriction means that the restriction - is always satisfied. + In a Matcher, agent attributes using the + Public Agent named individual + MUST match all Contexts.
acp:AuthenticatedAgent
- The Authenticated Agent named - individual used in an agent restriction means that any agent in - the Context satisfies the restriction. + In a Matcher, agent attributes using the + Authenticated Agent named + individual MUST match Contexts that contain an agent.
acp:CreatorAgent
- The Creator Agent named - individual used in an agent restriction means that the restriction - is satisfied if the Context contains an agent that is also a - creator. + In a Matcher, agent attributes using the + Creator Agent named individual + MUST match Contexts where a defined creator matches the defined + agent.
acp:OwnerAgent
- The Owner Agent named - individual used in an agent restriction means that the restriction - is satisfied if the Context contains an agent that is also an - owner. + In a Matcher, agent attributes using the + Owner Agent named individual + MUST match Contexts where a defined owner matches the defined + agent.
acp:client
- The client attribute used in a Matcher defines a set of clients, - at least one of which MUST match the resource access Context for - the client restriction to be satisfied. + In a Matcher, client attributes define a set of clients, at least + one of which MUST match the Context for the Matcher to be + satisfied.
acp:PublicClient
- The Public Client named - individual used in a client restriction means that the restriction - is always satisfied. + In a Matcher, client attributes using the + Public Client named individual + MUST match all Contexts.
acp:issuer
- The issuer attribute used in a Matcher defines a set of issuers, - at least one of which MUST match the resource access Context for - the issuer restriction to be satisfied. + In a Matcher, issuer attributes define a set of issuers, at least + one of which MUST match the Context for the Matcher to be + satisfied.
acp:PublicIssuer
- The Public Issuer named - individual used in an issuer restriction means that the - restriction is always satisfied. -
- -
- acp:time -
-
- The time attribute used in a Matcher defines a set of times, at - least one of which MUST match the resource access Context for the - time restriction is satisfied. + In a Matcher, issuer attributes using the + Public Issuer named individual + MUST match all Contexts.
acp:vc
- The vc attribute used in a Matcher defines a set of types of - types + of + Verifiable Credentials - (VC), at least one of which MUST match the resource access Context - for the vc restriction to be satisfied. + (VC), at least one of which MUST match the Context for the Matcher + to be satisfied. A VC type present in the Context MUST be a + valid + VC + presented + as part of the resource access request.
>

- The following example authorization graph means that Agent Matcher - A will be satisfied when either Alice or the owner of the access + The following example authorization graph means that Matcher A + will be satisfied when either Alice or the owner of the access controlled resource are requesting access.

@@ -1957,9 +1967,9 @@

The following example authorization graph means that the defined - Client Matcher will be satisfied when matched against a context - graph where the client used to access the access controlled - resource is client B. + Matcher will be satisfied when matched against a context graph + where the client used to access the access controlled resource is + client B. 

             >
 
             

-              The following example authorization graph means that Issuer
-              Matcher A will be satisfied when matched against a context graph
-              where the identity provider used to assert the identity of the
-              agent requesting access to the access controlled resource is
-              issuer B.
+              The following example authorization graph means that Matcher A
+              will be satisfied when matched against a context graph where the
+              identity provider used to assert the identity of the agent
+              requesting access to the access controlled resource is issuer B.
             

 
             
 
             

               The following example authorization graph means that the defined
-              Verifiable Credentials (VC) Matcher A will be satisfied when
-              matched against a context graph where one of the presented
-              verifiable credentials is an instance of credential B, is valid
-              and has been issued to the agent requesting the resource.
+              Matcher will be satisfied when matched against a context graph
+              showing that a valid VC of type credential B has been presented by
+              the agent requesting access to the access controlled resource.
             

 
             
               The following example authorization graph means that the defined
               matcher will be satisfied only if Alice, whose identity is
               asserted by Identity Provider B, is the agent requesting resource
-              access and is doing so presenting a VC that is a verified instance
-              of credential A issued to Alice.
+              access and is doing so presenting a VC that is a valid instance of
+              credential A.
             

 
             
             >

- All sub-properties of acp:attribute correspond - implicitly to their own type of Matcher restriction. If applications - support additional sub-properties of - acp:attribute other than the ones defined by ACP, then, - they MUST also implement corresponding matching algorithms. + ACP implementations supporting sub-properties of + acp:attribute other than the ones defined by ACP SHOULD + also define and implement corresponding matching algorithms.

The following example access grant graph means that Access Modes acl:Read and acl:Write have been granted - to Bob for accessing resource X. + to Alice for accessing resource X. 

 []
   acp:grant acl:Read, acl:Write ;  
   acp:context [
-    acp:agent ex:Bob ;
+    acp:agent ex:Alice ;
     acp:target ex:resourceX ;
   ] .
Instead, any Access Mode granted is an instance of the Access Mode class. Access Modes and their granularity can be tailored to the needs of an - application. Access Modes defined in other vocabularies (for example ACL) can also be used. + application and Access Modes defined in other vocabularies can + also be used (for example instances of + ACL Access).
@@ -2299,8 +2306,7 @@

The following example access grant graph means that acl:Read and ex:Delete are Access Modes; furthermore, it means that acl:Read and - ex:Delete have been granted to Bob for accessing - resource X. + ex:Delete have been granted to Bob over resource X. 

 []
   acp:grant acl:Read, ex:Delete ;  
   acp:context [
-    acp:agent ex:Bob ;
     acp:target ex:resourceX ;
+    acp:agent ex:Bob ;
   ] .
@@ -2335,6 +2341,52 @@

for resolving permissions to access controlled resources.

+
+

+ 6.1. Resolved Access Control +

+

+ An ACP engine MUST grant exactly those Access Modes allowed by + Effective Policies. +

+ +
+

+ 6.1.1. Resolved Access Control pseudocode +

+ 
function resolveAccessControl(acr, ancestorAcrs, context) {
+  const effectivePolicies = gatherEffectivePolicies(acr, ancestorAcrs)
+  const allowedAccessModes = grantAccessModes(effectivePolicies, context)
+  const grantGraph = {
+      context,
+      grant: allowedAccessModes
+  }
+
+  return grantGraph
+}
+
+
+
+
property="bibo:hasPart" >

- 6.1. 6.2. Effective Policies

- Both the acp:resource property and its inverse - acp:accessControlResource MUST be taken into account in - determining the Access Control Resources controlling access to - resources. + Effective Policies are the Policies controlling access to a + resource.

-

- All Access Controls controlling member resources access via the - acp:memberAccessControl property MUST be included in - the set of Access Controls linked as - acp:accessControl in the effective authorization graph - of a resource. -

+

A Policy MUST control access to a resource if:

-

- The set of Policies controlling access to a resource MUST contain - all Policies that are linked to a resource via the - property path - acp:accessControlResource/acp:accessControl/acp:apply - SPARQL11 QUERY. -

+
    +
  • + it is applied by an Access Control of an ACR of the resource; or, +
    • +
  • + it is applied by a member Access Control of an ACR of an ancestor + of the resource. +
    • +
property="bibo:hasPart" >

- 6.1.1. 6.2.1. Effective Policies example

@@ -2417,6 +2459,38 @@

+ +
+

+ 6.2.2. Effective Policies pseudocode +

+ 
function gatherEffectivePolicies(acr, ancestorAcrs) {
+  const effectivePolicies = new Set
+
+  // Direct access controls of own ACR.
+  for (const accessControl of acr.accessControls)
+      for (const policy of accessControl.appliedPolicies)
+          effectivePolicies.add(policy)
+
+  // Member access controls of ancestor ACRs.
+  for (const acr of ancestorAcrs)
+      for (const accessControl of acr.memberAccessControls)
+          for (const policy of accessControl.appliedPolicies)
+              effectivePolicies.add(policy)
+
+  return effectivePolicies
+}
+
+
property="bibo:hasPart" >

- 6.2. 6.3. Granted Access Modes

- An Access Mode MUST be granted over a resource if and only if in - the set of Policies controlling access to it: + An Access Mode MUST be granted if and only if in the set of + Effective Policies:

    -
  • A satisfied policy allows the Access Mode; and
    • -
  • No satisfied policy denies the Access Mode.
    • +
  • a satisfied policy allows the Access Mode; and,
    • +
  • no satisfied policy denies it.
@@ -2448,7 +2522,7 @@

property="bibo:hasPart" >

- 6.2.1. 6.3.1. Granted Access Modes example

@@ -2501,30 +2575,30 @@

property="bibo:hasPart" >

- 6.2.2. 6.3.2. Granted Access Modes pseudocode 

function grantAccessModes(policies, context) {
-  const allow = new Set, deny = new Set
+  const allowedAccessModes = new Set, deniedAccessModes = new Set
 
-  // Gather allowed and denied access modes from satisfied policies  
+  // Gather allowed and denied access modes from satisfied policies
   for (const policy of policies)
       if (isSatisfiedPolicy(policy, context)) {
-          for (const mode of policy.allow)
-              allow.add(mode)
+          for (const mode of policy.allowedAccessModes)
+              allowedAccessModes.add(mode)
 
-          for (const mode of policy.deny)
-              deny.add(mode)
+          for (const mode of policy.deniedAccessModes)
+              deniedAccessModes.add(mode)
       }
 
   // Deny overrules allow.
-  for (const mode of deny)
-      allow.delete(mode)
+  for (const mode of deniedAccessModes)
+      allowedAccessModes.delete(mode)
 
-  return allow
+  return allowedAccessModes
 }
@@ -2537,40 +2611,30 @@

property="bibo:hasPart" >

- 6.3. 6.4. Satisfied Policy

-

- Policies are satisfied via the acp:allOf, - acp:anyOf and acp:noneOf properties which - act respectively as intersection, union and exclusion operators. -

-
-

A Policy MUST be considered satisfied if and only if:

+

A Policy MUST be satisfied if and only if:

  • - It references at least one Matcher via a - acp:allOf or acp:anyOf property; and + it references at least one Matcher via an + acp:allOf or acp:anyOf property; and,
  • - At least one Matcher it references matches the given resource - access description; and + all of its acp:allOf Matchers are satisfied; and,
  • - The acp:allOf, acp:anyOf and - acp:noneOf of conditions it defines are satisfied. + at least one of its acp:anyOf Matchers is + satisfied; and, +
    • +
  • + none of its acp:noneOf Matchers are satisfied.
-

- Given that the acp:noneOf condition excludes matches, a - policy without a satisfied acp:allOf or - acp:anyOf condition is never satisfied. -

-
property="bibo:hasPart" >

- 6.3.1. 6.4.1. Satisfied Policy example

@@ -2594,16 +2658,17 @@

A will not be satisfied.
  • - If both Matcher D and Matcher E are not satisfied, then Policy A + If neither Matcher D nor Matcher E are satisfied, then Policy A will not be satisfied.
  • - If Matcher F is satisfied, then Policy A will not be satisfied. + If either Matcher F or Matcher G is satisfied, then Policy A + will not be satisfied.
  • If both Matcher B and Matcher C are satisfied, and, either - Matcher D or Matcher E are satisfied, and, Matcher F is not - satisfied, then Policy A will be satisfied. + Matcher D or Matcher E are satisfied, and, Matcher F and Matcher + G are not satisfied, then Policy A will be satisfied.
    • @@ -2621,7 +2686,7 @@

    ex:policyA acp:allOf ex:matcherB, ex:matcherC ;   acp:anyOf ex:matcherD, matcherE ; - acp:noneOf ex:matcherF . + acp:noneOf ex:matcherF, ex:matcherG .

    @@ -2633,7 +2698,7 @@

    property="bibo:hasPart" >

    - 6.3.2. 6.4.2. Satisfied Policy pseudocode

    @@ -2641,17 +2706,17 @@

    class="highlight pseudocode" >function isSatisfiedPolicy(policy, context) { // If any 'none of' matcher is satisfied then the policy is not satisfied. - for (const matcher of policy.noneOf) + for (const matcher of policy.noneOfMatchers) if (isSatisfiedMatcher(matcher, context)) return false - // If any 'all of' matcher is not satisfied then the policy is not satisfied.   - for (const matcher of policy.allOf) + // If any 'all of' matcher is not satisfied then the policy is not satisfied. + for (const matcher of policy.allOfMatchers) if (!isSatisfiedMatcher(matcher, context)) return false // If any 'any of' matcher is satisfied then the policy is satisfied. - for (const matcher of policy.anyOf) + for (const matcher of policy.anyOfMatchers) if (isSatisfiedMatcher(matcher, context)) return true @@ -2663,7 +2728,7 @@

    // Hence, the policy is satisfied if it has // - an 'all of' condition and // - no 'any of' condition. - return policy.allOf.size !== 0 && policy.anyOf.size === 0 + return policy.allOfMatchers.size !== 0 && policy.anyOfMatchers === 0 } @@ -2676,35 +2741,23 @@

    property="bibo:hasPart" >

    - 6.4. 6.5. Satisfied Matcher

    -

    - The default operation of matching is based on - IRI - and - literal term equality - as defined in the RDF 1.1 Concepts and Abstract Syntax - RDF11 CONCEPTS. -

    -
    -

    A Matcher MUST be considered satisfied if and only if:

    +

    A Matcher MUST be satisfied if and only if:

      -
    • It defines at least one matching attribute; and
      • +
    • it defines at least one attribute; and,
    • - All the attributes defined find a match in the given resource - access description. + at least one value of each defined attribute matches the + Context.
    +

    + ACP engines MUST match the context attributes defined by this + specification according to IRI equality and literal term equality. +

    property="bibo:hasPart" >

    - 6.4.1. 6.5.1. Satisfied Matcher example

    +

    + The following example authorization graph means that access to + resource X is controlled by a Policy that will allow read if it is + satisfied and be satisfied if either matcher A or matcher B or + both are satisfied. +

    + +

    Matcher A will be satisfied if:

    + +
      +
    • + either Alice or Bob are the requesting agent or if the + requesting agent is an owner or creator; and, +
      • +
    • client 1 is used by the requesting agent; and,
      • +
    • + issuer 2 is used by the requesting agent to assert their + identity. +
      • +
    + +

    Matcher B will be satisfied if:

    + +
      +
    • a valid VC of type "Family Member" is presented.
      • +
    + + 
    +[
+  acp:resource ex:X ;
+  acp:accessControl [
+    acp:apply [
+      acp:allow acl:Read ;
+      acp:anyOf ex:matcherA, ex:matcherB ;
+    ]
+  ]
+] .
+
+ex:matcherA
+  acp:agent ex:Alice, ex:Bob, acp:CreatorAgent, acp:OwnerAgent ;  
+  acp:client ex:client1 ;
+  acp:issuer ex:issuer2 .
+
+ex:matcherB
+  acp:vc ex:FamilyMember .
+
    property="bibo:hasPart" >

    - 6.4.2. 6.5.2. Satisfied Matcher pseudocode

    + 
    function isSatisfiedMatcher(matcher, context) {
+  // An empty matcher is never satisfied.
+  if (matcher.agents.size === 0 && matcher.clients.size === 0 && matcher.issuers.size === 0 && matcher.vcs.size === 0)
+      return false
+
+  // For each attribute, if any values are defined, then at least one of them must match the context.
+
+  if (matcher.agents.size !== 0) {
+      let isMatch = false
+
+      for (const agent of matcher.agents)
+          if (agentMatches(agent, context)) {
+              isMatch = true
+              break
+          }
+
+      if (!isMatch)
+          return false
+  }
+
+  if (matcher.clients.size !== 0) {
+      let isMatch = false
+
+      for (const client of matcher.clients)
+          if (clientMatches(client, context)) {
+              isMatch = true
+              break
+          }
+
+      if (!isMatch)
+          return false
+  }
+
+  if (matcher.issuers.size !== 0) {
+      let isMatch = false
+
+      for (const issuer of matcher.issuers)
+          if (issuerMatches(issuer, context)) {
+              isMatch = true
+              break
+          }
+
+      if (!isMatch)
+          return false
+  }
+
+  if (matcher.vcs.size !== 0) {
+      let isMatch = false
+
+      for (const vc of matcher.vcs)
+          if (vcMatches(vc, context)) {
+              isMatch = true
+              break
+          }
+
+      if (!isMatch)
+          return false
+  }
+
+  // At this point, the matcher is satisfied because
+  // - there was at least one defined attribute and
+  // - at least one value of each defined attribute matched the context.
+  return true
+}
+
+const publicAgent = "https://www.w3.org/ns/solid/acp#PublicAgent"
+const authenticatedAgent = "https://www.w3.org/ns/solid/acp#AuthenticatedAgent"
+const creatorAgent = "https://www.w3.org/ns/solid/acp#CreatorAgent"
+const ownerAgent = "https://www.w3.org/ns/solid/acp#OwnerAgent"
+function agentMatches(agent, context) {
+  if (agent === publicAgent)
+      return true
+
+  if (agent === authenticatedAgent && context.agent !== null)
+      return true
+
+  if (agent === creatorAgent && context.creators.includes(context.agent))
+      return true
+
+  if (agent === ownerAgent && context.owners.includes(context.agent))
+      return true
+
+  if (agent === context.agent)
+      return true
+}
+
+const publicClient = "https://www.w3.org/ns/solid/acp#PublicClient"
+function clientMatches(client, context) {
+  if (client === publicClient)
+      return true
+
+  if (client === context.client)
+      return true
+}
+
+const publicIssuer = "https://www.w3.org/ns/solid/acp#PublicIssuer"
+function issuerMatches(issuer, context) {
+  if (issuer === publicIssuer)
+      return true
+
+  if (issuer === context.issuer)
+      return true
+}
+
+function vcMatches(vc, context) {
+  if (context.vcs.includes(vc))
+      return true
+}
+
    @@ -2747,174 +2961,82 @@

    >

    - This section introduces ACP server capability and ACR discovery, as - well as ACR editing, and ACP resources lifecycle management. + This section introduces conforming resource server and ACP server + requirements.

    -

    +

    7.1. Capability discovery + >Conforming resource server

    - When a server wants to enable applications to discover its ACP - capabilities, it MUST do so via link headers. -

    - -

    - The server MUST advertise the access modes it supports by responding - to HTTP OPTIONS requests over ACP access control resources including - a Link header with the rel value of - http://www.w3.org/ns/solid/acp#grant and the full URI - of an access mode as link target [RFC8288]. The server MUST produce - one such Link header for each access mode it supports. -

    - -

    - For example, if a server supports the ACL read, write and append - access modes, it should advertise it by responding to HTTP OPTIONS - requests over ACP access control resources including three link - headers with rel value of - http://www.w3.org/ns/solid/acp#grant and respectively - targets of http://www.w3.org/ns/auth/acl#Read, - http://www.w3.org/ns/auth/acl#Write and - http://www.w3.org/ns/auth/acl#Append in order to make - it explicit which set of access modes are understood and relevant - when editing ACP policies. + Conforming resource servers MUST provide ACP servers with resource + access Contexts and MUST authorize resource access according to + grant graphs produced by a conforming ACP server.

    - The server MUST advertise the request attributes it supports by - responding to HTTP OPTIONS requests over ACP access control - resources including a Link header with the rel value of - http://www.w3.org/ns/solid/acp#attribute and the full - URI of an acp attribute as link target [RFC8288]. The server MUST - produce one such Link header for each request attribute it supports. + When responding to requests targetting access controlled resources, + conforming resource servers MUST include a Link header + with the rel value of acl and controlled + resources' ACRs as the link target + RFC 8288.

    - For example, if a server supports the ACP agent, client and issuer - request attributes, it should advertise it by responding to HTTP - OPTIONS requests over ACP access control resources including three - link headers with rel value of - http://www.w3.org/ns/solid/acp#attribute and - respectively targets of - http://www.w3.org/ns/solid/acp#agent, - http://www.w3.org/ns/solid/acp#client and - http://www.w3.org/ns/solid/acp#issuer in order to make - it explicit which set of request attributes are understood and - relevant when editing ACP matchers. + Conforming resource servers MUST provide ACP servers with sufficient + resource membership information to resolve ancestor ACRs.

    -

    +

    7.2. ACR discovery + >Conforming ACP server

    - When a server wants to enable applications to discover the ACP - access control resource associated with a given resource, the server - MUST advertise the ACP access control resource that is associated - with that resource by responding to HTTP requests over the resource - including a Link header with the rel value - of acl (acl Link Relation) and the ACP access control - resource as the link target [RFC8288]. The same mechanism is used in - Web Access Control resource discovery. -

    -

    - A server responding to an HTTP request over an ACP access control - resource MUST include a Link header with the + When responding to requests targetting an ACR, conforming ACP + servers MUST include a Link header with the rel value of type and the - acp:AccessControlResource URI as link target. + http://www.w3.org/ns/solid/acp#AccessControlResource + IRI as the link target.

    -
    -
    -

    - 7.3. ACR editing -

    - The owner of a storage is implicitly considered an owner of all the - resources in the URI space corresponding to the storage. + When responding to OPTIONS requests targetting an ACR, conforming + ACP servers MUST include a Link header for each + supported Access Mode with the rel value of + http://www.w3.org/ns/solid/acp#grant and the full IRI + of the supported Access Mode as the link target.

    - An owner of a resource is implicitly considered an owner of its - associated Access Control Resource. -

    - -

    - An owner of an Access Control Resource implicitly has full read and - write access over it. -

    - -

    - To add or remove an Access Control from an ACR, agents that are not - owners of said ACR need read and write access to both the ACR itself - and to the resource where said Access Control is defined. In other - words, Access Controls defined as part of a separate resource can be - protected from unwanted edits in and out of ACRs by setting adequate - permissions in their own ACR. -

    -
    - -
    -

    - 7.4. Resource management -

    -

    Access Control Resources MUST be server managed.

    - -

    - There is a one to one relationship between a resource and its - authoritative source of access control. Therefore, when resources - are created or deleted, the corresponding ACRs MUST be created or - deleted accordingly. + When responding to OPTIONS requests targetting an ACR, conforming + ACP servers MUST include a Link header for each + supported attribute with the rel value of + http://www.w3.org/ns/solid/acp#attribute and the full + IRI of the supported attribute as the link target.

    -

    - Access Controls, Policies and Matchers MAY all be access controlled - via their own ACR. -

    +

    Conforming ACP engines MAY be conforming resource servers.

    - As long as an Access Control, a Policy or a Matcher is referenced by - an ACR, it MUST not be deleted. However, if such consistency failed - to be enforced or if an Access Control, a Policy or a Matcher is not - accessible for any other reason, then access permissions resolution - MUST fail to its default behaviour of only granting read and write - access to the invalid ACR to its owners; read and write access MUST - not be implicitly granted to a resource whose access control - resolution fails, even to owners of that resource. + The lifecycle of Access Control Resources SHOULD take into account + the lifecycle of resources they control access to.

    @@ -2928,6 +3050,19 @@

    >

    Acknowledgements

    This section is non-normative.

    + +

    + Samu Lang provided a comprehensive review of the specification as well + as the pseudocode sections. +

    + +

    + The Solid Community Group would like to thank the following individuals + for reviewing and providing feedback on the specification (in + alphabetical order): Justin Bingham, Sarven Capadisli, Aaron Coburn, + Pete Edwards, Samu Lang, Elf Pavlik, Henry Story, Ted Thibodeau Jr, + Emmet Townsend. +

    References property="bibo:hasPart" >

    Normative references

    -
    +
    [RDF11-CONCEPTS]
    Normative references >https://www.w3.org/TR/rdf11-concepts/.
    +
    [RFC2119]
    Normative references >https://datatracker.ietf.org/doc/html/rfc2119.
    +
    [RFC8174]
    Normative references >https://datatracker.ietf.org/doc/html/rfc8174.
    -
    [SPARQL11-QUERY]
    + +
    [RFC8288]
    +
    + Web Linking. B. Leiba. IETF. October 2017. Proposed Standard. URL: + https://datatracker.ietf.org/doc/html/rfc8288. +
    + +
    [VC-DATA-MODEL]
    SPARQL 1.1 Query. Steve Harris; Andy Seaborne; Eric Prud'hommeaux. W3C. 21 March - 2013. W3C Recommendation. URL: - https://www.w3.org/TR/sparql11-query/VC Data Model. Manu Sporny; Grant Noble; Dave Longley; Daniel C. Burnett; Brent + Zundel; Kyle Den Hartog. W3C. 3 March 2022. W3C Recommendation. URL: + https://www.w3.org/TR/vc-data-model/.
    @@ -3006,6 +3156,18 @@

    Normative references

    property="bibo:hasPart" >

    Informative references

    +
    +
    [RDF11-TURTLE]
    +
    + RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C + Recommendation. URL: + https://www.w3.org/TR/turtle/. +
    +
    diff --git a/2022/acp-20220518.ttl b/2022/acp-20220518.ttl new file mode 100644 index 00000000..20f146cf --- /dev/null +++ b/2022/acp-20220518.ttl @@ -0,0 +1,285 @@ +prefix acp: +prefix rdf: +prefix rdfs: +prefix owl: +prefix xsd: +prefix dc: +prefix vann: + + + a owl:Ontology ; + rdfs:label "Access Control Policy Language (ACP)"@en ; + rdfs:comment "The Access Control Policy Language (ACP) is a language for describing, controlling and granting access to resources."@en ; + rdfs:isDefinedBy acp: ; + rdfs:seeAlso ; + cito:citesAsAuthority + , + , + , + , + ; + dc:issued "2022-05-18"^^xsd:date ; + vann:preferredNamespacePrefix "vann" ; + vann:preferredNamespaceUri "http://www.w3.org/ns/solid/acp#"^^xsd:anyURI . + + +################# +# Classes +################# +acp:Context + a rdfs:Class ; + rdfs:label "Context"@en ; + rdfs:comment "Instances of the Context class describe instances of resource access."@en ; + rdfs:isDefinedBy acp: . + +acp:AccessControlResource + a rdfs:Class ; + rdfs:label "Access Control Resource"@en ; + rdfs:comment "Instances of the Access Control Resource (ACR) class connect resources to their Access Controls."@en ; + rdfs:comment "Both the acp:resource property and its inverse acp:accessControlResource MUST be taken into account in determining the Access Control Resources controlling access to resources."@en ; + rdfs:isDefinedBy acp: . + +acp:AccessControl + a rdfs:Class ; + rdfs:label "Access Control"@en ; + rdfs:comment "Instances of the Access Control class connect Access Control Resources to their Policies."@en ; + rdfs:commnet "All Access Controls controlling member resources access via the acp:memberAccessControl property MUST be included in the set of Access Controls linked as acp:accessControl in the effective authorization graph of a resource."@en ; + rdfs:isDefinedBy acp: . + +acp:Policy + a rdfs:Class ; + rdfs:label "Access Policy"@en ; + rdfs:comment "Instances of the Policy class connect Access Controls to allowed and denied Access Modes as well as sets of Matchers describing instances of resource access."@en ; + rdfs:comment " An ACP engine MUST grant exactly those Access Modes allowed by Effective Policies."@en ; + rdfs:comment "Effective Policies are the Policies controlling access to a resource. A Policy MUST control access to a resource if: it is applied by an Access Control of an ACR of the resource; or, it is applied by a member Access Control of an ACR of an ancestor of the resource."@en ; + rdfs:comment "An Access Mode MUST be granted if and only if in the set of Effective Policies controlling access to it: a satisfied policy allows the Access Mode; and, no satisfied policy denies it."@en ; + rdfs:comment "A Policy MUST be satisfied if and only if: it references at least one Matcher via an acp:allOf or acp:anyOf property; and, all of its acp:allOf Matchers are satisfied; and, at least one of its acp:anyOf Matchers is satisfied; and, none of its acp:noneOf Matchers are satisfied."@en ; + rdfs:seeAlso ; + rdfs:isDefinedBy acp: . + +acp:Matcher + a rdfs:Class ; + rdfs:label "Matcher"@en ; + rdfs:comment "Instances of the Matcher class are descriptions of matching resource access Contexts."@en ; + rdfs:comment "A Matcher MUST be satisfied if and only if: it defines at least one attribute; and, at least one value of each defined attribute matches the Context. ACP engines MUST match the context attributes defined by this specification according to IRI equality and literal term equality."@en ; + rdfs:comment "ACP implementations supporting sub-properties of acp:attribute other than the ones defined by ACP SHOULD also define and implement corresponding matching algorithms."@en ; + rdfs:seeAlso ; + rdfs:isDefinedBy acp: . + +acp:AlwaysSatisfiedRestriction + a rdfs:Class ; + rdfs:label "Always Satisfied Restriction"@en ; + rdfs:comment "Defined instances of the Always Satisfied Restriction class are used in Matcher restrictions to indicate that the restriction is always satisfied. The default behaviour of a Matcher is to not be satisfied, so this is the only way to make a Matcher always satisfied."@en ; + rdfs:isDefinedBy acp: . + +acp:AccessMode + a rdfs:Class ; + rdfs:label "Access Mode"@en ; + rdfs:comment "The ACP specification does not define specific Access Modes. Instead, any Access Mode granted is an instance of the Access Mode class. Access Modes and their granularity can be tailored to the needs of an application and Access Modes defined in other vocabularies can also be used (for example instances of ACL Access)."@en ; + rdfs:isDefinedBy acp: ; + rdfs:seeAlso . + +acp:AccessGrant + a rdfs:Class ; + rdfs:label "Access Grant"@en ; + rdfs:comment "Instances of the Access Grant class define sets of Access Modes granted in particular Contexts."@en ; + rdfs:isDefinedBy acp: . + + +#################### +# Properties +#################### +acp:resource + a rdf:Property ; + owl:inverseOf acp:accessControlResource ; + rdfs:label "resource"@en ; + rdfs:comment "The resource property connects ACRs to resources they control. It is the inverse of acp:accessControlResource."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:AccessControlResource . + +acp:accessControlResource + a rdf:Property ; + owl:inverseOf acp:resource ; + rdfs:label "access control resource"@en ; + rdfs:comment "The access control resource property connects resources to ACRs controlling access to them. It is the inverse of acp:resource."@en ; + rdfs:isDefinedBy acp: ; + rdfs:range acp:AccessControlResource . + +acp:accessControl + a rdf:Property ; + rdfs:label "access control"@en ; + rdfs:comment "The access control property connects ACRs to Access Controls."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:AccessControlResource ; + rdfs:range acp:AccessControl . + +acp:memberAccessControl + rdfs:label "member access control"@en ; + rdfs:comment "The member access control property transitively connects ACRs of member resources to Access Controls."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:AccessControlResource ; + rdfs:range acp:AccessControl . + +acp:apply + a rdf:Property ; + rdfs:label "apply"@en ; + rdfs:comment "The apply property connects Access Controls to the Policies they apply to resources."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:AccessControl ; + rdfs:range acp:Policy . + +acp:allow + a rdf:Property ; + rdfs:label "allow"@en ; + rdfs:comment "The allow property connects Policies to the Access Modes they allow if satisfied."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:Policy ; + rdfs:range acp:AccessMode . + +acp:deny + a rdf:Property ; + rdfs:label "deny"@en ; + rdfs:comment "The deny property connects Policies to the Access Modes they deny if satisfied."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:Policy ; + rdfs:range acp:AccessMode . + +acp:allOf + a rdf:Property ; + rdfs:label "all of"@en ; + rdfs:comment "The all of property connects Policies to a set of Matchers all of which MUST be satisfied for the Policy to be satisfied."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:Policy ; + rdfs:range acp:Matcher . + +acp:anyOf + a rdf:Property ; + rdfs:label "any of"@en ; + rdfs:comment "The any of property connects Policies to a set of Matchers at least one of which MUST be satisfied for the Policy to be satisfied."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:Policy ; + rdfs:range acp:Matcher . + +acp:noneOf + a rdf:Property ; + rdfs:label "none of"@en ; + rdfs:comment "The none of property connects Policies to a set of Matchers all of which MUST NOT be satisfied for the Policy to be satisfied."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:Policy ; + rdfs:range acp:Matcher . + +acp:attribute + a rdf:Property ; + rdfs:label "attribute"@en ; + rdfs:comment "Sub-properties of ACP attribute are used to describe instances of resource access."@en ; + rdfs:comment "Sub-properties of acp:attribute can be created to fit the specific access control requirements of applications."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:Context . + +acp:target + rdfs:label "target"@en ; + rdfs:comment "The target attribute describes requested access controlled resources."@en ; + rdfs:isDefinedBy acp: ; + rdfs:subPropertyOf acp:attribute . + +acp:mode + rdfs:label "mode"@en ; + rdfs:comment "The mode attribute describes requested modes of access."@en ; + rdfs:isDefinedBy acp: ; + rdfs:subPropertyOf acp:attribute . + +acp:agent + rdfs:label "agent"@en ; + rdfs:comment "The agent attribute describes agents initiating requests."@en ; + rdfs:comment "In a Matcher, agent attributes define a set of agents, at least one of which MUST match the Context for the Matcher to be satisfied."@en ; + rdfs:isDefinedBy acp: ; + rdfs:subPropertyOf acp:attribute . + +acp:creator + rdfs:label "creator"@en ; + rdfs:comment "The creator attribute describes creators of requested resources."@en ; + rdfs:isDefinedBy acp: ; + rdfs:subPropertyOf acp:attribute . + +acp:owner + rdfs:label "owner"@en ; + rdfs:comment "The owner attribute describes owners of requested resources."@en ; + rdfs:isDefinedBy acp: ; + rdfs:subPropertyOf acp:attribute . + +acp:client + rdfs:label "client"@en ; + rdfs:comment "The client attribute describes client applications used to request resources."@en ; + rdfs:comment "In a Matcher, client attributes define a set of clients, at least one of which MUST match the Context for the Matcher to be satisfied. "@en ; + rdfs:isDefinedBy acp: ; + rdfs:subPropertyOf acp:attribute . + +acp:issuer + rdfs:label "issuer"@en ; + rdfs:comment "The issuer attribute describes identity providers used to assert the identity of agents requesting resources."@en ; + rdfs:comment "In a Matcher, issuer attributes define a set of issuers, at least one of which MUST match the Context for the Matcher to be satisfied."@en ; + rdfs:isDefinedBy acp: ; + rdfs:subPropertyOf acp:attribute . + +acp:vc + rdfs:label "vc"@en ; + rdfs:comment "The vc attribute describes types of Verifiable Credentials (VC) presented as part of resource access requests."@en ; + rdfs:comment "In a Matcher, vc attributes define a set of types of Verifiable Credentials (VC), at least one of which MUST match the Context for the Matcher to be satisfied. A VC type present in the Context MUST be a valid VC presented as part of the resource access request."@en ; + rdfs:isDefinedBy acp: ; + rdfs:subPropertyOf acp:attribute ; + cito:citesAsAuthority , ; + rdfs:seeAlso . + +acp:context + rdfs:label "context"@en ; + rdfs:comment "The context property connects Access Grants to the Contexts in which they're given."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:AccessGrant ; + rdfs:range acp:Context . + +acp:grant + rdfs:label "grant"@en ; + rdfs:comment "The grant property connects Access Grants to the Access Modes they grant."@en ; + rdfs:isDefinedBy acp: ; + rdfs:domain acp:AccessGrant ; + rdfs:range acp:AccessMode . + + +######################## +# Named Individuals +######################## +acp:PublicAgent + a owl:NamedIndividual, acp:AlwaysSatisfiedRestriction ; + rdfs:comment "In a Matcher, agent attributes using the Public Agent named individual MUST match all Contexts."@en ; + rdfs:isDefinedBy acp: ; + rdfs:label "Public Agent"@en . + +acp:AuthenticatedAgent + a owl:NamedIndividual ; + rdfs:comment "In a Matcher, agent attributes using the Authenticated Agent named individual MUST match Contexts that contain an agent."@en ; + rdfs:isDefinedBy acp: ; + rdfs:label "Authenticated Agent"@en . + +acp:CreatorAgent + a owl:NamedIndividual ; + rdfs:comment "In a Matcher, agent attributes using the Creator Agent named individual MUST match Contexts where a defined creator matches the defined agent."@en ; + rdfs:isDefinedBy acp: ; + rdfs:label "Creator Agent"@en . + +acp:OwnerAgent + a owl:NamedIndividual ; + rdfs:comment "In a Matcher, agent attributes using the Owner Agent named individual MUST match Contexts where a defined owner matches the defined agent."@en ; + rdfs:isDefinedBy acp: ; + rdfs:label "Owner Agent"@en . + +acp:PublicClient + a owl:NamedIndividual, acp:AlwaysSatisfiedRestriction ; + rdfs:comment "In a Matcher, client attributes using the Public Client named individual MUST match all Contexts."@en ; + rdfs:isDefinedBy acp: ; + rdfs:label "Public Client"@en . + +acp:PublicIssuer + a owl:NamedIndividual, acp:AlwaysSatisfiedRestriction ; + rdfs:comment "In a Matcher, issuer attributes using the Public Issuer named individual MUST match all Contexts."@en ; + rdfs:isDefinedBy acp: ; + rdfs:label "Public Issuer"@en . diff --git a/2022/acp-code-20220513.css b/2022/acp-code-20220518.css similarity index 100% rename from 2022/acp-code-20220513.css rename to 2022/acp-code-20220518.css diff --git a/2022/acp-data-model-20220513.svg b/2022/acp-data-model-20220513.svg deleted file mode 100644 index 57717ec9..00000000 --- a/2022/acp-data-model-20220513.svg +++ /dev/null @@ -1 +0,0 @@ - \ No newline at end of file diff --git a/2022/acp-data-model-20220518.svg b/2022/acp-data-model-20220518.svg new file mode 100644 index 00000000..8f1a8928 --- /dev/null +++ b/2022/acp-data-model-20220518.svg @@ -0,0 +1 @@ + diff --git a/2022/acp-main-20220513.css b/2022/acp-main-20220518.css similarity index 100% rename from 2022/acp-main-20220513.css rename to 2022/acp-main-20220518.css diff --git a/acp.html b/acp.html index ade86308..bb1f2778 100644 --- a/acp.html +++ b/acp.html @@ -1,50 +1,51 @@ - + Access Control Policy (ACP) - - + +
    -

    Access Control Policy (ACP)

    Version 0.9.0, - +

    More details about this document
    This version
    - https://solidproject.org/TR/2022/acp-20220513 + https://solidproject.org/TR/2022/acp-20220518
    Latest version
    @@ -97,7 +98,7 @@

    2022 W3C Solid Community Group.

    @@ -116,7 +117,7 @@

    Abstract

    >Access Control Policy Language (ACP). ACP is a language for describing, controlling and granting access to + >ACP is a language for describing, controlling, and granting access to resources.

    @@ -376,30 +377,53 @@

    Table of Contents

    6Access Control resolution +
      +
    1. + 6.1Resolved Access Control +
        +
      1. + 6.1.1Resolved Access Control + pseudocode +
        2. +
      +
      2. +
    1. 6.1Effective Policies6.2Effective Policies
      1. 6.1.1Effective Policies + >6.2.1Effective Policies example
      +
        +
      1. + 6.2.2Effective Policies + pseudocode +
        2. +
    1. 6.2Granted Access Modes6.3Granted Access Modes
      1. 6.2.1Granted Access Modes + >6.3.1Granted Access Modes example
        2. @@ -407,7 +431,7 @@

        Table of Contents

        1. 6.2.2Granted Access Modes + >6.3.2Granted Access Modes pseudocode
          2. @@ -417,19 +441,19 @@

          Table of Contents

          1. 6.3Satisfied Policy6.4Satisfied Policy
            1. 6.3.1Satisfied Policy example6.4.1Satisfied Policy example
            1. 6.3.2Satisfied Policy + >6.4.2Satisfied Policy pseudocode
              2. @@ -439,12 +463,12 @@

              Table of Contents

              1. 6.4Satisfied Matcher6.5Satisfied Matcher
                1. 6.4.1Satisfied Matcher + >6.5.1Satisfied Matcher example
                  2. @@ -452,7 +476,7 @@

                  Table of Contents

                  1. 6.4.2Satisfied Matcher + >6.5.2Satisfied Matcher pseudocode
                    2. @@ -466,29 +490,15 @@

                    Table of Contents

                    >
                    1. - 7.1Capability discovery -
                      2. -
                    -
                      -
                    1. - 7.2ACR discovery -
                      2. -
                    -
                      -
                    1. - 7.3ACR editing7.1Conforming resource server
                    1. - 7.4Resource management7.2Conforming ACP server
                    @@ -531,7 +541,7 @@

                    explanation of the conventions used in this document, example graphs to illustrate basic concepts of resource access description and validation, a diagram representing the main elements of the ACP data - model, and a non-normative RDF representation of the ACP ontology. + model, and an RDF representation of the ACP ontology.

                    >namespace prefix, RDF graph, - RDF triplegraph, IRI >, node - of an RDF graph, - RDF term, - subjectterm, - predicate, and - object - of RDF triples, - datatype, and IRIIRI equality and

                    This section is non-normative.

                    -
                    Context graph
                    +
                    Context graph
                    Context graphs describe the - attributes of resource access instances. Those attributes can be - matched to sets of conditions defined in the form of an - authorization graph + attributes of resource access instances. An access request's + attributes can be matched to sets of conditions defined in the + form of an + authorization graph in order to determine Access Modes granted over resources.
                    -
                    Authorization graph
                    + +
                    + Authorization graph +
                    Authorization graphs authoritatively define the conditions for granting Access Modes - over resources through Access Controls, Policies and Matchers. The - result of applying an authorization graph to a described instance - of resource access is an - access grant graph. + over resources through Access Control Resources, Access Controls, + Policies and Matchers. The result of applying an authorization + graph to a described instance of resource access is an + access grant graph.
                    -
                    Access grant graph
                    + +
                    Access grant graph
                    Access grant graphs describe - sets of granted access modes over resources in the context of - resource access instances. + sets of Access Modes granted over resources in the context of + resource access requests. Access grants are the result of + access control resolution. +
                    + +
                    + Access control resolution +
                    +
                    + Access control resolution + describes the algorithm used to apply an authorization graph to a + context graph in order to obtain an access grant graph.
                    @@ -773,18 +787,22 @@

                    Throughout this document, color-coded boxes contain the RDF representation of example context graphs, authorization graphs, and - access grant graphs serialized in Turtle. Those graphs use a mix of - IRIs and blank nodes where applicable to better show the range of - possible representations. + access grant graphs serialized in + turtle + RDF11-TURTLE. Those graphs use a mix of IRIs and blank nodes where applicable + to better show the range of possible representations.

                    The following example - context graph describes an - instance of resource access and could be translated as: + context graph describes + an instance of resource access and could be translated as: "Bob is trying to access resource X using client application Y - with his identity asserted by identity provider Z.""Bob is trying to read resource X using client application Y with + their identity asserted by identity provider Z.".

                    @@ -793,23 +811,26 @@

                    # It describes an instance of resource access   [] - acp:agent ex:Bob ; acp:target ex:resourceX ; - acp:client ex:ClientApplicationY ; - acp:issuer ex:IdentityProviderZ . + acp:agent ex:Bob ; + acp:mode acl:Read ; + acp:client ex:clientApplicationY ; + acp:issuer ex:identityProviderZ .

                    The following example - authorization graph - authoritatively defines the conditions of access to resource X and - could be translated as: + authorization graph + defines the conditions of access to resource X and could be + translated as: "Access to resource X is mandated by one Access Control that applies one Policy which allows access mode - acl:Read when the agent matcher is satisfied that - Alice or Bob are the agent trying to access resource X."acl:Read when Alice or Bob are the agent trying to + access resource X.".

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

                    a acp:Policy ; acp:allow acl:Read ; acp:anyOf [ - a acp:AgentMatcher ; + a acp:Matcher ; acp:agent ex:Alice, ex:Bob ; ] ] @@ -839,17 +860,19 @@

                    The following example - access grant graph is - the result of applying the previous example authorization graph - which defines access to resource X to the previous example context - graph which describes an instance of access to target resource X. - Bob is matched as the context agent and since it defines no further - restrictions, the policy allowing acl:Read is + access grant graph + is the result of + applying + the previous example authorization graph which defines access to + resource X to the previous example context graph which describes a + read access request to target resource X. Bob is matched as the + context agent and since the policy allowing + acl:Read defines no further restrictions, it is satisfied. The following access grant graph could be read as: "The access mode acl:Read is granted to Bob whom - requested access to resource X using client application Y and - whose identity was asserted by identity provider Z.""The access mode acl:Read is granted to Bob who + requested read access to resource X using client application Y + with their identity asserted by identity provider Z.".

                    @@ -865,6 +888,7 @@

                    acp:context [ acp:agent ex:Bob ; acp:target ex:resourceX ; + acp:mode acl:Read ; acp:client ex:ClientApplicationY ; acp:issuer ex:IdentityProviderZ ; ] . @@ -887,7 +911,7 @@

                    The following diagram illustrates the main elements of ACP.

                    ACP Data Model @@ -905,7 +929,7 @@

                    All terms defined by the Access Control Policy Language are present in a non-normative RDF representation of the - ACP ontology serialized in turtle. + ACP ontology serialized in turtle.

                    @@ -1021,16 +1045,11 @@

                    acp:attribute
                    - The attribute properties - defined by ACP describe + Sub-properties of ACP + attribute are used to describe instances - of - resource - access. + >instances of resource access.
                    attribute - describes requested resources. + describes + requested resources.

    requesting resources. -
    - acp:time -
    -
    - The time - attribute - describes times of resource access requests. -
    -
    attribute - describes verifiable credentials presented as part of resource - access requests. + describes types of Verifiable Credentials (VC) presented as part + of resource access requests.
    @@ -1203,7 +1208,7 @@

    The following example context graph denotes instances of resource - access over resource X initiated by Bob. + access initiated by Bob. 

    @@ -1214,20 +1219,20 @@ 
    
             >
 
             
    
-              The following example context graph denotes instances of resource
-              access over resource X initiated by Bob using client application Y
-              where Bob's identity is asserted by identity provider Z, Bob is
-              the owner of resource X, and Alice is the creator of resource X.
+              The following example context graph means that Bob requests access
+              to resource X using client application Y and with their identity
+              asserted by identity provider Z; furthermore, resource X was
+              created by Alice and is owned by Bob.
             
    
 
             
     ex:contextA
-  acp:agent ex:Bob ;
   acp:target ex:resourceX ;
-  acp:owner ex:Bob ;
-  acp:creator ex:Alice ;
+  acp:agent ex:Bob ;
   acp:client ex:ClientApplicationY ;  
-  acp:issuer ex:IdentityProviderZ .
+  acp:issuer ex:IdentityProviderZ ;
+  acp:owner ex:Bob ;
+  acp:creator ex:Alice .
 
    
 
@@ -1260,8 +1265,7 @@ 
    
           
    
           
    
             Sub-properties of acp:attribute can be created to fit
-            the specific resource access description requirements of
-            applications.
+            the specific access control requirements of applications.
           
    
 
           
    
               class="example example-context-graph"
             >
 ex:contextA
-  acp:agent ex:Bob ;
   acp:target ex:resourceX ;
+  acp:agent ex:Bob ;
   ex:tag ex:Music, ex:FavouriteRecord .  
    @@ -1328,7 +1332,7 @@

    The following example authorization graph means that access to resource X is controlled by both Access Controls B and C; furthermore, access to members of resource X is controlled by - Access Control D. + Access Control D; furthermore, member control is transitive, + therefore, further members of member resources will also be + controlled by Access Control D. 

                 >
 
             
    
-              The following two example authorization graphs mean that access to
-              resource X is controlled by Policy D and Policy E.
+              The following two example authorization graphs both mean that
+              access to resource X is controlled by Policy D and Policy E.
             
    
 
             
                 
    
               The all of property connects
               Policies
-              to the set of
+              to a set of
               Matchers
-              all of which MUST must be satisfied for the Policy to be
-              satisfied.
+              all of which MUST be satisfied for the Policy to be satisfied.
             
    
 
             
    
             
    
               The any of property connects
               Policies
-              to the set of
+              to a set of
               Matchers
               at least one of which MUST be satisfied for the Policy to be
               satisfied.
@@ -1666,7 +1671,7 @@ 
    
             
    
               The none of property connects
               Policies
-              to the set of
+              to a set of
               Matchers
               all of which MUST NOT be satisfied for the Policy to be satisfied.
             
    
@@ -1685,8 +1690,8 @@ 
    
             
    
             
    
               The following example authorization graph means that Policy A will
-              allow Read for instances of resource access satisfying both
-              Matcher B and Matcher C.
+              allow acl:Read for instances of resource access
+              satisfying both Matcher B and Matcher C.
             
    
 
             
     
             
    
               The following example authorization graph means that a Policy will
-              deny Write for instances of resource access satisfying either
-              Matcher B or Matcher C.
+              deny acl:Write for instances of resource access
+              satisfying either Matcher B or Matcher C.
             
    
 
             
                 >
 
             
    
-              The following example authorization graph means that Reading and
-              Writing resource X will be allowed for instances of resource
+              The following example authorization graph means that reading and
+              writing resource X will be allowed for instances of resource
               access satisfying Matcher A and not Matcher B.
             
    
 
@@ -1762,18 +1767,16 @@
    Instances of the Matcher class - are descriptions of matching resource access Contexts. To satisfy - a Matcher, every described resource access attribute must match - the resource access Context. + are descriptions of matching Contexts.
    acp:agent
    - The agent attribute used in a Matcher defines a set of agents, at - least one of which MUST match the resource access Context for the - agent restriction to be satisfied. + In a Matcher, agent attributes define a set of agents, at least + one of which MUST match the Context for the Matcher to be + satisfied.
    acp:PublicAgent
    - The Public Agent named - individual used in an agent restriction means that the restriction - is always satisfied. + In a Matcher, agent attributes using the + Public Agent named individual + MUST match all Contexts.
    acp:AuthenticatedAgent
    - The Authenticated Agent named - individual used in an agent restriction means that any agent in - the Context satisfies the restriction. + In a Matcher, agent attributes using the + Authenticated Agent named + individual MUST match Contexts that contain an agent.
    acp:CreatorAgent
    - The Creator Agent named - individual used in an agent restriction means that the restriction - is satisfied if the Context contains an agent that is also a - creator. + In a Matcher, agent attributes using the + Creator Agent named individual + MUST match Contexts where a defined creator matches the defined + agent.
    acp:OwnerAgent
    - The Owner Agent named - individual used in an agent restriction means that the restriction - is satisfied if the Context contains an agent that is also an - owner. + In a Matcher, agent attributes using the + Owner Agent named individual + MUST match Contexts where a defined owner matches the defined + agent.
    acp:client
    - The client attribute used in a Matcher defines a set of clients, - at least one of which MUST match the resource access Context for - the client restriction to be satisfied. + In a Matcher, client attributes define a set of clients, at least + one of which MUST match the Context for the Matcher to be + satisfied.
    acp:PublicClient
    - The Public Client named - individual used in a client restriction means that the restriction - is always satisfied. + In a Matcher, client attributes using the + Public Client named individual + MUST match all Contexts.
    acp:issuer
    - The issuer attribute used in a Matcher defines a set of issuers, - at least one of which MUST match the resource access Context for - the issuer restriction to be satisfied. + In a Matcher, issuer attributes define a set of issuers, at least + one of which MUST match the Context for the Matcher to be + satisfied.
    acp:PublicIssuer
    - The Public Issuer named - individual used in an issuer restriction means that the - restriction is always satisfied. -
    - -
    - acp:time -
    -
    - The time attribute used in a Matcher defines a set of times, at - least one of which MUST match the resource access Context for the - time restriction is satisfied. + In a Matcher, issuer attributes using the + Public Issuer named individual + MUST match all Contexts.
    acp:vc
    - The vc attribute used in a Matcher defines a set of types of - types + of + Verifiable Credentials - (VC), at least one of which MUST match the resource access Context - for the vc restriction to be satisfied. + (VC), at least one of which MUST match the Context for the Matcher + to be satisfied. A VC type present in the Context MUST be a + valid + VC + presented + as part of the resource access request.
    >

    - The following example authorization graph means that Agent Matcher - A will be satisfied when either Alice or the owner of the access + The following example authorization graph means that Matcher A + will be satisfied when either Alice or the owner of the access controlled resource are requesting access.

    @@ -1957,9 +1967,9 @@

    The following example authorization graph means that the defined - Client Matcher will be satisfied when matched against a context - graph where the client used to access the access controlled - resource is client B. + Matcher will be satisfied when matched against a context graph + where the client used to access the access controlled resource is + client B. 

                 >
 
             
    
-              The following example authorization graph means that Issuer
-              Matcher A will be satisfied when matched against a context graph
-              where the identity provider used to assert the identity of the
-              agent requesting access to the access controlled resource is
-              issuer B.
+              The following example authorization graph means that Matcher A
+              will be satisfied when matched against a context graph where the
+              identity provider used to assert the identity of the agent
+              requesting access to the access controlled resource is issuer B.
             
    
 
             
     
             
    
               The following example authorization graph means that the defined
-              Verifiable Credentials (VC) Matcher A will be satisfied when
-              matched against a context graph where one of the presented
-              verifiable credentials is an instance of credential B, is valid
-              and has been issued to the agent requesting the resource.
+              Matcher will be satisfied when matched against a context graph
+              showing that a valid VC of type credential B has been presented by
+              the agent requesting access to the access controlled resource.
             
    
 
             
                   The following example authorization graph means that the defined
               matcher will be satisfied only if Alice, whose identity is
               asserted by Identity Provider B, is the agent requesting resource
-              access and is doing so presenting a VC that is a verified instance
-              of credential A issued to Alice.
+              access and is doing so presenting a VC that is a valid instance of
+              credential A.
             
    
 
             
                 >

    - All sub-properties of acp:attribute correspond - implicitly to their own type of Matcher restriction. If applications - support additional sub-properties of - acp:attribute other than the ones defined by ACP, then, - they MUST also implement corresponding matching algorithms. + ACP implementations supporting sub-properties of + acp:attribute other than the ones defined by ACP SHOULD + also define and implement corresponding matching algorithms.

    The following example access grant graph means that Access Modes acl:Read and acl:Write have been granted - to Bob for accessing resource X. + to Alice for accessing resource X. 

     []
   acp:grant acl:Read, acl:Write ;  
   acp:context [
-    acp:agent ex:Bob ;
+    acp:agent ex:Alice ;
     acp:target ex:resourceX ;
   ] .
    Instead, any Access Mode granted is an instance of the Access Mode class. Access Modes and their granularity can be tailored to the needs of an - application. Access Modes defined in other vocabularies (for example ACL) can also be used. + application and Access Modes defined in other vocabularies can + also be used (for example instances of + ACL Access).
    @@ -2299,8 +2306,7 @@

    The following example access grant graph means that acl:Read and ex:Delete are Access Modes; furthermore, it means that acl:Read and - ex:Delete have been granted to Bob for accessing - resource X. + ex:Delete have been granted to Bob over resource X. 

     []
   acp:grant acl:Read, ex:Delete ;  
   acp:context [
-    acp:agent ex:Bob ;
     acp:target ex:resourceX ;
+    acp:agent ex:Bob ;
   ] .
    @@ -2335,6 +2341,52 @@

    for resolving permissions to access controlled resources.

    +
    +

    + 6.1. Resolved Access Control +

    +

    + An ACP engine MUST grant exactly those Access Modes allowed by + Effective Policies. +

    + +
    +

    + 6.1.1. Resolved Access Control pseudocode +

    + 
    function resolveAccessControl(acr, ancestorAcrs, context) {
+  const effectivePolicies = gatherEffectivePolicies(acr, ancestorAcrs)
+  const allowedAccessModes = grantAccessModes(effectivePolicies, context)
+  const grantGraph = {
+      context,
+      grant: allowedAccessModes
+  }
+
+  return grantGraph
+}
+
    +
    +
    +
    property="bibo:hasPart" >

    - 6.1. 6.2. Effective Policies

    - Both the acp:resource property and its inverse - acp:accessControlResource MUST be taken into account in - determining the Access Control Resources controlling access to - resources. + Effective Policies are the Policies controlling access to a + resource.

    -

    - All Access Controls controlling member resources access via the - acp:memberAccessControl property MUST be included in - the set of Access Controls linked as - acp:accessControl in the effective authorization graph - of a resource. -

    +

    A Policy MUST control access to a resource if:

    -

    - The set of Policies controlling access to a resource MUST contain - all Policies that are linked to a resource via the - property path - acp:accessControlResource/acp:accessControl/acp:apply - SPARQL11 QUERY. -

    +
      +
    • + it is applied by an Access Control of an ACR of the resource; or, +
      • +
    • + it is applied by a member Access Control of an ACR of an ancestor + of the resource. +
      • +
    property="bibo:hasPart" >

    - 6.1.1. 6.2.1. Effective Policies example

    @@ -2417,6 +2459,38 @@

    + +
    +

    + 6.2.2. Effective Policies pseudocode +

    + 
    function gatherEffectivePolicies(acr, ancestorAcrs) {
+  const effectivePolicies = new Set
+
+  // Direct access controls of own ACR.
+  for (const accessControl of acr.accessControls)
+      for (const policy of accessControl.appliedPolicies)
+          effectivePolicies.add(policy)
+
+  // Member access controls of ancestor ACRs.
+  for (const acr of ancestorAcrs)
+      for (const accessControl of acr.memberAccessControls)
+          for (const policy of accessControl.appliedPolicies)
+              effectivePolicies.add(policy)
+
+  return effectivePolicies
+}
+
    +
    property="bibo:hasPart" >

    - 6.2. 6.3. Granted Access Modes

    - An Access Mode MUST be granted over a resource if and only if in - the set of Policies controlling access to it: + An Access Mode MUST be granted if and only if in the set of + Effective Policies:

      -
    • A satisfied policy allows the Access Mode; and
      • -
    • No satisfied policy denies the Access Mode.
      • +
    • a satisfied policy allows the Access Mode; and,
      • +
    • no satisfied policy denies it.
    @@ -2448,7 +2522,7 @@

    property="bibo:hasPart" >

    - 6.2.1. 6.3.1. Granted Access Modes example

    @@ -2501,30 +2575,30 @@

    property="bibo:hasPart" >

    - 6.2.2. 6.3.2. Granted Access Modes pseudocode 

    function grantAccessModes(policies, context) {
-  const allow = new Set, deny = new Set
+  const allowedAccessModes = new Set, deniedAccessModes = new Set
 
-  // Gather allowed and denied access modes from satisfied policies  
+  // Gather allowed and denied access modes from satisfied policies
   for (const policy of policies)
       if (isSatisfiedPolicy(policy, context)) {
-          for (const mode of policy.allow)
-              allow.add(mode)
+          for (const mode of policy.allowedAccessModes)
+              allowedAccessModes.add(mode)
 
-          for (const mode of policy.deny)
-              deny.add(mode)
+          for (const mode of policy.deniedAccessModes)
+              deniedAccessModes.add(mode)
       }
 
   // Deny overrules allow.
-  for (const mode of deny)
-      allow.delete(mode)
+  for (const mode of deniedAccessModes)
+      allowedAccessModes.delete(mode)
 
-  return allow
+  return allowedAccessModes
 }
    @@ -2537,40 +2611,30 @@

    property="bibo:hasPart" >

    - 6.3. 6.4. Satisfied Policy

    -

    - Policies are satisfied via the acp:allOf, - acp:anyOf and acp:noneOf properties which - act respectively as intersection, union and exclusion operators. -

    -
    -

    A Policy MUST be considered satisfied if and only if:

    +

    A Policy MUST be satisfied if and only if:

    • - It references at least one Matcher via a - acp:allOf or acp:anyOf property; and + it references at least one Matcher via an + acp:allOf or acp:anyOf property; and,
    • - At least one Matcher it references matches the given resource - access description; and + all of its acp:allOf Matchers are satisfied; and,
    • - The acp:allOf, acp:anyOf and - acp:noneOf of conditions it defines are satisfied. + at least one of its acp:anyOf Matchers is + satisfied; and, +
      • +
    • + none of its acp:noneOf Matchers are satisfied.
    -

    - Given that the acp:noneOf condition excludes matches, a - policy without a satisfied acp:allOf or - acp:anyOf condition is never satisfied. -

    -
    property="bibo:hasPart" >

    - 6.3.1. 6.4.1. Satisfied Policy example

    @@ -2594,16 +2658,17 @@

    A will not be satisfied.
  • - If both Matcher D and Matcher E are not satisfied, then Policy A + If neither Matcher D nor Matcher E are satisfied, then Policy A will not be satisfied.
  • - If Matcher F is satisfied, then Policy A will not be satisfied. + If either Matcher F or Matcher G is satisfied, then Policy A + will not be satisfied.
  • If both Matcher B and Matcher C are satisfied, and, either - Matcher D or Matcher E are satisfied, and, Matcher F is not - satisfied, then Policy A will be satisfied. + Matcher D or Matcher E are satisfied, and, Matcher F and Matcher + G are not satisfied, then Policy A will be satisfied.
    • @@ -2621,7 +2686,7 @@

    ex:policyA acp:allOf ex:matcherB, ex:matcherC ;   acp:anyOf ex:matcherD, matcherE ; - acp:noneOf ex:matcherF . + acp:noneOf ex:matcherF, ex:matcherG .

    @@ -2633,7 +2698,7 @@

    property="bibo:hasPart" >

    - 6.3.2. 6.4.2. Satisfied Policy pseudocode

    @@ -2641,17 +2706,17 @@

    class="highlight pseudocode" >function isSatisfiedPolicy(policy, context) { // If any 'none of' matcher is satisfied then the policy is not satisfied. - for (const matcher of policy.noneOf) + for (const matcher of policy.noneOfMatchers) if (isSatisfiedMatcher(matcher, context)) return false - // If any 'all of' matcher is not satisfied then the policy is not satisfied.   - for (const matcher of policy.allOf) + // If any 'all of' matcher is not satisfied then the policy is not satisfied. + for (const matcher of policy.allOfMatchers) if (!isSatisfiedMatcher(matcher, context)) return false // If any 'any of' matcher is satisfied then the policy is satisfied. - for (const matcher of policy.anyOf) + for (const matcher of policy.anyOfMatchers) if (isSatisfiedMatcher(matcher, context)) return true @@ -2663,7 +2728,7 @@

    // Hence, the policy is satisfied if it has // - an 'all of' condition and // - no 'any of' condition. - return policy.allOf.size !== 0 && policy.anyOf.size === 0 + return policy.allOfMatchers.size !== 0 && policy.anyOfMatchers === 0 } @@ -2676,35 +2741,23 @@

    property="bibo:hasPart" >

    - 6.4. 6.5. Satisfied Matcher

    -

    - The default operation of matching is based on - IRI - and - literal term equality - as defined in the RDF 1.1 Concepts and Abstract Syntax - RDF11 CONCEPTS. -

    -
    -

    A Matcher MUST be considered satisfied if and only if:

    +

    A Matcher MUST be satisfied if and only if:

      -
    • It defines at least one matching attribute; and
      • +
    • it defines at least one attribute; and,
    • - All the attributes defined find a match in the given resource - access description. + at least one value of each defined attribute matches the + Context.
    +

    + ACP engines MUST match the context attributes defined by this + specification according to IRI equality and literal term equality. +

    property="bibo:hasPart" >

    - 6.4.1. 6.5.1. Satisfied Matcher example

    +

    + The following example authorization graph means that access to + resource X is controlled by a Policy that will allow read if it is + satisfied and be satisfied if either matcher A or matcher B or + both are satisfied. +

    + +

    Matcher A will be satisfied if:

    + +
      +
    • + either Alice or Bob are the requesting agent or if the + requesting agent is an owner or creator; and, +
      • +
    • client 1 is used by the requesting agent; and,
      • +
    • + issuer 2 is used by the requesting agent to assert their + identity. +
      • +
    + +

    Matcher B will be satisfied if:

    + +
      +
    • a valid VC of type "Family Member" is presented.
      • +
    + + 
    +[
+  acp:resource ex:X ;
+  acp:accessControl [
+    acp:apply [
+      acp:allow acl:Read ;
+      acp:anyOf ex:matcherA, ex:matcherB ;
+    ]
+  ]
+] .
+
+ex:matcherA
+  acp:agent ex:Alice, ex:Bob, acp:CreatorAgent, acp:OwnerAgent ;  
+  acp:client ex:client1 ;
+  acp:issuer ex:issuer2 .
+
+ex:matcherB
+  acp:vc ex:FamilyMember .
+
    property="bibo:hasPart" >

    - 6.4.2. 6.5.2. Satisfied Matcher pseudocode

    + 
    function isSatisfiedMatcher(matcher, context) {
+  // An empty matcher is never satisfied.
+  if (matcher.agents.size === 0 && matcher.clients.size === 0 && matcher.issuers.size === 0 && matcher.vcs.size === 0)
+      return false
+
+  // For each attribute, if any values are defined, then at least one of them must match the context.
+
+  if (matcher.agents.size !== 0) {
+      let isMatch = false
+
+      for (const agent of matcher.agents)
+          if (agentMatches(agent, context)) {
+              isMatch = true
+              break
+          }
+
+      if (!isMatch)
+          return false
+  }
+
+  if (matcher.clients.size !== 0) {
+      let isMatch = false
+
+      for (const client of matcher.clients)
+          if (clientMatches(client, context)) {
+              isMatch = true
+              break
+          }
+
+      if (!isMatch)
+          return false
+  }
+
+  if (matcher.issuers.size !== 0) {
+      let isMatch = false
+
+      for (const issuer of matcher.issuers)
+          if (issuerMatches(issuer, context)) {
+              isMatch = true
+              break
+          }
+
+      if (!isMatch)
+          return false
+  }
+
+  if (matcher.vcs.size !== 0) {
+      let isMatch = false
+
+      for (const vc of matcher.vcs)
+          if (vcMatches(vc, context)) {
+              isMatch = true
+              break
+          }
+
+      if (!isMatch)
+          return false
+  }
+
+  // At this point, the matcher is satisfied because
+  // - there was at least one defined attribute and
+  // - at least one value of each defined attribute matched the context.
+  return true
+}
+
+const publicAgent = "https://www.w3.org/ns/solid/acp#PublicAgent"
+const authenticatedAgent = "https://www.w3.org/ns/solid/acp#AuthenticatedAgent"
+const creatorAgent = "https://www.w3.org/ns/solid/acp#CreatorAgent"
+const ownerAgent = "https://www.w3.org/ns/solid/acp#OwnerAgent"
+function agentMatches(agent, context) {
+  if (agent === publicAgent)
+      return true
+
+  if (agent === authenticatedAgent && context.agent !== null)
+      return true
+
+  if (agent === creatorAgent && context.creators.includes(context.agent))
+      return true
+
+  if (agent === ownerAgent && context.owners.includes(context.agent))
+      return true
+
+  if (agent === context.agent)
+      return true
+}
+
+const publicClient = "https://www.w3.org/ns/solid/acp#PublicClient"
+function clientMatches(client, context) {
+  if (client === publicClient)
+      return true
+
+  if (client === context.client)
+      return true
+}
+
+const publicIssuer = "https://www.w3.org/ns/solid/acp#PublicIssuer"
+function issuerMatches(issuer, context) {
+  if (issuer === publicIssuer)
+      return true
+
+  if (issuer === context.issuer)
+      return true
+}
+
+function vcMatches(vc, context) {
+  if (context.vcs.includes(vc))
+      return true
+}
+
    @@ -2747,174 +2961,82 @@

    >

    - This section introduces ACP server capability and ACR discovery, as - well as ACR editing, and ACP resources lifecycle management. + This section introduces conforming resource server and ACP server + requirements.

    -

    +

    7.1. Capability discovery + >Conforming resource server

    - When a server wants to enable applications to discover its ACP - capabilities, it MUST do so via link headers. -

    - -

    - The server MUST advertise the access modes it supports by responding - to HTTP OPTIONS requests over ACP access control resources including - a Link header with the rel value of - http://www.w3.org/ns/solid/acp#grant and the full URI - of an access mode as link target [RFC8288]. The server MUST produce - one such Link header for each access mode it supports. -

    - -

    - For example, if a server supports the ACL read, write and append - access modes, it should advertise it by responding to HTTP OPTIONS - requests over ACP access control resources including three link - headers with rel value of - http://www.w3.org/ns/solid/acp#grant and respectively - targets of http://www.w3.org/ns/auth/acl#Read, - http://www.w3.org/ns/auth/acl#Write and - http://www.w3.org/ns/auth/acl#Append in order to make - it explicit which set of access modes are understood and relevant - when editing ACP policies. + Conforming resource servers MUST provide ACP servers with resource + access Contexts and MUST authorize resource access according to + grant graphs produced by a conforming ACP server.

    - The server MUST advertise the request attributes it supports by - responding to HTTP OPTIONS requests over ACP access control - resources including a Link header with the rel value of - http://www.w3.org/ns/solid/acp#attribute and the full - URI of an acp attribute as link target [RFC8288]. The server MUST - produce one such Link header for each request attribute it supports. + When responding to requests targetting access controlled resources, + conforming resource servers MUST include a Link header + with the rel value of acl and controlled + resources' ACRs as the link target + RFC 8288.

    - For example, if a server supports the ACP agent, client and issuer - request attributes, it should advertise it by responding to HTTP - OPTIONS requests over ACP access control resources including three - link headers with rel value of - http://www.w3.org/ns/solid/acp#attribute and - respectively targets of - http://www.w3.org/ns/solid/acp#agent, - http://www.w3.org/ns/solid/acp#client and - http://www.w3.org/ns/solid/acp#issuer in order to make - it explicit which set of request attributes are understood and - relevant when editing ACP matchers. + Conforming resource servers MUST provide ACP servers with sufficient + resource membership information to resolve ancestor ACRs.

    -

    +

    7.2. ACR discovery + >Conforming ACP server

    - When a server wants to enable applications to discover the ACP - access control resource associated with a given resource, the server - MUST advertise the ACP access control resource that is associated - with that resource by responding to HTTP requests over the resource - including a Link header with the rel value - of acl (acl Link Relation) and the ACP access control - resource as the link target [RFC8288]. The same mechanism is used in - Web Access Control resource discovery. -

    -

    - A server responding to an HTTP request over an ACP access control - resource MUST include a Link header with the + When responding to requests targetting an ACR, conforming ACP + servers MUST include a Link header with the rel value of type and the - acp:AccessControlResource URI as link target. + http://www.w3.org/ns/solid/acp#AccessControlResource + IRI as the link target.

    -
    -
    -

    - 7.3. ACR editing -

    - The owner of a storage is implicitly considered an owner of all the - resources in the URI space corresponding to the storage. + When responding to OPTIONS requests targetting an ACR, conforming + ACP servers MUST include a Link header for each + supported Access Mode with the rel value of + http://www.w3.org/ns/solid/acp#grant and the full IRI + of the supported Access Mode as the link target.

    - An owner of a resource is implicitly considered an owner of its - associated Access Control Resource. -

    - -

    - An owner of an Access Control Resource implicitly has full read and - write access over it. -

    - -

    - To add or remove an Access Control from an ACR, agents that are not - owners of said ACR need read and write access to both the ACR itself - and to the resource where said Access Control is defined. In other - words, Access Controls defined as part of a separate resource can be - protected from unwanted edits in and out of ACRs by setting adequate - permissions in their own ACR. -

    -
    - -
    -

    - 7.4. Resource management -

    -

    Access Control Resources MUST be server managed.

    - -

    - There is a one to one relationship between a resource and its - authoritative source of access control. Therefore, when resources - are created or deleted, the corresponding ACRs MUST be created or - deleted accordingly. + When responding to OPTIONS requests targetting an ACR, conforming + ACP servers MUST include a Link header for each + supported attribute with the rel value of + http://www.w3.org/ns/solid/acp#attribute and the full + IRI of the supported attribute as the link target.

    -

    - Access Controls, Policies and Matchers MAY all be access controlled - via their own ACR. -

    +

    Conforming ACP engines MAY be conforming resource servers.

    - As long as an Access Control, a Policy or a Matcher is referenced by - an ACR, it MUST not be deleted. However, if such consistency failed - to be enforced or if an Access Control, a Policy or a Matcher is not - accessible for any other reason, then access permissions resolution - MUST fail to its default behaviour of only granting read and write - access to the invalid ACR to its owners; read and write access MUST - not be implicitly granted to a resource whose access control - resolution fails, even to owners of that resource. + The lifecycle of Access Control Resources SHOULD take into account + the lifecycle of resources they control access to.

    @@ -2928,6 +3050,19 @@

    >

    Acknowledgements

    This section is non-normative.

    + +

    + Samu Lang provided a comprehensive review of the specification as well + as the pseudocode sections. +

    + +

    + The Solid Community Group would like to thank the following individuals + for reviewing and providing feedback on the specification (in + alphabetical order): Justin Bingham, Sarven Capadisli, Aaron Coburn, + Pete Edwards, Samu Lang, Elf Pavlik, Henry Story, Ted Thibodeau Jr, + Emmet Townsend. +

    References property="bibo:hasPart" >

    Normative references

    -
    +
    [RDF11-CONCEPTS]
    Normative references >https://www.w3.org/TR/rdf11-concepts/.
    +
    [RFC2119]
    Normative references >https://datatracker.ietf.org/doc/html/rfc2119.
    +
    [RFC8174]
    Normative references >https://datatracker.ietf.org/doc/html/rfc8174.
    -
    [SPARQL11-QUERY]
    + +
    [RFC8288]
    +
    + Web Linking. B. Leiba. IETF. October 2017. Proposed Standard. URL: + https://datatracker.ietf.org/doc/html/rfc8288. +
    + +
    [VC-DATA-MODEL]
    SPARQL 1.1 Query. Steve Harris; Andy Seaborne; Eric Prud'hommeaux. W3C. 21 March - 2013. W3C Recommendation. URL: - https://www.w3.org/TR/sparql11-query/VC Data Model. Manu Sporny; Grant Noble; Dave Longley; Daniel C. Burnett; Brent + Zundel; Kyle Den Hartog. W3C. 3 March 2022. W3C Recommendation. URL: + https://www.w3.org/TR/vc-data-model/.
    @@ -3006,6 +3156,18 @@

    Normative references

    property="bibo:hasPart" >

    Informative references

    +
    +
    [RDF11-TURTLE]
    +
    + RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C + Recommendation. URL: + https://www.w3.org/TR/turtle/. +
    +
    From d7b5efef119d1a24293c3eb5f22a0f92513d4bd0 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 18 May 2022 10:33:53 +0100 Subject: [PATCH 4/9] ACP: Incorporate vocab feedback --- 2022/acp-20220518.html | 8 ++++---- 2022/acp-20220518.ttl | 8 ++++---- acp.html | 8 ++++---- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/2022/acp-20220518.html b/2022/acp-20220518.html index 64e6407e..e41f39a2 100644 --- a/2022/acp-20220518.html +++ b/2022/acp-20220518.html @@ -1637,7 +1637,7 @@

    The all of property connects Policies to a set of - Matchers + Matchers, all of which MUST be satisfied for the Policy to be satisfied. @@ -1654,7 +1654,7 @@

    The any of property connects Policies to a set of - Matchers + Matchers, at least one of which MUST be satisfied for the Policy to be satisfied. @@ -1672,7 +1672,7 @@

    The none of property connects Policies to a set of - Matchers + Matchers, all of which MUST NOT be satisfied for the Policy to be satisfied. @@ -2284,7 +2284,7 @@

    Access Mode class. Access Modes and their granularity can be tailored to the needs of an application and Access Modes defined in other vocabularies can - also be used (for example instances of + also be used (for example, instances of ACL Access). diff --git a/2022/acp-20220518.ttl b/2022/acp-20220518.ttl index 20f146cf..df2fc1a3 100644 --- a/2022/acp-20220518.ttl +++ b/2022/acp-20220518.ttl @@ -75,7 +75,7 @@ acp:AlwaysSatisfiedRestriction acp:AccessMode a rdfs:Class ; rdfs:label "Access Mode"@en ; - rdfs:comment "The ACP specification does not define specific Access Modes. Instead, any Access Mode granted is an instance of the Access Mode class. Access Modes and their granularity can be tailored to the needs of an application and Access Modes defined in other vocabularies can also be used (for example instances of ACL Access)."@en ; + rdfs:comment "The ACP specification does not define specific Access Modes. Instead, any Access Mode granted is an instance of the Access Mode class. Access Modes and their granularity can be tailored to the needs of an application and Access Modes defined in other vocabularies can also be used (for example, instances of ACL Access)."@en ; rdfs:isDefinedBy acp: ; rdfs:seeAlso . @@ -147,7 +147,7 @@ acp:deny acp:allOf a rdf:Property ; rdfs:label "all of"@en ; - rdfs:comment "The all of property connects Policies to a set of Matchers all of which MUST be satisfied for the Policy to be satisfied."@en ; + rdfs:comment "The all of property connects Policies to a set of Matchers, all of which MUST be satisfied for the Policy to be satisfied."@en ; rdfs:isDefinedBy acp: ; rdfs:domain acp:Policy ; rdfs:range acp:Matcher . @@ -155,7 +155,7 @@ acp:allOf acp:anyOf a rdf:Property ; rdfs:label "any of"@en ; - rdfs:comment "The any of property connects Policies to a set of Matchers at least one of which MUST be satisfied for the Policy to be satisfied."@en ; + rdfs:comment "The any of property connects Policies to a set of Matchers, at least one of which MUST be satisfied for the Policy to be satisfied."@en ; rdfs:isDefinedBy acp: ; rdfs:domain acp:Policy ; rdfs:range acp:Matcher . @@ -163,7 +163,7 @@ acp:anyOf acp:noneOf a rdf:Property ; rdfs:label "none of"@en ; - rdfs:comment "The none of property connects Policies to a set of Matchers all of which MUST NOT be satisfied for the Policy to be satisfied."@en ; + rdfs:comment "The none of property connects Policies to a set of Matchers, all of which MUST NOT be satisfied for the Policy to be satisfied."@en ; rdfs:isDefinedBy acp: ; rdfs:domain acp:Policy ; rdfs:range acp:Matcher . diff --git a/acp.html b/acp.html index bb1f2778..488c9025 100644 --- a/acp.html +++ b/acp.html @@ -1637,7 +1637,7 @@

    The all of property connects Policies to a set of - Matchers + Matchers, all of which MUST be satisfied for the Policy to be satisfied. @@ -1654,7 +1654,7 @@

    The any of property connects Policies to a set of - Matchers + Matchers, at least one of which MUST be satisfied for the Policy to be satisfied. @@ -1672,7 +1672,7 @@

    The none of property connects Policies to a set of - Matchers + Matchers, all of which MUST NOT be satisfied for the Policy to be satisfied. @@ -2284,7 +2284,7 @@

    Access Mode class. Access Modes and their granularity can be tailored to the needs of an application and Access Modes defined in other vocabularies can - also be used (for example instances of + also be used (for example, instances of ACL Access). From 1634625a3651a3f331832ba9c2edebb63a017c73 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 18 May 2022 10:45:13 +0100 Subject: [PATCH 5/9] Fix typo --- 2022/acp-20220518.ttl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2022/acp-20220518.ttl b/2022/acp-20220518.ttl index df2fc1a3..f170fe99 100644 --- a/2022/acp-20220518.ttl +++ b/2022/acp-20220518.ttl @@ -43,7 +43,7 @@ acp:AccessControl a rdfs:Class ; rdfs:label "Access Control"@en ; rdfs:comment "Instances of the Access Control class connect Access Control Resources to their Policies."@en ; - rdfs:commnet "All Access Controls controlling member resources access via the acp:memberAccessControl property MUST be included in the set of Access Controls linked as acp:accessControl in the effective authorization graph of a resource."@en ; + rdfs:comment "All Access Controls controlling member resources access via the acp:memberAccessControl property MUST be included in the set of Access Controls linked as acp:accessControl in the effective authorization graph of a resource."@en ; rdfs:isDefinedBy acp: . acp:Policy From ca63a006c3098273d66f6543a634e997f523cb98 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 18 May 2022 11:00:34 +0100 Subject: [PATCH 6/9] Align spec document and Ontology --- 2022/acp-20220518.ttl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/2022/acp-20220518.ttl b/2022/acp-20220518.ttl index f170fe99..0743bc05 100644 --- a/2022/acp-20220518.ttl +++ b/2022/acp-20220518.ttl @@ -9,7 +9,7 @@ prefix vann: a owl:Ontology ; rdfs:label "Access Control Policy Language (ACP)"@en ; - rdfs:comment "The Access Control Policy Language (ACP) is a language for describing, controlling and granting access to resources."@en ; + rdfs:comment "The Access Control Policy Language (ACP) is a language for describing, controlling, and granting access to resources."@en ; rdfs:isDefinedBy acp: ; rdfs:seeAlso ; cito:citesAsAuthority @@ -178,7 +178,7 @@ acp:attribute acp:target rdfs:label "target"@en ; - rdfs:comment "The target attribute describes requested access controlled resources."@en ; + rdfs:comment "The target attribute describes requested resources."@en ; rdfs:isDefinedBy acp: ; rdfs:subPropertyOf acp:attribute . From 04a4be4fd2403bed87edde24d4cb35e06eecdf55 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 18 May 2022 11:06:56 +0100 Subject: [PATCH 7/9] ACP: Remove whitespace and merge comments. --- 2022/acp-20220518.ttl | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/2022/acp-20220518.ttl b/2022/acp-20220518.ttl index 0743bc05..34b95fd6 100644 --- a/2022/acp-20220518.ttl +++ b/2022/acp-20220518.ttl @@ -50,8 +50,7 @@ acp:Policy a rdfs:Class ; rdfs:label "Access Policy"@en ; rdfs:comment "Instances of the Policy class connect Access Controls to allowed and denied Access Modes as well as sets of Matchers describing instances of resource access."@en ; - rdfs:comment " An ACP engine MUST grant exactly those Access Modes allowed by Effective Policies."@en ; - rdfs:comment "Effective Policies are the Policies controlling access to a resource. A Policy MUST control access to a resource if: it is applied by an Access Control of an ACR of the resource; or, it is applied by a member Access Control of an ACR of an ancestor of the resource."@en ; + rdfs:comment "An ACP engine MUST grant exactly those Access Modes allowed by Effective Policies. Effective Policies are the Policies controlling access to a resource. A Policy MUST control access to a resource if: it is applied by an Access Control of an ACR of the resource; or, it is applied by a member Access Control of an ACR of an ancestor of the resource."@en ; rdfs:comment "An Access Mode MUST be granted if and only if in the set of Effective Policies controlling access to it: a satisfied policy allows the Access Mode; and, no satisfied policy denies it."@en ; rdfs:comment "A Policy MUST be satisfied if and only if: it references at least one Matcher via an acp:allOf or acp:anyOf property; and, all of its acp:allOf Matchers are satisfied; and, at least one of its acp:anyOf Matchers is satisfied; and, none of its acp:noneOf Matchers are satisfied."@en ; rdfs:seeAlso ; From 025353e542c01b67c7da02a82a561eb439f7e007 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 18 May 2022 13:33:36 +0100 Subject: [PATCH 8/9] Remove ontology from the PR. --- 2022/acp-20220518.html | 2 +- 2022/acp-20220518.ttl | 284 ----------------------------------------- acp.html | 2 +- 3 files changed, 2 insertions(+), 286 deletions(-) delete mode 100644 2022/acp-20220518.ttl diff --git a/2022/acp-20220518.html b/2022/acp-20220518.html index e41f39a2..53b80a25 100644 --- a/2022/acp-20220518.html +++ b/2022/acp-20220518.html @@ -929,7 +929,7 @@

    All terms defined by the Access Control Policy Language are present in a non-normative RDF representation of the - ACP ontology serialized in turtle. + ACP ontology serialized in turtle.

    diff --git a/2022/acp-20220518.ttl b/2022/acp-20220518.ttl deleted file mode 100644 index 34b95fd6..00000000 --- a/2022/acp-20220518.ttl +++ /dev/null @@ -1,284 +0,0 @@ -prefix acp: -prefix rdf: -prefix rdfs: -prefix owl: -prefix xsd: -prefix dc: -prefix vann: - - - a owl:Ontology ; - rdfs:label "Access Control Policy Language (ACP)"@en ; - rdfs:comment "The Access Control Policy Language (ACP) is a language for describing, controlling, and granting access to resources."@en ; - rdfs:isDefinedBy acp: ; - rdfs:seeAlso ; - cito:citesAsAuthority - , - , - , - , - ; - dc:issued "2022-05-18"^^xsd:date ; - vann:preferredNamespacePrefix "vann" ; - vann:preferredNamespaceUri "http://www.w3.org/ns/solid/acp#"^^xsd:anyURI . - - -################# -# Classes -################# -acp:Context - a rdfs:Class ; - rdfs:label "Context"@en ; - rdfs:comment "Instances of the Context class describe instances of resource access."@en ; - rdfs:isDefinedBy acp: . - -acp:AccessControlResource - a rdfs:Class ; - rdfs:label "Access Control Resource"@en ; - rdfs:comment "Instances of the Access Control Resource (ACR) class connect resources to their Access Controls."@en ; - rdfs:comment "Both the acp:resource property and its inverse acp:accessControlResource MUST be taken into account in determining the Access Control Resources controlling access to resources."@en ; - rdfs:isDefinedBy acp: . - -acp:AccessControl - a rdfs:Class ; - rdfs:label "Access Control"@en ; - rdfs:comment "Instances of the Access Control class connect Access Control Resources to their Policies."@en ; - rdfs:comment "All Access Controls controlling member resources access via the acp:memberAccessControl property MUST be included in the set of Access Controls linked as acp:accessControl in the effective authorization graph of a resource."@en ; - rdfs:isDefinedBy acp: . - -acp:Policy - a rdfs:Class ; - rdfs:label "Access Policy"@en ; - rdfs:comment "Instances of the Policy class connect Access Controls to allowed and denied Access Modes as well as sets of Matchers describing instances of resource access."@en ; - rdfs:comment "An ACP engine MUST grant exactly those Access Modes allowed by Effective Policies. Effective Policies are the Policies controlling access to a resource. A Policy MUST control access to a resource if: it is applied by an Access Control of an ACR of the resource; or, it is applied by a member Access Control of an ACR of an ancestor of the resource."@en ; - rdfs:comment "An Access Mode MUST be granted if and only if in the set of Effective Policies controlling access to it: a satisfied policy allows the Access Mode; and, no satisfied policy denies it."@en ; - rdfs:comment "A Policy MUST be satisfied if and only if: it references at least one Matcher via an acp:allOf or acp:anyOf property; and, all of its acp:allOf Matchers are satisfied; and, at least one of its acp:anyOf Matchers is satisfied; and, none of its acp:noneOf Matchers are satisfied."@en ; - rdfs:seeAlso ; - rdfs:isDefinedBy acp: . - -acp:Matcher - a rdfs:Class ; - rdfs:label "Matcher"@en ; - rdfs:comment "Instances of the Matcher class are descriptions of matching resource access Contexts."@en ; - rdfs:comment "A Matcher MUST be satisfied if and only if: it defines at least one attribute; and, at least one value of each defined attribute matches the Context. ACP engines MUST match the context attributes defined by this specification according to IRI equality and literal term equality."@en ; - rdfs:comment "ACP implementations supporting sub-properties of acp:attribute other than the ones defined by ACP SHOULD also define and implement corresponding matching algorithms."@en ; - rdfs:seeAlso ; - rdfs:isDefinedBy acp: . - -acp:AlwaysSatisfiedRestriction - a rdfs:Class ; - rdfs:label "Always Satisfied Restriction"@en ; - rdfs:comment "Defined instances of the Always Satisfied Restriction class are used in Matcher restrictions to indicate that the restriction is always satisfied. The default behaviour of a Matcher is to not be satisfied, so this is the only way to make a Matcher always satisfied."@en ; - rdfs:isDefinedBy acp: . - -acp:AccessMode - a rdfs:Class ; - rdfs:label "Access Mode"@en ; - rdfs:comment "The ACP specification does not define specific Access Modes. Instead, any Access Mode granted is an instance of the Access Mode class. Access Modes and their granularity can be tailored to the needs of an application and Access Modes defined in other vocabularies can also be used (for example, instances of ACL Access)."@en ; - rdfs:isDefinedBy acp: ; - rdfs:seeAlso . - -acp:AccessGrant - a rdfs:Class ; - rdfs:label "Access Grant"@en ; - rdfs:comment "Instances of the Access Grant class define sets of Access Modes granted in particular Contexts."@en ; - rdfs:isDefinedBy acp: . - - -#################### -# Properties -#################### -acp:resource - a rdf:Property ; - owl:inverseOf acp:accessControlResource ; - rdfs:label "resource"@en ; - rdfs:comment "The resource property connects ACRs to resources they control. It is the inverse of acp:accessControlResource."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:AccessControlResource . - -acp:accessControlResource - a rdf:Property ; - owl:inverseOf acp:resource ; - rdfs:label "access control resource"@en ; - rdfs:comment "The access control resource property connects resources to ACRs controlling access to them. It is the inverse of acp:resource."@en ; - rdfs:isDefinedBy acp: ; - rdfs:range acp:AccessControlResource . - -acp:accessControl - a rdf:Property ; - rdfs:label "access control"@en ; - rdfs:comment "The access control property connects ACRs to Access Controls."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:AccessControlResource ; - rdfs:range acp:AccessControl . - -acp:memberAccessControl - rdfs:label "member access control"@en ; - rdfs:comment "The member access control property transitively connects ACRs of member resources to Access Controls."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:AccessControlResource ; - rdfs:range acp:AccessControl . - -acp:apply - a rdf:Property ; - rdfs:label "apply"@en ; - rdfs:comment "The apply property connects Access Controls to the Policies they apply to resources."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:AccessControl ; - rdfs:range acp:Policy . - -acp:allow - a rdf:Property ; - rdfs:label "allow"@en ; - rdfs:comment "The allow property connects Policies to the Access Modes they allow if satisfied."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:Policy ; - rdfs:range acp:AccessMode . - -acp:deny - a rdf:Property ; - rdfs:label "deny"@en ; - rdfs:comment "The deny property connects Policies to the Access Modes they deny if satisfied."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:Policy ; - rdfs:range acp:AccessMode . - -acp:allOf - a rdf:Property ; - rdfs:label "all of"@en ; - rdfs:comment "The all of property connects Policies to a set of Matchers, all of which MUST be satisfied for the Policy to be satisfied."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:Policy ; - rdfs:range acp:Matcher . - -acp:anyOf - a rdf:Property ; - rdfs:label "any of"@en ; - rdfs:comment "The any of property connects Policies to a set of Matchers, at least one of which MUST be satisfied for the Policy to be satisfied."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:Policy ; - rdfs:range acp:Matcher . - -acp:noneOf - a rdf:Property ; - rdfs:label "none of"@en ; - rdfs:comment "The none of property connects Policies to a set of Matchers, all of which MUST NOT be satisfied for the Policy to be satisfied."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:Policy ; - rdfs:range acp:Matcher . - -acp:attribute - a rdf:Property ; - rdfs:label "attribute"@en ; - rdfs:comment "Sub-properties of ACP attribute are used to describe instances of resource access."@en ; - rdfs:comment "Sub-properties of acp:attribute can be created to fit the specific access control requirements of applications."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:Context . - -acp:target - rdfs:label "target"@en ; - rdfs:comment "The target attribute describes requested resources."@en ; - rdfs:isDefinedBy acp: ; - rdfs:subPropertyOf acp:attribute . - -acp:mode - rdfs:label "mode"@en ; - rdfs:comment "The mode attribute describes requested modes of access."@en ; - rdfs:isDefinedBy acp: ; - rdfs:subPropertyOf acp:attribute . - -acp:agent - rdfs:label "agent"@en ; - rdfs:comment "The agent attribute describes agents initiating requests."@en ; - rdfs:comment "In a Matcher, agent attributes define a set of agents, at least one of which MUST match the Context for the Matcher to be satisfied."@en ; - rdfs:isDefinedBy acp: ; - rdfs:subPropertyOf acp:attribute . - -acp:creator - rdfs:label "creator"@en ; - rdfs:comment "The creator attribute describes creators of requested resources."@en ; - rdfs:isDefinedBy acp: ; - rdfs:subPropertyOf acp:attribute . - -acp:owner - rdfs:label "owner"@en ; - rdfs:comment "The owner attribute describes owners of requested resources."@en ; - rdfs:isDefinedBy acp: ; - rdfs:subPropertyOf acp:attribute . - -acp:client - rdfs:label "client"@en ; - rdfs:comment "The client attribute describes client applications used to request resources."@en ; - rdfs:comment "In a Matcher, client attributes define a set of clients, at least one of which MUST match the Context for the Matcher to be satisfied. "@en ; - rdfs:isDefinedBy acp: ; - rdfs:subPropertyOf acp:attribute . - -acp:issuer - rdfs:label "issuer"@en ; - rdfs:comment "The issuer attribute describes identity providers used to assert the identity of agents requesting resources."@en ; - rdfs:comment "In a Matcher, issuer attributes define a set of issuers, at least one of which MUST match the Context for the Matcher to be satisfied."@en ; - rdfs:isDefinedBy acp: ; - rdfs:subPropertyOf acp:attribute . - -acp:vc - rdfs:label "vc"@en ; - rdfs:comment "The vc attribute describes types of Verifiable Credentials (VC) presented as part of resource access requests."@en ; - rdfs:comment "In a Matcher, vc attributes define a set of types of Verifiable Credentials (VC), at least one of which MUST match the Context for the Matcher to be satisfied. A VC type present in the Context MUST be a valid VC presented as part of the resource access request."@en ; - rdfs:isDefinedBy acp: ; - rdfs:subPropertyOf acp:attribute ; - cito:citesAsAuthority , ; - rdfs:seeAlso . - -acp:context - rdfs:label "context"@en ; - rdfs:comment "The context property connects Access Grants to the Contexts in which they're given."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:AccessGrant ; - rdfs:range acp:Context . - -acp:grant - rdfs:label "grant"@en ; - rdfs:comment "The grant property connects Access Grants to the Access Modes they grant."@en ; - rdfs:isDefinedBy acp: ; - rdfs:domain acp:AccessGrant ; - rdfs:range acp:AccessMode . - - -######################## -# Named Individuals -######################## -acp:PublicAgent - a owl:NamedIndividual, acp:AlwaysSatisfiedRestriction ; - rdfs:comment "In a Matcher, agent attributes using the Public Agent named individual MUST match all Contexts."@en ; - rdfs:isDefinedBy acp: ; - rdfs:label "Public Agent"@en . - -acp:AuthenticatedAgent - a owl:NamedIndividual ; - rdfs:comment "In a Matcher, agent attributes using the Authenticated Agent named individual MUST match Contexts that contain an agent."@en ; - rdfs:isDefinedBy acp: ; - rdfs:label "Authenticated Agent"@en . - -acp:CreatorAgent - a owl:NamedIndividual ; - rdfs:comment "In a Matcher, agent attributes using the Creator Agent named individual MUST match Contexts where a defined creator matches the defined agent."@en ; - rdfs:isDefinedBy acp: ; - rdfs:label "Creator Agent"@en . - -acp:OwnerAgent - a owl:NamedIndividual ; - rdfs:comment "In a Matcher, agent attributes using the Owner Agent named individual MUST match Contexts where a defined owner matches the defined agent."@en ; - rdfs:isDefinedBy acp: ; - rdfs:label "Owner Agent"@en . - -acp:PublicClient - a owl:NamedIndividual, acp:AlwaysSatisfiedRestriction ; - rdfs:comment "In a Matcher, client attributes using the Public Client named individual MUST match all Contexts."@en ; - rdfs:isDefinedBy acp: ; - rdfs:label "Public Client"@en . - -acp:PublicIssuer - a owl:NamedIndividual, acp:AlwaysSatisfiedRestriction ; - rdfs:comment "In a Matcher, issuer attributes using the Public Issuer named individual MUST match all Contexts."@en ; - rdfs:isDefinedBy acp: ; - rdfs:label "Public Issuer"@en . diff --git a/acp.html b/acp.html index 488c9025..eff5d642 100644 --- a/acp.html +++ b/acp.html @@ -929,7 +929,7 @@

    All terms defined by the Access Control Policy Language are present in a non-normative RDF representation of the - ACP ontology serialized in turtle. + ACP ontology serialized in turtle.

    From 6275efe270a6ac25467dbd6b634a238671a8ae69 Mon Sep 17 00:00:00 2001 From: Aaron Coburn Date: Wed, 18 May 2022 21:35:30 -0400 Subject: [PATCH 9/9] Adjust the text that references the ACP vocabulary. --- 2022/acp-20220518.html | 2 +- acp.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/2022/acp-20220518.html b/2022/acp-20220518.html index 53b80a25..51d8d251 100644 --- a/2022/acp-20220518.html +++ b/2022/acp-20220518.html @@ -928,7 +928,7 @@

    All terms defined by the Access Control Policy Language are present - in a non-normative RDF representation of the + in an RDF representation of the ACP ontology serialized in turtle.

    diff --git a/acp.html b/acp.html index eff5d642..6bd24c5d 100644 --- a/acp.html +++ b/acp.html @@ -928,7 +928,7 @@

    All terms defined by the Access Control Policy Language are present - in a non-normative RDF representation of the + in an RDF representation of the ACP ontology serialized in turtle.