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

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 13 Jun 2012 18:03:50 +0200

Hi John,

would it make sense to use a hash of the URI instead of the URI itself in your use case?

regards,
Torsten.

John Bradley <[email-masked]> schrieb:

I think that the issues are getting confused.

There is a use case where the Authorization server may be a embedded app, at least in one openID case.    As it won't have a separate registration or token endpoint,  the client needs to make its own clientID for the request.   A reasonable thing to use is the redirect URI to create a unique value that the user could use for revocation at a later point.

Currently with the no : restriction we would use the host and path to crate the clientid.

There are some scenarios where having the scheme as part of that would be helpful.

This has nothing to do with discovery or the dynamic client registration proposal as far as I know.

A URL as a client_id comes from prototype work for a personal provider that we are doing as part of openID Connect.

John B.

On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote:

Hi all,

can anyone please explain the relation between dynamic client registration and URIs as client ids? None of the current drafts (uma or connect) seem to require URIs.

regards,
Torsten.

Jianhua Shao <[email-masked]> schrieb:

Hello,

Dynamic client registration is very useful if client or resource or authorisation server is not permanently available. 

A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available. 

Another typical case is that authorisation server do not necessary to have client pre-registered on itself. At moment, industry like facebook would like developer to register a app on its app centre first, and then ask user auth to use the app. 

We are researchers from Digital Economy Research Institute. We have this problem When we developing Dataware that could manage the control of access to personal data. We play around our solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki

We are in the list to receive your mail list, but currently need moderate to post any message. cc my colleague, Richard Mortier

Best

Jian

On 12 Jun 2012, at 21:08, Eran Hammer wrote:

The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that would be nice.

I do agree we need some actual use cases before we spend much more time on this.

EH

From: William Mills [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: [email-masked]
Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I think dynamic client registration is something we have not talked out enough yet.  There's a pretty clear use case for dynamic registration.  

Does identifying the client with a URI allow some form of OpenID-ish flow for this? 

Is the client ID as a URI a way to allow a trusted site to provide metadata about the client?

Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret?

I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing.

-bill

_____________________________________________

From: Eran Hammer <[email-masked]>
To: Mike Jones <[email-masked]>; William Mills <[email-masked]>; Hannes Tschofenig <[email-masked]>; Julian Reschke <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Tuesday, June 12, 2012 11:39 AM
Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means.

I just want to make sure those thinking about more complex use cases involving dynamic registration or distri buted client manamgenet are aware of this potential restriction.

I'm fine either way.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope” nor “error” allow non-ASCII characters.

Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misunderstanding the intent of suggested changes.

                                                            Thanks all,

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized".  In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way.

I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.

-bill

_____________________________________________

From: Hannes Tschofenig <[email-masked]>
To: Julian Reschke <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I had a chat with Julian yesterday and here is my short summary. 

Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client_secret)

With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. 

With our brand new custom OAuth authentication mechanism we have more options. 

One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter. 

Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret? 

Here we have the possibility to define something better. 

In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails. 

Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism? 

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic.
> 
> I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them.
> 
>> Therefore, I'd like to propose these updated ABNF definitions:
>> 
>>    VSCHAR = %20-7E
>>    NOCOLONVSCHAR = %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR = <Any Unicode character other than ( %x0-1F / %x7F )>
>> 
>>    client-id = *NOCOLONVSCHAR
>>    client_secret = *VSCHAR
>> 
>>    username = *UNICODENOCTRLCHAR
>>    password = *UNICODENOCTRLCHAR
> 
> In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time).
> 
>> It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified.
> 
> I'll send a separate mail about that, the current text in the spec is way too unspecific.
> 
>>                 -- Mike
>> 
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode character other than ( %x0-1F / %x7F )>", please send it to me!
> 
> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
> 
> Best regards, Julian
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. 

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. 

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Wed, 13 Jun 2012 20:40:08 +0200

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. 

Sent from my iPhone

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 14 Jun 2012 10:53:12 +1200

On 14.06.2012 06:40, John Bradley wrote:
> 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.
>

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

---

From: Jianhua Shao <[email-masked]>
Date: Wed, 13 Jun 2012 22:54:16 +0100

In dynamic, it is hard to know what A come back is B want and B original give, specially for registration. Therefore, if A wants to register on B, A should give B a unique callback to identify which session it is dealing to, B should also do the same when A come back to B to confirm the communication.

Let us think about, a client have a general name (Mac OS), but a client will be used by multiple entities (like browser, IM, etc in Mac OS), they all go to a website to request for access. So in this A -> B cases, what we do is, for any role, we will have a general name for it (we use URI), and we will have a token for each session (callback, it is generated by A, and give to B). Once registration is done, the token (it is generated by B  give to A, so that every time A can hold this token to access to B) would keep reuse for same session.

