Add 2023-02-15 agenda and minutes

meetings/2023-02-15.md

@@ -8,6 +8,12 @@
 
 ## Present
 * [Sarven Capadisli](https://csarven.ca/#i)
+* [Virginia Balseiro](https://virginiabalseiro.com/#me)
+* elf Pavlik
+* [Arthur Joppart](https://github.com/belgiannoise)
+* Maxime Lecoq
+* Fellow Jitster
+* James Doe Jr.
 
 ---
 
@@ -29,10 +35,10 @@
 
 
 ### Scribes
-* name
+* Virginia
 
 ### Introductions
-* name: text
+* James: My name is James Doe Jr., and I am a founding engineer of Diaphanous, which is a web3 development company registered in Norfolk, Virginia, United States. TBL fanboy :) excited to see what Solid is all about and how to implement different use cases. 
 
 ---
 
@@ -45,6 +51,28 @@
 
 ### Coordinating further work on authentication and authorization
 * SC: Proposed by eP. See also https://github.com/solid/authorization-panel/issues/325#issuecomment-1427113300
+* eP: Example scenario: https://github.com/solid/notifications/issues/134
+* eP: Last week Matthieu was here and hopefully Aaron will join tomorrow, Wouter will also be interested in this. Notification Panel currently has more clear use cases for AuthZ/AuthN scenarios acting as a client for notification sender and some notification receivers. I now have more experience with OIDC on the server side. We use Inrupt Solid-OIDC client libraries on the server and it's quite problematic. Two main problems: make sure we have a good AuthN approach for server-side client,Solid-OIDC doesn't address properly, and second clarify where AuthN ends and AuthZ starts. We made a mistake trying to separate clearly and have two separate panels because they are heavily intertwined. For example, if we look at Solid-OIDC, we have an OpenID provider that issues an ID token, latest Solid-OIDC doesn't get into access tokens... we use this ID token to get information about end user and the client but for browser applications it works pretty well, it's an app that runs on the device so it cannot securely store secrets. This flow is designed for web apps where user authenticates with OpenID provider which is responsible for issuing tokens and signing them. For server-side clients we don't have the same scenario because they can keep secrets. What Jackson originally proposed is a simpler mechanisms, he added Webhook subscription type. That could be a more general mechanism to pout in other places. I see this part is heavily missing, as Solid-OIDC will not fit for server-side clients. We are relying on OIDC ID tokens tokens... will not work with Inrupt libraries because of problems with refresh tokens and token rotation. So we need a different mechanism for that. From Gitter discussions I see Aaron agrees. We have a strong use cases to have a different approach to AuthN for server-side clients. Re: AuthN/AuthZ being too separated: in practice for server-side clients they should be able to authenticated independent of end user and may be not used by a person directly on the web browser, it can all be automated and the client is not used by a user per se, but on behalf of a user. For that case it'd be convenient that it can authenticate independently of user. And we still need to have a way for the client to say it acts on behalf of a social agent. This part is the AuthZ. I don't think we should strictly focus on AuthN because in that case trying to separate is counterproductive. 
+* ML: Sébastien Rosset has been working on ActivityPods (with ActivityPub) and HTTP Signature in the context of notifications and suggested using proxy and http signature here: https://forum.solidproject.org/t/authentication-with-proxy-and-http-signature/5517. 
+* SC: Good point. https://github.com/solid/notifications/issues/148
+* SC: Had similar thoughts on what we can do to get a server to be able to send a message to another server, where the flow starts with client. Client talks to server, and then server talks to another server. That was the case in the LDN channel type, but it overlaps with the case mentioned by ML, and overlaps with work Henry Story on HTTPSig has been doing. That's just one part when signing these messages. Other part is exchanging the keys. If we can align these patterns and considerations it seems like we're looking at the same direction. 
+* eP: We can discuss details now. HTTP Signatures is a valid direction. Some nuances: we currently work with Solid-OIDC with the assumption that the resource server shouldn't be too complex, and should have its own AuthN server. We leave it to implementation how to handle access tokens. We just specify the ID Token and ways to interact with AuthZ server to push id token in exchange for access token. The complexity can be on AuthZ server and resource server can focus on other things. With HTTP Signatures the Resource Server may need to  ... my main intention is to find a way to move forward and addressing those nuances with these use cases. Jackson proposed something, there are other approaches. In that work we should not separate AuthZ and AuthN. Maybe task force or dedicated meetings, they should be worked on together because they are hand in hand. 
+* SC: Henry raised that concern a while back. Not necessarily coupling, but thinking of the flow together. Let's keep this topic in the agenda for next week, compile a list of issues that touch both. The notification example: seems it's not a panel/notification specific problem, but something that we need to have a better view/design on the whole ecosystem. It's good to raise problem from strictly notification. 
+* eP: We have very clear use cases and implementations. CSS couples OIDC Provider (OP) and the Resource Server. I am using an authorization agent that needs to receive notifications so we have existing codebases with gaps that can give feedback to the spec work. 
+* SC: Do you think the PRotocol spec should be more clean on when to use Solid-OIDC? Because you mentioned it is social agent depends on a person. Whereas other cases (server-server), should we start mentioning these more clearly? Notifications as example: if notification server sends a message to a receiver, it is something we acknowledge for how some notification channels can be. Is that enough to raise it in PRotocol, Solid-OIDC for client-driven stuff, but if you want to do server-driven we don't have it nailed down yet but there is this other spec. Solid-OIDC or WebID-OIDC weren't the only way to authenticate, but only now we are trying to cover these major scenarios. 
+* eP: It'd be beneficial that spec clarifies Solid-OIDC is intended to be used by a user, possibly create an issue for server-side clients, and link to those as ongoing work. We should not only talk about authentication. We still miss similar AuthZ when using Solid-OIDC. We don't have a way for a user to authorize a client to access data. 
+* SC: Henry raised this in issues/discussions. The issued I linked (URL) there is one line: 
+  >Subscription Client lets the Notification Receiver know about the Notification Sender and their public key.
+  >Notification Receiver sets Authorization rules for Notification Sender.
+* SC: We need to allow receiver to add an authorization rule for who will have access to send a message. 
+* eP: That's valid in some cases. [Issue notifications#134](https://github.com/solid/notifications/issues/134). ACME should be able to switch from `sent.ex` to `hermes.ex` to deliver notifications In some cases, it is valid to allow change between services while the channel is active, without breaking it. There's a way to do that if you set policies on the receiver to ACME you can push as a claim a data/access grant, as request is being made you can provide proof that you're authorized. Inrupt does this with access grants, and we have work in progress. We need to clear those issues and define those patterns, probably follow what Inrupt is doing with access grants. This is all about access delegation which has various prior work. We need to find ways to all work together on this.
+* SC: If we can have this topic on the radar people can be aware that it's happening at least on Wed so people can join in. Otherwise we continue as we have been on issues/chat, but I don't find it too active. 
+* eP: Tomorrow we'll have discussion with Jackson. He proposed a different AuthN approach for webhook channel type so we will be able to dive deeper. Hopefully Aaron will join too. 
+
+
+#### Access controls on storage description resource
+URL: https://matrix.to/#/!QxZtVBYQfMeMTnespj:gitter.im/$ut5bwPyKmna0YvctMyB-rgsvpztIp5eXUwujfDaJ2_g
+* SC: ... I agree description resource should be readable. I have a proposal for how it can work, but didn't want to get into it now. 
 
 
 ### Add TR/2022/notifications-protocol-20221231