Aesthetically this makes my tummy hurt...
That said, I think it will work, and I'm willing to go with it.
>________________________________
> From: Mike Jones <[email protected]>
>To: George Fletcher <[email protected]>
>Cc: "[email protected]" <[email protected]>
>Sent: Friday, June 15, 2012 10:30 AM
>Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed
>on username and password ABNF definitions
>
>
>
>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; [email protected]
>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:[email protected]]
>Sent: Friday, June 15, 2012 9:26 AM
>To: Mike Jones
>Cc: George Fletcher; [email protected]
>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" <[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]] On Behalf Of
>>George Fletcher
>>Sent: Friday, June 15, 2012 8:48 AM
>>To: [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]
>>https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>_______________________________________________
>>OAuth mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/oauth
>_______________________________________________
>OAuth mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
