Comments (14)
Instead of investing further energy on the differences, can we consolidate the flavours? Bring in the good parts from all to the table. Any particular technical or social barriers?
If trustedWhatever is a shared notion, it makes sense to agree on that even if not all implementations of the spec use it. Aside: it may also mean that systems can function without trustedWhatever in place.
W3C wiki/WAC documents the wider design whereas auth/acl is just a vocab.
We all aim for a single WAC and not further fragment. It is completely okay that there are different flavours now, it only reflects the implementations/experiences from different perspectives. Let's take advantage of that knowledge.
from web-access-control-spec.
Instead of investing further energy on the differences, can we consolidate the flavours? Bring in the good parts from all to the table. Any particular technical or social barriers?
If trustedWhatever is a shared notion, it makes sense to agree on that even if not all implementations of the spec use it. Aside: it may also mean that systems can function without trustedWhatever in place.
W3C wiki/WAC documents the wider design whereas auth/acl is just a vocab.
We all aim for a single WAC and not further fragment. It is completely okay that there are different flavours now, it only reflects the implementations/experiences from different perspectives. Let's take advantage of that knowledge.
Yes, but we should be clear about what "consolidation of flavors" entails. For starters, how is Solid using http://www.w3.org/ns/auth/acl#
, distinct from its existing specification?
from web-access-control-spec.
OK! @dmitrizagidulin in 2016 you created this document and stated it was a Solid-specific subset of WAC. Was it your intention that https://www.w3.org/wiki/WebAccessControl would live on independently? Or was it your intention to replace that wiki page?
And having come to the current point, what do you think should happen now with that wiki page?
from web-access-control-spec.
Got it! Thanks for explaining. Then we should update https://github.com/solid/solid-spec#authorization-and-access-control to say we use "Solid-flavoured WAC" and that it's only one of the four flavours out there.
This spec should also have a preamble explaining that it's only one of four flavours.
from web-access-control-spec.
The wiki page being open to anyone to edit, you can add a link from the wiki to the page here.
from web-access-control-spec.
I seem to have an account on https://www.w3.org/community/solid/wiki/ but not on https://www.w3.org/wiki/. I created an account now but it's awaiting review. I'll add the note once my account is active, unless someone else beats me to it! :)
from web-access-control-spec.
The wiki was where ideas that were discussed by Dan Connolly and TimBL and others MIT folks on IRC where put together initially. Then things were consolidated on the github repository when solid came to be named.
from web-access-control-spec.
The WAC ontology has been under the W3C namespace forever. I think what would make most sense is to move both the documentation and the RDF file to a repository under @w3c GitHub account, so people could suggest/review/discuss changes and fixes using the git process. URL redirection should be fairly easy to setup.
Last I knew, @timbl was in control of the vocabulary file.
from web-access-control-spec.
@michielbdejong Yes, the idea was that this repo and the w3c wiki would live on independently. The wiki, and the way Solid was using and extending WAC had diverged before I joined the project. Devs were complaining that there wasn’t a spec for it, so I put together this repo.
And yes, there are 3 different flavors of WAC out there (4 actually, since the OpenLink crew has their own extensions and their own spec) - this repo, the wiki, and the w3c draft, and open link spec).
from web-access-control-spec.
And having come to the current point, what do you think should happen now with that wiki page?
No opinion about what should happen to the wiki page; as far as I know, we don’t really have jurisdiction over it, it’s not in our project’s scope.
from web-access-control-spec.
@dmitrizagidulin the version that matters most is the one published under http://www.w3.org/ns/auth/acl
from web-access-control-spec.
Is it really necessary to have four different "flavors" instead of one standard?
from web-access-control-spec.
I think the other three are mainly unused, but it's not up to us to deprecate them, so we just mention that those alternative versions exist, and we ignore them.
from web-access-control-spec.
@michielbdejong I still don't get what Solid is doing. If you're using a "Solid-flavored WAC", then the namespace of such ontology should be distinct from http://www.w3.org/ns/auth/acl.
from web-access-control-spec.
Related Issues (20)
- Use WAC ontology for authorizing authentication HOT 4
- Proposed Fix to: Loss of Access with lower level ACL (Effective ACL Resource Algorithm) HOT 18
- More explicit names for `acl:accessTo` and `acl:default` predicats HOT 1
- Is N3 patch allowed for Append access? HOT 4
- Is create an append operation? HOT 8
- Bad numbering of Access Privileges section HOT 1
- More examples needed
- Access Mode Extensions HOT 3
- Use of Latin Abbreviations HOT 1
- Add time constraints to WAC rules HOT 4
- Express what expectations users should have of acl:AuthenticatedAgent HOT 11
- Consider adding acl:originGroup HOT 3
- Security implications of ACL resources on different servers HOT 5
- Atomicity of creating a resource and its ACL HOT 2
- Dependent resources / explicit inheritance across containers HOT 7
- Clarify whether ACL needs normalization
- deprecate acl:Control, replace with ... HOT 2
- Edge cases require all implementations to couple authorization and storage HOT 36
- Append to container for resources creation not reflected in current text HOT 1
- Effective ACL Resource discovery requires 2n+1 requests HOT 28
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from web-access-control-spec.