# 2020-08-17 Authentication Panel ## Agenda * self introducing Hannah Short * mechanism for client identification * [Next week agenda](https://hackmd.io/mYu1aCWSRyO_R9uA-7v34w) ## Present * Aaron Coburn * Hannah Short * Jackson Morgan * Sarven Capadisli * elf Pavlik * Emmet Townsend ## Minutes - Hannah: Intro she's from Cern ### Mechanism Client Identification - Aaron: Sometimes we want to restric access to specific applications (clients). There have been various proposals, initial one relied on Origin HTTP header, which is easily spoofable. I discussed it with Adam and Riki, as well as Justin Richer. We found 3 mechanisms, we propose to rely on all those ways. - 1: traditional OIDC. Static/dynamic registration. It allows us to operate with an existing ecosystem. As long as you can generate a webId for a user. But, this means the clientID is effectively anonymous. The RS would not see an identifier in the access token. So the resource server would not allow you to have access to client constrained resources - 2: We define a static, public identifier like an IRI (A solid:publicAgent). This is less secure in a sense because it would allow any redirect_uri to be used. It's an even less strongly identified agent than the first mechanism. It's for clients that are interacting with an IDP that understands how Solid Works. If a client uses this identifier as its client Id, it means a client does not need to go through the static/dynamic registration process. A resource server could explicitly choose to block this client IRI. But, this is more in the Solid frame. But, it also allows you to opt into the system without a whole lot of access. It means the client doesn't need to do the round trip for client registration. An IDP doesn't need to dereference this IRI. - Pavlik: Does each client have it's own IRI? - Aaron: The distinction is the difference between this mechanism and the third mechanism. It allows a client to avoid the additional registration that is unneccissary in the context of Solid. - 3: When an application interacts with an IDP it sends an IRI as the client ID. When the identity provider dereferences the IRI it gets back and RDF document that contains an OIDC registration. The redirect URI must be in that registration. When the IDP creates the access token JWT the client identifier will be contained therein - Jackson: Options 3 sounds like flow from proposal: https://github.com/solid/authorization-panel/blob/master/proposals/TrustedAppsReplacement.md#general-networking-flow - ...: In short AppID Document includes redirect_uri. - Jackson: Davi pointed our relying on DNS and compliant browser. I think since OIDC also relies on that we should have same security model. We could add another option where server side (confidential) clients could have private key. - Pavlik: I think refresh token grant requres sending client_id. - Aaron: I'm not sure if for public clients refresh flow is needed. - Hannah: I remember suggestion from recent OIDC workshop not to get refresh tokens for public clients. - Pavlik: Instead of refresh token flow the client could use assertion flow. - Aaron: The benefit of the second case prevents the client from needing to do static/dynamic - Jackson: It sounds that from ACL point of view only option 3 would allow restricting clients. Do we need option 2 since option 1 already provides for anonymous clients. - Aaron: I see option 2 as bridge between option 1 and 3. I agree that option 2 seems the weakest of those options. - Aaron: In contrast to DPoP where private key is only for a session. Having client to maintain keys published in clients profile document is different timeframe. - Jackson: We had discussion with Davi and Oz about problems with strongly verifying clients. This would only be used for clients with server side componet. This client would serve it's own profile document with public key. Client could even use the same key for DPoP which would allow RS to verify identity of that client. - Aaron: It sounds like a way to strongly identify clients. At the same time it sounds like going further away from OIDC. - Pavlik: - Aaron: In device code flow, the subject of the token is the client identifier not WebID.... Actually I meant the client credentials flow. - Jackson: At this moment device code flow is not used anywhere in solid. - Jackson: Few months ago I remember that Inrupt has requirment for strongly identifiable clients.