Comments (2)
All ACP matchers are subject to the RDF definition of IRI equality and literal term equality; furthermore, the ACP resolution algorithm defines no normalisation and runs at once against a specific context for all effective policies (whether they acl:deny
or acl:allow
access modes).
In other words, all effective policies in obtaining access, whether they are policies denying or allowing access, are run against the same input, at the same time, without normalisation. In that sense, there is no risk that https://id.example.org/bob
will on the one hand be allowed and not denied access.
One can imagine users writing policies and using completely different URLs in different places https://id.example.org/bob
, urn:whatever:bobby
, https://id.example.com/bob
, https://id.example.org/bob/
and https://id.example.org/bob#me
with the intention of allowing/denying access to the same person... I would tend to argue that it is a UI/client problem which I wouldn't necessarily address here and if I were to think of this range of issues, I'd be more warry of things such as, for example, mixing of ascii and international characters https://id.example.org/alice
vs https://id.example.org/αlice
or just easy to miss permutations https://id.example.org/latif
vs https://id.example.org/latfi
(or loss of domain registration overtime).
ACP remains pretty generic about it:
ACP engines MUST match the context attributes defined by this specification according to IRI equality and literal term equality.
— https://solidproject.org/TR/acp#satisfied-matcher
I'm not sure that the problems inherent to any system relying on identifiers should further be described by ACP (it feels orthogonal).
from authorization-panel.
@matthieubosquet Thanks!
In other words, all effective policies in obtaining access, whether they are policies denying or allowing access, are run against the same input, at the same time, without normalisation. In that sense, there is no risk
I agree that the equality is well defined (as I state in my post). But the risk is incorrect or incompatible implementations; i.e., an attack vector. For instance, a proxy might apply HTTP URL equivalency (where certain encoding differences don't matter) instead of RDF's strict string equality for URLs.
I would tend to argue that it is a UI/client problem
I fine with that; I'm just posing the question whether the ACP spec—or Solid specs in general—should address this as potential attack surfaces. And especially the case of negation: whereas a narrow interpretation of positive statements has a restrictive effect, the narrow interpretation of negative statements has a widening effect. Especially that effect I'd expect to be documented as an attack vector.
In fact, the fact that the ACP spec currently seems to have no security considerations section might be an issue of itself.
from authorization-panel.
Maybe the particular issue of incorrect implementations for instance would be best addressed via a test suite?
I have not given a lot of thoughts to a security considerations section but I’m not against it (if not 100% convinced yet ^^,). Speaking of matching IRIs and literals there would not sound like a bad start for such a section.
Now, as you mention above, it’s possible that matching IRIs (and potentially literals) for the purpose of identity assertion and access control is a concern that spans multiple specs, it might best live as a separate document referenced by other specs.
from authorization-panel.
Maybe the particular issue of incorrect implementations for instance would be best addressed via a test suite?
Yes, but that's exactly where the spec can help
it might best live as a separate document referenced by other specs.
Sure; that is an acceptable resolution.
As far as this issue is concerned, I think the main questions are:
- should there be a security considerations section?
- should that section point at negation specifically?
Feel free to handle as you see fit, I just wanted to signal.
from authorization-panel.
Related Issues (20)
- Required Credentials Discovery HOT 6
- support Trig serialization of Access Control Resources
- define a 2nd relation for ACRs to go with "acl" HOT 1
- Ideas for access modes and corresponding operations in the Protocol HOT 53
- acp:CreatorAgent logic HOT 5
- place meeting minutes on "draft-minutes" branch HOT 3
- Process Point of Order in meeting 2021-09-29 HOT 15
- ACP Draft design flaw HOT 18
- Distinction between policies which can be enforced by technology and by law HOT 5
- Enforce a secure default for client restrictions HOT 5
- Consider ACP matcher for conditional by relationship
- Update authorization-ucr's editors HOT 5
- Specify that the modes available are calculated using the resolution algorithm.
- Remove acp:mode from Context properties HOT 2
- Cannot match a context that contains a client/issuer HOT 4
- ACP vocabulary base URI problems HOT 1
- Serve ACP vocabulary from its base URI
- Authorization focused meetings HOT 13
- ACP acronym also used for: Authoritative Claims Provider (OIDC + VC)
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 authorization-panel.