# 2019-12-09 Authentication Panel

## Present

* Jackson
* Elf
* @bblfish
* @dmitrizagidulin

## Issues

### [Accessing NonRDF-Sources directly via browser #31](https://github.com/solid/authentication-panel/issues/31)
- Elf: We have an access controlled HTML page and someone follows a link to access a protected resource.
- Dmitri: Similar for image or document (eg. pdf)
- Henry: We don't have ACL related javascript of the app. Maybe browser extension would work
- Jackson: If you are not authenticated it will pop up a window that you need to authenticate. Currently NSS sets a cookie.
- Dmitri: I was thinking more of case where I access image in Jackson's storage. We don't have any js app or browser extension, so it works well on mobile and does create adopton barier. Here Jackson's storage acts as Relying Party and it receives id_token from OP. Then it creates cookie session with my browser.
- ...: This case fits most the clasic OIDC forkflow.
- Elf: You don't use oauth to access a resource. You use Oauth to authenticate with the storage server. It's not really an oauth resource server at that point, but maybe it's a nuance.
- Henry: From a launcher app viewpoint, there's quite a lot of knowledge that we'd need on the client. In the end this should be done by the browser. The reason it's not is because they'll only do it when we've shown them how to do it correctly. What would be useful is if we would allow the resource server to say 401 and the launcher app would take care of it. But perhaps that's what the oauth redirect does anyway. It would be nice to have a functionality where you can go to a server but you could link it to a launcher app.
- Elf: Can we agree that in this case we only have authentication so that we don't get distracted by that. It's just that we need to authenticate with the solid storage here
- Henry: You mean "client authorization" not "server authorization" which is done by the resource server.
- Elf: This can happen with 0 javascript involved
- Jackson: If you get 401, solid storage server needs to initialze OIDC flow for user to authenticate. Do we need it in the spec?
- Henry: what that 401 page needs to include?
- Jackson: currently it has the 'login' page
- Henry: you can't use it to return content of the ACL, server will not know what to expect from the client.
- Elf: I think we will have the default content type. If you have text/html then return the ui.
- Jacksion: If we want to return ACL, web browser will request text/html as default. If request conneg RDF we can return something else.
- Henry: this sounds like a hack to me. should client having some capabilities have a way to signal it to the server?

- Jackson: Do we need to spec it?
- Dmitri: which part needs to go to the spec?
- Jackson: returning HTML form that allows you to log in.
- Dmitri: not sure if we need to requrie it. solid storage may have different way to initiating OIDC flow
- Elf: I don't think we need to define the ux. But we may need to say it must implment an oidc relying party so also oauth client.
- Henry: I'd agree with Jackson. If the server can't tell whether the client can deal with the authentication and HTML content returned in the 401 body that allows the user to authenticate one way or another should be provided. If the RS understands oauth or openid or webidtls then those are the things that it should clearly allow the user to use. So the RS knows what methods it can deal with.
- Elf: We've had this discussion about calling a multi-resource server. We don't have multi rs here. I think it makes sense to have a mini spec with a webid claim requirement.

### Catch Up Jackson
- Elf: Last week we cancelled. Two weeks ago we talked about HTTP signatures and then the diagrams Jackson posted.

### Dmitri's Work on Normative Spec
- Dmitri: I can summarize some of the issues we've been discussing in previous calls, and we can continue that discussion in individual PRs. All of that stuff is stuff we've seen before.
- Things like how do we communicate the authentication scheme the resource server supports. The header. https://github.com/solid/authentication-panel/issues/4
- We will use the WWW-Authenticate header with comma separated values.
- Changes to the PoP Token Flow https://github.com/solid/authentication-panel/issues/7
- We want to change the proof of posession mechanism to DPoP. What's new is now we use 2 headers: An authorization header and a separate PoPToken header. Instead of reusing the ID Token for the multi RS workflow. We'll request an ID credential inside the ID token. And the access token will be used for backwards compatibility (for when the OP and resource server are the same party).
- Making dynamic registration optional.
- A client can use the redirect uri as their client id and it uses the PoP mechanism to authenticate.
- Elf: I think it would be useful to conside other ways to use the access token that we've talked about before.
- Dmitri: the access token is less of a special case. It's more of a simplified case. It's not audience constained so it can't be use for multi RS
- Dmitri: We were def considering ways of carrying authorization with the access token, so we can discuss that in more detail.
- Jackson: they would need to understand common scopes / authorization details
- Henry: There was a movement to put HTTP signatures into an IETF working group. There was some progress on that. https://lists.w3.org/Archives/Public/ietf-http-wg/2019OctDec/0132.html
- Dmitri: Justin Richer gave a presentation on the different mechanisms and included HTTP signatures. The area maintainer said let's more the HTTP signatures onto an actual track.
- Dmitri: Given how slow the spec works, I don't think it makes sense for us to wait for the spec to finish.
- Dmitri: In the extensibility portion of the spec, I'd like to propose it as one of the PoP mechanisms for the spec.
- Elf: I think we can isolate it and say "Some kind of signature mechansim can be used for clients to prove the key" But it wouldn't matter is we use DPoP or PoP.
- Dmitri: It does matter from the spec perspective because it reduces of increases the implmentation burden.
- Dmitri: In summary, you'll have a chance to offer detailed feedback line by line in specific PRs.

### Sequence Diagrams