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

[Justin Richer <[e-mail]>]

Just to clarify, I was actually referring to the self-issued OpenID 
Connect clients that Nat and others have been working on that sparked 
this discussion of the utility of colon, not ones that we have here 
locally in our implementations.

  -- Justin

On 06/15/2012 02:58 PM, Mike Jones wrote:
>
> Justin, it's a useful data point that you already have clients with 
> colon (":") in client_id values (that work because you aren't using 
> HTTP Basic).  Thanks for letting us know that.
>
> For the record, I'd be fine if the working group decided that 
> %-encoding of client_id values when used with HTTP Basic was the right 
> thing to do.  The Tab strawman was intended to break as few 
> implementations as possible, but I fully recognize that the set of 
> implementations broken by using % for %-encoding may well be the empty 
> set.
>
> Other's thoughts?
>
>                                                             Cheers,
>
>                                                             -- Mike
>
> *From:*Justin Richer [mailto:[e-mail]]
> *Sent:* Friday, June 15, 2012 11:53 AM
> *To:* Mike Jones
> *Cc:* [e-mail]
> *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
> Discussion needed on username and password ABNF definitions
>
> 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] <mailto:[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]  <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
>