If I understand correctly, this parameter is used to appropriately constrain the schema of the Redirect URIs at the time of the registration and is not about fulfilling the Client Type registration requirement in section 2.1. So, making go or no-go decision based on the discussion around section 2.1 probably would not be the way to go. The discussion should happen around the needs on constraining the schema depending on the kind of client.
Apparently, Connect WG perceived that it is a big enough risk that they need to put a plug on based on the risk evaluation as an identity federation protocol. OAuth has different risk profile so it could decide otherwise, but my gut feeling is that unless there is a good reason not to have it, we may as well keep it. Nat 2014-07-09 7:54 GMT+09:00 Richer, Justin P. <jric...@mitre.org>: > This value was introduced in -18, and it's a direct port from OpenID > Connect. It was never in the OAuth Dynamic Registration spec, and though it > has been in the OpenID Connect Dynamic Registration spec for a very long > time, I think it was a mistake to add it in for several reasons: > > First, the semantics around its values and use are not clearly defined, > for the reasons . I don't see any particular harm in keeping it, but I > don't really see what value it adds for clients or server developers. We > are in a world where there are OAuth clients that are much more than just > "native" or "web". > > Second, RFC6749 defines "Client Type" in § 2.1 which defines two values: > "confidential" and "public", neither of which maps very cleanly to "native" > or "web" as stated in -18. This is especially true when you've got dynamic > registration that can make native clients confidential with relative ease. > We actually take care of registering the "client type" through the use of > the "token_endpoint_auth_method" parameter, which is what § 2.1 is really > talking about: secure client authentication (to the token endpoint). > > With this in mind, my preference and suggestion would be to remove this > field. If other protocols need it, they can register and define it (like > Connect has done). > > -- Justin > > > On Jul 8, 2014, at 4:38 PM, Mike Jones <michael.jo...@microsoft.com> > wrote: > > 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:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] On > Behalf Of John Bradley > Sent: Tuesday, July 08, 2014 12:37 PM > To: Phil Hunt > Cc: oauth@ietf.org > 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 <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 <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 <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 > _______________________________________________ > 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 > > -- 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
