- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Thu, 16 Apr 2026 03:01:38 +0200
- To: elf Pavlik <elf-pavlik@hackers4peace.net>
- Cc: public-solid <public-solid@w3.org>
- Message-ID: <CAKaEYhJYpUD25gqWXgj9QW7G7Gzw2r+T0WjqE0XQQimtjZeNmA@mail.gmail.com>
čt 16. 4. 2026 v 1:21 odesílatel elf Pavlik <elf-pavlik@hackers4peace.net> napsal: > Hi Melvin, > > On Wednesday, April 15th, 2026 at 7:18 AM, Melvin Carvalho < > melvincarvalho@gmail.com> wrote: > > > 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 > > In principle I think forking something is an option. > When I look at your repo I notice right always > > 1. It doesn't cleanly fork the original work, instead it may misled people > that this is your individual creative work > https://github.com/webacl/secure-access-conditions/commits/main/ > 2. It doesn't pick another name e.g., MAC 2.0, instead it just presents > itself as WAC 2.0 > > Even before discussing if I agree with a need to fork WAC, since you > already are doing it I would suggest that you at least fork it properly. > Hi eP, Thanks for the feedback. On attribution: the draft preserves the original W3C Solid CG license, lists the original authors, and references PR #133 and PR #134. The intent is to make the provenance clear. On naming: "WAC 2.0" is used to signal continuity. The draft uses the same vocabulary and condition model, with a change in evaluation semantics, which I'm treating as a major version change. On forking: as a CG Report, publishing variants is expected. The aim here is to explore an alternative evaluation model while keeping alignment with the existing work, focusing on deterministic and secure authorization conditions, suitable for production deployments. The draft addresses the question of authorization applicability when a server encounters an unsupported condition type, and comparing fail-open vs fail-closed behaviour. Best, Melvin > > Best, > eP > >
Received on Thursday, 16 April 2026 01:01:57 UTC