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

From: Mike Jones <[email-masked]>
Date: Fri, 8 Jun 2012 18:09:27 +0000

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.

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.

The working group should also discuss whether client_id and client_secret should use the same character set restrictions as username and password or whether they should be different for some reason.  In the case of one character, they need to be different:  The client_id field already allows colon (":") for reasons identified by Nat Sakimura, among others, whereas username can't because of HTTP Basic restrictions.

				Best wishes,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Friday, June 08, 2012 2:52 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Draft OAuth Core spec changes updating proposed ABNF

On 2012-06-08 09:56, Mike Jones wrote:
> The attached proposed edits to the Core spec update the ABNF to remove 
> the character set restrictions that working group participants had 
> objected to, and to define common syntax elements, where appropriate.
> After working group review, I believe that these changes are ready to 
> be checked in for draft 27 after being merged with whatever other 
> changes Eran has made.
> ...

As far as I can tell, you have chosen to restrict everything to US-ASCII. That definitively makes the ABNF and the wire representation simpler, but it does break I18N big time.

And please don't tell me that people do not use non-ASCII characters in credentials (-> <https://bugzilla.mozilla.org/show_bug.cgi?id=41489>).

Focusing on username and password... If this relates to the use in Basic and Digest, it's fine that it has their current limitations; but in that case the ABNF shouldn't invent new productions and claim that they match 2617's when they do not.

If this relates to uses of usernames and passwords outside Basic and Digest (thus new uses), then I believe the proposed solution is not acceptable.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jun 2012 20:39:16 +0200

> 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 Unicod…

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 doi…

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

---

From: Mike Jones <[email-masked]>
Date: Sun, 10 Jun 2012 18:50:11 +0000

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-masked]] 
Sent: Sunday, June 10, 2012 11:39 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: Discussion needed on username and password ABNF definitions

> 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 Unicod…

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 doi…

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

---

From: Phil Hunt <[email-masked]>
Date: Sun, 10 Jun 2012 12:06:36 -0700

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-masked]

On 2012-06-10, at 11:50 AM, Mike Jones wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Sun, 10 Jun 2012 19:25:12 +0000

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-masked]] 
Sent: Sunday, June 10, 2012 12:07 PM
To: Mike Jones
Cc: Julian Reschke; [email-masked]
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Am I missing something?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Sun, 10 Jun 2012 20:27:30 +0100

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.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jun 2012 21:45:58 +0200

> 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…

I don't understand OAuth enough to know whether a constraint of Basic 
and Digest should affect OAuth in general.

Also, we actually might be able to *fix* these schemes, in which case it 
would be unfortunate if OAuth adopted the constraint in a way that makes 
it hard to update.

I believe the right thing to do is not to have a special ABNF; but 
instead to just note that when these protocol elements need to be used 
with Basic or Digest, the respective constraints of these schemes apply.

> 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 p…

I'll leave that to the WG :-)

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Sun, 10 Jun 2012 19:55:57 +0000

Hi Julian,

As background, the reason for the special ABNF is to satisfy a DISCUSS raised by Sean Turner specifically that specifically requested a comprehensive ABNF.  I believe that these very discussions show how valuable Sean's request is to improving the clarity of the spec for implementer's, as even some experts on the list hadn't completely worked through syntax consequences of the dependent specs used, whereas as the ABNF makes the syntax restrictions obvious.  I believe this has improved the clarity of the spec and likely improved interoperability of implementations because of it.

				Best wishes,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Sunday, June 10, 2012 12:46 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: Discussion needed on username and password ABNF definitions

> 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…

I don't understand OAuth enough to know whether a constraint of Basic and Digest should affect OAuth in general.

Also, we actually might be able to *fix* these schemes, in which case it would be unfortunate if OAuth adopted the constraint in a way that makes it hard to update.

I believe the right thing to do is not to have a special ABNF; but instead to just note that when these protocol elements need to be used with Basic or Digest, the respective constraints of these schemes apply.

Best regards, Julian

---

