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
