Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

[Justin Richer <[e-mail]>]

So it's been pointed out to me that percent encoding like this would 
break any clients that already have % in their client_id who are using 
the Basic auth. My question to the group is: how many of these are out 
there, really? Do we really have to worry about them? Right now, those 
are just hyptothetical, whereas clients with a : are real.

Considering there already are (at the moment, technically noncompliant) 
clients using : who aren't using basic that we're definitely trying to 
support (otherwise this issue wouldn't be coming up), I would argue in 
favor of the known-existence side as opposed to the potential-existence 
side. Which is to say, use percent encoding (which is established and 
referenceable from another spec) and call it a day.

What *really* bothers me about the strawman proposal is that it's making 
up a new, arbitrary encoding mechanism for one corner case. This is such 
a tiny and oddly specific-to-OAuth2 thing that my gut instinct tells me 
this is going to be either:
   1) ignored
   2) implemented wrong
   3) coupled with some other encoding mechanism for people who want to 
do other things like internationalization

  -- Justin

On 06/15/2012 02:15 PM, Justin Richer wrote:
> Why not percent encoding for just colon and percent?
>
>  -- Justin
>
> On 06/15/2012 01:30 PM, Mike Jones wrote:
>>
>> I was asked a question off-list, which I think is worth answering 
>> on-line.  The question was:  Why the Tab character, rather than 
>> %-encoding?
>>
>> Introducing % encoding would break all existing OAuth 2.0 deployments 
>> using HTTP Basic.  A non-starter...
>>
>> Tab is legal in HTTP Basic but not in URLs or presently client_ids.  
>> It's also a character that can be visibly rendered in an acceptable 
>> manner for debugging.  The other choices were CR and LF, which are 
>> also legal in HTTP Basic but wouldn't render very nicely. ;-)
>>
>>                                                             Cheers,
>>
>>                                                             -- Mike
>>
>> *From:*Mike Jones
>> *Sent:* Friday, June 15, 2012 9:30 AM
>> *To:* 'Eran Hammer'
>> *Cc:* George Fletcher; [e-mail]
>> *Subject:* RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
>> Discussion needed on username and password ABNF definitions
>>
>> I agree with Eran that I prefer that this not be underspecified and 
>> that an encoding for just colon for just Basic will suffice.
>>
>> I'd suggested the encoding s/:/<tab>/g as a strawman.  Are there any 
>> other encoding proposals?
>>
>>                                                             -- Mike
>>
>> *From:*Eran Hammer [mailto:[e-mail]] 
>> <mailto:[mailto:[e-mail]]>
>> *Sent:* Friday, June 15, 2012 9:26 AM
>> *To:* Mike Jones
>> *Cc:* George Fletcher; [e-mail] <mailto:[e-mail]>
>> *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
>> Discussion needed on username and password ABNF definitions
>>
>> 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" <[e-mail] 
>> <mailto:[e-mail]>> 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:*[e-mail] <mailto:[e-mail]>
>>     [mailto:[e-mail]]
>>     <mailto:[mailto:[e-mail]]> *On Behalf Of *George
>>     Fletcher
>>     *Sent:* Friday, June 15, 2012 8:48 AM
>>     *To:* [e-mail] <mailto:[e-mail]>
>>     *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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth