<div dir="ltr">Thank you for your comment.<br><br>If both native clients and web clients can be public or confidential,<br>application_type which is described in Client Metadata section of<br>OpenID Connect Dynamic Client Registration 1.0 is DIFFERENT from the<br>
client type described in RFC 6749.<br><br>Considering the following two points:<br><br> (1) RFC 6749 (OAuth 2.0) requires a client type to be registered.<br> (RFC 6749, 2. Client Registration)<br><br> (2) OpenID Connect Relying Party is a kind of OAuth 2.0 client app.<br>
(OpenID Connect Core 1.0, 1.2. Terminology)<br><br>there should be a client metadata entry to specify a client type (e.g.<br>client_type), and it should be treated separately from application_type.<br><br>Information about Client Type (not Application Type) is really needed<br>
to implement OAuth 2.0 authorization server correctly. Especially it<br>is needed to determine (1) whether client authentication is required<br>at the token endpoint (3.2.1. Client Authentication) and (2) whether<br>registration of redirect URIs can be omitted (3.1.2.2. Registration<br>
Requirements).<br><br>Without a client metadata entry to specify a client type, the default<br>value of client type cannot help but be left to implementations of<br>OpenID Connect Dynamic Client Registration 1.0.<br><br>IMHO, if such an entry (e.g. client_type) should be added, 'public'<br>
would be appropriate as the default value because 'client_secret' in<br>Client Registration Response is OPTIONAL.<br><br>--<br>Best Regards,<br>Takahiko Kawasaki<br><br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-05-11 5:54 GMT+09:00 John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Native clients may also be confidential if they register a unique client_id and have a secret that is provisioned in registration or out of band in some way.<br>
<br>
Web includes both confidential and public types of clients.<br>
<br>
Client type web or native came from a number of IdP like Google who do not allow the same client_id to be used across different types of clients.<br>
<br>
The type of client restricts the type of redirect_uri that is allowed to be registered.<br>
<br>
All clients must register full redirect URI and the Authorization server must match the registered redirect_uri with the one in the request.<br>
<br>
The recent covert redirect furor and the consequences of Facebook not requiring it should go some way to explaining why registering redirect_uri is important.<br>
<br>
One reason for not allowing native_apps and back end Web servers to share a client_id is privacy. A user granting a app on there phone access to a API is not the same as<br>
granting a Web site access, and a user discovering that consenting to one automatically consented to the other may not be taken well.<br>
<br>
The reason for separating the two types of clients is both good security and good privacy policy.<br>
<br>
John B.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On May 10, 2014, at 12:02 PM, Takahiko Kawasaki <<a href="mailto:daru.tk@gmail.com">daru.tk@gmail.com</a>> wrote:<br>
<br>
> If "Native Clients" in "OpenID Connect Dynamic Client Registration<br>
> 1.0, 2. Client Metadata" means "native application" in "RFC 6749<br>
> (OAuth 2.0), 2.1 Client Types" (yes it apparently does), "Native<br>
> Clients" are always 'public' clients.<br>
><br>
> If "Web Clients" in "OpenID Connect Dynamic Client Registration 1.0,<br>
> 2. Client Metadata" means "web application" in "RFC 6749 (OAuth 2.0),<br>
> 2.1 Client Types" but does not include "user-agent-based application",<br>
> "Web Clients" are always 'confidential' clients.<br>
><br>
> Using the above interpretation, application_type=native and<br>
> application_type=web correspond to 'public' and 'confidential',<br>
> respectively.<br>
><br>
> However, the requirement of application_type:<br>
><br>
> Web Clients using the OAuth Implicit Grant Type MUST only<br>
> register URLs using the https scheme as redirect_uris; they<br>
> MUST NOT use localhost as the hostname. Native Clients MUST<br>
> only register redirect_uris using custom URI schemes or URLs<br>
> using the http: scheme with localhost as the hostname.<br>
><br>
> is irrelevant to whether or not clients are "capable of maintaining<br>
> the confidentiality of their credentials" (from RFC 6749). In other<br>
> words, redirect URIs are irrelevant to how to authentication clients.<br>
> Therefore, it sounds to me that Application Type and Client Type are<br>
> different concepts.<br>
><br>
> It is weird that all "OAuth 2.0 clients" must comply with either of<br>
> the 'redirect_uris' requirements (one is for Web Clients and the<br>
> other is for Native Clients), so probably it is inappropriate that<br>
> 'web' is used as the default value when application_type is omitted.<br>
> IMHO, neither of 'native' nor 'web' should be assumed when<br>
> application_type is omitted. But, I may be missing something. Is<br>
> there any reason to impose the 'redirect_uris' requirements on all<br>
> "OpenID Connect clients"?<br>
><br>
> Anyway, my conclusion is that Application Type and Client Type are<br>
> different. And I hope that client_type (public or confidential) is<br>
> added to the list of Client Metadata and that neither of 'native'<br>
> nor 'web' is used as the default value when application_type is not<br>
> contained in client registration requests.<br>
><br>
> --<br>
> Best Regards,<br>
> Takahiko Kawasaki<br>
><br>
><br>
> 2014-05-10 10:29 GMT+09:00 Takahiko Kawasaki <<a href="mailto:daru.tk@gmail.com">daru.tk@gmail.com</a>>:<br>
>> Hello,<br>
>><br>
>> I'm wondering whether this is the right place to ask my question.<br>
>> If not, please tell me so.<br>
>><br>
>> I posted a question to StackOverflow, but no answer yet.<br>
>><br>
>> <a href="http://stackoverflow.com/q/23557801/1174054" target="_blank">http://stackoverflow.com/q/23557801/1174054</a><br>
>><br>
>> My question is "Does Application Type (OpenID Connect) correspond to<br>
>> Client Type (OAuth 2.0)?" Could anyone give me an answer please?<br>
>> Below is the detail of the question.<br>
>><br>
>> "OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata"<br>
>> has an entry named application_type, whose defined values are<br>
>> 'native' and 'web'.<br>
>><br>
>> --- Excerpt from OpenID Connect Dynamic Client Registration ------<br>
>> application_type<br>
>> OPTIONAL. Kind of the application. The default, if omitted, is<br>
>> web. The defined values are native or web. Web Clients using the<br>
>> OAuth Implicit Grant Type MUST only register URLs using the<br>
>> https scheme as redirect_uris; they MUST NOT use localhost as<br>
>> the hostname. Native Clients MUST only register redirect_uris<br>
>> using custom URI schemes or URLs using the http: scheme with<br>
>> localhost as the hostname. Authorization Servers MAY place<br>
>> additional constraints on Native Clients. Authorization Servers<br>
>> MAY reject Redirection URI values using the http scheme, other<br>
>> than the localhost case for Native Clients. The Authorization<br>
>> Server MUST verify that all the registered redirect_uris conform<br>
>> to these constraints. This prevents sharing a Client ID across<br>
>> different types of Clients.<br>
>> ------------------------------------------------------------------<br>
>><br>
>> Do these defined values correspond to 'public' and 'confidential'<br>
>> described in "RFC 6749 (OAuth 2.0), 2.1. Client Types"?<br>
>><br>
>> --- Excerpt from RFC 6749 (OAuth 2.0) ----------------------------<br>
>> OAuth defines two client types, based on their ability to<br>
>> authenticate securely with the authorization server (i.e., ability<br>
>> to maintain the confidentiality of their client credentials):<br>
>><br>
>> confidential<br>
>> Clients capable of maintaining the confidentiality of their<br>
>> credentials (e.g., client implemented on a secure server with<br>
>> restricted access to the client credentials), or capable of<br>
>> secure client authentication using other means.<br>
>><br>
>> public<br>
>> Clients incapable of maintaining the confidentiality of their<br>
>> credentials (e.g., clients executing on the device used by the<br>
>> resource owner, such as an installed native application or a<br>
>> web browser-based application), and incapable of secure client<br>
>> authentication via any other means.<br>
>> ------------------------------------------------------------------<br>
>><br>
>> If not, why doesn't the specification (OpenID Connect Dynamic Client<br>
>> Registration 1.0) have an entry to specify a client type? Is there<br>
>> any way to specify a client type (public or confidential) at the<br>
>> client registration endpoint?<br>
>><br>
>><br>
>> --<br>
>> Best Regards,<br>
>> Takahiko Kawasaki<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
<br>
</div></div></blockquote></div><br></div>