I put it back because otherwise, we wouldn't be meeting one of the requirements
of the RFC 6749. If you look at the client registration section
http://tools.ietf.org/html/rfc6749#section-2, you'll see that registering
redirect_uri values is required, as is registering the client type. Without
this, there wasn't a way to register the client type.
-- Mike
-----Original Message-----
From: OAuth [mailto:[email protected]] On Behalf Of John Bradley
Sent: Tuesday, July 08, 2014 12:37 PM
To: Phil Hunt
Cc: [email protected]
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type
It was taken out and then put back in as it is a common parameter used by a
number of AS.
We have it in Connect, the best reason for keeping it is to stop people from
coming up with a new parameter for the same thing because they haven't looked
at the Connect version.
John B.
On Jul 8, 2014, at 3:16 PM, Phil Hunt
<[email protected]<mailto:[email protected]>> wrote:
> Does this need to be in the spec? I believe we've already said that others
> can add attributes as they need.
>
> Phil
>
> @independentid
> www.independentid.com<http://www.independentid.com>
> [email protected]<mailto:[email protected]>
>
>
>
> On Jul 8, 2014, at 11:56 AM, John Bradley
> <[email protected]<mailto:[email protected]>> wrote:
>
>> The application_type is collected as part of current registration by Google
>> and some other OAuth providers as part of registering redirect uri.
>>
>> The text was cut down to allow more flexibility in OAuth. Connect requires
>> registration of redirect_uri and is more ridged about it than OAuth 2.
>>
>> Do you think the Connect wording would be appropriate for OAuth?
>>
>> John B.
>>
>> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig
>> <[email protected]<mailto:[email protected]>> wrote:
>>
>>> This additional information makes a lot of sense.
>>>
>>> As you said in an earlier mail, the attempt to copy text from the
>>> OpenID Connect spec failed a bit...
>>>
>>> On 07/08/2014 02:49 PM, Nat Sakimura wrote:
>>>> I suppose authors has imported one of the security feature of
>>>> OpenID Connect here as well. In the Dynamic Client Registration
>>>> standard, which is a bit longer than IETF version. You can see the reason
>>>> from it:
>>>>
>>>> application_type
>>>> OPTIONAL. Kind of the application. The default, if omitted, is web.
>>>> The defined values are native or web. Web Clients using the OAuth
>>>> Implicit Grant Type MUST only register URLs using the https scheme
>>>> as redirect_uris; they MUST NOT use localhost as the hostname.
>>>> Native Clients MUST only register redirect_uris using custom URI
>>>> schemes or URLs using the http: scheme with localhost as the
>>>> hostname. Authorization Servers MAY place additional constraints on
>>>> Native Clients. Authorization Servers MAY reject Redirection URI
>>>> values using the http scheme, other than the localhost case for
>>>> Native Clients. The Authorization Server MUST verify that all the
>>>> registered redirect_uris conform to these constraints. This
>>>> prevents sharing a Client ID across different types of Clients.
>>>>
>>>> Regards,
>>>>
>>>> Nat
>>>>
>>>>
>>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig
>>>> <[email protected]
>>>> <mailto:[email protected]>>:
>>>>
>>>> Hi all,
>>>>
>>>> with version -18 you guys have added a new meta-data attribute,
>>>> namely application_type.
>>>>
>>>> First, this new attribute is not listed in the IANA consideration
>>>> section.
>>>>
>>>> Second, could you provide a bit of motivation why you need it?
>>>> What would the authorization server do with that type of
>>>> information? The description is rather short.
>>>>
>>>> IMHO there is also no clear boundary between a "native" and "web" app.
>>>> Just think about smart phone apps that are developed using JavaScript.
>>>> Would this be a web app or a native app?
>>>>
>>>> Here is the definition from the draft:
>>>>
>>>> application_type
>>>> OPTIONAL. Kind of the application. The default, if omitted, is
>>>> "web". The defined values are "native" or "web".
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [email protected]<mailto:[email protected]> <mailto:[email protected]>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>
>>> _______________________________________________
>>> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
