diff --git a/index.html b/index.html index 3c383a1..3138e22 100644 --- a/index.html +++ b/index.html @@ -392,7 +392,15 @@

Table of Contents

  1. 4.1 Access Objects
  2. 4.2 Access Modes
    3. -
  3. 4.3 Access Subjects
    4. +
  4. +

    4.3 Access Subjects

    +
      +
    1. 4.3.1 Identifying the Subject Agent
      2. +
    2. 4.3.2 Allowed Issuers of Subject Assertion
      3. +
    3. 4.3.3 Allowed Clients
      4. +
    4. 4.3.4 Allowed Origins
      5. +
    +
  • @@ -495,6 +503,10 @@

    Terminology

    An agent group is a group of persons or entities identified by a URI.
    agent class
    An agent class is a class of persons or entities identified by a URI.
    +
    issuer
    +
    An issuer is an agent that asserts characteristics of an agent, such as identity, role, attribute, capability, or similar.
    +
    client
    +
    A client is a software agent (application) which requests resources on behalf of an agent (possibly itself).
    origin
    An origin indicates where an HTTP request originates from [RFC6454].
    @@ -649,36 +661,72 @@

    Note: Loss of Control Mitigation

    Access Subjects

    -

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

    -

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

    -

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

    -

    Two agent classes are defined here:

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

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

    -

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

    -
    -

    Note: Subject Verification

    +

    The ability of a subject to access a resource can be granted to identifiable agents, groups of agents, and/or classes of agents.

    +
    +

    Identifying the Subject Agent

    -

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

    +

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

    +

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

    +

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

    +

    Two agent classes are defined here:

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

    Note: Origin Considerations

    +
    +
    +

    Allowed Issuers of Subject Assertion

    -

    Typical web browsers use origin-based security to isolate content and prevent malicious interactions. While not designed to identify clients, it can complement security mechanisms such as mTLS-based authentication.

    +

    The ability to authenticate a subject — particularly to verify an asserted identity, role, attribute, capability, or similar — relies on the ability to identify the issuing agent, the issuer, of the corresponding assertion. To enable explicit definition of this trust relationship, the following properties are defined:

    +

    The acl:issuer predicate denotes an issuer being trusted to make correct assertions about a subject agent.

    +

    The acl:issuerGroup predicate denotes a group of agents being trusted to make correct assertions about a subject agent. The object of an acl:issuerGroup statement is an instance of vcard:Group, where the members of the group are specified with the vcard:hasMember predicate.

    +

    The acl:issuerClass predicate denotes a class of agents being trusted to make correct assertions about a subject agent.

    +

    One issuer class is defined here:

    +
    +
    foaf:Agent
    +
    Accept assertions made by any agent, i.e., the public.
    - -
    -

    Issue: Client Identification

    +
    +

    Note: Subject Verification

    +
    +

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

    +
    +
    +
    +
    +

    Allowed Clients

    -

    Distinguishing social entities and clients: issues/81.

    +

    A subject agent may interact with resources using a client. To define which set of clients is acceptable to process a resource, the following properties are defined:

    +

    The acl:client predicate denotes a client being allowed access when acting on behalf of the subject agent.

    +

    The acl:clientGroup predicate denotes a group of agents being allowed access when acting on behalf of the subject agent. The object of an acl:clientGroup statement is an instance of vcard:Group, where the members of the group are specified with the vcard:hasMember predicate.

    +

    The acl:clientClass predicate denotes a class of agents being allowed access when acting on behalf of the subject agent.

    +

    One client class is defined here:

    +
    +
    foaf:Agent
    +
    Allow requests by any agent, i.e., the public, to make requests on behalf of the subject agent.
    +
    +
    +

    Issue: Client Identification

    +
    +

    Distinguishing social entities and clients: issues/81.

    +
    - +
    +
    +

    Allowed Origins

    +
    +

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

    +
    +
    +

    Note: Origin Considerations

    +
    +

    Typical web browsers use origin-based security to isolate content and prevent malicious interactions. While not designed to identify clients, it can complement security mechanisms such as mTLS-based authentication.

    +
    +
    +

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

    @@ -725,7 +773,9 @@

    Authorization Conformance

  • At least one rdf:type property whose object is acl:Authorization.
  • At least one acl:accessTo or acl:default property value (Access Objects).
  • At least one acl:mode property value (Access Modes).
    • -
  • At least one acl:agent, acl:agentGroup, acl:agentClass or acl:origin property value (Access Subjects).
    • +
  • At least one acl:agent, acl:agentGroup, acl:agentClass property value (Subject Agent).
    • +
  • At least one acl:issuer, acl:issuerGroup, acl:issuerClass property value (Subject Issuer).
    • +
  • At least one acl:client, acl:clientGroup, acl:clientClass property value (Subject Client).

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

    @@ -814,7 +864,7 @@

    Authorization Matching

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

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

    -
    Example: Match an Authorization with a specific resource, agent and access mode.
    +
    Example: Match an Authorization with a specific resource, agent, issuer, client and access mode.
    PREFIX acl: <http://www.w3.org/ns/auth/acl#>
 PREFIX foaf: <http://xmlns.com/foaf/0.1/>
 PREFIX vcard: <http://www.w3.org/2006/vcard/ns#>
@@ -825,6 +875,8 @@ 
    Authorization Matching
    
       a acl:Authorization ;
       acl:accessTo $resource ;
       acl:agent $agent ;
+      acl:issuer $issuer ;
+      acl:client $client ;
       acl:mode $mode .
   }
 }
    @@ -833,7 +885,7 @@

    Authorization Matching

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

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

    -
    Example: Match an Authorization with a specific container resource, agent class membership and access mode.
    +
    Example: Match an Authorization with a specific container resource, agent class membership, issuer class membership, client class membership, and access mode.
    ASK {
   GRAPH $aclResource {
     {
@@ -841,6 +893,8 @@ 
    Authorization Matching
    
         a acl:Authorization ;
         acl:default $containerResource ;
         acl:agentClass $agentClass ;
+        acl:issuerClass $issuerClass ;
+        acl:clientClass $clientClass ;
         acl:mode $requiredMode .
     }
     UNION
@@ -849,6 +903,8 @@ 
    Authorization Matching
    
         a acl:Authorization ;
         acl:default $containerResource ;
         acl:agentClass $agentClass ;
+        acl:issuerClass $issuerClass ;
+        acl:clientClass $clientClass ;
         acl:mode ?mode .
       GRAPH $aclOntologyResource {
         $requiredMode rdfs:subClassOf+ ?mode .
@@ -860,13 +916,15 @@ 
    Authorization Matching

    The following query can be used to check if an agent is a member of any group that can access a resource:

    -
    Example: Match an Authorization with a specific resource, agent with any group membership, and specific access mode.
    +
    Example: Match an Authorization with a specific resource, agent with any group membership, issuer and client from specific groups, and specific access mode.
    ASK {
   GRAPH $aclResource {
     ?authorization
       a acl:Authorization ;
       acl:accessTo $resource ;
       acl:agentGroup ?agentGroup ;
+      acl:issuerGroup $issuerGroup ;
+      acl:clientGroup $clientGroup ;
       acl:mode $mode .
   }
   GRAPH ?groupResource {