2020-03-02 Solid Authentication Panel

# 2020-03-02 Solid Authentication Panel ## Present * @dmitrizagidulin * @jaxoncreed * @elf-pavlik * ewingson ## Issues ### Decoupling aspects of Trusted App Replacements #### Restrictions model / language - Elf: I think we can separate a few aspects from all the proposals. For example, I don't see using tags as being mutually exclusive from using shapes. We can have a model that uses shapes or tags, or a "secret" that an app needs to know. This part of the proposal is not coupled with the other part that Michael proposes (having a prefix for the auth doc). We may need to have different classes for those capabilities, but they aren't mutually exclusive. #### Presenting capability - Elf: The second part with presenting capabilities, in Michael's proposal, he wanted to use the http link header of the request to access the app's authorization. For me, that's a second aspect that we can consider. How the client presents the capability. #### Verifying that user granted client the capability - Elf: The last one is how it's verified. The user in the webid profile puts a prefix where all the docmuments are published. And the resource server just needs to see if the url of the app authorization document matches that prefix. The prefix of the location needs to be one that the user mentioned in their webid profile. ### Presenting Multiple Credentials - Dmitri: does it make sense to have separate credentials: The identity one and the capabilties one - ...: the main question is do we want the same entity issuing them. - Jackson: If you have OP / IdP issuing credentials, you assume that user fully trusts it. We should consider if we want this assumption. We may want to have 4th party trusted with restricting apps. - Elf: Would we see it in reverse? You might want to 4th party issuing capabilities. The credentials need to be issues on the behalf of the user, so if that would happen do we still need the idp. Because we could just say this capability was issued on the behalf of the user. - Jackson: IdP exists for cases where user don't want to use self-issued one. We may need to use it to authenticate with mentioned 4th party. - Elf: I'd be interested in seeing how this flow would work with the 4th party. It could complicate the flow.- - Need two consent screents etc. - Jackson: WebID profile would advertise that 4th party, client would redirect there after visiting IdP / OP. IdP / OP would only give you credential to authenticate with 4th party, that 4th party would issue credentials to access RS / storage. - ...: I worry that the more things we require the more difficult it becomes to onboard. - ...: CP - Capability Provider, we could recommend to co-deploy it with IdP / OP. - Elf: Why would you use an IDP you don't trust. What's the use case for that? You still have to trust someone, like the Capabilitiy Provider. - ...: Question, I have a question. Once you get a capability from a capability provider, is that sufficient to make a request to the storage. Is there a need for a second credential? - Jackson: In that scenrario credential from IdP/OP would only get used with CP. In both cases I don't necessary need reason why RS / Storage needs to receive mulitple credentials. - Dmitri: The reason for the storage server getting a capabilities token was about expiration and issuing from multiple providers. We're basically talking about wallets. The reason why IDPs are a thing is because wallets are hard and it's hard to manage keys client side. All IDPs are are server side wallets. - Elf: To clarify, would you see self-issued oidc as client side wallet. - Jackson: If we don't trust IdP 100% and don't trust CP 100%... - Dmirtri: It doesn't make sense to me, it means that you don't trust your wallet. - Jackson: User may want to pit IdP and CP agains each other and require credentials from both to access RS - Elf: Sounds bit like two-factor but using similar factors. - Jackson: More as securign agains one of the things getting bridged. - ...: I see it along lines of proposal by ... of ... where he proposes to use multiple IdP and you would need to use tokens from all of them. - ...: I think having IdP / OP to issue capabilities would come convienient. To have higher security one could use that multi IdP approach I've mentioned. - Jackson: I mostly hear those concerns from privacy enthusiasts - Elf: How do you see the expiration time coming into play? - Dmitri: I don't know - Elf: I think capability would be the shorter lived and if we make it required than it would in practice limit the validity period. - ...: You could not give them too long because a user might want to revoke that access. And it should expire reasonably soon, but the identity might not change as much as I want to change the restrictions on the client. - Jackson: If we conside one credential option, to represent capability of client to access resources. Than one would just have shorter expiration on that credential. I see it as question why would you want that longer id credential. - Elf: So, we don't need the separate identity credential. - Jackson: I agree that having two separate credentials feels like an artifact of how we arrived at this solution. ### Revoking Access - Jackson: Traditinal way would rely on short expiration on tokens and having refresh token issued to the client as well. It does mean that when you revoke token you still have that period where client can still use existing access token. - ...: Some OIDC systems rely on RS checking with OP if token is valid. Which works better in centralized systems. For example where IDP and RS share the same DB and don't have HTTP overhead. - Elf: do we talk about token introspection endpoint? - Jackson: For Solid yes we would need to use that for revocation check. - Elf: We could have both and there could be a way for a resource server to decide whether it wants to check the token introspection endpoint, but it doesn't have to if it doesn't want to. We could say it must respect the expiration, but it may perform the introspection. - Jackson: I think i shouldn't be setting on the RS side. I think user should define this policy. - Elf: So, you would think there would be something like a flag in capability credential that says this is a higher security token, so validate with the introspection enpoint. - ...: I think there might be a case to allow the resource controller to put this into an access control rule. - ...: I think we need to think about the tags. Because the tags on the resource and the tags on the client application. We often have the tendancy to assume that the user is the resource controller which isn't always the case. Elf: I will focus today on getting the breakdown of various trusted apps replacements. How should we start working with the simple case of read only capabilities?