Comments (11)
In OIDC/OAuth, there is typically a pre-existing trust relationship between the IdP and the RS. Absent that initial trust relationship, the RS cannot validate the signature of that bearer token and the HTTP request will not pass through the authentication stage.
from web-access-control-spec.
I agree, I'm not sure acl:AuthenticatedAgent
is that useful.
from web-access-control-spec.
acl:AuthenticatedAgent
is useful for at least these two cases:
- anyone can post a chat/comment/whatever to X, but they need a webid (that is, no anonymous posts)
- anyone can access my X but i want to know who it was later (perhaps in a log file or audit trace)
just because an IdP gives out a signed id_token
that says it's for webid W doesn't mean that it's really W. W still has to say that IdP is an Authorized Issuer for its identity. it's between W and IdP how authentication happens, and isn't really anyone else's business.
from web-access-control-spec.
@zenomt my point is that since authentication happens between W and IdP, someone can set up an IdP that doesn't authenticate, and so, anybody can do anonymous posts. I.e. acl:AuthenticatedAgent
cannot be relied on for those two cases.
from web-access-control-spec.
I agree. In addition, even without a fake IdP, it is absolutely trivial to create a throwaway WebID (it is literally a single API call, or a few seconds filling out a web form), so I'm not sure how much value that WebID would have (it's not much better than anonymous posting or for access logging purposes).
from web-access-control-spec.
i think acl:AuthenticatedAgent
means "the agent has authenticated and proved its webid to me (the resource server) with like an Authorization
header", not "the agent has authenticated in some reasonable and secure way with its identity provider".
making a new transient webid might be trivial, but having a new domain for the webid (or its issuer) is more work. if this were to become a problem in the future, an abusive hosting or issuing domain could be blacklisted.
and i think at "web scale" there's value in "i want to know your webid even if i don't know you specifically already". especially for the friend-request case, but also for commenting or other open collaboration scenarios. acl:AuthenticatedAgent
forces a webid to be proved to the server, so that it can be used.
from web-access-control-spec.
Indeed, this is essentially about setting expectations, but I think the expectations might have exceeded what can reasonably be delivered.
from web-access-control-spec.
Good issue @kjetilk .
@dmitrizagidulin Point well taken about how one can get around it by creating a throwaway but it comes down to why a server may need to have an agent go through the authentication process. I find @zenomt 's comments quite adequate as a response to the concern.
Is acl:AuthenticatedAgent
used in implementations in a way that's different than what's outlined in https://github.com/solid/web-access-control-spec#authenticated-agents-anyone-logged-on ?
@zenomt re:
anyone can post a chat/comment/whatever to X, but they need a webid (that is, no anonymous posts)
The use case makes sense but we don't currently have a strict definition for "anonymous". I would generally say that it doesn't necessarily mean no WebID ie. "unlinkable". It could simply be a WebID Profile with no description or claiming itself to be "Anonymous" (perhaps by name/label or some other description) - which is to say that it is a WebID that's intended to engage anonymously - certainly different from pseudo-anonymous identities. "Anonymity" should not to be conflated with "unlinkability". So, I think the use case you're describing is along the lines "linkable identities only".
To be clear, acl:AuthenticatedAgent
effectively ensures linkable identities. A server or an application may have additional requirements eg. must have a name, has certification x. Any sort of trust on that is orthogonal and we shouldn't couple them together.
Edit: mixed up my authn/z in the paragraph above. Simplified what I really wanted to say.
from web-access-control-spec.
OK, I can accept that view. So, I think this is more about setting expectations right. I'll adjust the title to reflect that.
from web-access-control-spec.
Unclear if there is a particular finding that will be satisfactory to close this issue but I do think that the definition of AuthenticatedAgent is sufficiently clear and can be distinguished from foaf:Agent (at least perhaps in context of agentClass use). Authentication mechanism is orthogonal here.
Closing this issue and moving it to the WAC repo. People can still chime in and we can reopen if necessary. The current WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ requires AuthenticatedAgent and gives a simplified description of the term in ACL ontology "Allows access to any authenticated agent."
from web-access-control-spec.
I have still had a bit of an issue with this, but as @timbl clarified in an Editor's meeting, it doesn't need to be thought of as a security mechanism at all, it is useful to ensure that some identity is conveyed. However, I think this user expectations should still be managed by a paragraph in the Security Considerations section of the WAC spec. I would therefore suggest transferring it back to the spec repo and reopen.
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
- 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.