Part of the issue is that we want people to use a good source of entropy for this. PRNG on the device seems like the most likely thing. Those generally give you a an array of bytes.
Yes you could use anything to make them URL safe but that happens to be precisely what base64url is intended for. So while it is true that they could come up with some other way to do it, likely that is the result of doing something stupid around generating the values like using a fixed string with a counter. In the default mode the AS is just doing a string compare so what the client uses to encode the string the string is probably not relevant to the server. Saying that the client MUST send a URL safe value vs letting it be encoded by the http lib is I think important for interoperability. For the SHA256 version we are adding base64url encoding for both the hash and the string seem the best choice as well. John B. On Oct 20, 2014, at 5:25 PM, Nat Sakimura <[email protected]> wrote: > So, for the default case, the intent was to use just the unreserved chars, > i.e., > > code_verifier = code_challenge = 16*128unreserved > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > > In sha256 case, I would expect the transform to conform to the constraint: > i.e., define such a transform > so that the end result expressed in code_verifier and code_challenge would be > expressed in unreserved. > > Nat > > 2014-10-20 15:13 GMT-05:00 Brian Campbell <[email protected]>: > In the default case, aren't the challenge and verifier just an arbitrary > string value? One that would be application/x-www-form-urlencoded on the > authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1) and > token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) like any > other parameter value? If the client uses unreserved characters then no > additional encoding is needed but I"m not sure I see any reason to restrict > it. > > If a transform is used, I'd think that the transform defines how the octets > are represented as strings. > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
