+1 for a simple encoding and allowing ':' in the client_id
On 6/13/12 6:53 PM, Amos Jeffries wrote:
On 14.06.2012 06:40, John Bradley wrote:
That would probably work as well. That is why I am not particularly
concerned about excluding the :
We originally used the URI itself, mostly for convenience of
debugging, but there are other potential options.
The authorization server needs to compare the client_id and the
redirect uri. But it could compare the hash with not much more work.
Also a sha256 hash is probably longer than the uri it is hashing.
I am not super concerned with being able to have : in the client_id
John B.
If I'm following all these threads correctly the only explicit problem
with URI in client_id is HTTP username field being : terminated.
As such it does not have to be a hash per-se, just an encoding that
removes ":" and other reserved characters from the on-wire form *when
sent via HTTP*.
AYJ
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
