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]] *On
Behalf Of *Mike Jones
*Sent:* Tuesday, June 12, 2012 11:27 AM
*To:* William Mills; Hannes Tschofenig; Julian Reschke
*Cc:* [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]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
