Re: WAC 2.0: Secure Access Conditions - draft published

Dear Melvin,

I am disappointed to see you continuing your disruptive behaviour 
despite you announcing to work with the usual process of the CG [1].
Addressing the issue in the way you currently pursue is disruptive to 
the CG and does not provide an environment where feedback feels welcome, 
despite you stating otherwise.

I have already provided feedback on your draft [2,3] and thus deem your 
proposal not more secure than the proposal for WAC 1.1 put forward in [4].
It does not provide the "fail-closed semantics" you desire, despite you 
stating otherwise.
It merely modifies the evaluation behaviour regarding a particular part 
of authorization evaluation leaving other parts untouched [5].

I had already proposed a sound extension to WAC in [6], which was 
discussed over a decent period of time.
Rough consensus emerged following the usual process.
I recommend you follow the usual process if you want to engage 
meaningfully in the CG and want to be taken seriously in that.

That is all,
Christoph

[1] 
https://github.com/solid/web-access-control-spec/pull/134#issuecomment-4184262972
[2] 
https://github.com/solid/web-access-control-spec/pull/134#issuecomment-4183448327
[3] 
https://github.com/solid/web-access-control-spec/pull/134#issuecomment-4184233481
[4] https://github.com/solid/web-access-control-spec/pull/134
[5] https://webacl.org/secure-access-conditions/#extensions
[6] 
https://github.com/solid/web-access-control-spec/pull/133#issuecomment-3950907935


On 15/04/2026 15:17, Melvin Carvalho wrote:
> Hi all,
>
> I've published a draft extending Web Access Control with 
> acl:condition, using fail-closed evaluation semantics:
>
> https://webacl.org/secure-access-conditions/
>
> Source: https://github.com/webacl/secure-access-conditions
>
> This builds on PR #133 [1] and PR #134 [2], reusing the same 
> acl:condition syntax and condition types (acl:IssuerCondition, 
> acl:ClientCondition).
>
> The key difference is in evaluation semantics: if a server encounters 
> a condition it does not support, the authorization is treated as 
> non-applicable. This ensures that access constraints are never 
> silently ignored and avoids fail-open behaviour in mixed-capability 
> deployments.
>
> This is a breaking change, hence versioned as WAC 2.0. Servers that do 
> not understand a condition must reject it, rather than evaluating the 
> authorization as if the condition were absent.
>
> Two implementations exist today:
> - JavaScriptSolidServer (JSS)
> - VisionClaw (via JSS) [3]
>
> Feedback is very welcome, particularly from implementers. I’m also 
> looking for co-editors and reviewers interested in shaping this work.
>
> Melvin Carvalho
>
> [1] https://github.com/solid/web-access-control-spec/pull/133
> [2] https://github.com/solid/web-access-control-spec/pull/134
> [3] https://github.com/DreamLab-AI/VisionClaw

Received on Wednesday, 15 April 2026 16:01:48 UTC