On Mar 24, 2011, at 6:36 PM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote:
> >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Chuck Mortimore >> Sent: Monday, March 14, 2011 6:10 PM > >> 1) I'd vote for dropping the following from 1.4.2. In turn I'd discuss >> some of >> the security considerations, such as difficulty of protecting a >> client_secret in >> almost all use-cases of this profile. >> >> "Implicit grants improve the responsiveness and efficiency of some >> clients (such as a client implemented as an in-browser application) >> since it reduces the number of round trips required to obtain an >> access token." > > Why drop it? What about it isn't accurate? It's accurate, but my opinion is it sends the wrong message. It's clearly the less secure of the response types. By positioning it as the most performant people may find that attractive and make the wrong security decision. > >> 2) Section 2.1, we should MUST TLS even for Authorization Code. > > Why? What's the attack vector? See Phils comment on past experience with artifact bindings. Spec should default for security always on, and let deployments that don't want to use HTTPs simply be non-conformant. > >> 3) Section 4.1.3 - not clear to me why redirect_uri is REQUIRED since in >> 4.1.1 >> it's "REQUIRED unless" > > The client should always confirm where the code was sent to. It can omit the > redirection is one was provided but should tell the server where it went to. > This is more consistent on the verification side, but if the original flow > designers want to chime in (Dick, Brian, etc.?), I'm open to change this. > >> 4) Section 4.2.2 - when did we drop refresh_token? I assume this goes >> back to disagreement on how best to handle native clients. I'd prefer it to >> simply reference 5.1 and leave what is issued up to the security profile of >> the >> particular deployment as to what is issued. > > -08 June 2010. > > This has been decided for a long time. I'm not eager to change it. Thanks - I can live with it. Unfortunately we still seem to be fragmenting on the native client approach. Good topic for IIW I suspect -cmort > > EHL > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
