# 2019-09-23 Solid Authentication Panel

## Present

* @jaxoncreed
* @zenomt
* @elf-pavlik
* @bblfish
* @dmitrizagidulin

## Panel Boundaries
- Elf: May be simpler if we have one panel with two calls
- elf-pavlik: where does the client authentication belong to, either client_id + secret or some assertion based client auth (both client to AS)
- Henry: As long as everyone agrees that the concepts are very close, I am not against them being two panels (it's only if the panels refused discussing overlap that I think they should be merged). But I'm not against merging either.
- Jaxon: same people show up and it might make sense
- Michael: One reason to keep them separate is the expected deliverability date. The Authentication panel is supposed to have something by december.
- Elf: We need to be careful about rushing authentication so we don't do something that will tie our hands with authorization.

## Henry's Proposal

- [Http Signature PR](https://github.com/solid/authentication-panel/pull/20) better looked [at here in one file](https://github.com/bblfish/authentication-panel/blob/master/HttpSignature.md)
- [User Controlled Authorization App and App Launcher proposal](https://github.com/solid/authorization-and-access-control-panel/issues/45)
- Henry: I presented HTTP-Sig a few weeks ago. This lead to some interesting discussion about capabilities vs access control. It could be that HTTP-Sig is more access controll based, but I am not sure (still reading up on the debate)
- Henry: Anyway, the new thing I came up with is a way to control where the keys come from.
- What does HttpSig do: it allows the client to authenticate by sign http headers. It doesn't have to use a WebID identifier, but rather uses a keyId, which is a URL for the key.
- This lead to the question: How does the client get the public/private keys? One option we considered a few weeks ago (and that I implemented a few years ago) was that JavaScript can create a private key locally using JS-Crypto. But the problem is that for any other agent to which the app authenticates, they cannot tell if the key was generated safely or from the JS origin or indeed a friend of the origin. So, how do we guarantee that the key is owned by the user and not the origin?
- Answer: The user's personal Pod can have some javascript that's the "application launcher keychain" for all apps the user likes to use. If you do that you can have many things including a unified access control UI
- The private key can be saved in the browser or on the server. So it can sign headers for other applications for other origins via the window.postMessage method of JS.
- Henry: A user can launch the private key management app, which will launch apps and then signs token requested by those apps with a private key. Perhaps this could deal with OAuth tokens also remaining securely in possession of the user.
- Elf: That sounds like we're talking about client authentication (directly to RS). This concept does not only apply to http signatures.
- Henry: Right I opened a new issue so as to not tie this to HTTP-Sig. But I can best explain it with respect to http signatures as I know that well. But it could be generalizable, to OAuth for example.
- Dmitri: To be clear. OAuth in its threat model talks about having mechanisms for passing the client token around so that's not really a problem we're facing currently. A general purpose signature based authentication panel is going to be useful, but there's a lot of groundwork to do around supporting new key ontologies etc.
- Henry: Yes, there is a lot to do. But we should start by seeing if this could be useful, checking that it could actually work. If the answer is positive we can then give some of the tasks to another group (eg vocabulary group) to build on... The proposal does have some key advantages, such as allow one to create completely RESTful Solid-based authentication system. Does it help with other protocols? Perhaps it's not that interesting to OAuth, ... but it does help the http signature case.
- Elf: What do you think about settling on a direction that the client will always hold a public key. We could use assertion
- elf-pavlik: OAuth Sender Constrained tokens eg. PoP or DPoP
- Jaxon: we always want to outsource key management to some server, User may not want to deal with it.
- Henry: The Launcher App should make it easier for users to manage their keys, and in a way compatible with Solid. Furthermore, it doesn't just give you the keychain piece, but also the App management part. The keychain part is not to be neglected though: this could be a way to have a keychain that works with every browser, in a way that doesn't leak the keys to othe lest trusted apps Origin.
- Elf: I agree that we don't want to make the user manually manage keys. We could use assertion based authentication with the client, but we could
- Jaxon: Please include sequence diagrams for any proposal you want to put out.
- Elf: Henry, have you considered what would take responsibility for a user granting access. Would it be with this keychain app? If the client authenticates directly to the resource server and we don't use an authorization serever, where would that be?
- Henry: The Launcher/keychain app could do that, especially if all connections get proxied through it. There used to be something called [HTTP Foreign fetch](https://developers.google.com/web/updates/2016/09/foreign-fetch) where you could have in your browswer a Service Worker that acts like a Proxy that would fetch remote documents. If that was made available, or if one can find another mechanism such as Web Workers to do that, then one could filter all the requests to a browser based proxy. The App could then prevent the Client Apps from making certain types of requests. Perhaps there is a way to do that just with `postMessage` too. I'd have to look into that.
- Elf: IF that app holds the private key then we cannot assume this app will use the proxy we want, because it could use its own
- Henry: You always trust your keychain App, that's why you place it on your Origin/Freedbom Box. It signs headers/tokens for other apps, but those requests would still have the Origin header to avoid the web browser acting as a confused deputy.
- Essentially the Origin header is the web browsers way of saying not
- `User says PUT ...``
- but the correct `User says $Origin says PUT` (or whatever verb instead of PUT such as PATCH...)
- Jaxon: so you trust you 'keychain app' and all the other apps that you want to delegete just subset of you access, how do they make requests? Do thay always make requests via the 'keychain app'?
- Henry: They ask the keychain app to sign headers via `window.postMessage` (see [StackExchange thread](https://security.stackexchange.com/questions/218608/can-javascript-from-different-origins-communicate-securely)) I'm note sure if we need different frame or just different tab. We need to check postMessage constraints.
- Elf: I think we should try to take the open questions from the minutes and put them in the issues. Whoever asked question and didn't get satisfying answer could preferably follow up in respective issue with more details.
- Henry: Indeed feedback is welcome. I was looking to see if this had been thought before.
- Dmitri: `postMessage` has come up before and has been discussed in Solid before and the result was unsatisfactory. This is definitely not the first time has come up.
- Henry: it would be great to know what the limitations were and why it was unsatisfactory
- elf-pavlik: solid-auth-client uses pop-up window and `postMessage` to authenticated with IdP and pass token to the client.
- Jaxon: yes, true, it can also redirect in the main window as another option.
- Dmitri: redirecting in main window impacts keeping the app state throughout direct. this pop-up window gets served from location configured in the app. Solid auth client embeds default pop-up.
- Jaxon: it only takes the token from pop-up window and uses postMessage to send it to the main window. So that's very different from Henry's suggested use case.
- _Henry Story note after teleconf_: So it looks like what is unsatisfactory about `postMessage` as used was the use case it was implementing.

## DID Discussion
- https://github.com/solid/specification/issues/79
- Jaxon: I would like to clarify if we need MUST or SHOULD with respect to support for DID.
- Jaxon: For every feature we should have at least some kind of fallback with less efficient way of doing the same. If RS receives DID it needs to know how to de-reference it.
- Dmitri: Agreed. If we are to implement it we need to do it as a MUST, which means we also need to specify which DiD methods its going to support. So, it's definitely an issue.
- Henry: I wonder if that's an issue. My rww-Play server would tell the clients which authentication methods it could use in the HTTP headers - specify which authentication methods are allowed.
- Jaxon: Many people who want to use DID don't want to have additional WebID.
- Henry: true, but also we all are going to end up with a lot of identifiers: OAuth, WebId, many credentials...
- Elf: Can we consider a webid as a subset of DiD. We'd say for now the only required method is WebID for the 1.0 spec.
- Jaxon: does DID community have plans to provide downlodable code for de-referencing DIDs ?
- Dmitri: The state of the art at the moment is there are use cases that care about security. And they have secure and verified clients. The more flexible methods rely on universal DiD resolvers: libraries and APIs that support all the DiD method. There are agregator libraries that suppot.
- Henry: is there a document on DID and Solid?
- Dmitri (in channel) https://github.com/solid/identity-panel/issues/1