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 <phil.h...@oracle.com> 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 > phil.h...@oracle.com > > > > On Jul 8, 2014, at 11:56 AM, John Bradley <ve7...@ve7jtb.com> 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 <hannes.tschofe...@gmx.net> >> 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 <hannes.tschofe...@gmx.net >>>> <mailto:hannes.tschofe...@gmx.net>>: >>>> >>>> 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 >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=nat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