From: John Bradley <[email-masked]>
Date: Sun, 10 Jun 2012 21:40:41 +0100

So we have two competing good ideas.

1 include an ABNF directly and codify what is expected to to work at the cost of flexibility.
2 Reference RFC 2617 itself referencing RFC 2616 to allow for a future fix to the encoding limitations to be automatically picked up by OAuth if RFC 2617 is updated.  

My observation is that if we are having a hard time deciding this,  a developer is going to as well.
My vote is for directly including the ABNF.

I also want to note that I think the ABNF for client-id is wrong.
It should exclude ":".  Colon is used as a field separator by Basic (god help us) if you allow it it will blow up parsing.   

*<TEXT excluding ":">

That is probably the most important thing I realized in this exercise.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Jun 2012 01:36:32 +1000

Are we so sure the non-english "half" of the world only use ASCII characters in passwords? Sounds highly unlikely to me.

> Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest"...

It can work. It is just underspecified. So things can get messy.
draft-reschke-basicauth-enc-05 is a current draft (March 2012) attempting to fix this as much as possible.

Forcing ASCII password for people feels unacceptable. Better would be to say OAuth servers accepting HTTP BASIC MUST accept UTF-8 encoded usernames and passwords. A warning about interop problems with non-ASCII password is ok.

ASCII-only for usernames is almost as bad. I thought internationalized email addresses were just standardized, and email addresses are often used as usernames.

For client id & password ASCII-only is less of an issue. These are values configured into apps, not remembered by human brains.

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 Jun 2012 22:16:47 +0000

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.

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

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.

				-- 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!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Monday, June 11, 2012 8:37 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Jun 2012 10:54:28 +0200

> 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…

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.

>      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.

> 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

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 12 Jun 2012 18:38:22 +0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mike Jones
> Sent: Tuesday, June 12, 2012 6:17 AM
> To: [email-masked]
> 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.
> 

As a person in the non-English half of the world, this sounds like a
reasonable solution.

> 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.
> 
> 				-- 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!
> 
> Are we so sure the non-english "half" of the world only use ASCII
characters in
> passwords? Sounds highly unlikely to me.
> 
> draft-reschke-basicauth-enc-05 is a current draft (March 2012) attempting
to
> fix this as much as possible.
> 
> Forcing ASCII password for people feels unacceptable. Better would be to
say
> OAuth servers accepting HTTP BASIC MUST accept UTF-8 encoded usernames
> and passwords. A warning about interop problems with non-ASCII password is
> ok.
> 
> ASCII-only for usernames is almost as bad. I thought internationalized
email
> addresses were just standardized, and email addresses are often used as
> usernames.
> 
> For client id & password ASCII-only is less of an issue. These are values
> configured into apps, not remembered by human brains.
> 
> 
> --
> James Manger
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Jun 2012 21:01:14 +0300

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:

> 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.
> 
> 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).
> 
> I'll send a separate mail about that, the current text in the spec is way too unspecific.
> 
>> 				-- Mike
>> 
> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
> 
> Best regards, Julian

---

From: William Mills <[email-masked]>
Date: Tue, 12 Jun 2012 11:17:32 -0700 (PDT)

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-masked]>
>To: Julian Reschke <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, June 12, 2012 11:01 AM

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Jun 2012 18:26:39 +0000

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-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

-bill

________________________________
From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
To: Julian Reschke <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer <[email-masked]>
Date: Tue, 12 Jun 2012 18:39:16 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

                                                            Thanks all,
                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

-bill

Ciao
Hannes

---

