Encoding is an option which does not require us to address it. Those seeking to use URIs can simply specify that.
However, Julian indicated earlier that this restriction in Basic may change, in which case we can reference Basic and simply add an interop warning (like the one we have for redirections including a fragment) about it. EH From: George Fletcher [mailto:gffle...@aol.com] Sent: Tuesday, June 12, 2012 11:44 AM To: Eran Hammer Cc: Mike Jones; William Mills; Hannes Tschofenig; Julian Reschke; oauth@ietf.org 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: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org<mailto:oauth@ietf.org> 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: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org]<mailto:[mailto:oauth-boun...@ietf.org]> On Behalf Of William Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org<mailto:oauth@ietf.org> 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 <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> To: Julian Reschke <julian.resc...@gmx.de<mailto:julian.resc...@gmx.de>> Cc: "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> 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 > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
