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]>
>To: Julian Reschke <[email protected]>
>Cc: "[email protected]" <[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]
>> 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