From: George Fletcher <[email-masked]>
Date: Tue, 12 Jun 2012 14:44:00 -0400

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-masked] [mailto:[email-masked]] *On 
> Behalf Of *Mike Jones
> *Sent:* Tuesday, June 12, 2012 11:27 AM
> *To:* William Mills; Hannes Tschofenig; Julian Reschke
> *Cc:* [email-masked]
> *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-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] 
> <mailto:[mailto:[email-masked]]> *On Behalf Of *William Mills
> *Sent:* Tuesday, June 12, 2012 11:18 AM
> *To:* Hannes Tschofenig; Julian Reschke
> *Cc:* [email-masked] <mailto:[email-masked]>
> *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-masked] 
> <mailto:[email-masked]>>
> *To:* Julian Reschke <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Tuesday, June 12, 2012 11:01 AM
> *Subject:* Re: [OAUTH-WG] Discussion needed on username and password 
> ABNF definitions
>
>
> 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
>
> With HTTP Basic authentication the problem is that this is a legacy 
> technology and there is no internationalization support.
>
> 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?
>
> 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
>
> >> 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.
> >
> > 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.
> >
> > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Eran Hammer <[email-masked]>
Date: Tue, 12 Jun 2012 18:57:07 +0000

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:[email-masked]]
Sent: Tuesday, June 12, 2012 11:44 AM
To: Eran Hammer
Cc: Mike Jones; William Mills; Hannes Tschofenig; Julian Reschke; [email-masked]
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

I'm fine either way.

EH

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mike Jones

                                                            Thanks all,
                                                            -- Mike

-bill

Ciao
Hannes

OAuth mailing list

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Jun 2012 19:20:10 +0000

Frankly, I know of an OpenID Connect use case where it would really useful to be able to use URIs as client_id values, so the exclusion of colon (":") is unfortunate.  (Some clients might want to use URIs with iOS custom schemas in some cases.) In this use case, the client_id would never be sent using HTTP Basic, so the prohibition against colon is actually unnecessary.

Therefore, I'm somewhat sympathetic to relaxing the restriction on client_id and client_password, but pointing out that if they are used with HTTP Basic, the more restricted character set required by it MUST be used.  I think Julian was thinking along those lines as well.

                                                            -- Mike

Thanks,
George

I'm fine either way.

EH

                                                            Thanks all,
                                                            -- Mike

-bill

Ciao
Hannes

OAuth mailing list

---

From: William Mills <[email-masked]>
Date: Tue, 12 Jun 2012 13:04:10 -0700 (PDT)

I think dynamic client registration is something we have not talked out enough yet.  There's a pretty clear use case for dynamic registration.  

Does identifying the client with a URI allow some form of OpenID-ish flow for this?  

Is the client ID as a URI a way to allow a trusted site to provide metadata about the client?
Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret?

I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing.

-bill

> From: Eran Hammer <[email-masked]>
>To: Mike Jones <[email-masked]>; William Mills <[email-masked]>; Hannes Tschofenig <[email-masked]>; Julian Reschke <[email-masked]> 
>Sent: Tuesday, June 12, 2012 11:39 AM
>Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions
> 
>
> 
>From:[email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
>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-masked] [mailto:[email-masked]] On Behalf Of William Mills
>From:Hannes Tschofenig <[email-masked]>
>Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions):
>>> 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.

---

From: Eran Hammer <[email-masked]>
Date: Tue, 12 Jun 2012 20:08:29 +0000

The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that would be nice.

I do agree we need some actual use cases before we spend much more time on this.

EH

From: William Mills [mailto:[email-masked]]
Sent: Tuesday, June 12, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: [email-masked]
Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

-bill

________________________________
From: Eran Hammer <[email-masked]<mailto:[email-masked]>>
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; William Mills <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Julian Reschke <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 12, 2012 11:39 AM
Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I'm fine either way.

EH

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones

                                                            Thanks all,
                                                            -- Mike

-bill

Ciao
Hannes

---

From: William Mills <[email-masked]>
Date: Tue, 12 Jun 2012 13:12:59 -0700 (PDT)

Is it workable/useful then to define something like:

    basic_client_id = 1*basic_auth_allowed_characters
    uri_client_id = 1*uri_allowed_characters

And include text saying, "Clients using HTTP Basic authentication MUST have a client_id of type basic_client_id.  Clients using client_id of type uri_client_id MUST NOT use HTTP Basic client authentication."?

-bill

