# 2020-01-13 Authentication Panel

## Present

* Jackson
* Dmitri
* Henry
* Jamie
* @elf-pavlik

## Issues

### Spec Sync-Up
- Dmitri: Spec is still in progress. Had a lot of drama over the holidays. But, I'm back in the saddle and will be making some PRs. So, stay tuned for that?

#### [Proposed Terminology section #35](https://github.com/solid/authentication-panel/pull/35)
- Elf: One of my concerns was around the term "controller document" I think since we have a varient of a common term like "resource controller." I think it would be better to avoid confusion. The controller document may imply that it relates to the person or organization controlling the resource. So, I think controller document should be something different. It could be called an "entity document" or "resource document."
- Dmitri: I agree with your concern. That was the initial proposal. But, I agree that controller may imply things that it doesn't mean to. So, to match the DiD spec, we can call it the identifier document.
- ...: We need a generic term that means WebID or DiD document, the graph containing statements about the subject for the identifier.
- ...: How do we feel about identifier document.
- Elf: That sounds good. What do you think about entity document
- Dmitri: I feel that entity document is broader. Identifier document is more scoped. It's statements about the identity. It contains statements other than the identifier.
- Elf: Next is the term "POD." Pod does not mean openid provider. It's just storage.
- Jackson: TimBL also only considers POD as storage not OP
- Dmitri: We do need a term for the peer node for the solid server that acts as all the nodes?
- Elf: Where in spec do we need to use that?
- Dmitri: That's a good point, so maybe we can get away with using more specific terms.
- Jackson: Sometimes we refer to OP as AS, for example in OAuth.xyz
- Dmitri: UMA 2.0 specs, separate AS from IdP.
- Elf: We should also keep in mind Maichel's proposal for exchanging tokens with the RS. In this case there would be a distinct AS from the OP. I think we may need to disambiguate it. If we say it's the same as the OP, it removes Michael's proposal.

### Generalizable Auth/Discovery Standard (https://github.com/solid/data-interoperability-panel/issues/34)
- Jackson: It tries to solve problem of having different ways of addressing access restrictions. I see common problem that those different approaches try to solve in different ways. Any time we try to address new use case we need to add something new to the spec. My proposal tries to rely on flexible and generic approach. SPARQL Construct seems fit for basing such approach on it. Using it one can construct queries which build subgraphs. On could translate current ACLs to this approach. One could also translate SHACL and ShEx shapes to it. As well as translating tags into those queries. SPARQL is not turing complete but I don't think we even want to use turing complete language.
- Elf: When do you think you would have an example of translating an acl into the query language.
- Jackson: I'll probably have time over the weekend to work on those examples
- Henry: Sounds like a good idea to do it with SPARQL because it's well known. It would be good to have examples. But the idea of using SPARQL. It's like my idea of using OWL. To see what you could do in one vs the other would be an interesting comparison. I think it's definitely better than a simple tagging system.

### What do we want to focus on next meeting?
- Elf: For me, the most interesting topics are how we represent capabilities. How do we make some kind of token that contains capabilities. I think in those two approaches how the client presents those.
- ...: How do we prevent data leakage to the RS to prevent it from knowing capabilities it shouldn't know
- Jackson: I like idea of going after generalized access control approach.
- elf-pavlik: no matter how we express those access rules, we still have to decide on authority (source) of specific sets of rules and how RS gets hold of them to enforce them.

### Rewrite of solid-auth-client

- Jackson: I've discussed it few weeks ago. Current implementation depends on libraries which don't stay actively maintained. New implementation will have well maintained dependencies. It will also have more fleible architecture. Old implementaiton only had legacy implicit flow, new one will work with other flows. One will also be able to reuse code across different environments. Today I will discuss with TimBL how we roll it out. Besides better security it will also have better DX.
- Dmitri: Can you share a link to it?
- Jackson: Code stays private until we release MVP. Most likely under MIT license.
- elf-pavlik: which oauth flows have you already implemented?
- Jackson: We plan AuthCode +PKCE, Device Code, we also will use refresh tokens.