# Solid Authorization Panel
2021-01-27

## Call
* https://meet.jit.si/solid-authorization

## Present
* Sarven C
* Justin B
* Henry S
* elf Pavlik
* Emmet T
* Matthieu
* Dmitri Z
* Josh C

## Agenda

* Announcements
* Discussing the Feb 17 meeting with Credentials Group
described [in Gitter](https://gitter.im/solid/specification?at=6001ada781c55b09c70d2da8)
* Review Minutes
* See [prior minutes](https://github.com/solid/authorization-panel/pull/159) (2m)
* Pull Requests
* https://github.com/solid/authorization-panel/pull/157 (5-10m perhaps borrowing content from issue/160)
* https://github.com/solid/authorization-panel/pull/152 (5m - status)
* Issues
* [Authorization Capabilities for Linked Data](https://github.com/solid/authorization-panel/issues/160) (0m?)
* Topic Items
* Discuss authorization server vs. resource server (in context of verifiable credentials and capabilities) (5-10m)
* Summary of authorization-related work from interoperability (10m)
* UC Survey ( https://github.com/solid/authorization-panel/blob/master/proposals/wac-ucr/uc-survey.md )

## Minutes

### Presentation to DIF

Schedule: February (date TBD)

JB: What's the focus on the presentation to the W3C DIF group?

Action Item: To put together a presentation (agree on topics, presenters, etc.)

## Issue 160

See especially two things:

The main use case from the video comes from the

<img width="580"
src="https://user-images.githubusercontent.com/876431/105429987-21255f80-5c18-11eb-8b7f-c0b5402f317b.png">

That is it is a statement about who can access what in what mode.
Actually this is what WAC gives us.

But it is meant to be passed around as we can see here:

<img width="580" alt="Passing the credential around" src="https://user-images.githubusercontent.com/124506/105539193-bdbd2f80-5cf4-11eb-9d3e-3fc7518400d0.png">

Actually no protocol passes around the capability, they pass around a "token" and a URL
for the service, ie. they pass around something equivalent to a URL.

And indeed that is what I am proposing too in the protocol presented
Monday, which I copy here for clarity
(note we are missing the request to find the acls/acps)

Client                                Resource              KeyId           Age
App                                   Server                Doc             Credential
|                                        |                    |                |
|-request URL -------------------------->|                    |                |
|<---------- 401 + WWW-Auth Sig header---|                    |                |
|                                        |                    |                |
|--add Cred hdr+sign+keyId-------------->|                    |                |
|                           initial auth |                    |                |
|                           verification |                    |                |
|                                        |                    |                |
|                                        |--GET keyId-------->|                |
|                                        |<-------- keyId doc-|                |
|                                        |                                     |
|                             verify sig |                                     |
|                                        |                                     |
|                                        |--GET credential-------------------->|
|                                        |<-------------------send credential--|
|                                        |
|                       WAC verification |
|                                        |
|<----------------------send content-----|

But the Omni server Guard needs to know who it is going to give access to.
It needs to know a rule on which it can act. The rule
we need for this is something of the form

{ </proj/A/> ldp:contains ?r .
  acme:co :employs ?p } => {
       acme:co :controls {
          [] ldp:accessTo ?r ;
             ldp:mode ldp:Write;
             ldp:agent ?p .
       }
   }

So in short in [issue 160]() we worked out how we can do Capabilities by extending the current ACL system deployed in Solid.

### Authorization Server vs. Resource Server

* Emmet: Thinking how we implmented it currently authorization is pretty much a microservice within the resource server.
...: Last week conversation made me thinking if we should pull out AS into separate service and RS stays sort of dumm and only manages resources. If we did that it feels like spec level thing not neccessarly implementation thing.
* Justin: RS would persist ACP or WAC but the AS would make determinations based on the request.
* Emmet: Possibly AS would store that metadata, RS just needs to know how to talk to AS
* Henry: We only specify link `rel=acl` and client can find out the access control rules, I think it's up to implementation how you do it. The important thing is for there to be a minimum of connections so that authentication can happen efficiently, which is very much needed for Solid, as an App might need to make 20 or more conenctions to different servers. But how the authorization and authentication is done one the server is left completely open. It could be done by a different microservice from that which servers the resource. That seems like a very good way to implement it.
*
* Emmet: You just talked about passing a key, I think we would need to specify it. Solid-OIDC says very little of authorization.
... We could specify protocol level how AS and RS talk to one another.

* JB: Suggest to come back with a sketch of what this exchange could look like betweeen AS / RS and hit in upcoming session

* EP: compares to https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html

### Interop panel update

JB: Work in interop panel stays at a higher level than what we do here. It focuses on ecosystem of different applications using data in various pods. For that you need to make decision what you authorize those apps to do and store that decision. We cover way of expressing access needs and granting them.
JB: When you get access to let's say project, it needs to be well formated as a project.

### Next Agenda Items

* Scribe interrupt protocol - Eric P (3m) - Has conflict
* UC Survey ( https://github.com/solid/authorization-panel/blob/master/proposals/wac-ucr/uc-survey.md )

### Action Items

* GROUP: working out what to present with the Credentials Group