diff --git a/solid26.html b/solid26.html index 1092cc88..c071470e 100644 --- a/solid26.html +++ b/solid26.html @@ -301,6 +301,15 @@

Table of Contents

3. Implementation Guidance

  1. 3.1 WebID
    2. +
  2. +

    3.2 WAC and ACP

    +
      +
    1. 3.2.1 Data Model Comparison
      2. +
    2. 3.2.2 Converting WAC to ACP
      3. +
    3. 3.2.3 Converting ACP to WAC
      4. +
    4. 3.2.4 Summary of Convertible Features
      5. +
    +
  • References
    • @@ -427,6 +436,165 @@

    Note

    + +
    +

    WAC and ACP

    +
    +

    The Solid ecosystem defines two access control systems: [WAC] and [ACP]. A Solid server implements one or both of these. Clients working across servers may need to convert between the two representations.

    +

    WAC and ACP overlap in what they can express but are not equivalent. WAC uses a flat list of acl:Authorization instances. ACP uses a layered structure of Access Control Resources, Access Controls, Policies, and Matchers. Some constructs in each system have no counterpart in the other.

    + +
    +

    Data Model Comparison

    +
    +

    A WAC authorization (an instance of acl:Authorization) combines access objects, access modes, and access subjects into a single resource. It uses acl:accessTo and acl:default to identify target resources, acl:mode to specify permissions, and acl:agent, acl:agentClass, acl:agentGroup, and acl:origin to identify subjects.

    +

    ACP separates these concerns across multiple classes. An acp:AccessControlResource connects a resource to one or more acp:AccessControl instances via acp:accessControl and acp:memberAccessControl. Each Access Control links to Policies via acp:apply. A Policy specifies allowed and denied modes via acp:allow and acp:deny, and references Matchers via acp:allOf, acp:anyOf, and acp:noneOf. A Matcher describes agent, client, issuer, and credential conditions.

    +
    +
    + +
    +

    Converting WAC to ACP

    +
    +

    Each acl:Authorization produces one acp:AccessControlResource containing one acp:AccessControl, one acp:Policy, and one acp:Matcher.

    + +
      +
    1. For each acl:Authorization in the source:
      2. +
    2. If the authorization has any acl:origin values, the conversion fails. WAC's origin-based access has no equivalent in ACP's matcher model.
      3. +
    3. If acl:accessTo is present, create an acp:AccessControlResource and link it to a new acp:AccessControl via acp:accessControl. Set acp:resource to the value of acl:accessTo. Then populate the Policy and Matcher as described in steps 4–7.
      4. +
    4. If acl:default is present, create an acp:AccessControlResource and link it to a new acp:AccessControl via acp:memberAccessControl. Set acp:resource to the value of acl:default. The acp:memberAccessControl property provides the transitive inheritance that acl:default provides in WAC. Then populate the Policy and Matcher as described in steps 4–7.
      5. +
    5. Create a new acp:AccessControl, a new acp:Policy, and a new acp:Matcher. Link the Access Control to the Access Control Resource's acp:accessControl or acp:memberAccessControl set (depending on step 2 or 3). Link the Policy to the Access Control via acp:apply. Link the Matcher to the Policy via acp:allOf.
      6. +
    6. For each acl:mode value on the authorization, add it to the Policy via acp:allow. Both systems use the same mode IRIs from the ACL vocabulary (acl:Read, acl:Write, acl:Control, acl:Append).
      7. +
    7. For each acl:agent value: +
        +
      • If the value is foaf:Agent, add acp:PublicAgent to the Matcher's acp:agent.
        • +
      • If the value is acl:AuthenticatedAgent, add acp:AuthenticatedAgent to the Matcher's acp:agent.
        • +
      • Otherwise, add the agent IRI directly to the Matcher's acp:agent.
        • +
      +
      8. +
    8. For each member of an acl:agentGroup (resolved via vcard:hasMember), add the member IRI to the Matcher's acp:agent. ACP has no group indirection; group members are flattened into individual agent references.
      9. +
    +
    +
    + +
    +

    Converting ACP to WAC

    +
    +

    Each acp:AccessControlResource produces one acl:Authorization. The authorization accumulates modes and agents from all Access Controls and their Policies.

    + +
      +
    1. Given an acp:AccessControlResource in the source:
      2. +
    2. Create a new acl:Authorization.
      3. +
    3. If the ACR has any acp:accessControl values, set acl:accessTo on the authorization to the ACR's acp:resource value,
      4. +
    4. If the ACR has any acp:memberAccessControl values, set acl:default on the authorization to the ACR's acp:resource value.
      5. +
    5. For each acp:AccessControl linked via acp:accessControl or acp:memberAccessControl, and for each acp:Policy linked via acp:apply: +
        +
      1. If the Policy has any acp:deny values, the conversion fails. WAC has no deny mechanism.
        2. +
      2. If the Policy has any acp:anyOf matchers, the conversion fails. WAC has no disjunctive matching.
        3. +
      3. If the Policy has any acp:noneOf matchers, the conversion fails. WAC has no negation.
        4. +
      4. For each acp:allow value on the Policy, add it to the authorization's acl:mode.
        5. +
      5. For each acp:Matcher linked via acp:allOf: +
          +
        • If the Matcher has any acp:client values, the conversion fails. WAC has no client restriction.
          • +
        • If the Matcher has any acp:issuer values, the conversion fails. WAC has no issuer restriction.
          • +
        • If the Matcher has any acp:vc values, the conversion fails. WAC has no verifiable credential matching.
          • +
        • For each acp:agent value on the Matcher: +
            +
          • If the value is acp:CreatorAgent, the conversion fails. WAC has no creator concept.
            • +
          • If the value is acp:OwnerAgent, the conversion fails. WAC has no owner concept.
            • +
          • If the value is acp:PublicAgent, add foaf:Agent to the authorization's acl:agent.
            • +
          • If the value is acp:AuthenticatedAgent, add acl:AuthenticatedAgent to the authorization's acl:agent.
            • +
          • Otherwise, add the agent IRI directly to the authorization's acl:agent.
            • +
          +
          • +
        +
        6. +
      +
      6. +
    +
    +
    + +
    +

    Summary of Convertible Features

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    WAC ↔ ACP feature mapping
    WACACP
    acl:accessToacp:resource (with acp:accessControl)
    acl:defaultacp:resource (with acp:memberAccessControl)
    acl:modeacp:allow
    acl:agentacp:agent
    foaf:Agentacp:PublicAgent
    acl:AuthenticatedAgentacp:AuthenticatedAgent
    acl:agentGroup (with vcard:hasMember)acp:agent
    acl:origin∅
    ∅acp:deny
    ∅acp:anyOf
    ∅acp:noneOf
    ∅acp:client
    ∅acp:issuer
    ∅acp:vc
    ∅acp:CreatorAgent
    ∅acp:OwnerAgent
    +
    +
    +
    +
    @@ -443,6 +611,9 @@

    References

    [WAC]
    Web Access Control. W3C Solid Community Group. URL: https://solidproject.org/TR/2024/wac-20240512
    +
    [ACP]
    +
    Access Control Policy. W3C Solid Community Group. URL: https://solidproject.org/TR/2022/acp-20220518
    +
    [BKY+24]
    AuthApp - Portable, Reusable Solid App for GDPR-Compliant Access Granting.