Web Authorization Protocol (OAuth) ---------------------------------- THURSDAY, July 24, 2014 1520-1720 EDT Manitoba (MM) - Welcome & Agenda Bashing (Chairs, 10min) (includes status update of the current WG documents in IESG processing) Hannes went through the status update slide deck: http://www.ietf.org/proceedings/90/slides/slides-90-oauth-6.pptx - Dynamic Client Registration (Justin, 10min) http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ Justin went through his slide deck http://www.ietf.org/proceedings/90/slides/slides-90-oauth-4.pdf The topic of copyright was raised since text in the dynamic registration draft was copied from OpenID Connect specs and UMA specs. Justin suggested to provide appropriate attribution and Hannes will post a mail to the IETF lawyer to confirm that this is the appropriate approach. Issue "application_type": This parameter is collected by some providers at the registration stage. The challenge today is, however, that the notions of "native" and "web" applications are ill-defined. Justin is in favour of dropping this parameter from the specification. Not clear whether the group is informed enough to decide about dropping the parameter to keeping it in the spec. Discussion about the way forward will have to continue on the mailing list. Issue "client_secret_expires_at": if the server gives you a symmetric secret then the lifetime indicates how long that secret is. The AS can expire your secret at any time anyway. Group decided to leave the client_secret_expires_at parameter in the specification. Issue "redirect URI": required only for re-direct follows (auth code, redirect URI). if you are not using a redirect based flow then the parameter does not make sense. Justin needs to double-check whether those changes have indeed been captured in the document. Issue "Management API": Justin suggested to publish the management API spec as an informational specification. Phil suggested to publish it as an experimental document since informational might still convey a fairly strong message from the group. Hannes suggested to organize a few conference calls to find out what use cases have not been covered yet by other specifications that justify the work on the management API. - Proof-of-Possession Security (Hannes, 15min) http://datatracker.ietf.org/doc/draft-richer-oauth-signed-http-request/ http://datatracker.ietf.org/doc/draft-bradley-oauth-pop-key-distribution/ http://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/ http://datatracker.ietf.org/doc/draft-jones-oauth-proof-of-possession/ Hannes went through his slide deck: http://www.ietf.org/proceedings/90/slides/slides-90-oauth-7.pptx Hannes asked for reviewers and Torsten, John and Reddy Tirumaleswar volunteered. We are still missing the mutual TLS binding, John argues. John volunteered to craft initial text for such a write-up based on the earlier-published HOTK document. Miked pointed to a presentation about TLS channel binding/channel id. Torsten says that he did not see text about how the client sends the digital signature to the resource server. Justin says that this is part of his document and that document is still incomplete. Justin also says that we have zero running code for this part and we need to do some hands-on work! Justin volunteers the MIT kit to host projects. Reddy Tirumaleswar argues that algorithm negotation is not yet provided in the documents. Hannes will have to double-check this. John argues that the discovery spec would answer some of those questions but it has not been worked on. - Token Introspection (Justin, 15min) http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/ Justin went through his presentation slides: http://www.ietf.org/proceedings/90/slides/slides-90-oauth-5.pdf Some discussion about the value of token-by-reference vs. token-by-value. It was also noticed that any considerations regarding proof-of-possession tokens is still missing. Many persons in the room have read the document. The group was in favour for adopting this document as a working group item. - OAuth Symmetric Proof of Possession for Code Extension (Nat, 15min) http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 Nat presented the attack and the solution proposed by the spec: http://www.ietf.org/proceedings/90/slides/slides-90-oauth-0.pptx Currently, the document uses a random number and earlier versions of the specification used a technique that also utilize symmetric cryptography. A number of people have read the document and the group is in strong favour for adopting this document as a working group item. - Providing User Authentication Information to OAuth 2.0 Clients (Mike, 15min) http://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c/ Mike presented the work he co-authors with Tony and Phil: http://www.ietf.org/proceedings/90/slides/slides-90-oauth-1.pdf Mike and Phil argued that not using an access token and only an ID token leads to no reasons to ask for consent. Lucy raised privacy concerns and Torsten confirmed that this is not inline with their understanding at Deutsche Telekom. Torsten: People use OAuth for authentication and they get it wrong. This is an area where we need to provide guidance. A couple of people read the document. Too few people were in favour for adopting this document as a working group item. Hannes suggested to have conference calls to discuss what people get wrong in deploying OAuth for authentication. Lucy and Torsten agreed that this would be a good idea. Kathleen suggested to add information to the Wiki or to the working group page. - OAuth 2.0 Token Exchange (Mike, 15min) http://tools.ietf.org/html/draft-jones-oauth-token-exchange-01 Mike explains the concept of token exchange (=delegation): http://www.ietf.org/proceedings/90/slides/slides-90-oauth-2.pdf Torsten: How is the act as functionality different from the current assertion draft functionality? Mike: This is a generalization of the assertion drafts Torsten: Why aren't we generalizing the assertion drafts? John: Do we want to overload the token endpoint endlessly? Justin: I would like to have a mechanism that allows me to give one access token and to get a new one. Phil and I had submitted drafts about this topic earlier. A couple of people read the document. - Request by JWS ver.1.0 for OAuth 2.0 (Nat, 15min) http://tools.ietf.org/html/draft-sakimura-oauth-requrl-05 Nat presented his document: http://www.ietf.org/proceedings/90/slides/slides-90-oauth-3.pptx A handful of people have read the document. The group is in favour for adopting this document as a working group item. Tony: I am failing to see the use cases. I see the use cases in OpenID Connect. John: Some people want to use OAuth without OpenID Connect and for this work it is useful. Justin: +1 to John. I see value in having a way to protect the requests to the authorization endpoints (which go through the browser). - Summary & Next Steps (Chairs, 10min) Skipped.