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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 08 Jul 2014 14:17:08 +0200

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

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 8 Jul 2014 21:49:05 +0900

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_typeOPTIONAL. 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]>:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 08 Jul 2014 15:22:46 +0200

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:
> 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,
> 
>     [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Tue, 8 Jul 2014 14:56:21 -0400

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.

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Jul 2014 12:16:22 -0700

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]

---

From: John Bradley <[email-masked]>
Date: Tue, 8 Jul 2014 15:37:04 -0400

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.

---

From: Mike Jones <[email-masked]>
Date: Tue, 8 Jul 2014 20:38:11 +0000

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

John B.

On Jul 8, 2014, at 3:16 PM, Phil Hunt <[email-masked]<mailto:[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.

> 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:

>>> As you said in an earlier mail, the attempt to copy text from the

>>> OpenID Connect spec failed a bit...

>>>> 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:

>>>> registered redirect_uris conform to these constraints. This

>>>> 2014-07-08 21:17 GMT+09:00 Hannes Tschofenig

>>>> <[email-masked]

>>>>  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.

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

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

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

OAuth mailing list

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Jul 2014 13:43:55 -0700

Ok. 

Phil

> On Jul 8, 2014, at 13:38, 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
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 8 Jul 2014 22:54:02 +0000

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]<mailto:[email-masked]>> wrote:

                                                            -- 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]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

John B.

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

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

OAuth mailing list

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 9 Jul 2014 09:54:04 +0900

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
>
>
>
> From: OAuth [mailto:[email-masked] <[email-masked]>] On
> Behalf Of John Bradley
> 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.
>
> >> 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.
>
> >>
>
> >>>> <mailto:[email-masked] <[email-masked]>>>:
>
> >>>>
>
> >>>>  Hi all,
>
> >>>>
>
> >>>>  [email-masked] <mailto:[email-masked] <[email-masked]>>
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 9 Jul 2014 01:35:55 +0000

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]<mailto:[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]<mailto:[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:

 -- Justin

                                                            -- 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]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Dynamic Client Registration: application_type

John B.

OAuth mailing list

---

From: [email-masked]
Date: Tue, 22 Jul 2014 18:27:40 -0400

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.: 

> On Jul 8, 2014, at 8:54 PM, Nat Sakimura <[email-masked]> wrote: 
> 
> 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 [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] _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth [3] 
> https://www.ietf.org/mailman/listinfo/oauth [3]

 -- 
 Nat Sakimura (=nat) 
Chairman, OpenID Foundation
http://nat.sakimura.org/ [4]
 @_nat_en 

_______________________________________________
OAuth mailing list
[email-masked]
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/