diff --git a/solid26.html b/solid26.html index 8208eed9..717b2dec 100644 --- a/solid26.html +++ b/solid26.html @@ -295,8 +295,9 @@

Table of Contents

  • 2.1 Solid Protocol
  • 2.2 Solid-OIDC
  • 2.3 Web Access Control
  • -
  • 2.4 WebID 1.0
  • -
  • 2.5 Solid WebID Profile
  • +
  • 2.4 Access Control Policy
  • +
  • 2.5 WebID 1.0
  • +
  • 2.6 Solid WebID Profile
  • @@ -361,6 +362,11 @@

    Specifications

    (CG-DRAFT, v1.0.0, 2024-05-12) Link + + Access Control Policy + (v0.9.0, 2022-05-18) + Link + @@ -376,28 +382,19 @@

    Solid Protocol

  • - Servers are strongly encouraged to implement Web Access Control (WAC), see below. + The Solid Protocol requires Servers to conform to Web Access Control (WAC), Access Control Policy (ACP), or both, and requires Clients to conform to both. In practice, Clients typically conform to one. A Client that conforms to only one and needs to read or write access-control rules will not interoperate with a Server that implements only the language the Client does not support; Clients that do not interact with access-control rules are unaffected. Implementers choosing between the two should consider the requirements satisfied by each.

    +

    WAC is pragmatic, user-friendly, and extensible. WAC 1.0 does not support deny or non-additive policy composition, application-aware matching beyond Origin, or issuer matching; application-aware matching, issuer matching, and other conditional grants land as acl:condition in WAC 1.1 ED, with no implementations known at the time of publication.

    +

    ACP is expressive. It supports allow and deny rules (deny overrides allow), application-aware (acp:client) and issuer (acp:issuer) matching, verifiable-credential matching (acp:vc), and policy composition via acp:allOf / acp:anyOf / acp:noneOf.

    Note

    -

    The March 2026 implementation survey yields the following results (archived):

    - -

    The data shows that most clients implement only one access control language, despite the Solid Protocol requiring Clients to conform to both WAC and ACP.

    +

    The March 2026 implementation survey (data, archived):

    + +

    Most surveyed Clients implement one access control language, not both.

    -

    - In case WAC seems not to satisfy implementers' requirements, implementers are strongly encouraged to verify their understanding of the matter in community discussion by providing feedback to the community. - If WAC is not able to satisfy the requirements, implementers might consider ACP or other suitable mechanisms to achieve their goals. - Client implementers are advised to consider that their Client implementation will not be able to interoperate with every conforming Server their Client might encounter. -

  • @@ -443,7 +440,14 @@

    EDITORS' Note

    Web Access Control

    Web Access Control (CG-DRAFT, v1.0.0, 2024-05-12) is included.

    -
    + + + +
    +

    Access Control Policy

    +
    +

    Access Control Policy (v0.9.0, 2022-05-18) is included.

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

    Note

    @@ -670,6 +674,9 @@

    References

    [WAC]
    Web Access Control. Sarven Capadisli. W3C Solid Community Group. 12 May 2024. Draft Community Group Report, Version 1.0.0. URL: https://solidproject.org/TR/2024/wac-20240512
    +
    [ACP]
    +
    Access Control Policy. Matthieu Bosquet. W3C Solid Community Group. 18 May 2022. Version 0.9.0. URL: https://solidproject.org/TR/2022/acp-20220518
    +
    [WEBID]
    WebID 1.0. Andrei Sambra; Stéphane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/