Signpost WAC 1.1 ED additions in §2.1 commentary

Per @elf-pavlik on PR #783: the 'WAC does not express…' sentence
was correct for WAC 1.0 (which solid26 pins) but readers should know
that two of the three gaps close in the WAC 1.1 ED via acl:condition
(application-aware matching and conditional grants). Deny rules
remain absent in WAC 1.1, consistent with WAC's monotonic design.
No implementations known at time of publication.

Co-authored-by: elf Pavlik <elf-pavlik@hackers4peace.net>

Author: jeswr

solid26.html

@@ -384,7 +384,7 @@ <h3>Solid Protocol</h3>
                       <p>
                         The Solid Protocol requires Servers to conform to Web Access Control (<a href="#web-access-control">WAC</a>), Access Control Policy (<a href="#access-control-policy">ACP</a>), 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.
                       </p>
-                      <p>WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics &mdash; adding or removing triples preserves the truth of existing grants. Optional <code>acl:origin</code> matching is not intended as client identification [<cite><a class="bibref" href="#ref-wac">WAC</a></cite> § <a href="https://solidproject.org/TR/2024/wac-20240512#security-privacy-review">Security and Privacy Review</a>]. WAC does not express deny rules, application-aware matching beyond Origin, or conditional grants.</p>
+                      <p>WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics &mdash; adding or removing triples preserves the truth of existing grants. Optional <code>acl:origin</code> matching is not intended as client identification [<cite><a class="bibref" href="#ref-wac">WAC</a></cite> § <a href="https://solidproject.org/TR/2024/wac-20240512#security-privacy-review">Security and Privacy Review</a>]. WAC 1.0 (pinned here) does not express deny rules, application-aware matching beyond Origin, or conditional grants. Application-aware matching and conditional grants land as <code>acl:condition</code> in <a href="https://solid.github.io/web-access-control-spec/">WAC 1.1 ED</a>, with no implementations known at the time of publication.</p>
                       <p>ACP is the more expressive alternative, suited to requirements that go beyond what WAC can directly express. Policies can carry allow and deny rules in the same document with non-monotonic semantics, so a deny rule can override a prior allow. Subjects can additionally be identified by the <em>application</em> making the request via the <code>acp:client</code> matcher, and rules composed via <code>acp:allOf</code>, <code>acp:anyOf</code>, and <code>acp:noneOf</code>, supporting context-aware policies.</p>
                       <div class="note" id="note-survey">
                         <h4><span>Note</span></h4>