Mike Jones
2016-11-16 08:07:04 UTC
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
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