Meeting Minutes, OAuth Interim Meeting, 23rd May 2011 ===================================================== Scribe: Bill Mills (post-processing by Hannes Tschofenig) Participants: ** in person ** - Hannes Tschofenig - Jonas Hogberg - Bill Mills - Marius Scurtescu - Andrew Wansley - Breno de Medeiros - Thomas Roessler - Mike Jones - Kihara Boku - Hayashi Tatsuya - Yutaka Oiwa - Harry Halpin - David Recordon - Tony Nadalin - Matthew Sutkus - David Robinson - Skylar Woodward - Chuck Mortimore - Phil Hunt - Dale Olds - Paul Tarjan ** on the conference bridge ** - Lucy Lynch - Brian Campbell - Igor Faynberg - Peter Saint-Andre - Axel Nennker - Karen O'Donoghue - Doug Tangren Agenda: 1. draft-ietf-oauth-v2-16 ------------------------- *** Client Authentication *** Concern that Section 3 and 3.1 do not clearly show a way for a native client to provide client_id (to identify the client only) without doign authentication. Proposed new text, insert in bold: "In addition, the authorization server MAY allow unauthenticated access token requests when the client identity does not matter (e.g. anonymous client), when client authenitcation is not practical, or when the client identity is established via other means." Last paragraph, section 3, proposed new text, reversing the order, putting "since ..." at the end of the sentence: The authorization server MUST require the use of a transport-layer security mechanism when sending requests to exchange an the token endpoint since requests using a method other than client password this authentication method result in the transmission of clear-text credentials. 3.1 edit first paragraph Delete: "(the client identifier together with a shared symmetric secret secret)" *** Error Description *** Agreement among the participants that the error codes are meant for consumption by the developer rather than the end user. Hence, language codes are not important nor a human readable version that is supposed to be understood by end users. Section 4.1.2.1. Error Response -- Character set for error_description becomes "OPTIONAL. Human-readable UTF-8 encoded text providing additional information, used to assist to the developer in understanding the error that occurred." Section 4.1.2.1. Error URI -- "resource owner" becomes "developer" *** Error URIs *** Agreement among the participants that the error codes are meant for consumption by the developer rather than the end user. error_uri OPTIONAL. A URI identifying a human-readable web page with information about the error, used to provide the developer with additional information about the error. *** Error Response Codes *** This is considered a possible area for confusion between the HTTP error code and the error code returned in protocol. The agreement among the participants was to remove all HTTP error codes and to investigate whether there is a need to add new error codes. TODO: Eran H-L to look at which HTTP error codes should be mapped in to protocol specific error codes. Section 4.1.2.1. Error -- remove HTTP 4xx and 5xx error code as an allowed "error" value Section 4.2.2.1. Error Response -- ibid *** Security *** Section 10.10 Session fixation... Breno does not feel that session fixation is properly described nor dealt with. Igor is providing reference links to session fixation description (mail to the list). TODO: Breno@google.com is working on new draft language. Section 10.13. XSRF/CSRF Prevention TODO: Breno and Bill M. working on new draft text. *** Native applications *** Objections that this recommends against things that are extant implementations. TODO: Chuck N. to draft revised text. Discussion on the list: http://www.ietf.org/mail-archive/web/oauth/current/msg06394.html Followed by http://www.ietf.org/mail-archive/web/oauth/current/msg06444.html *** Extensibility *** TODO: Hannes will look at policy for using IETF URN TODO: Mike J./Chuck N. to draft 4.5.1 subsection on assertions. Clarifying the use case there and suggested behavior. Discussion on the list: http://www.ietf.org/mail-archive/web/oauth/current/msg06387.html - Proposed additions - "Immediate Mode" with display= and response= - response_type={none, cookie} TODO: Paul Tarjan to send proposed requirements to the list. TODO: Eran to add extensibilty language for this based on requirements. *** Redirect URI *** Recommendation made that "RedirectURI" should be optional TODO: Eran to send mail to the list proposing language changes to either change this from REQUIRED to OPTIONAL and add clarifying language, or leave as required and add a pre-defined value for "we're not actually using this". Discussion on the list: http://www.ietf.org/mail-archive/web/oauth/current/msg06419.html *** Encoding *** Section 4.3 (and 3.1) Username/Password: Need to figure out what the encoding will be here, since these can be outside the ascii charset. TODO: Peter St.A to review the language. Peter's more complete review is here: http://www.ietf.org/mail-archive/web/oauth/current/msg06520.html *** Client credentials *** TODO: Tony N./Chuck N. to propose new spec to handle assertions both for authentication and authorization. *** Client ID *** Client ID is not specified. Discussion on the list: http://www.ietf.org/mail-archive/web/oauth/current/msg06389.html 2. draft-ietf-oauth-v2-bearer-05 -------------------------------- MIke J. reviewing changes in Draft 5. - 2. Authenticated requests Discussed possible language change and oped for no change. - 400 vs 401 return TODO: Mike Jones to follow up with HTTP WG or representatives and ask whether there are objections. NOTE: Mark Nottingham (in the HTTP community says that either 400 or 401 are acceptible in most cases. - can we move from 403 to 401? Eran's statement is that 403 is sematically correct in HTTP. Probably true. 3. draft-ietf-oauth-v2-http-mac-00 ---------------------------------- Eran ran through the current status. Only significant issue at this time is body hash. Seems to be a thorny issue, he is looking for actual implementer experience. 4. draft-ietf-oauth-saml2-bearer-04 ----------------------------------- Brian Campbell: No recent feedback on the list. Not sure whether that's good or just no attention on SAML.