<html>
<head>
<meta name="generator" content="Windows Mail 17.5.9600.20461">
<style><!--
.EmailQuote {
margin-left:1pt;
padding-left:4pt;
border-left:#800000 2px solid;
}
--></style><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><br></div><div data-signatureblock="true">so how does the protection philosophy prevent one “authorized” app getting the token, and then turning around and reminting it to now act as issuer to others (and thus escaping Google’s governance policy)? That is, any one RP is an IDP (to its community of downstream RPs, distrustful of Google but trustful of my act of reliance)?</div><div><br></div><div>What I found, nearly 20 years ago in the web (vs military PKI) space, was that the more you governed in this kind of area, the more folks worked around it. It became pointless, as folks just didn’t want to be governed (by a Google or a VeriSign…). Not being particularly exceptional, I didnt feel it was my place to impose…</div><div><br></div><div>General Hayden (the General Keith of the day) was not too happy with me, as a vendor, and arranged for personal sanctions. He wanted the VeriSign of the day (the Google of today) as enforcer of “public” trust policy. That we/I had no effective control over the re-issuing process was irrelevant (one was to keep the faith…at all costs). That it turned me into the PKI-Nazi (supposed to be threatening sanctions on unwilling folks’ E&O policies, in the Aussie version of the General) was what “delegation” of national power to be a commercial IDP/CA was meant to mean - in the regulated space of post 2001 CAs (doing cert issuing, vs token issuing).</div><div><br></div><div><br></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> Saturday, May 10, 2014 1:54 PM<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="">
<div class="PlainText">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>
<br>
<br>
On May 10, 2014, at 12:02 PM, Takahiko Kawasaki <daru.tk@gmail.com> 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 <daru.tk@gmail.com>:<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>
> _______________________________________________<br>
> general mailing list<br>
> general@lists.openid.net<br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_parent">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
<br>
_______________________________________________<br>
general mailing list<br>
general@lists.openid.net<br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_parent">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
</div>
</div>
</div>
</body>
</html>