From 63e4bab30656f1310ce67e6d9240813c652a8fe2 Mon Sep 17 00:00:00 2001 From: Matthieu Bosquet Date: Wed, 15 Sep 2021 16:17:59 +0100 Subject: [PATCH 1/3] Minutes 2021-09-15 --- meetings/2021-09-15.md | 168 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 168 insertions(+) create mode 100644 meetings/2021-09-15.md diff --git a/meetings/2021-09-15.md b/meetings/2021-09-15.md new file mode 100644 index 00000000..11995246 --- /dev/null +++ b/meetings/2021-09-15.md @@ -0,0 +1,168 @@ +# W3C Solid Community Group: Authorization Panel + +* Date: 2021-09-15T14:00:00Z +* Call: https://meet.jit.si/solid-authorization +* Chat: https://gitter.im/solid/authorization-panel +* Repository: https://github.com/solid/authorization-panel + + +## Present +* [Sarven Capadisli](https://csarven.ca/#i) (SC) +* Matthieu Bosquet (Matthieu) +* [Henry Story](https://bblfish.net/) (Henry) +* Kjetil Kjernsmo (KK) +* elf Pavlik (Pavlik) +* Barath (Barath) + + +## Announcements + +### Contributions +* Join the W3C Solid CG: https://www.w3.org/community/solid/join +* W3C Account Request: http://www.w3.org/accounts/request +* W3C Community Contributor License Agreement: https://www.w3.org/community/about/agreements/cla/ + +### Scribe Selection +* Matthieu Bosquet +* Pavlik + +### Notes and Reminders +* Solid CG will have a session at W3C TPAC CG: https://www.w3.org/wiki/TPAC/2021/GroupMeetings#CG_Group_Meetings_details + +### Introductions +* [name](url): + +--- + +## Topics + +### Previous Minutes +* https://github.com/solid/authorization-panel/pull/254 + +Pavlik: +1 merge + +MB: +1 merge + +HS: +1 merge + + +* https://github.com/solid/authorization-panel/pull/256 + +HS: +1 merge + +Pavlik: +1 merge + +MB: +1 merge + + +### Csarven Fix PR of previous meeting + +HS: Done. + + +### Pavlik create issue proposing GNAP terminology + +* URL: https://github.com/solid/authorization-panel/discussions/259 + +Pavlik: I just did it today. Feedback welcome. + +Henry: I noticed that the really good discussions are difficult to follow without threading. But discussions don't seem to quite adequately notify people of answers. Maybe we need to tag people in those discussion threads. + +Pavlik: If you do watch on a repo, you can set your notifications as you whish. + + +### Henry Propose using WAC to limit wallets to sign requests for apps +* URL: [Use WAC ontology for authorizing authentication](https://github.com/solid/authorization-panel/discussions/258) + +Henry: Last week we were speaking about access control authentication. I just propose here (begining of a thought) to use the access control ontology to describe what an agent/application can access. +If you trust an app for everything, it would have accessToClass rdfs:Resource. +You could also limit it to a Pod... +Essentially authorized authentication. +The signer which could be an OpenID thing or a Wallet or a proxy... +Knows for which resources it can sign. +It works really well to sign HTTP requests. It's an IETF rec. + +Feedback welcome. + +Pavlik: With proof of possession, HTTP signature is one thing. DPoP currently used in Solid OIDC is pretty similar. There is something similar in GNAP as well. + +Henry: Is GNAP using HTTP sig instead of DPoP. + +Pavlik: Yes, it's in the core of GNAP. + +Henry: Interesting. +By the way, I've implemented this in Scala; which should be compilable to Javascript with some effort (HTTPSig). + +Sarven: I would add that if you can consider discussing the state of things related to HTTPSig in the authentication panel, it might really help understand where the HTTPSig thread (as a tech) should be going/fits in the Solid ecosystem. + +Henry: DPoP is one option. As far as this concern; using WAC for authorising authentication might work and I could have something a bit more concrete with the time I will be able to dedicate to client side code next month. +I'll try to present it to the authentication panel then. + +Pavlik: It seems that you're thinking mostly about web browser based usage. What about native mobile apps? As well as clients that run in the cloud not on user's device. + +Henry: Browser is the most wide user base, next to android maybe. +But conceptually it's just a keychain. So there is no reason why not to have that component be part of an operating system. +But there is no good reason not to prototype it because there is no clear cross compatibility path yet. + +Pavlik: I understand that you focus on the browser and don't try to address clients for example running in the cloud not on user's device. + +Henry: It's limited to HTTP. You need two actors: Wallet agent (just like an OPenID connect server but it's in the browser so can do more and is not limited by the speed of light); and an agent that is allowed to describe what an agent is allowed to authorize, should be able to give tokens to access things. +I think using the ontology that way/this use case is more interesting to implement in the web browser. +If you do a request via a proxy, then the proxy can sign your requests, whether it's in the browser or the operating system. +Is everybody clear about the benefits of this? + +Sarven: It would help having a diagram to visualise the components and interactions involved. + +Henry: It makes sense, that's a good idea. + +Sarven: I'm losing some of the meaning because of terminology. + +ACTION: Henry makes a diagram. + +ACTION: Pavlik to link to what we discussed in minutes from discussion + + +### Justin: write up comparison for a use case on modes + +Henry: I don't think this has been done. + +ACTION: No status. Take up next meeting. + + +### Draft specification proposal for ACP +URL: https://github.com/solid/authorization-panel/pull/183 + +Matthieu: I think it's in a good state. Can you see something still needed before we merge it? + +Henry: Can you go over with us? Can we see HTML? + +Matthieu: https://htmlpreview.github.io/?https://github.com/solid/authorization-panel/blob/initial-acp-spec/proposals/acp-specification/index.html#data-model + +I think the Data Model section is really useful to have an overview. + +Pavlik: do you use `acp:access` on ACR or AC? + +Matthieu: On AC. + +Pavlik: I see so if AC uses `acp:access` it applies to ACR, when it uses `acp:apply` it applies to the resource this ACR was created for. + +Matthieu: Correct. +Each resource has one ACR, they have a one-to-one relationship. And an ACR always defines permissions for itself. + +Pavlik: Have you consider different predicate to link ACR to policies which are applied to itself and different to which are applied to the resource? + +Matthieu: Yes. +However this seemed like the best way to avoid duplication of information. + +Pavlik: Why do we need `AccessContrl` and don't link directly to `Policy` from `AccessControlResource`? (still using equivalent of `acp:apply` and `acp:access`) + +Matthieu: If you were to define different predicates on the ACR level, then you could not define a generic, reusable set of permissions for both Resources and their ACRs to be reused. You would need to link to several access controls, some via a "`accessToResource`" predicate another via an "`accessToMyself`" predicate. +Here, since the `AccessControl` is the first reusable unit, you can have a "`defaultAccessControl`" which defines permissions over resources and their ACRs in a generic way. +The two predicates `acp:access` and `acp:apply` are at the level of `AccessControl` just in order to avoid unnecessary duplication of information. +The ACR is really close to the resource and only links to AccessControls that will apply at the level of the resource and on its contained resources. +It's the simplest purpose. +That being said, maybe the predicates `acp:access` and `acp:apply` could be better named, for example, `acp:applyToResource` and `acp:applyToAccessControlResource`; which would be more explicit and less prone to confusion. + +Pavlik: And is the use of `acp:access` & `acp:apply` mutually exclusive? + +Matthieu: No. Access Controls can link to multiple Policies via both predicates. From 9e782ae8825dac867ee2079a51b4b0c6b014ab18 Mon Sep 17 00:00:00 2001 From: Henry Story Date: Tue, 21 Sep 2021 19:20:33 +0200 Subject: [PATCH 2/3] fix typo in previous minutes. Improve 09-15 --- meetings/2021-09-01.md | 2 +- meetings/2021-09-15.md | 122 +++++++++++++++++++++++------------------ 2 files changed, 70 insertions(+), 54 deletions(-) diff --git a/meetings/2021-09-01.md b/meetings/2021-09-01.md index ac4c6669..02ca9875 100644 --- a/meetings/2021-09-01.md +++ b/meetings/2021-09-01.md @@ -1,6 +1,6 @@ # 2021-09-01 Authorization Panel -**https**//meet.jit.si/solid-authorization +https//meet.jit.si/solid-authorization ## Agenda diff --git a/meetings/2021-09-15.md b/meetings/2021-09-15.md index 11995246..281a7efc 100644 --- a/meetings/2021-09-15.md +++ b/meetings/2021-09-15.md @@ -11,7 +11,7 @@ * Matthieu Bosquet (Matthieu) * [Henry Story](https://bblfish.net/) (Henry) * Kjetil Kjernsmo (KK) -* elf Pavlik (Pavlik) +* Elf Pavlik (Pavlik) * Barath (Barath) @@ -39,130 +39,146 @@ ### Previous Minutes * https://github.com/solid/authorization-panel/pull/254 -Pavlik: +1 merge +**Pavlik** +1 merge -MB: +1 merge +**Matthieu** +1 merge -HS: +1 merge +**Henry** +1 merge * https://github.com/solid/authorization-panel/pull/256 -HS: +1 merge +**Henry** +1 merge -Pavlik: +1 merge +**Pavlik** +1 merge -MB: +1 merge +**Matthieu** +1 merge ### Csarven Fix PR of previous meeting -HS: Done. +**Henry** Done. ### Pavlik create issue proposing GNAP terminology * URL: https://github.com/solid/authorization-panel/discussions/259 -Pavlik: I just did it today. Feedback welcome. +**Pavlik** I just did it today. Feedback welcome. -Henry: I noticed that the really good discussions are difficult to follow without threading. But discussions don't seem to quite adequately notify people of answers. Maybe we need to tag people in those discussion threads. +**Henry** I noticed that the really good discussions are difficult to follow without threading. But discussions don't seem to quite adequately notify people of answers. Maybe we need to tag people in those discussion threads. -Pavlik: If you do watch on a repo, you can set your notifications as you whish. +**Pavlik** If you do watch on a repo, you can set your notifications as you whish. ### Henry Propose using WAC to limit wallets to sign requests for apps * URL: [Use WAC ontology for authorizing authentication](https://github.com/solid/authorization-panel/discussions/258) -Henry: Last week we were speaking about access control authentication. I just propose here (begining of a thought) to use the access control ontology to describe what an agent/application can access. -If you trust an app for everything, it would have accessToClass rdfs:Resource. -You could also limit it to a Pod... -Essentially authorized authentication. -The signer which could be an OpenID thing or a Wallet or a proxy... -Knows for which resources it can sign. -It works really well to sign HTTP requests. It's an IETF rec. +**Henry** Last week we were speaking about limiting what Apps can do. +I propose here to use the access control ontology to describe what an agent/application can access. +If you trust an app for everything, it would have + +```Turtle +[] wac:accessToClass rdfs:Resource. +``` + +You could also limit the App to read or write to a Pod, or subsets of resources on a Pod. +Essentially this gives us authorization of authentication. +But this Authorization is not done on the server, rather it is done +by the signer of an HTTP header. +Such a rule could be read by an OpenID provider, a Wallet in the browser +or a proxy on the Server... +By consluting such rules, the wallet can Know which resources it can sign. +It works really well to sign HTTP-Sig requests. Note: HTTP-Sig is based on +Signing HTTP Messages, a IETF REC Worked on by the HTTP WG. Feedback welcome. -Pavlik: With proof of possession, HTTP signature is one thing. DPoP currently used in Solid OIDC is pretty similar. There is something similar in GNAP as well. +**Pavlik** With proof of possession, HTTP signature is one thing. DPoP currently used in Solid OIDC is pretty similar. There is something similar in GNAP as well. -Henry: Is GNAP using HTTP sig instead of DPoP. +**Henry** Is GNAP using HTTP Sig instead of DPoP? -Pavlik: Yes, it's in the core of GNAP. +**Pavlik** Yes, it's in the core of GNAP. -Henry: Interesting. -By the way, I've implemented this in Scala; which should be compilable to Javascript with some effort (HTTPSig). +**Henry** Interesting. +By the way, I've implemented HTTP Sig in Scala; which should be compilable to Javascript with a little effort. -Sarven: I would add that if you can consider discussing the state of things related to HTTPSig in the authentication panel, it might really help understand where the HTTPSig thread (as a tech) should be going/fits in the Solid ecosystem. +**Sarven** +It may be worth discussing the state of things related to HTTPSig in the authentication panel, it might really help understand where the HTTPSig thread (as a tech) should be going/fits in the Solid ecosystem. -Henry: DPoP is one option. As far as this concern; using WAC for authorising authentication might work and I could have something a bit more concrete with the time I will be able to dedicate to client side code next month. -I'll try to present it to the authentication panel then. +**Henry** +I'll try to present it to the authentication panel when I have made a bit more +progress on the implementation which I will be doing in October. +Ising WAC for authorising authentication might work for DPop too. -Pavlik: It seems that you're thinking mostly about web browser based usage. What about native mobile apps? As well as clients that run in the cloud not on user's device. +**Pavlik** It seems that you're thinking mostly about web browser based usage. What about native mobile apps? As well as clients that run in the cloud not on user's device. -Henry: Browser is the most wide user base, next to android maybe. +**Henry** Browser has the widest user base, next to android, maybe. But conceptually it's just a keychain. So there is no reason why not to have that component be part of an operating system. -But there is no good reason not to prototype it because there is no clear cross compatibility path yet. +It is easier to prototype this in the browser where there is a good cross-platform compatibility story. -Pavlik: I understand that you focus on the browser and don't try to address clients for example running in the cloud not on user's device. +**Pavlik** I understand that you focus on the browser and don't try to address clients for example running in the cloud not on user's device. -Henry: It's limited to HTTP. You need two actors: Wallet agent (just like an OPenID connect server but it's in the browser so can do more and is not limited by the speed of light); and an agent that is allowed to describe what an agent is allowed to authorize, should be able to give tokens to access things. +**Henry** It's limited to HTTP. Abstractly we only need two actors: + - a Wallet agent (like an OpenID connect server), but it's in the browser so can do more as it is not pushing against the limits of the speed of light by having to travel around the world + - The App that is requesting access to some resource +The WAC ontology can then be used by the Wallet Agent to describe what the resources an App can access. I think using the ontology that way/this use case is more interesting to implement in the web browser. -If you do a request via a proxy, then the proxy can sign your requests, whether it's in the browser or the operating system. +But the wallet could also be inside an HTTP Proxy on the Solid Pod. That proxy can sign the Apps requests. Is everybody clear about the benefits of this? -Sarven: It would help having a diagram to visualise the components and interactions involved. +**Sarven** It would help having a diagram to visualise the components and interactions involved. -Henry: It makes sense, that's a good idea. +**Henry** It makes sense, that's a good idea. -Sarven: I'm losing some of the meaning because of terminology. +**Sarven** I'm losing some meaning because of terminology. -ACTION: Henry makes a diagram. +**ACTION** Henry to make a diagram. -ACTION: Pavlik to link to what we discussed in minutes from discussion +**ACTION** Pavlik to link to what we discussed in minutes from discussion ### Justin: write up comparison for a use case on modes -Henry: I don't think this has been done. +**Henry** I don't think this has been done. -ACTION: No status. Take up next meeting. +**ACTION** No status. Take up next meeting. ### Draft specification proposal for ACP -URL: https://github.com/solid/authorization-panel/pull/183 +**URL** https://github.com/solid/authorization-panel/pull/183 -Matthieu: I think it's in a good state. Can you see something still needed before we merge it? +**Matthieu** I think it's in a good state. Can you see something still needed before we merge it? -Henry: Can you go over with us? Can we see HTML? +**Henry** Can you go over with us? Can we see the HTML? -Matthieu: https://htmlpreview.github.io/?https://github.com/solid/authorization-panel/blob/initial-acp-spec/proposals/acp-specification/index.html#data-model +**Matthieu** https://htmlpreview.github.io/?https://github.com/solid/authorization-panel/blob/initial-acp-spec/proposals/acp-specification/index.html#data-model I think the Data Model section is really useful to have an overview. -Pavlik: do you use `acp:access` on ACR or AC? +**Pavlik** do you use `acp:access` on ACR or AC? -Matthieu: On AC. +**Matthieu** On AC. -Pavlik: I see so if AC uses `acp:access` it applies to ACR, when it uses `acp:apply` it applies to the resource this ACR was created for. +**Pavlik** I see so if AC uses `acp:access` it applies to ACR, when it uses `acp:apply` it applies to the resource this ACR was created for. -Matthieu: Correct. +**Matthieu** Correct. Each resource has one ACR, they have a one-to-one relationship. And an ACR always defines permissions for itself. -Pavlik: Have you consider different predicate to link ACR to policies which are applied to itself and different to which are applied to the resource? +**Pavlik** Have you consider different predicate to link ACR to policies which are applied to itself and different to which are applied to the resource? -Matthieu: Yes. +**Matthieu** Yes. However this seemed like the best way to avoid duplication of information. -Pavlik: Why do we need `AccessContrl` and don't link directly to `Policy` from `AccessControlResource`? (still using equivalent of `acp:apply` and `acp:access`) +**Pavlik** Why do we need `AccessContrl` and don't link directly to `Policy` from `AccessControlResource`? (still using equivalent of `acp:apply` and `acp:access`) -Matthieu: If you were to define different predicates on the ACR level, then you could not define a generic, reusable set of permissions for both Resources and their ACRs to be reused. You would need to link to several access controls, some via a "`accessToResource`" predicate another via an "`accessToMyself`" predicate. +**Matthieu** If you were to define different predicates on the ACR level, then you could not define a generic, reusable set of permissions for both Resources and their ACRs to be reused. You would need to link to several access controls, some via a "`accessToResource`" predicate another via an "`accessToMyself`" predicate. Here, since the `AccessControl` is the first reusable unit, you can have a "`defaultAccessControl`" which defines permissions over resources and their ACRs in a generic way. The two predicates `acp:access` and `acp:apply` are at the level of `AccessControl` just in order to avoid unnecessary duplication of information. The ACR is really close to the resource and only links to AccessControls that will apply at the level of the resource and on its contained resources. It's the simplest purpose. That being said, maybe the predicates `acp:access` and `acp:apply` could be better named, for example, `acp:applyToResource` and `acp:applyToAccessControlResource`; which would be more explicit and less prone to confusion. -Pavlik: And is the use of `acp:access` & `acp:apply` mutually exclusive? +**Pavlik** And is the use of `acp:access` & `acp:apply` mutually exclusive? -Matthieu: No. Access Controls can link to multiple Policies via both predicates. +**Matthieu** No. Access Controls can link to multiple Policies via both predicates. From af976d3c261c42e473bbc911e4ae2e2e364b09e4 Mon Sep 17 00:00:00 2001 From: Henry Story Date: Thu, 23 Sep 2021 10:44:40 +0200 Subject: [PATCH 3/3] Update meetings/2021-09-15.md Co-authored-by: Ted Thibodeau Jr --- meetings/2021-09-15.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meetings/2021-09-15.md b/meetings/2021-09-15.md index 281a7efc..bcc407b3 100644 --- a/meetings/2021-09-15.md +++ b/meetings/2021-09-15.md @@ -109,7 +109,7 @@ It may be worth discussing the state of things related to HTTPSig in the authent **Henry** I'll try to present it to the authentication panel when I have made a bit more progress on the implementation which I will be doing in October. -Ising WAC for authorising authentication might work for DPop too. +Using WAC for authorising authentication might work for DPop too. **Pavlik** It seems that you're thinking mostly about web browser based usage. What about native mobile apps? As well as clients that run in the cloud not on user's device.