New text (moved the first half from sub section 3.2 to 3):
In addition, the authorization server MAY allow unauthenticated access
token requests
when the client identity does not matter (e.g. anonymous client) or
when the client
identity is established via other means. For readability purposes only,
this specification
is written under the assumption that the authorization server requires
some form of client
authentication. However, such language does not affect the
authorization server's discretion
in allowing unauthenticated client requests.
EHL
> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Torsten Lodderstedt
> Sent: Saturday, February 26, 2011 5:03 AM
> To: OAuth WG
> Subject: [OAUTH-WG] Breaking change for authorization code flow?
>
> Hi all,
>
> I just noticed a change between draft 11 and 13 I would like to bring to your
> attention.
>
> Until draft 11, the spec left open whether the client of the authz code grant
> type had to present a secret or not. It had been a decision of the authz
> server and I assume some deployments already work that way (at least our's
> does).
>
> Accordingly the text for the request to change a code for token is:
> "Validate the client credentials (if present) and ensure they match the
> authorization code."
>
> In drafts 12/13, the text has been changed to:
> "Validate the client credentials and ensure they match the authorization
> code."
>
> Given the assumption that, w/o a dynamic client registration feature, native
> application cannot securely manage secrets, this means native apps cannot
> use the authorization code flow any longer.
>
> The only interactive flows left would be "implicit grant", which is not
> capable
> of issuing refresh tokens. Which in turn means, native app would be forced
> to acquire access tokens interactively in every session.
>
> Am I right? Or do I just misinterpret the text?
>
> I would suggest to stick to the -11s semantics of the authorization code flow.
>
> regards,
> Torsten.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
