# Solid Authorization Panel March 31st, 2021 https://meet.jit.si/solid-authorization ## Present * Justin B * Matthieu B * Elf Pavlik * Henry Story * Eric P * Sarven C ## Agenda * Announcements * Review Minutes (2m) * [#196 Meeting notes 2021-03-24](https://github.com/solid/authorization-panel/pull/196) * Pull Requests * [#188 Reword URI semantics UCR and fix typos](https://github.com/solid/authorization-panel/pull/188) * [#28 Propose access request with LDN](https://github.com/solid/authorization-panel/pull/28) * [#178 Create wac-acp-diff-story.md](https://github.com/solid/authorization-panel/pull/178) * [#193 Tiny cleanup after #152](https://github.com/solid/authorization-panel/pull/193) * Topic Items ## Minutes ### Last weeks meetings notes * Added to github as PR, need to review? ### Reword URI semantics * Merge ### Create WAC-ACP diff story From last week's discussion * the ShEx Todo: * Move to evaluations * Add AuthorizedAgent to shapes ### Tiny cleanup after #152 * Merge and keep issue alive. ### Access Request with LDN [Linked Data Notifications](https://github.com/solid/authorization-panel/pull/28) Justin: I would like to show how this can be extended for shape trees and capability requests. CSarven: There are two parts: - notification - data format open to discussion extensions. But this is based on making a request for one particular resource. This issue has been shifted around for various places. I'd like to move it to the protocol panel. What is missing here: The LDN spec says you are requesting access to one resource. But the protocol needs to allow one to answer the question: how do you discover the inbox when one gets a 401/403 (which is why it may be part of the protocol) Then the other question is what should the notification look like. Re Activity Streams. Some parts may work well with say Activity Streams. There is a `follow-request` in the Activity space, but not a `request-access`. As to what that shape of looks like is something else. Action item - Setup a dedicated session to go through the access request / response scenarios. Agree on any protocol specifics, as well as composition of the access request / responses themselves Henry: We can agree that we need a link relation to a endpoint where content can be posted to request access. Perhaps we should settle on this. The next is the format of the access, and how a client can discover what types of access format it wants. Elf: Suggests to merge it, and the follow up on it, and fix the document it. CSarven: it should map to the use cases.