## Resource Server Token Use Cases
- https://github.com/solid/authentication-panel/pull/19
- zenomt: Solid uses PoP Tokens as bearer tokens, neither OP or app itself has standing to issue access tokens, authorizaton server of the resource server should do that.
- Resource token wants to control it's own refresh tokens
- Resource server wants to control the validity period of its access tokens
- A resource server might not want to remember a token for an arbitrarily long amount of time
- The resource server wants to issue its own access token to allow for custom implementations that cater to the server's need
- elf-pavlil: can public client (presenter) running in a browser resuse the same ID Token and PoP Token to exchange it for access token?
- zenomnt: it can reuse ID Token but would have to issue new PoP Token based on new nonce provied by authorization server
- Jackson: was there still a notion that there is a security hole in that the client and the server being in collusion would allow you to mock a token.
- No, that's more of an act of life.

## Resource Server Authentication
- Justin Richer: I had a lot of the same problems with the existing standard. Aproach to a solution was a bit different:
- I had an issue with sending an id_token to another party. That should never happen in Open ID connect. id tokens live for a matter of seconds.
- Took issue with the notion of the client pretending to create its own access token. My approach would use DPoP. The client is able to take that access token and present it to resource servers.
- It's different from the current approach because you're presenting the access token in any structure as long as the RS can properly read it.
- I'm proposing that the access token itself has a specific format and uses webIds to define token issuers.
- The RS looks inside the access token and validates that the token itself is from an access server it trusts.
- Justin Richer: Understand and follow the arguments for why you would have a closely tied auth server to the resource server:
- But the proposed approach doesn't change the security or trust model.
- At any time the client could show up with a new token and present it to get a new token.
- If we're not trusting the server then we shouldn't be issuing access tokens anyway. It's pretty much the same as accepting an access token with more steps.
- As far as performance and validation, that can be very easily handled with validation caches. You agressively cache for a short window and recheck later when you see a presentation of the access token.
- In terms of interop with legacy systems: The idea would be to use a bridge or broker infrastructure. You would have a gateway application do the validation and exchange it with a local legacy auth server.
- Michael: I'd like to see something written up in studyable detail.
- Justin Richer: I've made a detailed write-up. We want to write things down in a more normative structure. That has not been done yet.
- Justin: we can take the write up that Justin referenced as a proposal approach.
- elf-pavlk: how does it work with 'local clients' - just in browser app or native app, 'remote clients' - bot etc. and hybrid cases
- Justin: DPoP addressess it very well... I'm not agains dynamic client registration ...
- zenomt: Dynamic client registration only happens currently between app in the browser and user's OP. In my proposal I also don't require new client registration with resource's server associated authorization server.
- Justin: I had throught that it was going to do a dynamic registration
- Michael: The difference between the solid PoP token scheme is there is a process for getting an access token that is optimal for that resource server and has a cryptographic challenge for the resource server.
- Justin: There's a couple of missing pieces: how does the client auth itself to the downstream authentication server. Also I was assuming it would be done as an OAuth extention point. So you're not talking to an OAuth endpoint?
- Michael: You're talking to a resource server's endpoint that returns something that looks like an OAuth but it's its own proprietary separate protocol.
- elf: In Michael's proposal it would keep the user associated IDP. And I noticed Justin mentioning a client associated authentication server. I didn't get that part
- Justin: What I'm calling Client associated and user associated are the same thing

## HTTP Signatures Initial Proposal
- [Pull Request 20](https://github.com/solid/authentication-panel/pull/20) on initial Http-Signature for Solid Protocol, [best viewed here](https://github.com/solid/authentication-panel/blob/b3f58eb30f40f2a3005e61a9d2de93157038a574/HttpSignature.md).
- This was discussed during the authorization panel last Wednesday, with Elf and Michael present: [meeting notes left on HackMD](https://hackmd.io/bvw37jzHSRiA35TWrKBF3A)
- bblfish: describes HTTP-Signature as
* a version of WebID-TLS without the disadvantages of TLS breaking HTTP boundaries and so better designed for HTTP2.0
* with more support that [WebID-RSA](https://github.com/solid/solid/blob/master/proposals/auth-webid-rsa.md) used in Solid (?), as it has a bigger community of implementors (need to ask Manu Sporny about the current situation).
* Not built into the browser UI as TLS-Client Auth, but with JS Web-Crypto. Still one can build a good client library to make development easier.
- Justin: What is the difference with [OIDC self-issued](https://github.com/solid/authentication-panel/issues/11)? It was designed to hosting OP on your local device which you cary it with you, not accessible with public HTTP
- ...: HTTP Signatures has its own version used by Amazon, I wrote somthing similar for OAuth, draft Henry refers to currently doesn't stay in any active standard group.
- DPoP signatures, HTTP Signatures, xyz etc. have a lot of similarities. Differences come in details, for example signing HTTP has a lot of challenges, many systems can accidentally break signatures.
- zenomt: besides on device cases self-issued also looks promissing for bots, it doesn't require all the discovery files to pretend being OP.