2022-12-05 Solid Interoperability

# 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 worte it based on arguments I put forwrad. To better align with different approaches to interop it might be better to split different aspects in 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 try and error approach is not feasible. The current draft of interop spec takes the identity of client and points to agent registration. This step is valuable and important piece of the puzzle so we can define it separatelly. * ...: It should be possible to incorporate resource discovery hub in other services. I gave an example of OIDC Provider but should also work with authorization agent. * ...: The idea is that client who wants to discover resource discovery hub, dereferences the id to get the document. We define link headers and we can fallback 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 current SAI spec. * ...: The last part is about agent registration, where agent can request a 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 is to big, and it has gotten in the way of adoption. Having it more modular and havig pieces that can be adopted one at the time. I think part of creating somthing like this must to be paired with what changes will need to be done in the spec document. * ...: The current spec is imlemented so we know it works, if we extract one and we update the main document to complement it we should know that it will stil work. * ...: I think we still should mention how to use type index or migrate from it. Showing the pathway or a bride is important. * WT: I think so and this is the main reason I started doing this. The quesiton is very importan about 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 by a discovery hub, but is not unimaginable that it would be the webid itself. * Justin: I really appreciate the 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: In near feature I think this will suffice * Pavlik: Can you already identify something? * Pavlik: I can only imagine some VC based authorization that doesn't rely on identiy of the end user or the client. * WT: Yes as I said we can have something in the future, for example zaps-ld * ### Type indexes * eP: I'll prepare proposal for meeting in next 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.