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