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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth