As written it probably does preclude that but I'm sure we could massage it to be more flexible while still keeping the intent that the code isn't something that can be easily guessed or is likely to collide.
I must admit to never having considered the authz code as anything but a random string as a reference that must be resolved. Can you expand on your thinking a bit, if only to enlighten me? Are you thinking of embedding what would be the entire access token response to the eventual authorization_code grant type request inside the access token itself and encrypting and/or singing it? On Thu, Jul 15, 2010 at 11:39 AM, Brian Eaton <bea...@google.com> wrote: > > Does that text preclude using stateless authorization code implementations? > > Authorization codes are issued frequently and change rapidly, so I am > very interested in supporting stateless implementations. > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
