<html>
<head>
<meta name="generator" content="Windows Mail 17.5.9600.20461">
<style data-externalstyle="true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst,
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle,
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir="ltr">
<div data-externalstyle="false" dir="ltr" style="font-family: 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif';font-size:12pt;"><div>generally speaking, Ive been following how microsoft cloud and directory is rolling out its first incarnation of openid connect for commodity developers to use. And its very simple (with openid connect being merely one of several protocols that come together as a websso/webapi family). Im hardly smart, and I CAN get it (in that form).</div><div><br></div><div>There, openid connect is presented as little more than oauth2 with an id-token (assuming that the access token might be encrypted one day, denying its repurposing as an id token with claims for UIs). The openid connect world shares some control plane material with the non openid-connect profiles of the family (which includes ws-fedp, and non-openid connect profiles of oauth2). This uses old SAML-proof token features like scopes and audiences and claim names standardization. These, whether in the openid connect compatability modes or not, can be orchestrated so the control and management does the technically-govern multi-server interactions - as a distributed/partitioned TCB (NCSC Red Book model for secure networking).</div><div><br></div><div>If it helps, I for one cannot relate much of what I read in the standard to what I see being practiced. It all feels somewhat like the PKIX spec, that took 100 pages to define what certs do (which only required 15 ISO pages in 1988, and 30 pages in 2000). The number of folks using the advanced profiles of PKIX must be about 0.000001% percent of the internet, with the 80% using the bottom set of features that have not really changed much in 20 years.</div><div><br></div><div>Now, you might come back at me and say: this is NOT for general internet apps building. This is REALLY all for telcos, and the world like Neustar run in which huge numbers of management servers control the security policy that govern interworking, roaming of users in such as GSM. And thus THAT is where openid foundation is REALLY focused (and not on the likes of me, in the traditional web world).</div><div><br></div><div>have I captured the right way to think - about where emphasis of all the work is targeted?</div><div><br></div><div><br></div><div style="padding-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;"><div><font face=" 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style='line-height: 15pt; letter-spacing: 0.02em; font-family: "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 12pt;'><b>From:</b> <a href="mailto:ve7jtb@ve7jtb.com" target="_parent">John Bradley</a><br><b>Sent:</b> Sunday, May 11, 2014 11:06 AM<br><b>To:</b> <a href="mailto:daru.tk@gmail.com" target="_parent">Takahiko Kawasaki</a><br><b>Cc:</b> <a href="mailto:openid-general@lists.openid.net" target="_parent">openid-general@lists.openid.net</a></font></div></div><div><br></div><div dir="">This list is for general information about openID.<div><br></div><div>The correct place to discuss deployment and interop issues and questions is <a href="http://groups.google.com/group/openid-connect-interop?hl=en" target="_parent">OpenID Connect Interop</a></div><div>That group/list has no IPR restrictions.</div><div><br></div><div>For discussing errata or other issues with the Connect specifications the list is <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_parent">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>.</div><div>You must sign a non assert IPR agreement to contribute to the specification, as all the other WG participants have.</div><div><br></div><div>The Connect WG page lists the links and other useful information <a href="http://openid.net/connect/" target="_parent">http://openid.net/connect/</a></div><div><br></div><div>The version of Dynamic Client registration being developed by the OAuth WG in the IETF based on the Connect specification can be discussed at:</div><div><a href="https://www.ietf.org/mailman/listinfo/oauth" target="_parent">https://www.ietf.org/mailman/listinfo/oauth</a></div><div><br></div><div>To your question Registration's application type is not the same as RFC 6749 Sec 2.1 Client Types.</div><div><br></div><div>It is dynamic registration itself that allows a native app to be confidential so that section of RFC 6749 may be changed after the IETF approves dynamic client registration.</div><div><br></div><div>That section also states</div><div><br></div><div>
<div class="page">
<div class="section" style="position: static; z-index: auto; background-color: rgb(255, 255, 255);">
<div class="layoutArea">
<div class="column">
<pre><span style='font-family: "Courier"; font-size: 10pt;'>A client may be implemented as a distributed set of components, each
with a different client type and security context (e.g., a
distributed client with both a confidential server-based component
and a public browser-based component).
</span></pre>
</div>
</div>
</div>
</div></div><div><br></div><div>Connect supports this with the hybrid response types.</div><div><br></div><div>A Web application with a single client_id may contain both a public component and a confidential component. </div><div><br></div><div>The element response_type determines the flows the client can preform.</div><div><br></div><div>The default for that is the client can only preform the code flow and must use a client credential to authenticate itself to the token endpoint.</div><div><br></div><div>The response types are a finer grained and imply public and private for the hybrid components.</div><div><br></div><div>What is not possible without extending dynamic client registration are public clients that use a code grant_type.</div><div>One of the main reasons for dynamic client registration is to eliminate the need for an AS to support public clients using the code grant_type.</div><div><br></div><div>In any event we can continue this on one of the other lists.</div><div><br></div><div>John B.</div><div><br><div><div>On May 11, 2014, at 6:56 PM, Takahiko Kawasaki <<a href="mailto:daru.tk@gmail.com" target="_parent">daru.tk@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote style="margin-top: 0px; margin-bottom: 0px;"><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="_parent">ve7jtb@ve7jtb.com</a>></span>:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
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" target="_parent">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" target="_parent">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="_parent">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" target="_parent">general@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_parent">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div>
</body>
</html>