IETF #93 Web Authorization Protocol Working Group Meeting --------------------------------------------------------- Date: Wednesday, July 22, 2015 (CEST) Time: 17:40-19:40 Wednesday Afternoon session III Room: Athens/Barcelona Note taker: Erik Wahlström Intro (Hannes) ——————————— Hannes A bunch of new RFC:s since last IETF meeting! - draft-ietf-oauth-assertions - draft-ietf-oauth-dyn-reg - draft-ietf-oauth-dyn-reg-management Hannes: We got some new errata that we need to look into. Hannes and John will look at them and they will send info to list if action is needed. Hannes: Agenda change to include a presentation about native apps. Token Exchange (Brian) ——————————— Brian: A couple of drafts that have very similar goals, solutions and functions. Phil+Brian: Discussion about the use cases and what an "Edge device" / "Edge Service" is. 2 different drafts as input: - draft-ietf-oauth-token-exchange-02, by Mike Jones & Tony Nadalin - draft-campbell-oauth-sts-02, by Brian Campbell & John Bradley - Should we re-use the token endpoint or should we use a new endpoint? Phil: The /token endpoint can actually be on another server. John: Should we keep the exact format or should we change it? Brian: The question about the token endpoint is related to how the client is authenticated. When the token endpoint is used then prior work in the OAuth group on client authentication can be re-used without any modification. Mike: We can re-use the JWT grant specs. John: If we are using the token endpoint then we should use token end point authentication methods. Hum: Should we re-use the token endpoint? Consensus: Yes - Is the requestor always an OAuth client? Justin: If you are not an OAuth client, what else would you be? So it's always OAuth2 clients! Phil: Clarify in the spec that it's really an OAuth2 client. The Resource Server acts as a client. Hum: Should we call the resource server an OAuth client in this scenario? Consensus: Yes. - Format of Request There are three options: * Primary content of the request is in a JWT that is a request parameter (in Jones draft). * Form request parameters (in Campbell draft). * JSON request body (like RFC 7591 Dynamic Client Registration. Hum: What format should we use for the request? Consensus: Form request parameters (in Campbell draft). - Format of Response Brian discusses the different options for responses. Justin: The response is an access token and hence we should use the existing access token encoding. Mike: There are different scenarios. The token is not intended to be used as an access token. Calling it an access token leads people wrong direction. John: Agreeing with Justin. Tokens should be opaque for the client. Hannes: Agrees with Justin and Brian. Mike: If the access_token is used, then we must add to spec that it's there for historic reasons and say that it's actually not always the same token. Hum: Two options: (a) Use of existing params defined in OAuth. (b) New params. Consensus: For use of existing params defined in OAuth. - Indicating the Target of the Requested Token Campbell draft uses "aud" parameter akin to PoP Key Distribution (draft-ietf-oauth-pop-key-distribution) (currently required but should be optional) Justin: We need an aud parameter because people are using it. Mike: Microsoft oauth2 server have a 'resource' param to indicate the audience. Justin: 'aud' and 'resource' is very equal. Hum: Should we define a generic 'aud' parameter? Consensus: Yes. Hannes: This requires us to strip it out of PoP and from the Token Exchange specs and. Mike Jones: We should call it "resource" because it's already whitely used. Discussion about the exact semantic of the two terms as used today. Agreement that we need to clarify the terminology. - Act-As, On-Behalf-Of Terminology Proposed solution: - Add examples showing how act-as, on-behalf-of are used in practice. - Evaluate specific editorial suggestions on how to make the meanings clearer Other solution: - Use new terminology Mike : There is hard to figure out what is what between the Act-As or On-Behalf-Of. We need to be very clear what they mean in the spec. Mike: Use must be the same as WS-Trust but we must describe them better. Brian: We need one place to put the token. Justin: We need new terminology. Phil: Would prefer new terminology as well. Tony: Terminology is based on Kerberos terminology. William: We need to define what it really means. Matt: We need to go on with out lives. Justin: Pick new terms and descriptions, try them out on spec to see if WG think it's worse or not. Brian: Agree. Conclusions: The editors will pick new terms and descriptions, try them out on spec to see if WG think it's worse or not. - Names for OAuth Token Types No objection to use the proposed mechanism for a default prefix. - Defining actor claim Justin: It starting to look like distribution of policies through out the network. We are loosing opaqueness. Mike: It's just as input for a token request, and it's not opaque by the party that's doing the change. Tony: Agrees with Justin. Mike: we should push this question down to the editors to describe the tokens that is needed to make it work. If we need claims then we take it to the WG. Justin: This is the questions we could ask ourselves: - Do we keep the actor claims as it is in the jones draft. - Do we defer the actor claim to another peace of work? - Do we forget about it and drop it from this draft? Hannes: Who feels comfortable to make a decision to answer the above questions? Conclusion: No one. Editors will continue work on defining and looking into this. - Proof-of-Possession Support skipped Way Forward: Editors will produce new draft incorporating decisions. The editors will together work with a new draft with input from the WG maybe together with Chuck Mortimore. Work will be done rather quickly. Hannes will checkup in a month or two. PoP (Phil, Mike, Hannes) ——————————— Phil: Got feedback from list to pop architecture document about the confused deputy problem. Justin: Will check the text and come with a proposal. Hannes: Add references to the confused deputy problem. Mike presents proof-of-possession key semantics for JWTs and goes through addressed comments from WGLC. Mike: John, Brian, Nat and Hannes should read the diffs. Mike: After the review we are ready to a shepherd write-up. Hannes goes through open issues. We need to decide what to do before the next update. Will schedule conference calls and post suggestions to the list. Request by JWT ver 1.0 for OAuth 2.0 (Nat) ——————————— Nat: Question: Can we just put all the parameters in to JWT? Justin Richter: Yes, we can. Nat: Question: Should we update the OAuth 2.0 RFC to allow the possibility to pass the parameters within a JWT and not to duplicating data? General consensus: Yes. Nat: Question: If REQUIRED parameters were duplicate, should we adopt "Exact Match" or "JWT supersedes query parameters" strategy. Nat will post a question to the list and see what people think. Nat: Question: Better title. Nat will post a question to the list. Sender Constrained JWT for OAuth2 2.0 (Kepeng) ——————————— Not enough people have reviewed it. Mike volunteered to review the document. Hannes: We will ask on the mailing list for further input. OAuth 2.0 Security: OAuth Open Redirector (John) ——————————— Possible recommendations: - Respond with an HTTP 400 ( Bad Request ) status code ( rather than 302) - Perform a redirect to an intermediate URI under the control of the AS to clear referer - The fragment "#_=_" MUST be appended to the error redirect URI . Nat: This is important work. We could do it as even enroll it into the RFC 6749. We need more dialog with the W3C when it comes to open redirects. Native Apps (William) ——————————— Quick go through of the document. Tony: There are reasons why people use web-views. William: I don't agree with them. I want to tell people not to use web views anymore. Tony: We are doing this in Windows. William: That's what we call external browsers - not web views. Several reviewers volunteered to review the new document: - Tony - Brian - Erik - Nat - Eduardo Next Steps (Hannes) ——————————— Hannes: We will talk to our AD, Kathleen, to update the charter and the milestones to do new work in the IETF.