Comments (15)
It seems like a good idea to pursue. I think the 'reword' part is important to make the text normative. So it's a bit more than just removing the "possible future" label as the title here might imply.
from web-access-control-spec.
Please don't pollute the WAC namespace with Solid-specific terms.
WAC quite clearly defines permissions for the document space.
However "applications" are another dimension, strictly orthogonal to documents. Therefore mixing acl:trustedApp
with the existing document-space terms makes no sense.
Please choose a namespace (under https://solid.inrupt.com/ ?) different from acl:
, and a separate ontology that imports acl:
.
from web-access-control-spec.
Please don't pollute the WAC namespace with Solid-specific terms.
But acl:trustedApp
is not Solid-specific, it's WAC-specific. I thought there was a 1:1 relationship between http://www.w3.org/ns/auth/acl# and this spec? Is the WAC spec not the only user of that namespace?
from web-access-control-spec.
The WAC ontology homepage is https://www.w3.org/wiki/WebAccessControl.
This spec is clearly under Solid's documentation.
As I explained, acl:trustedApp
is orthogonal to the rest of terms and therefore out of place.
from web-access-control-spec.
oh bummer so then we have two competing WAC specs. I see that https://www.w3.org/wiki/WebAccessControl calls it acl:trustedOrigin
instead of acl:trustedApp
.
We should definitely merge https://www.w3.org/wiki/WebAccessControl and https://github.com/solid/web-access-control-spec into one.
@namedgraph are you aware of anyone using the acl:trustedOrigin
predicate in production?
from web-access-control-spec.
I don't know where the trusted
stuff comes from because it's not in https://www.w3.org/ns/auth/acl
And no I'm not aware. As far as I'm concerned, the core of WAC is Authorization
, Mode
, accessTo(Class)
and agent(Class)
.
from web-access-control-spec.
Interesting! And who apart from Solid are using https://www.w3.org/ns/auth/acl, then? So maybe we have three versions of what WAC is then, this github repo, the wiki, and the vocab document...
@namedgraph can you maybe weigh in on #51?
from web-access-control-spec.
I must admit I'm still not confident about acl:trustedApp
's scalability properties. Before that, ACL resource caching was quite easy to achieve, and ACL checking implemented on the top of that cache. With acl:trustedApp
, I'm not sure how it will play out in practice, if we could end up in a situation where there are a lot of user profiles involved, and where caching could get messy, given that people edit their user profiles for many other reasons than ACL maintenance. Since ACL checking is something we do for every request, we need to be careful about it, and don't feel confident it will play out well at scale. It is possible that lazy checking will help, but also that there are sufficiently many cases where too much data needs to be fetched to allow for efficient ACL checking.
from web-access-control-spec.
@kjetilk This issue is about updating the spec text to match what we decided in March.
from web-access-control-spec.
@kjetilk This issue is about updating the spec text to match what we decided in March.
Yes, I know, and I think we might have been a bit hasty, and therefore, it shouldn't be removed before we have some empirical evidence for its consequences.
from web-access-control-spec.
I agree with you that we should move to something better than what we have now, but keeping this document out of sync with reality is not going to fix it. :)
Is it ok with you if we merge #56, and then work on a more granular consent system in the vein of solid/solid-spec#176 or other similar systems we could now start proposing?
from web-access-control-spec.
The question is really the process of deprecating things that have been implemented once it has been in the spec. If it says "possible future", then it is quite clear that it has been implemented as an experimental feature, so I don't think there is really a disconnect with reality in it, it is OK to implement "possible futures" as experimental features at any time.
But OTOH, we're not a working group producing a Recommendation here, I suppose removing it if we have seen it doesn't scale in a WG setting wouldn't be difficult to argue. So, I could live with merging #56, but I'd prefer not.
from web-access-control-spec.
ok, so you how about if we replace 'possible future' (which is factually incorrect) with 'experimental', which warns that it's probably more subject to change than some of the other parts?
from web-access-control-spec.
Yeah, that works for me, if it works for others.
from web-access-control-spec.
Great! Updated #56
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
- This document should not present itself as a "Candidate Recommendation" HOT 4
- Append mode creation of resource should work as well with PUT HOT 3
- Credential based access control (WAC + VC) HOT 11
- Client identification HOT 26
- WAC-Allow's `access-mode` parameter to allow any term HOT 5
- Access Mode Extensions HOT 3
- Use of Latin Abbreviations HOT 1
- 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.