*** OAuth Working Group Meeting / IETF 97 *** --- OAuth WG meeting minutes for 9:30-noon 14-Nov-16 in Seoul Hannes gave an OAuth WG status update AMR Values spec sent to the IESG Request by JWS spec sent to the IESG Native apps specification Recently updated to make it more readable Hannes is working on a shepherd update John Bradley said that some minor updates to the Windows Universal Platform language are being done It’s nearly done. People are requested to provide feedback. People are using an SDK embodying this specification that was published by the OpenID Connect working group The spec is a BCP that we can revise as needed Hannes suggested that a tutorial be done on how to use the SDK at the next IETF Hannes reviewed the published meeting agenda OAuth Device Flow specification Hannes described the specification Issue #1 is about polling The AS polls the device for the authorization code Hannes asked whether there are other ways to deal with this or whether polling is fine Aaron Parecki said that polling is simple William Denniss suggested also adding HTTP/2 long-poll as an option Simon Moffatt said that the HTTP stack itself may be too much Torsten Lodderstedt said that the OpenID MODRNA WG is working on similar specs Hannes said that people appear to be happy enough with polling Torsten: MODRNA is using polling for back-channel authentication Also for user consent There is not much implementation experience yet Torsten asked whether there is sufficient implementation experience showing that polling works well enough William Dennis: We run this at large scale. Every YouTube TV app uses this. It works. John Bradley: Roland Hedberg has use cases in which identity proofing is interleaved and responses may be delayed Polling works well if the replies come soon Leif Johansson: We could solve the long-response time situations differently Identity proofing is a longer-lived use case It’s not reasonable to always assume that authentication is quick Hannes asked whether the long-latency authentication use case might not be different than the device flow use case Justin Richer: The long polling use case might just need a different flow Don’t use the device flow in the “three days later” use case John Bradley: I’m OK with that Hannes asked Leif to get together with Roland to describe their use case Hannes: From this discussion, it’s clear that we go ahead with what we have now Issue #2 is about the user interface AS provides user code and verification URI to the user User enters these on a separate device What guidance can be given to improve the user interaction and experience? Dick Hardt asked what the question is and said that Amazon makes a number of devices Hannes got Dick to volunteer to write down some user interface guidance Issue #3 is about alternative contact mechanisms In the current mechanism, the device shows the user info that is entered in another place A possible alternative is for the user to enter a phone number into the device client, which initiates an SMS sending a user code The user enters the user code This could make the experience easier and faster Hannes: Should we document both methods or just the current one? Or should the additional mechanism be documented in a different specification? William Denniss: The protocol is the same so it’s fine to describe this in the same specification John Bradley: There is an additional user hint parameter It is close enough that we should probably describe this in the Device Flow document Mike Jones: Asked whether there is deployment experience with the second method John Bradley: I have seen it in the wild Phil Hunt: Asked whether sending people links spontaneously to click on is training users in bad behaviors Torsten Lodderstedt: Repeated Mike’s question. Said that at the minimum, the security considerations would be different. Hannes will reach out asking for deployment experience for the SMS method If there isn’t deployment experience, we shouldn’t include it OAuth Authorization Server Metadata Hannes started WGLC earlier this year We got a bit stuck on this This led to a new document on Resource Metadata Hannes: In Berlin, there appeared to be consensus to proceed with this work Hannes would like to get feedback on where we are with the work and how we should proceed The AS Metadata document makes the AS configuration information available online in a JSON structure The Resource Metadata document does the same for protected resources Hannes: Should we publish one or both of these or should we do additional security work? Justin Richer: The AS Metadata document is very stable and widely used. We should publish it. Resource Metadata is a different beast. It’s more dynamic. Different kinds of APIs need different kinds of resource discovery There are security considerations and subtle privacy considerations with resource-first discovery We shouldn’t conflate the two Tony Nadalin: I’m not sure the AS metadata document is accurate enough to publish yet We have a multi-tenant system and AS metadata about only a single tenant causes problems Tony is concerned that as we develop resource metadata it might result in changes to the AS metadata John Bradley: This document actually does deal with multi-tenant situations We are not precluding multi-tenant situations I agree with Justin that resource metadata is more complicated, since it relates closely to the protocol using OAuth Being able to describe the characteristics of the AS separately has value even without the resource metadata Other specs can deal with the problems with resource discovery Trying to do it in metadata is the wrong way to do it William Denniss: I see the AS metadata as being valuable. It improves security. There is a fair bit of proven deployment experience William doesn’t have an immediate use for resource metadata Phil Hunt: His concern is that as we automate configuration we make some things better both for the legitimate and for attackers He is concerned that clients could be convinced to use an attacker’s resource proxy Phil said that Mike Jones and he have been talking and working on this The resource metadata makes things better in combination with the AS metadata Phil thinks that the two specs should be combined Phil is frustrated that there isn’t a clear understanding of the problems or the solutions Phil said that Mike legitimately asked whether we are solving a problem that people want to deploy solutions to Phil asked whether there is willpower to solve the problem Hannes asked Phil whether he thought both should move forward Phil said that the most important thing is for people to verify the relationships between the AS and resource Phil and Hannes talked about the proof-of-possession and token binding work being related to this Hannes: People want to start with the simpler problem first and then in a second phase, work on resource metadata Phil: It’s important for the client to understand whether it has a valid set of endpoints and how the client knows that We don’t know whether to express this as metadata or in some other way Torsten: There is a need for automatic configuration to ASs He’s not sure whether there’s such a need for resources The AS metadata is mature and proven. I propose that we move it forward. John Bradley: George Fletcher from AOL says that it’s OK for the client to specify what AS to use It’s OK if the AS doesn’t have a pre-existing relationship with the resource It’s fine as long as the access token is audienced in a way that the token can’t be replayed at a different resource AS metadata is mature and ready for publication Resource metadata is not mature and not ready for publication Brian Campbell and John did a draft allowing the client to tell the AS where it plans to use the token draft-campbell-oauth-resource-indicators This enables the AS to audience restrict the access token to the resource Phil Hunt: We should keep the audience restriction idea on the table Phil asked about combining the documents in response to Hannes formulating questions Hannes said that that’s just a document management issue. Hannes asked these questions: 1. Should we move forward with the AS metadata document as a standalone document? 8 in favor 2. Should we adopt the resource metadata document? 2 in favor 3. Who thinks we should not adopt the resource metadata document 4 against adoption 4. Should we work on a combined AS/RS document? 5 in favor 5. Should we stop work on metadata? 0 in favor William Denniss: I disagree that they go together. We need the AS metadata now. We don’t need the other now. They need not be linked Hannes: Who is deploying the AS metadata specification? The question got interrupted by clarification questions Tony Nadalin: Microsoft uses it but it doesn’t meet our needs because it doesn’t support multi-tenancy John Bradley: Microsoft publishes an AS metadata document per tenant Multi-tenancy is more a discovery issue than a metadata issue Leif Johansson: Salesforce does the same thing – publishing a metadata document per tenant Hannes: I am trying to determine deployment status Phil: You have to have a bootstrap process to determine the AS to use William Dennis: Google has a real need that is solved by the AS metadata spec Torsten: It’s just a URL and you obtain the metadata from it. There’s no magic. It works very well. It helps with mix-up. Hannes asked: 6. Who has deployed or is planning to deploy AS metadata? 9 7. Who has deployed or is planning to deploy resource metadata? 1 Hannes: My sense is that we should proceed with the AS metadata I see people using it already I see people wanting it to progress it as a standalone document For resource metadata, I think additional clarification is needed before we work on it as a working group Kathleen Moriarty (Security Area Director): I agree with these conclusions OAuth 2.0 Token Binding Brian Campbell gave a presentation on the status of Token Binding for OAuth 2.0 and OpenID Connect The current WG draft uses the referred token binding for token binding access tokens Brian talked about how using the referred token binding for access tokens is conceptually the right thing But that there may be practical problems with doing this Brian is concerned about the HTTPSTB text about “explicitly signaling” John Bradley (a TokBind chair): The current HTTPSTB text is focused on the redirect case There are also other use cases supported by token binding We may have to refactor the current text Dick Balfanz (HTTPSTB editor) said that he was OK doing this The privacy principle is that unintended correlations not be created In the OAuth case, it’s the client who should be making this decision Brian asked Dirk if they could work on this text together and Dirk agreed Brian is concerned that using the referred token binding could be cumbersome in some cases For instance, clustered web server clients HTTPSTB has a SHOULD for an eTLD+1 scoping requirement This means that different access tokens would be needed for resources not sharing an eTLD+1 This prevents token replay across resources not sharing an eTLD+1 Torsten asked about the case in which resources share keys Torsten said that they use audienced access tokens – different access tokens are used at different resources John Bradley: Some of this may be platform-specific In general, you’re going to have to indicate which referred token binding to use If you have two different access tokens, you should probably have different keys for them Ben Kaduk: You’re right that if you already use the same access token across sites, they would need to share token binding keys Hannes: I’m concerned that some deployment patterns could lose some of the privacy properties of OAuth Justin Richer: My skepticism of the use of Token Binding for OAuth is that it’s designed for browser cookies OAuth access tokens aren’t browser cookies Clients tend not to think in terms of domains they’re calling – they think in terms of APIs providing functionality We are going to a world that’s more dynamic, which is a really hard nut to crack Justin pointed out that Google uses both google.com and googleapis.com There are up to 5 TLS connections that are involved in some OAuth flows This is a very different world than the browser case It works well for ID Tokens in the implicit flow and refresh tokens at the Token Endpoint But it doesn’t match access token usage Brian: Ideally the client developer isn’t going to have to know about these things If you use the same key, it just works Justin: What problem are we trying to solve? Audience restriction or presentation restriction? Brian: Both Tony Nadalin: I am concerned about the browser situation John Bradley: We still have some questions about _javascript_ in the browser using fetch eTLD+1 is still appropriate for that use case Brian: I am not proposing a change to token binding William Dennis: I agree that access tokens are somewhat tricky The token binding gives us more benefits than it adds in complexity Brian: It makes sense to try to take advantage of what token binding provides Andrei Popov: The tokens should be scoped no broader than the keys are scoped The OAuth token binding specification could live at the same level as the HTTPSTB specification John Bradley: The data structures are defined in the HTTPSTB specification Things building on HTTPSTB makes more sense than repeating most of HTTPSTB in other specifications Torsten: Things can get tricky for access tokens. Refresh tokens could get tricky as well. John: The client being a cluster can make things tricky Torsten: Developers need to consider which access tokens to use at which resources Reusing things all over rightly makes privacy people nervous Is there any deployment experience? Mike Jones: Microsoft internally has deployed something with the same semantics but different syntax Dick Hardt: Wants to enable refresh token to be token bound without requiring access tokens be token bound John: Nothing stops people from doing refresh tokens now, because it doesn’t actually have to be interoperable William Denniss: We see a lot of value in protecting the refresh token. Google is moving forward with that. Dirk Balfanz: We are removing explicit mentions of the key and always using the referred token binding Brian: Where referred is possible, always use referred. Otherwise, use explicit. John: We tried to have only one way to do things for each leg You can provide two different token bindings for different legs – one referred and one provided This is being done in the next document revision Token binding for authorization codes is still TBD Brian asked whether double binding (as described in a doc by Dirk Balfanz before Berlin) is necessary Brian presented a strawman for authorization code token binding It uses PKCE with a code_challenge value that is a hash of the provided token binding ID It uses a new code_challenge_method value The code_verifier is the provided token binding ID Binds the code to the channel between the browser and the client Brian proposed different methods for the native app and browser client cases Some of this was based on the proposal that Dirk wrote prior to Berlin The two methods are appropriate for different kinds of clients Torsten: Asked which is easier to implement John: In OAuth, there is no signed response In OpenID Connect, we can put it in the ID Token, which is signed The second method for browsers avoids having to have a signed response Dirk: The double binding isn’t needed Token Binding Metadata presented The resource metadata now may be in question Talked about phasing in Token Binding and detecting downgrade attacks It’s more subtle than just “supports” – it also includes all participants supporting the same cryptographic algorithms The Boolean metadata values may not be granular enough to actually express all the information needed Support may be dependent upon platform features as well Next steps Resolve conflict with wording in HTTPSTB Add token binding for authorization codes Flesh out or back off metadata and downgrade detection logic Hannes: We should work on getting implementation experience OAuth 2.0 Token Exchange Brian Campbell presented on the current Token Exchange status Relatively minor changes were made last month The want_composite request parameter was removed It’s ultimately up to the AS what to issue Added a short mention of PoP Torsten: The current version is really light-weight What I’m missing is a description of the relationship between audience, resource, and scopes Brian: I’m not sure how to do that Torsten agreed to help Brian with wording Tony Nadalin: We’ve been going through this doc with the developers at Microsoft Tony has asked them to describe their use cases and what is needed for them Their feedback is expected this week The Microsoft developers are having problems mapping the current document to their needs John Bradley: Should we reconstitute the stand-alone resource specification? Hannes: That’s a brilliant idea William Denniss: I agree with Tony. I’d like to get a few implementations done in the next year. It’s valuable to prove it out with some implementations Justin Richer: We will eventually implement this I agree that more implementation experience will be good for this Developers are there and ready to try this out Talked about the relationships between scopes, resources, and audiences Torsten: The use case of being able to indicate the resource is very relevant for every client John: We’re seeing the development of general-purpose APIs This was not initially imagined when OAuth was developed This means that we’ll have scopes used across contexts This is part of OAuth growing up I’m getting questions from customers about why Token Exchange isn’t done yet Torsten: We didn’t move the resource spec forward before because resources without scopes don’t make sense There is implementation experience at Deutsche Telekom with combining resources and scopes John: Torsten is right that people do horrible things creating structured scopes with key-value pairs that aren’t interoperable I suggest adopting the resource document as a starting point to have these more general discussions Hannes: We will discuss the resource indicator topic at our next session on Wednesday We should give it another try --- OAuth WG meeting minutes for 3:20-4:20 16-Nov-16 in Seoul Rich Salz helped Hannes Tschofenig run the meeting as a guest facilitator Brian Campbell discussed the status of Token Exchange Hannes: The consensus during the Monday meeting was to gain more implementation experience before WGLC Hannes asked who is implementing or planning to implement Token Exchange Justin Richer Brian Campbell Mike Jones Dick Hardt Tony Nadalin William Denniss expressed an interest in having Google do so during the previous meeting Torsten Lodderstedt presented about his new draft on security issues revealed by practical OAuth deployments draft-lodderstedt-oauth-security-topics He wants to provide practical guidance to implementers OAuth is used in much more complex and dynamic setups than originally anticipated This is intended to be a working document – not a standard Capture threats and mitigations He plans to refer to other drafts, for instance the mix-up-mitigation draft He plans to have there be a list of things that developers need to do to securely use OAuth Tony Nadalin: We’ve had a lot of discussions at Microsoft lately on the large number of OAuth documents Developers are having problems combining them together and knowing what to implement Tony agrees with what Torsten is trying to do but doesn’t think that it’s enough Torsten: We’re focusing first on documenting the obvious problems We didn’t update the security model when we added dynamic registration, for instance There’s a need to recommend best practices Tony Nadalin: The many OAuth add-ons are not part of an overall architecture For instance, PKCE was just a patch solving a problem we could have avoided up front Ben Kaduk: You should go ahead and do this even without working group adoption Torsten: I want it to record the conclusions of the working group – not just my personal opinions Dick Hardt: Why are we starting on this now? Torsten: Because we understand many of the security best practices now Dick: Why not broaden the scope from security best practices to OAuth best practices? Torsten: Because it would get huge John Bradley: That’s just a document management issue. I support working on best practices. I believe we need to adopt this so that it becomes an RFC so that it is taken seriously by some stakeholders BCPs should be task-oriented For instance, someone doing a single page application may not need to be concerned about Token Exchange Hannes: Doing focused BCPs seems more manageable than trying to do a comprehensive architecture document Torsten: Security practices are cross-cutting Dick: I agree that the security BCP should be all in one place Torsten: We need feedback on which scenarios and flows matter most to people William Denniss: I think it should be a BCP and be an RFC as soon as possible I like the BCP model of being able to snapshot and revise Hannes: Who is in favor of adopting this as a WG document? At least 15 were in favor and no one opposed Kathleen Moriarty: It looks good Hannes: Let’s make OAuth great again Justin Richer presented on the motivations for the HTTP Signing document draft-ietf-oauth-signed-http-request The current spec includes signing, presentation of the token, and a method for protecting the HTTP request OAuth 2.0 doesn’t include HTTP message signing, whereas OAuth 1.0 did Developers often got signing wrong in OAuth 1.0 Justin’s draft is designed for the real world understanding that many things will be changed in transit Therefore, you only sign the things that you know you care about and will be unchanged There are corner cases that the spec does not cover This is all optional The base signature is over the access token plus the nonce/timestamp/transaction-identifier Justin proposes putting the HTTP signing in one document and the base signature description in another The HTTP signing can be experimental This is a detached signature He proposes to move both documents forward together You need a method to present the PoP token to the resource This would be another presentation method parallel to RFC 6750 Justin and a few others have implemented the current approach Ben Kaduk: Do you plan to define discovery? Justin: No. Discovery isn’t defined for OAuth and so this work has taken the same position. Hannes: At the Berlin IETF meeting the feeling was that we didn’t need to do this work anymore Hannes: Who thinks that we should continue this work in this working group? 6 for 3 against Kathleen Moriarty: Take it to the list Dick Hardt: Has anyone deployed this? Justin: Not in large scale John Bradley: Token presentment without having an audience restriction for the token doesn’t buy you much If we’re going to do this work, we should do that too Mike Jones: I’m on record on the mailing list as saying that I don’t think we should be doing this work It’s not clear to me that this is worth our time. We’re doing a lot and this takes time away from other things. I haven’t seen a groundswell of people wanting to deploy this Hannes: Per Kathleen, we need to take it to the list Kathleen: This discussion seems pretty stuck to me John Bradley spoke about the resource indicator specification and other outstanding work There is implementation experience with the resource indicator John plans to do a BCP about single-page (_javascript_) applications Torsten: We should focus on the most relevant BCP Tony Nadalin: Single-page applications are not a major focus within Azure Hannes: I will send a note to the list asking people which BCPs they would like to see John: We also have lingering work for using postMessage to replace fragment encoding postMessage is complicated. It probably requires a lot of guidance Torsten: We should ask people whether this is important to them Mike Jones: The postMessage draft is an individual submission - not a working group document