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

Isn't the nuance that Basic and Digest should be able to be passed through OAuth?  Or is there a secondary requirement that uid/passwords forms in OAuth be re-encodable to Basic?

So while "UTF-8 may not work with Basic and Digest" is that a valid concern?  

I think our concern should be limited to "Basic and Digest working within OAuth". 

Am I missing something?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2012-06-10, at 11:50 AM, 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