Frankly, I know of an OpenID Connect use case where it would really useful to
be able to use URIs as client_id values, so the exclusion of colon (":") is
unfortunate. (Some clients might want to use URIs with iOS custom schemas in
some cases.) In this use case, the client_id would never be sent using HTTP
Basic, so the prohibition against colon is actually unnecessary.
Therefore, I'm somewhat sympathetic to relaxing the restriction on client_id
and client_password, but pointing out that if they are used with HTTP Basic,
the more restricted character set required by it MUST be used. I think Julian
was thinking along those lines as well.
-- Mike
From: George Fletcher [mailto:[email protected]]
Sent: Tuesday, June 12, 2012 11:44 AM
To: Eran Hammer
Cc: Mike Jones; William Mills; Hannes Tschofenig; Julian Reschke; [email protected]
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF
definitions
I agree that there is value in allowing the client_id to be a URI. The problem
is that the ':' of the URI is not allowed in HTTP Basic which is required by
the OAuth2 spec for client authentication. We could encode the client_id before
HTTP Basic but that needs to be documented and adds complexity.
Thanks,
George
On 6/12/12 2:39 PM, Eran Hammer wrote:
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 distributed client manamgenet are aware of this
potential restriction.
I'm fine either way.
EH
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: [email protected]<mailto:[email protected]>
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 protected]<mailto:[email protected]>
[mailto:[email protected]]<mailto:[mailto:[email protected]]> On
Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: [email protected]<mailto:[email protected]>
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 protected]<mailto:[email protected]>>
To: Julian Reschke <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
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, should 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 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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
