2.3.1 of Core http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3.1
requires support for HTTP Basic. Actually, in this context, it's requiring
support for using Basic with client_id and client_secret, therefore I believe
those must be restricted to ASCII, as (per Julian's note), UTF-8 does not work
with HTTP Basic.
Per your question about "Basic and Digest working within OAuth", since these
are separately specified by RFC 2617, I believe we are bound by the constraints
in that specification (hence this discussion).
Best wishes,
-- Mike
P.S. In re-reading the relevant portions of the draft, I discovered that in
A.1, A.2, and A.16 the parenthetical text currently reads "This matches the ...
definition in the HTTP Basic Authentication Scheme [RFC2617]". This was an
editorial error, as all of these places should instead read the same as A.15
which says "This is compatible with the ... definition in the HTTP Basic
Authentication Scheme [RFC2617]" (changing the word "matches" to "is
compatible"). This explains one of Julian's remarks, which had previously
puzzled me. ;-)
-----Original Message-----
From: Phil Hunt [mailto:[email protected]]
Sent: Sunday, June 10, 2012 12:07 PM
To: Mike Jones
Cc: Julian Reschke; [email protected]
Subject: 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
[email protected]
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:[email protected]]
> Sent: Sunday, June 10, 2012 11:39 AM
> To: Mike Jones
> Cc: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
