Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minutes from 2021-01-27 #161

Merged
merged 3 commits into from
Feb 3, 2021
Merged

Minutes from 2021-01-27 #161

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
97522af
Minutes from 2021-01-27
justinwb Jan 27, 2021
98978cb
Update 2021-01-27.md
bblfish Jan 27, 2021
3f12742
Update 2021-01-27.md
bblfish Jan 27, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
163 changes: 163 additions & 0 deletions meetings/2021-01-27.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,163 @@
# 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 [video bu Tristan Slominski posted by Elf in issue 160](https://github.com/solid/authorization-panel/issues/160#issuecomment-765035046)
explains capabilties with the following Diagram (see the issue for more context)

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

That is a capability is a statement about who can access what in what mode. It is often presented as just
requiring the holding of the capability, in which case the presenting of the credential is sufficient if the
credential is valid. But in more secure scenarios one also needs to prove that the holder of the credential
really is the subject, and this is done usually by proving ownership of a public key.
This relation of who can access what how, is what the ACL ontology as currently deployed on solid servers allows
us to express.

But instead of being kept on the server as current ACLs are, a capability is meant to be passed around
by clients, as we can see in this slide by Tristan:

<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 in the Authentication Panel, 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-----|
```

Note that in order to be able to decide what to do, 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 use to decide whome to give access.
The rule we need for this is something of the form:

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


In [issue 160](https://github.com/solid/authorization-panel/issues/160#issuecomment-764722858) I looked at
how this ties in with Martin Abadi's work on saying that for decentralised access control.
In short the rule delegates access to `</proj/A>` to Acme employees. It does this by stating that
for a requested resource `?r` by an employee `?p` of Acme, it is the agent `acme:co` that control access.
Controlling access means any statement of the form

```Turtle
[] ldp:accessTo ?r ;
ldp:mode ldp:Write;
ldp:agent ?p .
```

made by Acme is true, i.e. is accepted by the Omni guard as true. This means that if a signed statement of that
form by Acme is linked to in the request so that the Omni guard can retrieve it with a `GET credential`
type statment and verify the signature (see diagram above) then it can be accepted by the Guard.
The `credential` could be on the web somehwere or even in the client (acting as a web server).

This gives roughtly an idea of how one can create a RESTful capability that delegates
control to another agent for a set of resources.

### 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 connections to different servers. But how the authorization and authentication is done on the server is left completely open. It could be done by a different microservice from that which servers the resource. (Indeed 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