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

[Justin Richer <[e-mail]>]

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