Saying that the string must be base64url encoded when sent to the AS shouldn't impact any servers doing a string compare.
Yes we are a touch vague about what constitutes high entropy. On Oct 20, 2014, at 6:23 PM, Brian Campbell <[email protected]> wrote: > That all makes sense. And yeah, our AS side implementation just does a string > compare. I'd just really like to keep that compliant as the spec gets > updated. But being tighter about what the client can send doesn't change > anything there. > > If the concern is about people using a good source of entropy, then something > to that effect should probably be said directly. > > On Mon, Oct 20, 2014 at 2:54 PM, John Bradley <[email protected]> wrote: > 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
