# Solid Interoperability Panel
September 7th, 2021

## Present

- Hannes R
- Juliette C
- Jamie F
- Justin B
- elf Pavlik

## Agenda

Pull Requests:
- [Application Primer](https://github.com/solid/data-interoperability-panel/pull/170)
- [Migrate to Agent Registry](https://github.com/solid/data-interoperability-panel/pull/169)

Topics:
- Use of Access Inbox
- Patterns for client-side shape tree validation

## Minutes

### [Application Primer](https://github.com/solid/data-interoperability-panel/pull/170)

PAVLIK: Split out application primer from main primer that mostly just houses data snippets. Still need to provide more narrative, but beginning to provide the foundation here. Explains mapping of data grants to data registrations / data instances. Explains inclusion of link headers on update / create.

### [Migrate to Agent Registry](https://github.com/solid/data-interoperability-panel/pull/169)

Justin: I removed hard requirements on UUID, and changed formatting.
I also applied changes from discussion about Agents, Applications and Social Agents.
What was Agent section before is now Social Agent. We have two types of Agents: Social Agents
and Applications. Either one leads to profile document.
Now we have Agent Registry instead of Application Registry.
Both Social Agent and Application have clear definitions.
I changed Agent Registration to Registering Agents, to avoid having heading and subheading
having the same text.
Agent Registry can contain any number of SocialAgentRegistration or ApplicationRegistration

Eric: We should change randomly generated to unpredictable for regitration URIs

Pavlik: I need to make issue about not sharing AA URI across users, so each user would get
dedicated URI of their authorization agent, even if provided by the same service. https://github.com/solid/data-interoperability-panel/issues/171

### Next step, Access Grants and Consents

Justin: Acces Grants and related Data Grants are to be shared with grantee. Consent Grants are kept private by the user giving consent.

Eric and Pavlik: discussing some nuances

Justin: We should be able to drop a lot of text in that step

### Use of the Access Inbox

JC: Looking at curating a joint playlist, and was looking at how we could tell someone that we've shared something with them (e.g. a playlist). Question is how does the inbox work? Is it a public folder anyone can post anything to? What controls are applied to it so you can't just post anything to anyone's pod.

Justin: AccessInbox, separate from global Inbox, is meant to allow validation on the notifications. Only notification conforming to specific shape would be allowed. Currently any authenticated agent can post to that inbox. Of course there is a route for (D)DoS attacks.

JC: I understand one can limit what can be posted to it. I were looking at having a need to connect
to specific person before. Bob offers Alice to share some data with her, she agrees and than Bob can write to her inbox.

Justin: Having agent registry gives a pathway to do that, one can say that Bob and Alice establish relation would be reflected in AgentRegistry.

JC: It sounds very much in discussion space.

Justin: We will learn doing implementation.

Pavlik: Should be solid-wide discussion about security of public inboxes. Agree with direction that JC was proposing. Could advertise dedicated inbox for a given registered agent. Public inbox could be for initial connection request, and then specific inbox could be for direct discussion.

Eric: Is there an equivalent to SPF-like protection for this context?

Justin: Maybe could filter by requiring whoever is posting to public inbox is authenticated, and potentially filter by a list of trusted issuers.

Pavlik: Possibly a dedicated service could provide a public inbox and apply the right spam protections.

Justin: We should explore further as we document sending notifications. If Alice wants to register Bob, or more so if Bob shares something with Alice. How does Alice know if she knows and trusts Bob.

I think establishing the initial connection between Social Agents is critical.

PAVLIK: Should also always be a user consent before they start tracking data received from some agent.

## Action Items