I think when you say client_id, you mean the same. In current industry implementation, like facebook, because app has to be pre-register in facebook, it is already have the customer_token already, that is why it does not need a callback token generated by A in necessary. But in dynamic case, we have to add it on.

On 13 Jun 2012, at 19:40, John Bradley wrote:

John B.

Sent from my iPhone

On 2012-06-13, at 6:03 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

regards,
Torsten.

John Bradley <[email-masked]<mailto:[email-masked]>> schrieb:
I think that the issues are getting confused.

John B.

Hi all,

regards,
Torsten.

Jianhua Shao <[email-masked]<mailto:[email-masked]>> schrieb:
Hello,

EH

Cc: [email-masked]<mailto:[email-masked]>

-bill

________________________________
From: Eran Hammer <[email-masked]<mailto:[email-masked]>>
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; William Mills <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Julian Reschke <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 12, 2012 11:39 AM
Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I'm fine either way.

EH

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

                                                            Thanks all,
                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

-bill

________________________________
From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
To: Julian Reschke <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Fri, 15 Jun 2012 11:48:11 -0400

+1 for a simple encoding and allowing ':' in the client_id

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Jun 2012 16:17:13 +0000

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-masked] [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

That would probably work as well.  That is why I am not particularly
concerned about excluding the :

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

---

From: Brian Campbell <[email-masked]>
Date: Fri, 15 Jun 2012 10:19:52 -0600

+1

On Fri, Jun 15, 2012 at 10:17 AM, Mike Jones
<[email-masked]> 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
>
>
>
> Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion
> needed on username and password ABNF definitions
>
>
>
> 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
>

---

From: Eran Hammer <[email-masked]>
Date: Fri, 15 Jun 2012 16:26:19 +0000

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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

John B.

AYJ

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Jun 2012 16:29:40 +0000

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-masked]]
Sent: Friday, June 15, 2012 9:26 AM
To: Mike Jones
Cc: George Fletcher; [email-masked]
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

EH

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of George Fletcher
Sent: Friday, June 15, 2012 8:48 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

John B.

AYJ

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Jun 2012 17:30:44 +0000

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-masked]
Subject: RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

                                                            -- Mike

From: Eran Hammer [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, June 15, 2012 9:26 AM
To: Mike Jones
Cc: George Fletcher; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

EH

                                                            -- Mike

John B.

AYJ

---

From: William Mills <[email-masked]>
Date: Fri, 15 Jun 2012 11:12:49 -0700 (PDT)

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-masked]>
>To: George Fletcher <[email-masked]> 
>Sent: Friday, June 15, 2012 10:30 AM
>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 
>I’d suggested the encoding s/:/<tab>/g as a strawman.  Are there any other encoding proposals?
> 
>                                                            -- Mike
> 
>From:Eran Hammer [mailto:[email-masked]] 
>On Jun 15, 2012, at 19:17, "Mike Jones" <[email-masked]> wrote:
>>From:[email-masked] [mailto:[email-masked]] On Behalf Of George Fletcher

---

From: Justin Richer <[email-masked]>
Date: Fri, 15 Jun 2012 14:15:59 -0400

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?
>
> 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-masked]
> *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.
>
> *From:*Eran Hammer [mailto:[email-masked]] 
> <mailto:[mailto:[email-masked]]>
> *Sent:* Friday, June 15, 2012 9:26 AM
> *To:* Mike Jones
> *Cc:* George Fletcher; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
> Discussion needed on username and password ABNF definitions
>
> On Jun 15, 2012, at 19:17, "Mike Jones" <[email-masked] 
> <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]]
>     <mailto:[mailto:[email-masked]]> *On Behalf Of *George
>     Fletcher
>     *Sent:* Friday, June 15, 2012 8:48 AM
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re:
>     Discussion needed on username and password ABNF definitions
>
>     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
>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Fri, 15 Jun 2012 14:53:13 -0400

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:
>> We should not leave this under specified. Picking an encoding for 
>> just Basic and just colon is simple enough.
>>
>> EH
>>
>>     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: Mike Jones <[email-masked]>
Date: Fri, 15 Jun 2012 18:58:01 +0000

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:[email-masked]]
Sent: Friday, June 15, 2012 11:53 AM
To: Mike Jones
Cc: [email-masked]
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

 -- Justin

                                                            Cheers,
                                                            -- Mike

From: Mike Jones

                                                            -- Mike

EH

                                                            -- Mike

John B.

AYJ

OAuth mailing list

OAuth mailing list

---

From: Justin Richer <[email-masked]>
Date: Fri, 15 Jun 2012 14:59:32 -0400

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:[email-masked]]
> *Sent:* Friday, June 15, 2012 11:53 AM
> *To:* Mike Jones
> *Cc:* [email-masked]
> 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