Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

[Eve Maler <[e-mail]>]

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:

> 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, 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. 
> 
> 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:
> 
>> 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:
>> 
>>> 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:
>>> 
>>>> 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:[e-mail]] 
>>>> Sent: Tuesday, June 12, 2012 1:04 PM
>>>> To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
>>>> Cc: [e-mail]
>>>> Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions
>>>>  
>>>> 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 <[e-mail]>
>>>> To: Mike Jones <[e-mail]>; William Mills <[e-mail]>; Hannes Tschofenig <[e-mail]>; Julian Reschke <[e-mail]> 
>>>> Cc: "[e-mail]" <[e-mail]> 
>>>> Sent: Tuesday, June 12, 2012 11:39 AM
>>>> Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions
>>>>  
>>>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Mike Jones
>>>> Sent: Tuesday, June 12, 2012 11:27 AM
>>>> To: William Mills; Hannes Tschofenig; Julian Reschke
>>>> Cc: [e-mail]
>>>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of William Mills
>>>> Sent: Tuesday, June 12, 2012 11:18 AM
>>>> To: Hannes Tschofenig; Julian Reschke
>>>> Cc: [e-mail]
>>>> 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 <[e-mail]>
>>>> To: Julian Reschke <[e-mail]> 
>>>> Cc: "[e-mail]" <[e-mail]> 
>>>> 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
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>  
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 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.
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> Eve Maler                                  http://www.xmlgrrl.com/blog
>> [phone]                         http://www.twitter.com/xmlgrrl
>> 
>> 
> 


Eve Maler                                  http://www.xmlgrrl.com/blog
[phone]                         http://www.twitter.com/xmlgrrl