Following discussion on PR #134 and PR #133, this issue tracks the broader question of how authorization evaluation should handle unsupported condition types.
The core question: when a server encounters an acl:condition it does not support, should the authorization be treated as applicable (fail-open) or non-applicable (fail-closed)?
This choice affects whether adding constraints can unintentionally broaden access when evaluated on servers with differing capability support.
A fail-closed variant has been published as a draft for comparison:
https://webacl.org/secure-access-conditions/
Related: PR #133, PR #134
Following discussion on PR #134 and PR #133, this issue tracks the broader question of how authorization evaluation should handle unsupported condition types.
The core question: when a server encounters an acl:condition it does not support, should the authorization be treated as applicable (fail-open) or non-applicable (fail-closed)?
This choice affects whether adding constraints can unintentionally broaden access when evaluated on servers with differing capability support.
A fail-closed variant has been published as a draft for comparison:
https://webacl.org/secure-access-conditions/
Related: PR #133, PR #134