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
