No normative language needed. Security consideration is the right approach.
EHL On Jul 15, 2010, at 19:05, "Brian Campbell" <bcampb...@pingidentity.com> wrote: > Okay, I'm with you. Some text guiding the more obvious (to me anyway) > usage might still be useful. Something like, > > "If Authorization Code value is a reference to state on the server, > the value MUST/SHOULD be constructed from a cryptographically strong > random or pseudo-random number sequence [RFC1750] where the > probability of two Authorization Code values being identical is less > than or equal to 2^(-160)." > > It's not as clean the previous text but still maybe useful. > > I'm guessing you don't want any language restricting the length of the > code? Though there is some practical limit due to the URL length in > the 302 (I think it has to be a redirect). > > > > On Thu, Jul 15, 2010 at 3:30 PM, Brian Eaton <bea...@google.com> wrote: >> On Thu, Jul 15, 2010 at 2:16 PM, Brian Campbell >> <bcampb...@pingidentity.com> wrote: >>> 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? >> >> Yes. >> >> The oauth2 authorization code and the SAML artifact are similar in >> that they end up creating this pattern: >> >> user in location A creates some value >> value is transferred to location B >> server in location B resolves value >> value expires >> >> If A and B are geographically distant, you end up having to replicate >> rapidly changing state. that's expensive, and not terribly useful. >> >> If you use a stateless implementation (e.g. authorization code is a >> signed blob containing the client-id, the user-id, the list of scopes >> granted, a timestamp, and a hash of the callback URL) things are much >> more efficient. The code is a bit longer. >> >> Cheers, >> Brian >> > _______________________________________________ > 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
