Re: WAC 2.0: Secure Access Conditions - draft published

st 15. 4. 2026 v 18:04 odesílatel Christoph Braun <braun3@fzi.de> napsal:

> 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
>

Thanks Christoph.

I’ll review your point about the extensions section, if there's a gap in
the fail-closed guarantee, I'll address it. The draft is open for PRs.

For context, the fail-open concern raised on PR #134 received some support,
including an upvote from TimBL [1], which motivated me to explore the
fail-closed variant further. The draft builds on PR #133, reusing the same
condition model and types.

I appreciate the earlier technical engagement.

Melvin

[1]
https://github.com/solid/web-access-control-spec/pull/134#issuecomment-4183136080


>
> [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
>
>
>