Add condition to authorization evaluation

[csarven]

This PR supersedes #133 and closes #81 .

---

This PR introduces acl:condition as an additional requirement on an acl:Authorization, building on the notion of extensibility previously referenced in the Authorization Extensions section of the specification. The feature rests on a capability detection mechanism: servers that support specific condition types, e.g., acl:IssuerCondition and acl:ClientCondition (specified in this version of the specification), advertise them via Link headers on the effective ACL resource. Clients discover supported condition types from those headers and deploy condition-bearing authorizations accordingly. Condition types not signalled by the server are not used in Authorization Evaluation. When multiple conditions are present, they are conjunctive, i.e., all must be satisfied for an Authorization to be applicable. This mechanism paves the way for additional condition types to be incorporated in the future based on needs and implementations in the ecosystem, e.g., time-based conditions or ODRL policies, as anticipated in Authorization Extensions.

The PR includes the following changes (also included in the #changelog of the specification) with correction classes:

Correction Class	Description
1	Amend broken links, style sheets, or invalid markup.
2	Amend language and document details.
4	Add requirements for ACL Resource Condition Discovery.
4	Add Access Conditions section describing the condition requirement in an Authorization.
4	Update Authorization Conformance to include acl:condition as part of an applicable Authorization.
4	Add Condition Evaluation section describing the evaluation of conditions and their conjunctive requirement.
2	Add example query demonstrating access conditions with client condition and issuer condition.
2	Add security consideration advisement for client-issuer-agnostic control scenarios.
2	Add security consideration advisement for condition-unaware server scenarios.
2	Add privacy consideration advisement for client and issuer information exposure.
2	Amend first- and third-party context in security and privacy review.

---

Related TODOs (as separate PRs):

• Update the ACL vocabulary with the new terms.
• Update Conformance section to define classes of products and mark advisement levels.
• ...

Other TODOs:

• Call for reviews, implementations or commitment to implement.
• Discuss in the community.

---

Preview