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; oauth@ietf.org
*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...@hueniverse.com]
<mailto:[mailto:e...@hueniverse.com]>
*Sent:* Friday, June 15, 2012 9:26 AM
*To:* Mike Jones
*Cc:* George Fletcher; oauth@ietf.org <mailto:oauth@ietf.org>
*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" <michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>> 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:*oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org]
<mailto:[mailto:oauth-boun...@ietf.org]> *On Behalf Of *George
Fletcher
*Sent:* Friday, June 15, 2012 8:48 AM
*To:* oauth@ietf.org <mailto:oauth@ietf.org>
*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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
