[OAUTH-WG] Draft OAuth WG meeting minutes for 3:20-4:20 16-Nov-16 in Seoul

[Mike Jones <[e-mail]>]

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