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]<mailto:[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]<mailto:[email protected]>>
To: Mike Jones
<[email protected]<mailto:[email protected]>>; William
Mills <[email protected]<mailto:[email protected]>>; Hannes Tschofenig
<[email protected]<mailto:[email protected]>>; Julian Reschke
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[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]>
[mailto:[email protected]]<mailto:[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]<mailto:[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]>
[mailto:[email protected]]<mailto:[mailto:[email protected]]> On
Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: [email protected]<mailto:[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]<mailto:[email protected]>>
To: Julian Reschke <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[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]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[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
