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
