From 092322b0156387e77bbaaa6652d9b51c6d3b0dae Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Mon, 19 Jan 2026 17:26:05 +0100 Subject: [PATCH 1/9] add first draft for defining clients and issuers in ACLs --- index.html | 116 +++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 87 insertions(+), 29 deletions(-) diff --git a/index.html b/index.html index 3c383a1..768ef74 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. -
  4. 4.3 Access Subjects
  5. +
  6. +

    4.3 Access Subjects

    +
      +
    1. 4.3.1 Identifying the Subject Agent
    2. +
    3. 4.3.2 Allowed Issuers of Subject Assertion
    4. +
    5. 4.3.3 Allowed Clients
    6. +
    7. 4.3.4 Allowed Origins
    8. +
    +
  • @@ -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 characteristica of an agent, such as identity, role, attribute, capability, or similar.
    +
    client
    +
    A (resource) client is a software agent (application) which requests resources on behalf of an agent.
    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, a class of agents, or a group 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: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.

    -
    -
    -

    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, in particular to verify an asserted identity, role, attribute, capability, or similar, relies on identifying the issuing agent, the issuer, of the corresponding assertion. To be able to explicitly define 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: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.
    +

    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.

    - -
    -

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

    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.

    - +
    +

    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 {
    
    From 7b184c21145b7df761689b2dc8287d6a583c402b Mon Sep 17 00:00:00 2001
    From: Christoph Braun 
    Date: Fri, 23 Jan 2026 11:29:19 +0100
    Subject: [PATCH 2/9] client definition - include suggestions from review
    
    Co-authored-by: Ted Thibodeau Jr 
    ---
     index.html | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    diff --git a/index.html b/index.html
    index 768ef74..c9d7646 100644
    --- a/index.html
    +++ b/index.html
    @@ -506,7 +506,7 @@ 

    Terminology

    issuer
    An issuer is an agent that asserts characteristica of an agent, such as identity, role, attribute, capability, or similar.
    client
    -
    A (resource) client is a software agent (application) which requests resources on behalf of an agent.
    +
    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].
    From cbd41d79a51d6311c08e37c6496bf13d925d7808 Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Fri, 23 Jan 2026 11:29:51 +0100 Subject: [PATCH 3/9] access subject - include suggestions from review Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index c9d7646..25bf4a9 100644 --- a/index.html +++ b/index.html @@ -661,7 +661,7 @@

    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, or a group of agents.

    +

    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

    From e16dd38d8237616f42522232525ec5b1fe602949 Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Fri, 23 Jan 2026 11:30:30 +0100 Subject: [PATCH 4/9] re-ordering agent section- include suggestions from review Co-authored-by: Ted Thibodeau Jr --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 25bf4a9..d049c11 100644 --- a/index.html +++ b/index.html @@ -666,15 +666,15 @@

    Access Subjects

    Identifying the Subject Agent

    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 to any agent, i.e., the public.
    +
    Allows access by any agent, i.e., the public.
    acl:AuthenticatedAgent
    -
    Allows access to any authenticated agent.
    +
    Allows access by 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.

    From f7b95d093de46cca6cd9d59ff6fcd1a1ec6cd73a Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Fri, 23 Jan 2026 11:31:47 +0100 Subject: [PATCH 5/9] improving description clarity - issuers of subject assertion Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index d049c11..ea48102 100644 --- a/index.html +++ b/index.html @@ -680,7 +680,7 @@

    Identifying the Subject Agent

    Allowed Issuers of Subject Assertion

    -

    The ability to authenticate a subject, in particular to verify an asserted identity, role, attribute, capability, or similar, relies on identifying the issuing agent, the issuer, of the corresponding assertion. To be able to explicitly define this trust relationship, the following properties are defined:

    +

    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:issuerClass predicate denotes a class of agents being trusted to make correct assertions about a subject agent.

    One issuer class is defined here:

    From f97dd1c865977abe7d71a9cc01cab004a99c5a7f Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Fri, 23 Jan 2026 11:32:01 +0100 Subject: [PATCH 6/9] re-ordering issuer section- include suggestions from review Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index ea48102..13de8f4 100644 --- a/index.html +++ b/index.html @@ -682,12 +682,12 @@

    Allowed Issuers of Subject Assertion

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

    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.

    Note: Subject Verification

    From fe0fc93090aa8af6b354478d94b520e40d3c289b Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Fri, 23 Jan 2026 11:34:16 +0100 Subject: [PATCH 7/9] re-ordering client section --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 13de8f4..98ea972 100644 --- a/index.html +++ b/index.html @@ -701,13 +701,13 @@

    Allowed Clients

    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:issuerClass predicate denotes a class of agents 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.
    -

    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.

    -
    +

    Issue: Client Identification

    From c5449fd057191832514d41c96068d4a0ce674d69 Mon Sep 17 00:00:00 2001 From: Christoph Braun Date: Fri, 23 Jan 2026 11:36:02 +0100 Subject: [PATCH 8/9] Fix spelling Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 98ea972..d454c14 100644 --- a/index.html +++ b/index.html @@ -504,7 +504,7 @@

    Terminology

    agent class
    An agent class is a class of persons or entities identified by a URI.
    issuer
    -
    An issuer is an agent that asserts characteristica of an agent, such as identity, role, attribute, capability, or similar.
    +
    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
    From 08d01930dd7b858360846083f8a9f937b0946ae6 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 26 Jan 2026 10:12:58 +0100 Subject: [PATCH 9/9] Apply suggestions from code review Editorial --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index d454c14..3138e22 100644 --- a/index.html +++ b/index.html @@ -680,7 +680,7 @@

    Identifying the Subject Agent

    Allowed Issuers of Subject Assertion

    -

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