2020-06-08 Authentication Panel

# 2020-06-08 Authentication Panel ## Present * Davi * [Henry Story](https://co-operating.systems/) * Dmitri * Adam * Aaron * Pavlik ## Agenda ### Big Picture Overview - Jackson: We made progress on client constraining access control. - ...: Adam is writing the spec, Inrupt hired him as OIDC expert. - ...: If spec writing takes to much time we may split meeting into two seperate one's - ...: In 2 weeks I will be more of an observer and focus more on shapes. - Pavlik: I see that you act as a chair of the panel, and have been taking care of the voice call. - Jackson: Pavlik would you like to take help with it? - Pavlik: sure, i just need write access to panel repo and a way to solve issues with webex rooms - Jackson: Davi can help you with that. ### Spec Update from Adam - Adam: I and the person who's helping me behind the scenes, Ricky, are writing it. And we are taking a bit of a big bang approach. And I think everyone including me wants to create little pieces at a time, but I struggle with it because it's not much of a document until it's a complete document. So, I'm working on the "MUST only spec." Which is basically a spec that plots a minimum vialbe protocol. It removes much of the choice in coming up with the bear bones of the protocol, then it gorws from there. And it's a function of the fact that we came in cold and we found that to be a consumable way for us to do it. I would like to have it this week. I said to Jackson and Aaron that I wanted to put something up by today. I'm afraid that it will make us prone to bikeshedding if I posted that because there's nothing there. The big bang approach is going to be in the order of 5 pages, but hopefully it will be crisp and clear and will reflect on what Aaron has done in terms of software implementation. - Pavlik: I saw in the minutes from last week that the spec may include some use cases, and I would like to coordinate with that becasue we are starting to put use cases in the interop panel. So, we should coordinate on those use cases. - Adam: We would love to get use cases. And if you have developed use cases from the interop panel. But, I would like to get that to you. We would like to center it around those uses cases, but we don't have a lot to go off of. So, we'd be interested in getting those. - I will post two links: - One for the use cases from this panel: https://github.com/solid/data-interoperability-panel/blob/master/use-cases-and-requirements.bs - And one for the end to end document: https://github.com/solid/data-interoperability-panel/pull/42/files ### ID_VC: Where do they belong? - Adam: ID_VC is a verifiable credentials (claims) ([w3c standard](https://www.w3.org/TR/vc-data-model/)). It's about having those claims represented in a cryptographic way, and a verifiable way. It leans on JSON LD. - ...: The question is where they live. Do they belong in the access token, or do they belong in the ID_Token and the ID Token is extensible by nature. The problem with that, though, is that you don't hand the ID Token over to the RS. So, that means you have to have the stuff in the access token - Dmitri: So you're taking the verifiable credentials out of the id token and putting it in the access token? - Adam: Yeah, I was thinking the client could get them through the ID Token, that seems like a more natural fit. But the client shouldn't be passing the ID token to the RS. - Dmitri: Yeah, that's the current design. - Adam: Yeah, but if they're not always in there, the tokens don't match up. - Dmitri: But the token needs to be reforged for every different RS. - Adam: We said that it would be in the ID Token initially but the client would also return the - Jackson: I think Adam is saying that we have access token, which we can access via id token or access token. - ...: As implemented currently access_token is ... - Adam: Why have that, it's sort of a pointless choice. The access token is returned as the access token. - Henry: I think the answers there gave me enough understanding as to what the questions were about. - Adam: So, the way I interpret it is the way it's been written prior. I interpreted it as the ID VC element of our extended ID Token is a verifiable claim. - Pavlik: I think we shold clarify the thing that we mean by access token. I posted a link on the gitter channel to the draft that Dmitri wrote where the resource server is the same as the identity provider. https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md#bearer-tokens-authorization-bearer-single-rs-use-case. In this case, we don't have a clear notion of an access token. In that there is no clear notion of what an access token is. - Jackson: When I say access token, when you log in you receive 'access token' and 'id token' as in OIDC, they are both signed JWT. Access token contains all the information that RS needs. Right now that access token is identical to ID_VC embedded in 'id token'. - Adam: access token should be considered opaque from perspective of the client - Aaron: This is for the multi rs case. - Adam: And for the MUST spec, the multi-RS case is the main case. - Aaron: Right now there's duplication in the implmementation. There's no reason why they need to be duplicate. We could put additional data in the id token. - Dmitri: You you could just not return the access token. - Adam: I wouldn't want to contemplate a case where you wouldn't interpret one. - Pavlik: I have two things: one is about the audience of that access token. Jackson said it's identical, but the verifiable credential should not have the audient. - ...: Secondly, does the client need to know the constraints put on the client. And we haven't decided what stakes are put on the client, and at some point we need to answer where it comes from. If it comes from the IDP, then the client needs to be able to read that. - Adam: The access token is consumed by the RS and the ID Token is for the client and the access token is opaque to the client. - Jackson: We are considering the multi-RS use case, let's take the single-RS special case out of the picture. DPoP takes care of multi-rs case and it defines the audience. - ...: If user is part of AA, server doesn't need you identity but only AA membership credential. ID_VC is a specific kind of VC where later you can use other VCs. - Adam: id_vc is a access_token use for RS, when you interact with RS it considers your identity. - Aaron: My understanding is that we put all this VC stuff into the ID token becasue we didn't want to define the structure of the access token because all we want to do is say the access token is a signed JOT. At that point we're done with the id_vc. It would be a simpler, more typical scenario. - Henry: I think it's great the the multi-rs use case is deemed as the default. And perhaps that's what leads to this question from Elf. Imagine you have 5 different verifiable claims. Clearly you don't want to send any embarrassing VCs to your mother and have the RS resource server work out which is the right one. So the client needs to be able to work out which is the right crential to use for each resource. So, it can't really be that opaque to the client or whoever makes the decision on this resource. So, your client needs to do this kind of reasoning for you. So it doesn't seem like the thing in the middle can completely be opaque. This can be solved by having something play the role of a keychain in the browser. I developed this in a proposal I called a [LauncherApp](https://github.com/bblfish/LauncherApp/wiki/Where-To%3F). The name comes from attempting to work out how to build this in a browser. - Adam: And that to me is the rub. Because you can't just throw all the claims at the RS. I don't have an answer, I have an idea for this. The conversation starts by a user having access to a resource server. You still have the problem where you give more to any RS. - Elf: if you have client as aud in your access token i think it doesn't conform to https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07#section-4 - Pavlik: I just wanted to mention when we talk about the different claims, you want to look at how Uma 2.0 gathers claims. If we want to have a sophisticated version of claims, we don't want to have the resource server to handle it and possibly instead delegate to AS associated with it as @zenomt proposes. ### Reliance on the OAuth Authorization Code Flow ### Solid Auth Fetcher Update ### ACL Mode addition for Client Constraining Access Control