Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

From: Justin Richer <[email-masked]>
Date: Tue, 22 Jul 2014 18:15:51 -0700

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, [email-masked] 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 <[email-masked]> 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. <[email-masked]>:
>>>>
>>>> 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 <[email-masked]> 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:[email-masked]] On Behalf Of John Bradley
>>>>> Sent: Tuesday, July 08, 2014 12:37 PM
>>>>> To: Phil Hunt
>>>>> Cc: [email-masked]
>>>>> 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 <[email-masked]> 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-masked]
>>>>>
>>>>> >
>>>>>
>>>>> >
>>>>>
>>>>> >
>>>>>
>>>>> > On Jul 8, 2014, at 11:56 AM, John Bradley <[email-masked]> 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-masked]> 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-masked]
>>>>>
>>>>> >>>> <mailto:[email-masked]>>:
>>>>>
>>>>> >>>>
>>>>>
>>>>> >>>>  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-masked] <mailto:[email-masked]> 
>>>>>
>>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> >>>>
>>>>>
>>>>> >>>>
>>>>>
>>>>> >>>>
>>>>>
>>>>> >>>>
>>>>>
>>>>> >>>> --
>>>>>
>>>>> >>>> Nat Sakimura (=nat)
>>>>>
>>>>> >>>> Chairman, OpenID Foundation
>>>>>
>>>>> >>>> http://nat.sakimura.org/
>>>>>
>>>>> >>>> @_nat_en
>>>>>
>>>>> >>>
>>>>>
>>>>> >>> _______________________________________________
>>>>>
>>>>> >>> OAuth mailing list
>>>>>
>>>>> >>> [email-masked]
>>>>>
>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> >>
>>>>>
>>>>> >> _______________________________________________
>>>>>
>>>>> >> OAuth mailing list
>>>>>
>>>>> >> [email-masked]
>>>>>
>>>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> >
>>>>>
>>>>>  
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> OAuth mailing list
>>>>>
>>>>> [email-masked]
>>>>>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>  
>>> -- 
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> [email-masked]
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>  
>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 23 Jul 2014 14:35:52 +0000

It's more complicated than that, as native apps may use the implicit flow and not use https.  The set of constraints in the "application_type" definition in OpenID Connect Dynamic Registration are:

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.

If we’re going to add such constraints, I believe they should be the same ones as the ones above.

                                                            -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, July 22, 2014 6:16 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

--Justin

/sent from my phone/

On Jul 22, 2014 3:27 PM, [email-masked]<mailto:[email-masked]> wrote:

>> On Jul 8, 2014, at 8:54 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

>>> 2014-07-09 7:54 GMT+09:00 Richer, Justin P. <[email-masked]<mailto:[email-masked]>>:

>>>> On Jul 8, 2014, at 4:38 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

>>>>> Cc: [email-masked]<mailto:[email-masked]>

>>>>> On Jul 8, 2014, at 3:16 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

>>>>> > www.independentid.com<http://www.independentid.com>

>>>>> > [email-masked]<mailto:[email-masked]>

>>>>> > On Jul 8, 2014, at 11:56 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

>>>>> >> On Jul 8, 2014, at 9:22 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

