I'm ok with that text, and actually thought we had something along those lines already.
--Justin /sent from my phone/ On Jul 22, 2014 3:27 PM, tors...@lodderstedt.net wrote: > > 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, 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 >>>>> >>>>> > 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
