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:[email protected]] >> Sent: Tuesday, June 12, 2012 1:04 PM >> To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke >> Cc: [email protected] >> 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 <[email protected]> >> To: Mike Jones <[email protected]>; William Mills >> <[email protected]>; Hannes Tschofenig <[email protected]>; >> Julian Reschke <[email protected]> >> Cc: "[email protected]" <[email protected]> >> 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: [email protected] [mailto:[email protected]] On Behalf Of >> Mike Jones >> Sent: Tuesday, June 12, 2012 11:27 AM >> To: William Mills; Hannes Tschofenig; Julian Reschke >> Cc: [email protected] >> 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 protected] [mailto:[email protected]] On Behalf Of >> William Mills >> Sent: Tuesday, June 12, 2012 11:18 AM >> To: Hannes Tschofenig; Julian Reschke >> Cc: [email protected] >> 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 protected]> >> To: Julian Reschke <[email protected]> >> Cc: "[email protected]" <[email protected]> >> 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 >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
