Clarify and/or mitigate risks related to negation (acp:deny) about authorization-panel HOT 2 OPEN

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 😃 In a non-normative section, it can point to common pitfalls.

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.