> -----Original Message----- > From: Chuck Mortimore [mailto:cmortim...@salesforce.com] > Sent: Thursday, March 24, 2011 7:22 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt > > > 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.
It is not less secure if you can't authenticate the client. If the application is running inside the browser, how is any other profile better? It is performing better for browsers and is actually more secure by not sending anything over to the server hosting the static scripts. > >> 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. That does not explain the attack vector... The code is useless unless you have the ability to authenticate the client it was issued for. We have been requiring TLS solely because of secrets confidentiality (bearer token, MAC secret, client secret, etc.). This sounds like a different reason to require TLS, and I'm just trying to understand what it is. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
