Subject: [OAUTH-WG] Draft OAuth WG meeting minutes for 9:30-noon 14-Nov-16 in Seoul

From: Mike Jones <[email-masked]>
Date: Mon, 14 Nov 2016 06:50:39 +0000

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