From cdd14e6b9afa36344f4e0f23e0604a513399800f Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 16:48:35 +0100 Subject: [PATCH 01/20] Minutes 2021-07-21 --- meetings/2021-07-21.md | 174 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 meetings/2021-07-21.md diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md new file mode 100644 index 00000000..c129382d --- /dev/null +++ b/meetings/2021-07-21.md @@ -0,0 +1,174 @@ +# 2021-07-14 Solid Authorization + +https://meet.jit.si/solid-authorization + + +## Agenda + +* Minutes - https://github.com/solid/authorization-panel/pull/238 +* UC1 - https://github.com/solid/authorization-panel/pull/215 +* UC3 - https://github.com/solid/authorization-panel/pull/216 +* Closing outdated UCR issues? + * #87 - https://github.com/solid/authorization-panel/issues/87 + * #89 - https://github.com/solid/authorization-panel/issues/89 +* Transfer of issue 191 - https://github.com/solid/authorization-panel/issues/191 + +## Present + +* Henry Story +* Justin Bingham +* Elf Pavlik +* Matthieu B + + +## Minutes + +### ACP UC3 + +Henry: I don't think there is a way to build what we're trying to build without allowing global read to ACRs. There has to be some document that tells you how to authenticate. There is a privacy problem with people putting all access control statements in one ACL. But that problem goes away if you are doing it correctly. And there is no other way of doing it that doesn't require inventing a whole new system. This is why it is important to go through those Use Cases. +I don't think we want to go through all Use Cases. They were developped before we went through this process. It might not be coherent to go throuhg them all. +I don't see that the [latest comment on UC3](https://github.com/solid/authorization-panel/pull/216#discussion_r673945084) is a problem, it is up to Elf to put a proposition forward to deal with credentials requirement discovery. +The default is that you have to read the access control. +This is the only way to do Solid. +That is the right default and what happens if you don't get access? You don't know how to authenticate, therefore, you don't have access. +If you can't access the ACL, you don't know how to authenticate, you're left with guessing which is not acceptable. + +Matthieu: But it is a security issue to have ACRs readable publicly by default. + +Henry: In my view it is going to be the majority of cases. + +Justin: I think we're inflating a real problem that needs to be solved which is understanding what a given agent has access to with an access control system which should just be understand whether you have access to something or not. But there are other out of band ways to give agents a list of what they have access to. +There aren't patterns to tell an agent what they have access to. +I personally don't believe that the best way to deliver that information is through the ACL resources. I'm happy to be proven wrong. +I see it as a separate type of flow. +In other areas which aren't SOlid specific but if your control rules are setup (OAuth/Firewalls...). +I'm wondering what is the minimum amount that people need to know. +We have precedent with WAC-ALLOW in Solid. +But we need to be able to follow your nose through resources would be pretty problematic. Because you don't want to leak stuff you don't want to. + +Matthieu: There are two problems here: +1. how does an agent know all the resources it has access to +2. how does one knows which credentials to present to access a resource + +Justin: Absolutely, application workflows are much more richer that access to this or that. Pavlik and I specifically worked on it a lot with the interop work we've been doing. So we might have a more accute feeling for what is required. + +Elf: We have to make a pragmatic approach towards how to approach those UCs. For ACP my understanding is that the access control resource is not accessible unless there is an access control. + +Matthieu: It was also my understanding for WAC (not readable by default). +Maybe raise one more issue to make it explicit whether WAC resources are accessible by default. + +Elf: Even though ACP could make it accessible to the public. Why is it required for this use case? +Let's not make it required for this use case. + +Matthieu: I see here three questions that I would like + +Henry: Unless the ACL states that it is publicly readable, it should not be readable. +That is a limitation of WAC currently that doesn't allow just public read to ACLs. + +Matthieu: There is a proposal to extend access control modes including `ControlRead`. + +Henry: Link me to it. ACP does something. + +Matthieu: I think I agree and if we were to adopt extended access modes, maybe we wouldn't have to use so many different predicates to apply policies in ACP. + +Henry: I'll try to review that for next week. +We have a use case for shopping and buying music. It seems that in that case everybody should know the price and clearly that would be an access control rule saying on proof of payment you can download this music. + +Matthieu: You mean that the access control would allow you to infer that in order to read the music, you need to show that you need to pay for something. + +Henry: That is the same thing for say being a university member. +Just have the Group Bob and Alice being private but you know you need to be part of the group. + +Matthieu: This sounds like a classic verifiable credential/key based access where you just need to prove what set you pertain to. + + +### PR Workflow + +Pavlik: There is a bit of problem on who works on pull requests and who has to approve them. But it's pretty clear that ACP would be Matthieu, WAC Sarven, WAC+ Henry, but it would be good to have 1 person leading the proposal. + +Matthieu: That sounds good, but what do you think would be necessary to make things clearer? + +Henry: I think that's more or less what we've been doing. + +Pavlik: We could have separate PRs for separate proposals. + +Matthieu: I would prefer keeping a PR per use case. I think the current flow does work well to compare the implementation details. + +Justin: +1 Pavlik's point or the spirit of it. +I feel like we needed the specs yesterday and I can't build what I want with the current state of WAC. +We need to optimise our workflow to get to proposal state, we need to get there fast. +The ecosystem needs us to get to a better more robust access control system sooner rather than later. + +Henry: I agree that WAC got stuck where it was for 5 to 6 years. +At least now, the simple Use Cases help us show the limitations of WAC and get feedback for example from Sarven. +Comparing it to ACP is helping us tweak things a little bit. +We write out detail by detail the things and figure out problems as we go along. +We might have a problem with ACP and WAC both to do with copying data and figuring out what the problems and disavantages are and end up with one system. +We're just not putting enough time in it, which is why it's very slow. +I suggest we commit this and continue with new PRs to continue on what we've done. +Matthieu suggested that we've already agreed 2 weeks ago to merge and incrementally improve before you joined. +We have a use case that is dealing with privacy on the WAC side. +Matthieu can do the same and we can ask Sarven how that would be done. +It is a good way to see the advantages. +WAC is very easy to implement which is good at the begining and it's been advertised as a good decentralised access control solution, we need to tackle a few issues so that it meets expectations. + +Justin: It is a way and beneficial. +But the best way is to have something in the field and get it used in the field. +We need value from real; "in the field"; implementations and use. +We need to see value from there. +That's an essential part of maturing specs and getting them to completion to have something out there that is close to completion. +I wanna ideally try to get there. + +Henry: That's what I was doing 5/6 years ago, then it took a long time because something got stuck at MIT. +If you look at this report UC3, then you can see that WAC+ import solves a lot of issues. +And it might help solve things on the ACP side too. +It helps you avoid copying lots of data around. +And answers many questions, such as "If you change the root ACR do changes get effected everywhere else?... + +Matthieu: I agree with Henry. I think it is problematic that some fundamental issues have not been formulated clearly in the past and that the fact that we're doing it proves that we're doing something right. + +Justin: Yes. More than anything, I just want to understand how do we optimise what we have left to do? +How do we get back from implementation? + +Henry: Maybe we need 1 or 1.5 days a week for Matthieu and I to move along. +These UC cases are very much like an implementation. It is backed by experience. +I agree we need to move faster on this. + +Matthieu: I agree with Henry's assessment that we need more time aside mostly. There was also a problem of fluency and getting up to speed with the entire Solid ecosystem and state of the discussion on my side as well. But with my current understanding of WAC and Solid, we seem to move along much faster. I also agree that we want to get to implementation feedback as early as possible, but that the use cases are adequatly filling a bit of that space for now. + +Justin: Absolutely. + +Pavlik: Yes. Another part of my suggestion is not expecting someone else from commenting on your PRs to make progress. + +Matthieu: Yes, you're perfectly right, that has been problematic in the past, I'll try to adjust to make faster progress and focus on important issues and questions during the panel. + +Henry: Adjusting expectations of comments to move along faster sounds good. We'll keep it in check so that it doesn't get out of control. +Let's not lose the benefit of questions and feedback. + +Matthieu: +1 + +### Closing outdated UCR issues + +Justin: +1 + +Henry: I'll follow up on it on GitHub + +### Transfer of issue 191 + +Justin: I might have permission to do it. + +Matthieu: I'll ask Sarven otherwise. + + +## Actions + +* Matthieu to submit UC0 on effective access control resource discovery. +* Matthieu to create issues: + * How does an agent know all the resources it has access to? + * How are required credentials to present to access a resource advertised? + * Using extending access modes instead of to many apply policy predicates in ACP. +* Matthieu to clarify whether WAC's ACLs are private by default. +* Matthieu to point Henry to the extended access control modes issue/proposal and Henry to review it. +* Henry and Matthieu to bootstrap the use case on privacy. +* Henry to follow up on GitHub on outdated issues #87 and #89 +* Matthieu to follow up on transfet of https://github.com/solid/authorization-panel/issues/191 From b93ac5b148938c0f5c75f0ce03072fe343570653 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 16:52:18 +0100 Subject: [PATCH 02/20] Fix date in minutes title --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index c129382d..4936adff 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -1,4 +1,4 @@ -# 2021-07-14 Solid Authorization +# 2021-07-21 Solid Authorization https://meet.jit.si/solid-authorization From 30eca72a04f4e68769fefbc790c08477fd06f765 Mon Sep 17 00:00:00 2001 From: Henry Story Date: Wed, 21 Jul 2021 22:03:58 +0200 Subject: [PATCH 03/20] improve readability here and there. --- meetings/2021-07-21.md | 72 ++++++++++++++++++++++-------------------- 1 file changed, 37 insertions(+), 35 deletions(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index 4936adff..8f54031a 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -25,34 +25,36 @@ https://meet.jit.si/solid-authorization ### ACP UC3 -Henry: I don't think there is a way to build what we're trying to build without allowing global read to ACRs. There has to be some document that tells you how to authenticate. There is a privacy problem with people putting all access control statements in one ACL. But that problem goes away if you are doing it correctly. And there is no other way of doing it that doesn't require inventing a whole new system. This is why it is important to go through those Use Cases. -I don't think we want to go through all Use Cases. They were developped before we went through this process. It might not be coherent to go throuhg them all. +Henry: I don't think there is a way to build Solid without allowing global read to ACRs. There has to be some document that tells you how to authenticate. Now, it is true that there is a privacy problem with people putting all access control statements in one ACL (a problem that the current WAC `:default` behavior leads to) as there is no way then to set access control rules on the rules. But that problem can be made to disappear, as shown in [comment on issue 189](https://github.com/solid/authorization-panel/issues/189#issuecomment-797638239). If the client cannot know what the rules are, it cannot know how to access a resource. This would then be a major missing piece for solid to work at all. If we don't see this as working, we would need to inventing a whole new access control system. + +But we are getting there. This is why it is important to go through those Use Cases. +I don't think we want to go through all Use Cases though, as that will take too much time. They were developed before we went through this process. I don't see that the [latest comment on UC3](https://github.com/solid/authorization-panel/pull/216#discussion_r673945084) is a problem, it is up to Elf to put a proposition forward to deal with credentials requirement discovery. -The default is that you have to read the access control. -This is the only way to do Solid. -That is the right default and what happens if you don't get access? You don't know how to authenticate, therefore, you don't have access. -If you can't access the ACL, you don't know how to authenticate, you're left with guessing which is not acceptable. + +The default is that you have to read the access control. (Henry: I later add some nuance to this: this is not to say that the ACL has to by default have public access - it may be important to explicitly state so) +What happens if you don't get access to the ACL? You don't know how to authenticate: therefore, you don't have access. You would be left with guessing, which is not acceptable for privacy reasons on the client. Matthieu: But it is a security issue to have ACRs readable publicly by default. -Henry: In my view it is going to be the majority of cases. +Henry: It depends how it is done. +It can be done right, and in my view, far from being an exceptional case, it is going to be the majority of cases that do this. -Justin: I think we're inflating a real problem that needs to be solved which is understanding what a given agent has access to with an access control system which should just be understand whether you have access to something or not. But there are other out of band ways to give agents a list of what they have access to. +Justin: I think we're conflating a real problem that needs to be solved: which is understanding what a given agent has access to. An access control system should just be telling us whether you have access to something or not. But there are other out-of-band ways to give agents a list of what they have access to. There aren't patterns to tell an agent what they have access to. I personally don't believe that the best way to deliver that information is through the ACL resources. I'm happy to be proven wrong. I see it as a separate type of flow. -In other areas which aren't SOlid specific but if your control rules are setup (OAuth/Firewalls...). +In other areas which aren't Solid specific but if your control rules are setup (OAuth/Firewalls...). I'm wondering what is the minimum amount that people need to know. We have precedent with WAC-ALLOW in Solid. -But we need to be able to follow your nose through resources would be pretty problematic. Because you don't want to leak stuff you don't want to. +But we need to be able to follow your nose through resources would be pretty problematic. Because you don't want to leak stuff. Matthieu: There are two problems here: 1. how does an agent know all the resources it has access to 2. how does one knows which credentials to present to access a resource -Justin: Absolutely, application workflows are much more richer that access to this or that. Pavlik and I specifically worked on it a lot with the interop work we've been doing. So we might have a more accute feeling for what is required. +Justin: Absolutely, application workflows are much richer than access to this or that. Pavlik and I specifically worked on it a lot with the interop work we've been doing. So we might have a more acute feeling for what is required. -Elf: We have to make a pragmatic approach towards how to approach those UCs. For ACP my understanding is that the access control resource is not accessible unless there is an access control. +Elf: We have to make a pragmatic approach towards how to approach those UCs. For ACP my understanding is that the access control resource is not accessible unless there is an access control rule. Matthieu: It was also my understanding for WAC (not readable by default). Maybe raise one more issue to make it explicit whether WAC resources are accessible by default. @@ -62,29 +64,29 @@ Let's not make it required for this use case. Matthieu: I see here three questions that I would like -Henry: Unless the ACL states that it is publicly readable, it should not be readable. -That is a limitation of WAC currently that doesn't allow just public read to ACLs. +Henry: I need to nuance my previous statement: Unless the ACL states that it is publicly readable, it should not be readable. +That is a limitation of WAC currently that doesn't allow just public read to ACLs. (or even anything other than access to the controller) Matthieu: There is a proposal to extend access control modes including `ControlRead`. -Henry: Link me to it. ACP does something. +Henry: Link me to it. ACP does something like that too. And I had a proposal for [ACRs on ACRs](https://github.com/solid/authorization-panel/issues/189). It would be good to contrast and compare them. -Matthieu: I think I agree and if we were to adopt extended access modes, maybe we wouldn't have to use so many different predicates to apply policies in ACP. +Matthieu: I think I agree. If we were to adopt extended access modes, maybe we wouldn't have to use so many different predicates to apply policies in ACP. Henry: I'll try to review that for next week. -We have a use case for shopping and buying music. It seems that in that case everybody should know the price and clearly that would be an access control rule saying on proof of payment you can download this music. +We have a use case for shopping and buying music. It seems that, in that case, everybody should know the price and that would not create a privacy problem. We could have an access control rule saying that, on proof of payment, you can download this music. Matthieu: You mean that the access control would allow you to infer that in order to read the music, you need to show that you need to pay for something. -Henry: That is the same thing for say being a university member. -Just have the Group Bob and Alice being private but you know you need to be part of the group. +Henry: yes, we even have a use case for that [Conditional Access by Payment](https://solid.github.io/authorization-panel/authorization-ucr/#conditional-payment). That is the same thing for say being a university member. +To get back to our use case: I am happy to just have the resource describing the Group Bob & Alice be private to them. The access control rule can link to the group, but only they know they are part of it. I can make a PR for that. -Matthieu: This sounds like a classic verifiable credential/key based access where you just need to prove what set you pertain to. +Matthieu: This sounds like a classic verifiable credential/key-based access where you just need to prove what set you pertain to. ### PR Workflow -Pavlik: There is a bit of problem on who works on pull requests and who has to approve them. But it's pretty clear that ACP would be Matthieu, WAC Sarven, WAC+ Henry, but it would be good to have 1 person leading the proposal. +Pavlik: There is a bit of a problem regarding who works on pull requests and who has to approve them. But it's pretty clear that ACP would be Matthieu, WAC Sarven, WAC+ Henry, but it would be good to have 1 person leading the proposal. Matthieu: That sounds good, but what do you think would be necessary to make things clearer? @@ -96,21 +98,20 @@ Matthieu: I would prefer keeping a PR per use case. I think the current flow doe Justin: +1 Pavlik's point or the spirit of it. I feel like we needed the specs yesterday and I can't build what I want with the current state of WAC. -We need to optimise our workflow to get to proposal state, we need to get there fast. +We need to optimize our workflow to get the proposal to a finished state; we need to get there fast. The ecosystem needs us to get to a better more robust access control system sooner rather than later. Henry: I agree that WAC got stuck where it was for 5 to 6 years. -At least now, the simple Use Cases help us show the limitations of WAC and get feedback for example from Sarven. +At least now, the simple Use Cases help us show the limitations of WAC and get feedback, e.g. from Sarven. Comparing it to ACP is helping us tweak things a little bit. We write out detail by detail the things and figure out problems as we go along. -We might have a problem with ACP and WAC both to do with copying data and figuring out what the problems and disavantages are and end up with one system. -We're just not putting enough time in it, which is why it's very slow. -I suggest we commit this and continue with new PRs to continue on what we've done. -Matthieu suggested that we've already agreed 2 weeks ago to merge and incrementally improve before you joined. -We have a use case that is dealing with privacy on the WAC side. -Matthieu can do the same and we can ask Sarven how that would be done. -It is a good way to see the advantages. -WAC is very easy to implement which is good at the begining and it's been advertised as a good decentralised access control solution, we need to tackle a few issues so that it meets expectations. +We seem to have for example noticed a problem with ACP and WAC both having to copying data. This allows us to figuring out what the problems and disavantages are of each, how to solve them, and perhaps even end up with one system. +We have not been putting enough time in it, which is why it's very slow. +We had the vacations slowing us down right now, and before that we spent 3 weeks discussing [UMA](https://github.com/solid/authorization-panel/blob/main/meetings/2021-06-09.md). +I suggest we commit this PR and continue with new PRs to continue building on it. +Matthieu reminded me right before Elf and Justin joined, that [two weeks ago](https://github.com/solid/authorization-panel/commit/e0b77c5976056c42ab7018ade0e766c1fec78d0b) we already agreed to merge and incrementally improve the UC3 PR. + +WAC is very easy to implement which is good at the begining. It has been advertised as a good decentralised access control solution, and it is if we tackle a few issues so that it meets expectations. Justin: It is a way and beneficial. But the best way is to have something in the field and get it used in the field. @@ -119,22 +120,23 @@ We need to see value from there. That's an essential part of maturing specs and getting them to completion to have something out there that is close to completion. I wanna ideally try to get there. -Henry: That's what I was doing 5/6 years ago, then it took a long time because something got stuck at MIT. -If you look at this report UC3, then you can see that WAC+ import solves a lot of issues. +Henry: That's what I was doing 7 years ago in a startup I was with. I had built a server and clients . But the startup did not work out. Then it took a long time because something got stuck at MIT. + +If you look at this UC3 PR, then you can see that WAC+ import solves a lot of issues. And it might help solve things on the ACP side too. It helps you avoid copying lots of data around. And answers many questions, such as "If you change the root ACR do changes get effected everywhere else?... Matthieu: I agree with Henry. I think it is problematic that some fundamental issues have not been formulated clearly in the past and that the fact that we're doing it proves that we're doing something right. -Justin: Yes. More than anything, I just want to understand how do we optimise what we have left to do? +Justin: Yes. More than anything, I just want to understand how do we optimize what we have left to do? How do we get back from implementation? Henry: Maybe we need 1 or 1.5 days a week for Matthieu and I to move along. These UC cases are very much like an implementation. It is backed by experience. I agree we need to move faster on this. -Matthieu: I agree with Henry's assessment that we need more time aside mostly. There was also a problem of fluency and getting up to speed with the entire Solid ecosystem and state of the discussion on my side as well. But with my current understanding of WAC and Solid, we seem to move along much faster. I also agree that we want to get to implementation feedback as early as possible, but that the use cases are adequatly filling a bit of that space for now. +Matthieu: I agree with Henry's assessment that we need more time aside mostly. There was also a problem of fluency and getting up to speed with the entire Solid ecosystem and state of the discussion on my side as well. But with my current understanding of WAC and Solid, we seem to move along much faster. I also agree that we want to get to implementation feedback as early as possible, but that the use cases are adequately filling a bit of that space for now. Justin: Absolutely. From b07797d10f0482145d1030a53a0019983e6aaec1 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:00:05 +0100 Subject: [PATCH 04/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index 8f54031a..a8c89c08 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -25,7 +25,7 @@ https://meet.jit.si/solid-authorization ### ACP UC3 -Henry: I don't think there is a way to build Solid without allowing global read to ACRs. There has to be some document that tells you how to authenticate. Now, it is true that there is a privacy problem with people putting all access control statements in one ACL (a problem that the current WAC `:default` behavior leads to) as there is no way then to set access control rules on the rules. But that problem can be made to disappear, as shown in [comment on issue 189](https://github.com/solid/authorization-panel/issues/189#issuecomment-797638239). If the client cannot know what the rules are, it cannot know how to access a resource. This would then be a major missing piece for solid to work at all. If we don't see this as working, we would need to inventing a whole new access control system. +Henry: I don't think there is a way to build Solid without allowing global read to ACRs. There has to be some document that tells you how to authenticate. Now, it is true that there is a privacy problem with people putting all access control statements in one ACL (a problem that the current WAC `:default` behavior leads to) as there is no way then to set access control rules on the rules. But that problem can be made to disappear, as shown in [comment on issue 189](https://github.com/solid/authorization-panel/issues/189#issuecomment-797638239). If the client cannot know what the rules are, it cannot know how to access a resource. This would then be a major missing piece for Solid to work at all. If we don't see this as working, we would need to invent a whole new access control system. But we are getting there. This is why it is important to go through those Use Cases. I don't think we want to go through all Use Cases though, as that will take too much time. They were developed before we went through this process. From 6b556888be4ef0362e06697362c3644475b2e4ae Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:00:43 +0100 Subject: [PATCH 05/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index a8c89c08..47d4a21f 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -31,8 +31,8 @@ But we are getting there. This is why it is important to go through those Use Ca I don't think we want to go through all Use Cases though, as that will take too much time. They were developed before we went through this process. I don't see that the [latest comment on UC3](https://github.com/solid/authorization-panel/pull/216#discussion_r673945084) is a problem, it is up to Elf to put a proposition forward to deal with credentials requirement discovery. -The default is that you have to read the access control. (Henry: I later add some nuance to this: this is not to say that the ACL has to by default have public access - it may be important to explicitly state so) -What happens if you don't get access to the ACL? You don't know how to authenticate: therefore, you don't have access. You would be left with guessing, which is not acceptable for privacy reasons on the client. +The default is that you have to read the access control. (EDIT: I later add some nuance to this; this is not to say that the ACL has to by default have public access — it may be important to explicitly state so) +What happens if you don't get access to the ACL? You don't know how to authenticate; therefore, you don't have access. You would be left with guessing, which is not acceptable for privacy reasons on the client. Matthieu: But it is a security issue to have ACRs readable publicly by default. From 6923aa9b73c4194bbc104a585832b3a767987cf5 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:00:52 +0100 Subject: [PATCH 06/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index 47d4a21f..2307eb10 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -43,7 +43,7 @@ Justin: I think we're conflating a real problem that needs to be solved: which i There aren't patterns to tell an agent what they have access to. I personally don't believe that the best way to deliver that information is through the ACL resources. I'm happy to be proven wrong. I see it as a separate type of flow. -In other areas which aren't Solid specific but if your control rules are setup (OAuth/Firewalls...). +In other areas which aren't Solid specific, but if your control rules are set up (OAuth, Firewalls, ...). I'm wondering what is the minimum amount that people need to know. We have precedent with WAC-ALLOW in Solid. But we need to be able to follow your nose through resources would be pretty problematic. Because you don't want to leak stuff. From d6893402aa5c2d858052026eef382b95412aac5e Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:00:58 +0100 Subject: [PATCH 07/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index 2307eb10..d49c37e3 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -125,7 +125,7 @@ Henry: That's what I was doing 7 years ago in a startup I was with. I had built If you look at this UC3 PR, then you can see that WAC+ import solves a lot of issues. And it might help solve things on the ACP side too. It helps you avoid copying lots of data around. -And answers many questions, such as "If you change the root ACR do changes get effected everywhere else?... +And answers many questions, such as "If you change the root ACR, do changes take effect everywhere else?... Matthieu: I agree with Henry. I think it is problematic that some fundamental issues have not been formulated clearly in the past and that the fact that we're doing it proves that we're doing something right. From 3685c8dbb289f661aaa8f864bcc76b1d86183e29 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:01:04 +0100 Subject: [PATCH 08/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index d49c37e3..0c79556b 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -168,7 +168,7 @@ Matthieu: I'll ask Sarven otherwise. * Matthieu to create issues: * How does an agent know all the resources it has access to? * How are required credentials to present to access a resource advertised? - * Using extending access modes instead of to many apply policy predicates in ACP. + * Using extending access modes instead of too many apply policy predicates in ACP. * Matthieu to clarify whether WAC's ACLs are private by default. * Matthieu to point Henry to the extended access control modes issue/proposal and Henry to review it. * Henry and Matthieu to bootstrap the use case on privacy. From ad4280959ded5c6fba67174a6edf0d6954efef7b Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:01:13 +0100 Subject: [PATCH 09/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index 0c79556b..c5ecbf53 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -173,4 +173,4 @@ Matthieu: I'll ask Sarven otherwise. * Matthieu to point Henry to the extended access control modes issue/proposal and Henry to review it. * Henry and Matthieu to bootstrap the use case on privacy. * Henry to follow up on GitHub on outdated issues #87 and #89 -* Matthieu to follow up on transfet of https://github.com/solid/authorization-panel/issues/191 +* Matthieu to follow up on transfer of https://github.com/solid/authorization-panel/issues/191 From b0306f95d26111a93781c5916e108c8fa4be78cb Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:06:25 +0100 Subject: [PATCH 10/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index c5ecbf53..dccc02c5 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -115,7 +115,7 @@ WAC is very easy to implement which is good at the begining. It has been adverti Justin: It is a way and beneficial. But the best way is to have something in the field and get it used in the field. -We need value from real; "in the field"; implementations and use. +We need value from real, "in the field" implementations and use. We need to see value from there. That's an essential part of maturing specs and getting them to completion to have something out there that is close to completion. I wanna ideally try to get there. From 51546cf00fca3e03b571b9cb5023a9d09c37f24d Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:06:45 +0100 Subject: [PATCH 11/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index dccc02c5..3327e6b8 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -102,7 +102,7 @@ We need to optimize our workflow to get the proposal to a finished state; we nee The ecosystem needs us to get to a better more robust access control system sooner rather than later. Henry: I agree that WAC got stuck where it was for 5 to 6 years. -At least now, the simple Use Cases help us show the limitations of WAC and get feedback, e.g. from Sarven. +At least now, the simple Use Cases help us show the limitations of WAC and get feedback, e.g., from Sarven. Comparing it to ACP is helping us tweak things a little bit. We write out detail by detail the things and figure out problems as we go along. We seem to have for example noticed a problem with ACP and WAC both having to copying data. This allows us to figuring out what the problems and disavantages are of each, how to solve them, and perhaps even end up with one system. From beb868ac705da5cc5784305e017bc36043ab6982 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:06:57 +0100 Subject: [PATCH 12/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index 3327e6b8..d2c43be9 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -39,7 +39,7 @@ Matthieu: But it is a security issue to have ACRs readable publicly by default. Henry: It depends how it is done. It can be done right, and in my view, far from being an exceptional case, it is going to be the majority of cases that do this. -Justin: I think we're conflating a real problem that needs to be solved: which is understanding what a given agent has access to. An access control system should just be telling us whether you have access to something or not. But there are other out-of-band ways to give agents a list of what they have access to. +Justin: I think we're conflating a real problem that needs to be solved, which is understanding what a given agent has access to. An access control system should just be telling us whether you have access to something or not. But there are other out-of-band ways to give agents a list of what they have access to. There aren't patterns to tell an agent what they have access to. I personally don't believe that the best way to deliver that information is through the ACL resources. I'm happy to be proven wrong. I see it as a separate type of flow. From 596147dc2c84c1eddd31898d7e544817248c6dd3 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:07:08 +0100 Subject: [PATCH 13/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index d2c43be9..78082a94 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -29,7 +29,7 @@ Henry: I don't think there is a way to build Solid without allowing global read But we are getting there. This is why it is important to go through those Use Cases. I don't think we want to go through all Use Cases though, as that will take too much time. They were developed before we went through this process. -I don't see that the [latest comment on UC3](https://github.com/solid/authorization-panel/pull/216#discussion_r673945084) is a problem, it is up to Elf to put a proposition forward to deal with credentials requirement discovery. +I don't see that the [latest comment on UC3](https://github.com/solid/authorization-panel/pull/216#discussion_r673945084) is a problem; it is up to Elf to put a proposition forward to deal with credentials requirement discovery. The default is that you have to read the access control. (EDIT: I later add some nuance to this; this is not to say that the ACL has to by default have public access — it may be important to explicitly state so) What happens if you don't get access to the ACL? You don't know how to authenticate; therefore, you don't have access. You would be left with guessing, which is not acceptable for privacy reasons on the client. From 6d65c9312486fa56230e5f0a08fa28d41121d2a6 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:10:16 +0100 Subject: [PATCH 14/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index 78082a94..a76029f2 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -50,7 +50,7 @@ But we need to be able to follow your nose through resources would be pretty pro Matthieu: There are two problems here: 1. how does an agent know all the resources it has access to -2. how does one knows which credentials to present to access a resource +2. how does an agent know which credentials to present to access a resource Justin: Absolutely, application workflows are much richer than access to this or that. Pavlik and I specifically worked on it a lot with the interop work we've been doing. So we might have a more acute feeling for what is required. From 4741730e9c9b97d0a18abfef580cda74ff0dfc5b Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:16:53 +0100 Subject: [PATCH 15/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index a76029f2..538ee51c 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -54,7 +54,7 @@ Matthieu: There are two problems here: Justin: Absolutely, application workflows are much richer than access to this or that. Pavlik and I specifically worked on it a lot with the interop work we've been doing. So we might have a more acute feeling for what is required. -Elf: We have to make a pragmatic approach towards how to approach those UCs. For ACP my understanding is that the access control resource is not accessible unless there is an access control rule. +Elf: We have to make a pragmatic approach towards how to approach those UCs. For ACP, my understanding is that the access control resource is not accessible unless there is an access control rule. Matthieu: It was also my understanding for WAC (not readable by default). Maybe raise one more issue to make it explicit whether WAC resources are accessible by default. From 0c08f8e966473f7ad7a1316dff3bec4ee11fcf6e Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:17:29 +0100 Subject: [PATCH 16/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index 538ee51c..e7d2ac45 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -105,7 +105,7 @@ Henry: I agree that WAC got stuck where it was for 5 to 6 years. At least now, the simple Use Cases help us show the limitations of WAC and get feedback, e.g., from Sarven. Comparing it to ACP is helping us tweak things a little bit. We write out detail by detail the things and figure out problems as we go along. -We seem to have for example noticed a problem with ACP and WAC both having to copying data. This allows us to figuring out what the problems and disavantages are of each, how to solve them, and perhaps even end up with one system. +We seem to have, for example, noticed a problem with ACP and WAC both having to copy data. This allows us to figure out the problems and disadvantages of each, how to solve them, and perhaps even end up with one system. We have not been putting enough time in it, which is why it's very slow. We had the vacations slowing us down right now, and before that we spent 3 weeks discussing [UMA](https://github.com/solid/authorization-panel/blob/main/meetings/2021-06-09.md). I suggest we commit this PR and continue with new PRs to continue building on it. From 70afa90e2560de245328f67dc6ee293003f60fce Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 21 Jul 2021 23:17:40 +0100 Subject: [PATCH 17/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index e7d2ac45..d762bd0b 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -111,7 +111,7 @@ We had the vacations slowing us down right now, and before that we spent 3 weeks I suggest we commit this PR and continue with new PRs to continue building on it. Matthieu reminded me right before Elf and Justin joined, that [two weeks ago](https://github.com/solid/authorization-panel/commit/e0b77c5976056c42ab7018ade0e766c1fec78d0b) we already agreed to merge and incrementally improve the UC3 PR. -WAC is very easy to implement which is good at the begining. It has been advertised as a good decentralised access control solution, and it is if we tackle a few issues so that it meets expectations. +WAC is very easy to implement which is good at the beginning. It has been advertised as a good decentralised access control solution, and it is if we tackle a few issues so that it meets expectations. Justin: It is a way and beneficial. But the best way is to have something in the field and get it used in the field. From 741b4c0ece71c95fb3e5aed90df22489776c7aa8 Mon Sep 17 00:00:00 2001 From: Henry Story Date: Thu, 22 Jul 2021 05:27:52 +0200 Subject: [PATCH 18/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index d762bd0b..2fa14bde 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -167,7 +167,7 @@ Matthieu: I'll ask Sarven otherwise. * Matthieu to submit UC0 on effective access control resource discovery. * Matthieu to create issues: * How does an agent know all the resources it has access to? - * How are required credentials to present to access a resource advertised? + * How can an agent discover which credentials are required to access a resource? * Using extending access modes instead of too many apply policy predicates in ACP. * Matthieu to clarify whether WAC's ACLs are private by default. * Matthieu to point Henry to the extended access control modes issue/proposal and Henry to review it. From b0d59a3c9936236d969001b681e4c466d9e668f9 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Fri, 23 Jul 2021 08:45:01 +0100 Subject: [PATCH 19/20] Update meetings/2021-07-21.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index 2fa14bde..a6f45d75 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -46,7 +46,7 @@ I see it as a separate type of flow. In other areas which aren't Solid specific, but if your control rules are set up (OAuth, Firewalls, ...). I'm wondering what is the minimum amount that people need to know. We have precedent with WAC-ALLOW in Solid. -But we need to be able to follow your nose through resources would be pretty problematic. Because you don't want to leak stuff. +Using a follow your nose mechanism (that is, requiring the dereferencing of access control resources for clients to understand access requirements) would be pretty problematic, because you don't want to potentially leak information that should be private. Matthieu: There are two problems here: 1. how does an agent know all the resources it has access to From 2e0ba353a18a3860655fca9dbb15f395fa8f25b3 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Fri, 23 Jul 2021 08:47:47 +0100 Subject: [PATCH 20/20] Update meetings/2021-07-21.md --- meetings/2021-07-21.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-07-21.md b/meetings/2021-07-21.md index a6f45d75..990808a9 100644 --- a/meetings/2021-07-21.md +++ b/meetings/2021-07-21.md @@ -168,7 +168,7 @@ Matthieu: I'll ask Sarven otherwise. * Matthieu to create issues: * How does an agent know all the resources it has access to? * How can an agent discover which credentials are required to access a resource? - * Using extending access modes instead of too many apply policy predicates in ACP. + * Using extended access modes (control read, control write...) instead of `apply` + `access` predicates in ACP. * Matthieu to clarify whether WAC's ACLs are private by default. * Matthieu to point Henry to the extended access control modes issue/proposal and Henry to review it. * Henry and Matthieu to bootstrap the use case on privacy.