Minutes 2021-09-15

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
 

meetings/2021-09-15.md

@@ -0,0 +1,184 @@
+# 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
+
+**Matthieu** +1 merge
+
+**Henry** +1 merge
+
+
+* https://github.com/solid/authorization-panel/pull/256
+
+**Henry** +1 merge
+
+**Pavlik** +1 merge
+
+**Matthieu** +1 merge
+
+
+### Csarven Fix PR of previous meeting
+
+**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.
+
+**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 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.
+
+**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 HTTP Sig in Scala; which should be compilable to Javascript with a little  effort.
+
+**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**
+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.
+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.
+
+**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.
+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.
+
+**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.
+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.
+
+**Henry** It makes sense, that's a good idea.
+
+**Sarven** I'm losing some meaning because of terminology.
+
+**ACTION** Henry to make 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 the 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.