>>>>> >>>>  [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>>>> >>> [email-masked]<mailto:[email-masked]>

>>>>> >> [email-masked]<mailto:[email-masked]>

>>>>> [email-masked]<mailto:[email-masked]>

>>>>> [email-masked]<mailto:[email-masked]>

>>>> [email-masked]<mailto:[email-masked]>

>> [email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: [email-masked]
Date: Wed, 23 Jul 2014 11:03:14 -0400

Good point. I don't understand why clients using the implicit response
type generally shall be obliged to use HTTPS. Getting rid of this
requirement would significantly simplify the text. 

regards,
Torsten. 

Am 23.07.2014 10:35, schrieb Mike Jones: 

> If we're going to add such constraints, I believe they should be the same ones as the ones above. 
> 
> -- Mike 
> 
>>>>>> 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 
> 
>>>>>> 
> 
>>>>>> 
> 
>>>>>> 
> 
>>>>>>> www.independentid.com [2] 
> 
>>>>>> 
> 
>>>>>>> [email-masked] 
> 
>>>>>> 
> 
>>>>>>> 
> 
>>>>>> 
> 
>>>>>>> 
> 
>>>>>> 
> 
>>>>>>> 
> 
>>>>>> 
> 
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] 
> 
>>>>>> 
> 
>>>>>>>>>> 
> 
>>>>>> 
> 
>>>>>>>>>> 
> 
>>>>>> 
> 
>>>>>>>>>> 
> 
>>>>>> 
> 
>>>>>>>>>> 
> 
>>>>>> 
> 
>>>>>>>>>> -- 
> 
>>>>>> 
> 
>>>>>>>>>> Nat Sakimura (=nat) 
> 
>>>>>> 
> 
>>>>>>>>>> http://nat.sakimura.org/ [4] 
> 
>>>>>> 
> 
>>>>>>>>>> @_nat_en 
> 
>>>>>> 
> 
>>>>>>>>> 
> 
>>>>>> 
> 
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] 
> 
>>>>>> 
> 
>>>>>>>> 
> 
>>>>>> 
> 
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] 
> 
>>>>>> 
> 
>>>>>>> 
> 
>>>>>> 
> 
>>>>>> 
> 
>>>>>> 
> 
>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] 
> 
>>>>>> 
> 
>>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] 
> 
>>>>> 
> 
>>>>> 
> 
>>>>> https://www.ietf.org/mailman/listinfo/oauth [3] 
> 
>>>>> 
> 
>>>> 
> 
>>>> 
> 
>>>> 
> 
>>>> -- 
> 
>>>> Nat Sakimura (=nat) 
> 
>>>> http://nat.sakimura.org/ [4] 
> 
>>>> @_nat_en 
> 
>>> 
> 
>>> 
> 
>>> https://www.ietf.org/mailman/listinfo/oauth [3] 
> 
>>> 
> 
>> 
> 
>> 
> 
>> 
> 
> 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/

---

From: Mike Jones <[email-masked]>
Date: Wed, 23 Jul 2014 15:15:39 +0000

Web clients using the implicit flow MUST use https or the tokens returned would be communicated in the clear on the open Internet for anyone to snoop.  Not at good idea!

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 23, 2014 8:03 AM
To: Mike Jones
Cc: Justin Richer; [email-masked]
Subject: RE: [OAUTH-WG] Dynamic Client Registration: application_type

Good point. I don't understand why clients using the implicit response type generally shall be obliged to use HTTPS. Getting rid of this requirement would significantly simplify the text.

regards,
Torsten.

                                                            -- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, July 22, 2014 6:16 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

--Justin

/sent from my phone/

On Jul 22, 2014 3:27 PM, [email-masked]<mailto:[email-masked]> wrote:

OAuth mailing list

---

From: [email-masked]
Date: Wed, 23 Jul 2014 12:03:46 -0400

I thought the fragment is only delivered to the client on the AS leg,
meaning if the AS uses HTTPS everything is secure. 

Am 23.07.2014 11:15, schrieb Mike Jones: 

> FROM: [email-masked] [mailto:[email-masked]] 
> SENT: Wednesday, July 23, 2014 8:03 AM
> TO: Mike Jones
> CC: Justin Richer; [email-masked]
> SUBJECT: RE: [OAUTH-WG] Dynamic Client Registration: application_type 
> 

Links:
------

---

From: John Bradley <[email-masked]>
Date: Wed, 23 Jul 2014 12:44:40 -0500

If the request to the AS was over https then the response to the UA is over https.  The redirect from the UA wold not be https, that could be intercepted on the device but not over the Internet.   So we probably shouldn't overstate that element. 

In the implicit flow identifying the client is done via a https identifier ( redirect_uri) that MUST be registered for that client as the client cannot be confidential. 

I need to check with some of the OAuth providers, but I think the concern was that non https uri for implicit makes client impersonation too easy. 

John B. 

Sent from my iPhone

> On Jul 23, 2014, at 10:15 AM, Mike Jones <[email-masked]> wrote:
>