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: br...@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
