Merge pull request #290 from solid/minutes-2022-12-05

Meeting minutes 2022-12-05

Author: elf-pavlik

meetings/2022-12-05.md

@@ -0,0 +1,91 @@
+# 2022-12-05 Solid Interoperability
+
+* Time: 15:00UTC
+* Link: 
+
+## Present
+
+* Wouter Termont
+* Jamie Fiedler
+* elf Pavlik
+* Justin Bingham
+* Ángel Araya
+
+### Regrets
+
+* Laurens Debackere
+
+## Agenda
+
+* [Agent-Specific Discovery](https://github.com/solid/data-interoperability-panel/issues/289)
+* Open PRs
+
+## Scribes
+
+* Pavlik
+* Justin
+
+## Minutes
+
+
+### Agent-Specific Discovery
+
+Issue: https://github.com/solid/data-interoperability-panel/issues/289
+Spec: https://woutermont.github.io/solid/agent-specific-discovery.html
+
+* WT: I wrote it based on arguments I put forward. To better align with different approaches to interop, it might be better to split different aspects into separate specs. This is my first attempt, taking most of the agent registration aspects.
+* ...: Introduction tries to explain why this spec is needed, showing that trial-and-error approach is not feasible. The current draft of the interop spec takes the identity of the client and points to agent registration. This step is a valuable and important piece of the puzzle so we can define it separately.
+* ...: It should be possible to incorporate a resource discovery hub into other services. I gave an example of an OIDC Provider but it should also work with an authorization agent.
+* ...: The idea is that a client who wants to discover a resource discovery hub, dereferences the `id` to get the document. We define link headers and we can fall back to statements in the document. We also define uniqueness of discovery hub to the entity. If you have the discovery hub IRI, the client can call it for specific information. It happens in the same way that agent registration discovery happens in the current SAI spec.
+* ...: The last part is about agent registration, where an agent can request an agent-specific document at the discovery hub.
+* ...: There is a sequence diagram which follows all the steps.
+
+* Pavlik: Question about registration. The way I implemented it — the owner of Authz Agent handles it — the client redirects to the Authz Agent which handles it. So some user interaction is required.
+* WT: Need a way to register agents but don't stipulate the methods to do so. This spec just indicates the possibility. The basic registration proposed in the doc is to illustrate how back and forth could work but leaves implementation open to which type of registration is stipulated.
+* Pavlik: How in practice would you see it with a PR? Extract parts of SAI and then SAI extends more specifically?
+* WT: I tried to mention / use the SAI vocab in here - so parts of SAI that are similar could be left out, and then decide whether to change vocab here to reflect original vocab. Don't think it's necessary to have general _and_ more specific — just make one that's standalone, and in rest of SAI extend with specific implementation of registration procedures
+* Pavlik: Currently in SAI, the Authz Agent handles discovery of Agent Registration. It has logic based on client and end user identities to return the right registration. Would you see this part defined here or in SAI?
+* WT: Could include here, or could be implementation direction
+* Pavlik: Discussing possibility of having a special public agent registration and IRI for public agent (I think ACP does this). If we have something like that — maybe there would be two link headers returned for public and agent specific — or add a special triple to shortcut the hub — because you won't need to request authorization for public agent...
+* WT: If you're a public agent and you act as such — and are registered nowhere — then you could nevertheless pull from the RDH to get the public agent location, or could use a specific triple in the WebID. But using this mechanism you can separate technical stuff from the WebID and leave it open for read/write of profile or whatever else you want to do with it.
+* Pavlik: I wouldn't say the client is acting as a public agent — any agent is always acting as a public agent plus an authorized agent. So you can get agent-specific one plus public one. If you wanted one entry point, it would be useful to always get the public registration as a separate link in a header. Advertising in a WebID document could be seen as a shortcut (nice-to-have). Could also have a different predicate to advertise it. Would still have a structure of agent registration. To create it, you'd still want to use an authorization agent.
+* Pavlik: In general I think it's an interesting approach to extract something but need to see how to recombine it. Definitely worth exploring.
+* Justin: I agree. One of the criticisms is that it is to big, and it has gotten in the way of adoption. Having it more modular and having pieces that can be adopted one at a time. I think part of creating something like this must be pairing with what changes will need to be done in the spec document.
+* ...: The current spec is implemented, so we know it works. if we extract one and update the main document to complement it, we should know that it will still work.
+* ...: I think we still should mention how to use type index or migrate from it. Showing the pathway or a bridge is important.
+* WT: I think so, and this is the main reason I started doing this. The very important question is, what is this Public Agent Registration? Do we envision it as something separate again? Or do we say that this could be a document pointed to by a discovery hub, but is not unimaginable that it would be the WebID itself?
+* Justin: I really appreciate that you wrote this up. We've gotten a lot of feedback and suggestions, but not always follow-up with contributing material.
+* WT: I can prepare PRs with this draft and changes to current spec.
+* Pavlik: We should think how we want to break up the specs and how dependency graph will look.
+* Pavlik: For agent registrations, we have Application and Social Agent; we also discuss Public Agent. 
+* WT: I think this will suffice for near feature.
+* Pavlik: Can you already identify something?
+* Pavlik: I can only imagine some VC based authorization that doesn't rely on the identity of the end user or the client.
+* WT: Yes, as I said, we can have something else in the future; for example, `zaps-ld`.
+* 
+
+### Type indexes
+
+* eP: I'll prepare proposal for next meeting in two weeks, with position on type indexes.
+
+### Clean up smaller issues
+
+> * WT: Let's start next meeting by going through some of the smaller open issues and assigning them. 
+> * ...: The notion of "smaller" is up to the decision of anyone going through the list to select some. I would propose to estimate (1) whether we will be able to reach consensus around it in 5-10min tops, and (2) whether the decided action can be performed in less than an hour.
+> * ...: We can create a label for this, so we can tag them and pull them up easily next meeting.
+
+
+* eP: Would you like to prioritize some issues?
+* WT: Just by looking at the first page of issues, it looked like there are some small among them and we could discuss quickly and take action. If 2 or 3 of us go through the list and label the one that are solvable than we can make progress.
+
+
+
+### Open PRs
+
+Overview: https://github.com/solid/data-interoperability-panel/pulls
+
+#### [Access Needs for Public Resources #254](https://github.com/solid/data-interoperability-panel/pull/254)
+
+> ACTION: LD to rething it for next meeting.
+
+