Skip to content

Latest commit

 

History

History
84 lines (65 loc) · 9.57 KB

2021-11-24.md

File metadata and controls

84 lines (65 loc) · 9.57 KB

W3C Solid Community Group: Authorization Panel

Present

  • e Pavlik
  • Henry S
  • Matthieu B
  • Barath
  • Justin B

Announcements

Meeting Recordings and Transcripts

  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Use panel chat and repository. Queue in call to talk.

Participation and Code of Conduct

Scribes

  • Matthieu Bosquet
  • Elf Pavlik - makes PR and creates next week pad

Topics

Previous meeting minutes

Merged ✅

ACP Draft design flaw

URL: solid/authorization-panel#277.

  • Justin: Let's start with the design flaw.

    • I think that I wanna start with the comment we saw from Aaron that this change may create a problem with existing implementations. I just want to start by acknowledging that my work/organisation don't really have this issue. But Aaron brings up that the proposed adjustment is going to break some existing client/server implementations that currently use ACP (on pod spaces with ESS). Anytime there is potential for breakage, we should keep that in mind.
    • So how serious of an impact do you think it might have on any existing user base? If people use Pod Spaces, which is free, do we have to keep that in mind? When you're a bit ahead of the spec, sometimes, this can happen, and it's not a reason to not make the spec as good as we can.
    • But that comment made me realise that it could affect real users. (Sorry it's not substantial, but I wanted to bring it up).

  • Henry: Good point. That makes me wonder who is implementing what... Matthieu and Aaron? Anyone else? What is the size? That would be useful to know.

  • Justin: I don't know. I think it mostly affects Pod Spaces.

  • Matthieu: I don't have numbers, and don't know what the current impact of such a change would be. But the change Aaron is talking about is changing acp:apply to acp:policy. One could deprecate acp:apply before moving to acp:policy. The biggest migration problem is not in the naming, but in giving up acp:access. But the problems of acp:access are big enough to make the change worthwhile.

  • Barath: It seems like a simple renaming to change acp:apply to acp:policy. Is it a matter of search and replace? If that is what needs to be changed, it does seem minor...

  • Matthieu: It might be a bit more than just a search and replace, but I don't think it is a particularly challenging migration (renaming of acp:apply). The dropping of acp:access is more challenging, but in substance, I believe it is justified.

  • Henry: Your question is interesting, Barath, because as you say, in the old days of the semantic web, that's really what it amounted to. And it really shows why inferencing is really important. Say with inferencing, you'd just add a rule to your client or server that the new predicate is equivalent, and you have a transition.

  • Pavlik: I think that most people don't implement code with inferencing built in. I doubt if Aaron's implementation does it. I don't think Matthieu's does.

  • Matthieu: For me, the problem is inferencing in JS; on the other hand, Java, for example, has really good support for it.

  • Henry: For example, we have vcard and foaf on the web. A client may want to use both. If it doesn't, it is restricted just to part of the data. Of course, you can start by hardcoding the inferencing by hand. The people who invented the semantic web were developing common sense reasoning for computers (billion dollar projects like CYC); they already had 20 years of experience with it, and it's why they managed to distill it into those nice elements that are usable on the Web. I thought it's worth mentioning why it's done.

  • Matthieu: I think hard-coding inferencing is a good way to start with. Justin, do you have comments about the substance?

  • Justin: I like the simplification, and I agree that the current data model and specifically the acp:apply and acp:access properties are a source of confusion. Any time you can remove confusing things from an authz system, you reduce the opportunity for bad authz that doesn't do what the user expects. So generally I'm very much in favour of the simplification, but I'd like to take more time going through the feedback. Make sure I keep all that in mind. But TLDR; I think the simplification is nice. The bit I mentioned at the front is not necessarily something that affects me but may affect others, so I'd like to hear more context about how others might be affected. It feels like not such a hard migration path. But migrations are migrations. That proposal from a purely draft standpoint seems good.

  • Henry: It seems to me that the simplification is useful. I personally got stuck on that aspect and having the simplification makes it clearer. It also seems compatible with ACR on ACR so it sounds good to me.

  • Matthieu: One more thing that might be worth mentioning is that I think we can and should align on the access modes, and if everyone agrees that we need ControlRead, we can push it on the Solid Protocol level as entailing specific operations.

  • Pavlik: I have a question on auxiliary resources. I understand that only auxiliary resources have a control on them. Is there a case on controlling an auxiliary resource?

    • If we say there is a special access mode that refers to an auxiliary resource, it sounds to me like this approach is not using ACR on auxiliary resource. You would still need that path.

  • Matthieu: Are you asking if we have a way currently in Solid to define ACRs on ACRs?

  • Pavlik: Say you have controlRead on resource A, then you have a custom access mode to target the ACR. It doesn't apply to resource A; it applies to the ACR of resource A.

  • Matthieu: My short answer is that it is not up to ACP to define the mechanism you are proposing. ACP has a simple extension point, which is access modes. Those access modes are not defined by ACP but by the protocol. The Solid Protocol says that to be able to edit an auxiliary resource, you need an access mode acl:Control. So solid says you need ACL control to edit the auxiliary resource.

  • Barath: Can you be in a situation where your permissions would allow you to delete a resource but not its auxiliary control resource?

  • Matthieu: First, that is in my opinion something that the Solid Protocol should define precisely. Moreover, I think in order to delete a resource as currently defined in the Solid Protocol, you need acl:Control on both the resource and its container. So short answer, it should not be possible.

  • Henry: There are actually quite a few other good things that can happen from this change. Let me think... I think what Matthieu is saying is that one could open another use case for defining ACLs on ACLs, rather than control. I think that someone was arguing giving access control to sub-parts of a graph. Even though it wasn't mentioned.

  • Matthieu: I could have a go at describing this. This change highlights the difference between a Solid Resource, which is a document, and resources as defined by RDF (whether just part of a representation, dereferenceable via 200 or 303, etc.)...

  • Henry: From the client's perspective, it can follow links and arrive on an ACR. From a client's perspective there is no reason why you should differentiate between an ACL and another resource. This is why you should be able to define that every single resource on the web has an access control rule. So we're just defining an ontology that defines that.

  • Elf: Why couldn't we just use the Read control mode instead of ControlRead.

  • Henry: It's a legacy.

  • Elf: But, at this time, we just use control read to say it applies to the auxiliary resource. If we use control read, we don't target the acr, we target the resource that the ACR is auxiliary of. Do you see the difference?

  • Henry: That's why control is weird. You only need read and write. The client needs a way to define that. And it is part of another proposal, not the one Matthieu is putting forward. All you would have to do is follow the link header, and it could be the same resource.

  • Elf: If you have access control for the resource and sometimes by the acr.

  • Matthieu: My argument is to say that this needs to be defined at solid protocol level. ACP gives a confusing way to define access control over access control resource. What you are describing is possible today.

  • Barath: Is the discussion about what is syntactically possible, and what is semantically possible?

  • Matthieu: The change I propose is in my opinion semantically, syntactically and theoretically right while the current model is wrong on all those fronts as it makes wrong assumptions as to the nature of resources.

  • Henry: It's good progress. I think it is good that we bring up the ACRs-on-ACRs point. If you think about it, the complexity is quite big. You have default rules for access control resources.