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]<mailto:[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]>
[mailto:[email protected]]<mailto:[mailto:[email protected]]> On
Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: [email protected]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
