Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I think once the WG decided that client_id and client_secret need to be passed as the username and password for HTTP Basic authentication of the client to the Token Endpoint,  the Die was cast for those elements to have the same character restrictions.

In principal you could use the assertion profile or some other mechanism to authenticate the client, and avoid needing the restriction.   However as this is only intended to be machine readable it is probably better to be consistent with the ABNF rather than different ones per authentication method.

So I think we are back to ASCII for the client_id and client_secret.

John B.

On 2012-06-10, at 7:50 PM, Mike Jones wrote:

> Thanks for your reply, Julian.
> 
> Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest", and they're required to be used with Basic, I believe that that confirms that username and password must either be ASCII or ISO-8859-1, and given that several people have written that ISO-8859-1 is a "non-starter", that effectively confirms the current syntax in -27 that username and password must be ASCII.  Do you agree or am I missing a nuance here?
> 
> Julian, there was one aspect of the open issue that you didn't reply to:  Do you have an opinion on whether client_id and client_secret should be restricted to the same characters as username and password?  This seems logical to me, as they are objects of the same kind as username and password, but I also sympathize with your sentiment that "we shouldn't extend this problem to anything new we define".  On the other hand, given that client_id and client_secret are for machine (and not for human) consumption, I don't see any more need for internationalization of these fields than there was for scope (which the working group decided to limit to ASCII).
> 
> Julian, what do you think?  Working group, what do you think?
> 
> 				Thanks,
> 				-- Mike
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Sunday, June 10, 2012 11:39 AM
> To: Mike Jones
> Cc: oauth@ietf.org
> Subject: Re: Discussion needed on username and password ABNF definitions
> 
> On 2012-06-08 20:09, Mike Jones wrote:
>> Hi Julian,
>> 
>> The current draft restricts username and password to ASCII was because RFC 2616 says this about the TEXT fields used by HTTP Basic in RFC 2617:
>>    "Words of *TEXT MAY contain characters from character sets other than
>>     ISO-8859-1 [22] only when encoded according to the rules of
>>    RFC 2047 [14]."
>> 
>> Given that RFC 2047 MIME encodings aren't possible in this context, that you wrote that "If you define new protocol elements, either restrict them to US-ASCII, or find a way to encode all of Unicode", and you and Peter St. Andre wrote that using ISO-8859-1 is a non-starter, that seemed to leave ASCII as the only available choice.
> 
> The other choice was "find a way to encode all of Unicode". The way to do this usually is to use UTF-8. That doesn't work with Basic and Digest, but we shouldn't extend this problem to anything new we define.
> 
>> If you have an alternative proposal for encoding all of Unicode for username and password, I'd appreciate if you could propose specific text changes to -27 to accomplish them.  I'd be fine with doing that, but didn't know how to satisfy all the constraints above for Unicode characters.  Draft -27 is now available at http://tools.ietf.org/html/draft-ietf-oauth-v2-27.
>> ...
> 
> I haven't looked at the core OAuth spec. The right answer depends on where you use these protocol elements.
> 
> Changing this into a question to the WG: is it acceptable to restrict all of these protocol elements to US-ASCII?
> 
> Best regards, Julian
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth