Hi all,
I don't think this parameter adds any security (as it is self declarded by the caller). I think the constraints on redirect_uris can be specified without the need for another registration parameter. As far as I understand, they merely depend on the grant type. So we could some text to the redirect_uri parameter definition. Something along the following lines: "All redirect URIs registered for a particular client MUST either (1) use the HTTPS scheme or (2) the HTTP scheme with localhost as the hostname or custom schemes. Additionally, clients using the implict grant type MUST only register URLs using the https scheme as redirect_uris; they MUST NOT use localhost as the hostname." regards, Torsten. Am 08.07.2014 21:35, schrieb Richer, Justin P.: > Right, that's how it's used in Connect, which defines only redirect-based > flows. However, the OAuth version needs to be more general purpose. > > It seems like this parameter really does need more discussion in the group > before it should be added to the spec, and therefore I don't think it's > appropriate to add it at this stage (post-WGLC). > > -- Justin > > On Jul 8, 2014, at 8:54 PM, Nat Sakimura <sakim...@gmail.com> wrote: > > 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 [1], 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] 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 [2] > >> 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 [3] > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Nat Sakimura (=nat) > >>>>> Chairman, OpenID Foundation > >>>>> http://nat.sakimura.org/ [4] > >>>>> @_nat_en > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth [3] > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth [3] > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth [3] > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [3] > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [3] -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ [4] @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [3] Links: ------ [1] http://tools.ietf.org/html/rfc6749#section-2 [2] http://www.independentid.com/ [3] https://www.ietf.org/mailman/listinfo/oauth [4] http://nat.sakimura.org/
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
