# 2020-08-10 Authentication Panel ## Agenda * Diagram for Flow Section * WWW-Authenicate HTTP Header * [Editorial updates on OIDC Authentication #71](https://github.com/solid/authentication-panel/pull/71) * [Validating the Access Token #50](https://github.com/solid/authentication-panel/issues/50) * [Clarify use of Bearer token #72](https://github.com/solid/authentication-panel/issues/72) * Issues migrated from solid/specification repository * [Next week agenda](https://hackmd.io/kjx89lwRRTq5LAy0TrmnDQ) ## Present * Aaron Coburn * Ricky White * Sarven Capadisli * elf Pavlik * Justin Bingham * Jackson Morgan * Henry Story ## Minutes ### Diagram for Flow Section ![](https://i.imgur.com/U28S7Uc.png) - Ricky: We have no notion of converstaitons between RS and IdP. We can add more details but it seems repetitive to what we find in OIDC. - Pavlik: OIDC specifies that client validates ID Token and does discovery of OP's public keys. - Jackson: I agree. The RS to OP interaction are more solid specific. We also have numbers on diagram, where do we have steps explained. - Ricky: They directly map to Basic Flow section. I see that most people see need to add this RS to OP bit. - Aaron: I think we need to assume in general case that OP and RS are separate entities. I think we need to be careful with leaving possiblity to constraining trust between RS and OP. You can use OIDC discovery, you can manage it via local key stores. - Pavlik: In open ecosystem use case RS should allow user to use any OP they choose. - Aaron: In varoius scenarios I would predict that RS would limite which OP's it trusts. - Jackson: I understand that you want spec to leave room to have different relationsip beween RS and OP. - Aaron: RS can also cache keys etc. We shouldn't overspecify it. - Jackson: Which specification you would see it in scope of? - Aaron: Maybe ecosystem specification. JWT doesn't specify how to get public key. I don't think this spec should not specify how to get public keys neither. - Henry: We were thinking very early on in the history of Solid about wACL rules which described an agent via their OpenID. Eg: ``` [ a wac:acl:Authorization; acl:accessTo <resource1>; acl:mode acl:Read; acl:agent [ foaf:openid <https://jane.org/> ] ``` A resource server would give access to a user if she could prove (Using OpenID 1.0) that she controls that web page. This goes to point out that WebID is not necessary for Solid. And we should keep allowing that. It follows the same reasoning though: an RS needs to get to a discovery document which points it to the Identity Provider. - Pavlik: ... - Aaron: I would argue that in normative language shouldn't specify how to get OP's public key. Client can force RS to download any document if we use OIDC approach. - Jackson: We could specify that RS at any point can reject the flow, but we would define how it is rejected. - Aaron: As long as RS may constrain OPs it trusts I'm happy with it. bblfish: Aaron also suggested that the relaiton to the discovery document be visible. - Henry: So to go with Aarons point, the diagram should show the relation with the Discovery document. - Ricky: Let's try to summarize. - Jackson: To my understanding Aaron needs that we leave ability for RS to reject requests for any reason it wants, including not whitelisted OP. ### WWW-Authenicate HTTP Header - Ricky: I just wanted to check if we had any further discussions on it. - Pavlik: In UMA2.0 RS would include `as` and `ticket` in response to unauthirized request. Which specifies which AS client should interact with to gain access token. - Ricky: Last week we discussed need to specify what WWW-Authenticate response should include. - Jackson: Months ago we relied on WWW-Authenticate to tell difference if client should use new DPoP flow or old PoP with embedded ID Tokens. - ...: Ricky do you suggest that new attributes need to go through IANA. - Ricky: I just want to clarify if we need to specify it. - Aaron: If you need to specify scheme like Bearer or DPoP, it has to be registered, but not other attributes one would want to use. ### [Clarify use of Bearer token #72](https://github.com/solid/authentication-panel/issues/72) - Pavlik: ... - Jackson: I recall that new spec was dealing only with mutli-RS scenario. - Ricky: I don't remember why we ended up adding Bearer to the spec. - Aaron: In my implementaion if access token has `cfn` claim that DPoP is required. In more constrained scenarios Bearer token would be used.