On Wed, Jun 1, 2011 at 12:47 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: >> - ignore the problem and leave the spec vague and insecure. > > Could you please describe what you consider "insecure"?
As an example, optional client authentication in the authorization code flow makes the web server flow much less secure. But it's permitted by the spec. The confusion you mention about how to support native apps is also going to create security problems. You mentioned the risks of auto-approving token requests from native apps. > I think we have the > challenge to defining a secure protocol while supporting the needs of > different client types. +1 to that. > Past versions of the spec entirely focused on client secrets as mechanism to > validate a client's identity. This created the false impression that native > apps either... <snip analysis of the consequences of the spec language and how the security considerations tries to fix the spec> I think your efforts to clear this up in the security considerations are so admirable that they should move into the main body of the spec instead. =) In particular, I think the spec should say that: - native apps always use the authorization code grant - if authorization servers are comfortable issuing client secrets to native apps, they may do so - if authorization servers are not comfortable issuing client secrets to installed apps, they may use a blank or well-known client secret. That would let us simplify the authorization code protocol and the refresh token protocol, since parameters would move from sometimes-they-are-required-sometimes-not to being required. It would also let us have a clear direction to point people who want to support native apps. And it would meet the requirement of having a clear path forward for people who don't want to trust native apps to keep secrets really secret. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
