We should not leave this under specified. Picking an encoding for just Basic 
and just colon is simple enough.

EH

On Jun 15, 2012, at 19:17, "Mike Jones" 
<[email protected]<mailto:[email protected]>> wrote:

Based on use cases I’m seeing, believe it’s important to allow the use of URIs 
as client_id values (which means allowing “:” in the client_id string).  I’m OK 
with us either specifying a specific encoding when using them in Basic or 
simply saying that “When client_ids are used with HTTP Basic that contain 
characters such as “:” not allowed in HTTP Basic usernames, then the 
participants will need to agree upon a method of encoding the client_id for use 
with HTTP Basic.

                                                            -- Mike

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed 
on username and password ABNF definitions

+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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to