>To: George Fletcher <[email-masked]> 
>Cc: Mike Jones <[email-masked]>; William Mills <[email-masked]>; Hannes Tschofenig <[email-masked]>; Julian Reschke <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, June 12, 2012 11:57 AM
>From:George Fletcher [mailto:[email-masked]]

---

From: Jianhua Shao <[email-masked]>
Date: Tue, 12 Jun 2012 21:39:00 +0100

Hello,

Dynamic client registration is very useful if client or resource or authorisation server is not permanently available.
A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available.
Another typical case is that authorisation server do not necessary to have client pre-registered on itself. At moment, industry like facebook would like developer to register a app on its app centre first, and then ask user auth to use the app.

We are researchers from Digital Economy Research Institute. We have this problem When we developing Dataware that could manage the control of access to personal data. We play around our solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki

We are in the list to receive your maillist, but currently need moderate to post any message. cc my colleague, Richard Mortier
Best
Jian

On 12 Jun 2012, at 21:08, Eran Hammer wrote:

EH

-bill

I'm fine either way.

EH

                                                            Thanks all,
                                                            -- Mike

-bill

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

Ciao
Hannes

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

---

From: Eve Maler <[email-masked]>
Date: Wed, 13 Jun 2012 11:42:39 -0700

Also please see the UMA-flavored use cases (there are two) and the summary of requirements provided in this input document:

http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-03

	Eve

On 12 Jun 2012, at 1:39 PM, Jianhua Shao wrote:

> This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
> 

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Jianhua Shao <[email-masked]>
Date: Wed, 13 Jun 2012 21:52:20 +0100

Hi, UMA-flavored sound quite close to our dataware.catalog design to solve similar problem in dynamic auth and registration. I am interesting to know how it would push to next stage as it expired on 26 April 2012.

Currently OAuth 2 are one way registration and authentication, which is client register on authorisation server and also auth in the same direction. Have you think about the cases that either side can start the registration, which is in additional that authorisation server wants client to register on it and give the permission to access to limited resources. We met this demand that if I heard a application is very useful by listening to my friend, I would like to actively give permission to this application to start to use it.

A concrete example is from my real experience that when I travel to China, I have use a search engine called Baidu.com<http://Baidu.com>, because I am new to this search engine but I am using google as daily, so there is a app could leave the port that could move any historical search data into baidu.com<http://baidu.com>, If I can actively give my permission of google search history data into that app, I would than have baidu.com<http://baidu.com> to use in right way. If you think about many other cases in the life, it is actually a very common demand.

So have you think about this kind of dynamic registration/auth, and also can enable either side to start the process? Just want to know where and how to contribute to your existing work.

Jian

On 13 Jun 2012, at 19:42, Eve Maler wrote:

Eve

Hello,

EH

-bill

I'm fine either way.

EH

                                                            Thanks all,
                                                            -- Mike

-bill

Ciao
Hannes

---

From: Eve Maler <[email-masked]>
Date: Thu, 14 Jun 2012 11:15:29 -0700

Oops, sorry, should have pointed to the version of the draft that's actually meant for the OAuth WG workstream:

http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00

We hope to contribute as this work proceeds in the OAuth group, and I've also learned that Tom Brown has an open-source implementation here:

https://github.com/herestomwiththeweather/cyberwire/blob/master/src/org/opensourcecurrency/hack/AddProvider.java#L197

(He wrote recently to the OAuth list with a question about the spec: http://www.ietf.org/mail-archive/web/oauth/current/msg09053.html)

	Eve

p.s. I'm cc'ing the UMA WG here just to inform them of all this. Followups should be directed only to the appropriate list(s).

On 13 Jun 2012, at 1:52 PM, Jianhua Shao wrote:

> A concrete example is from my real experience that when I travel to China, I have use a search engine called Baidu.com, because I am new to this search engine but I am using google as daily, so there is a app could leave the port that could move any historical search data into baidu.com, If I can actively give my permission of google search history data into that app, I would than have baidu.com to use in right way. If you think about many other cases in the life, it is actually a very common demand. 
>