Yes for the default case it is a simple string comparison, so not such a big issue.
It might still be possible to cause it to break by using a binary value and letting the underlying libraries do the encoding on the two calls to the authorization server. They might possibly use different escaping, or the server might unescape one back to binary and use the escaped version on the other input causing the comparison to fail. I agree that base64url encoding is probably the safest for interoperability but will add a bit of processing on the client in the default case that might not be necessary if the verifier value is already URL safe by some other mechanism. Given a desire to make a SHA256 transform MTI for servers, standardizing on base64url encoding of the values seems to make sense. John B. On Oct 20, 2014, at 5:13 PM, Brian Campbell <[email protected]> wrote: > 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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
