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]> 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
> [email protected]
> 
> 
> 
> On Jul 8, 2014, at 11:56 AM, John Bradley <[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]> 
>> 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]>
>>>>  https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>> 
>>> _______________________________________________
>>> 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

Reply via email to