<html>
<head>
<meta name="generator" content="Windows Mail 17.5.9879.20671">
<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>so that's good and bad news!</div><div><br></div><div>its good that advanced features exist. Its bad that we have no simple table, hosted at the opened foundation, that showcases which of the 1000 features of the opened connect spec family actually exist… in products/services, today. That LACK of “PROMOTION” about feature options is what Im griping about, since Id be aiming to let 20,000 CISSP take charge of how opened connect is applied rather than worry about the same old 30 government paid/affiliated consultants/contractors, writing specs based on knowhow and practice learned in mostly hidden US government projects. I want to see the flower blossom, rather than the seed germinate.</div><div><br></div><div>So do I like the design of the feature, in question? no! It only widened my trust gap.</div><div><br></div><div>“This specification defines how an OpenID Connect Relying Party can dynamically register with the End-User's OpenID Provider, providing information about itself to the OpenID Provider, and obtaining information needed to use it, including the OAuth 2.0 Client ID for this Relying Party.”</div><div><br></div><div>The last thing I want is big fedramp-monitored cloud IDPs (OPs) to have control of my RPs. I want a gateway to supplant the role of the IDP (while perhaps playing much the same technical role, mentioned in the spec). I don't want to be under the policy thumb of vendors/government that use standards or audit or insurance or contracting or any other means of using soft policy control mechanism to project national policies (indirectly). If I subscribe to VISA as a Russian bank, I want as be Russian regulator to be able to dump visa - and easily replace it with another vendor - the moment visa becomes a pawn in some US/Russian power conflict, exerting soft power. This is my right (if I have any sense); preparing to resist the explicit soft-attack of dependency creation.</div><div><br></div><div>ok I said that in somewhat dramatic terms (speaking as someone who used to be paid in the 90s to do US government projects, all about soft power projection through DoD’s PKI program and the mission to “lead” IETF vendors to do US government bidding concerning spying, dependency injection, and “information assurance” programs).</div><div><br></div><div>What Id like to see is a non US-government centric side of the foundation leading elements that are NOT about some cyberwar mission. Then we have a balance - so critical for trust formation and the emergence of a civilian economy based on all the excellent technical work (that DoD/NSA/NIST/DHS/DARPA et al OFTEN seed, very usefully).</div><div><br></div><div> <br></div><div data-signatureblock="true"><div>Sent from Windows Mail</div><div><br></div></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:n-sakimura@nri.co.jp" target="_parent">Nat Sakimura</a><br><b>Sent:</b> Tuesday, February 17, 2015 10:29 PM<br><b>To:</b> <a href="mailto:home_pw@msn.com" target="_parent">peter Msn</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 dir="ltr"><div>Hi Peter, </div><div><br></div>If I understand correctly, SP Affiliation can be achieved by sector identifier. <br>See <a href="http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation" target="_parent">http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation</a><br><div><br></div><div>For token exchange, IETF OAuth WG is working on a spec. </div><div><a href="https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-00" target="_parent">https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-00</a><br></div><div><br></div><div>Perhaps this is something your are looking for? </div><div><br></div><div>Nat</div><div><br></div></div><br><div class="gmail_quote">On Wed Feb 18 2015 at 14:57:51 Peter Williams <<a href="mailto:home_pw@msn.com" target="_parent">home_pw@msn.com</a>> wrote:<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;">
<div>
<div>
<div style="font-family: Calibri,sans-serif; font-size: 11pt;">Saml has a feature that I like, called sp affiliations. In short, if a local name binding is assigned by one sp/rp, all other RP in the affiliation get the same value.<br>
<br>
That is an example of sp centric architecture.<br>
<br>
If one has a cluster of gateways (at ip switching points close to a distributed set of RPs) it takes quite some engineering to share those names, enable a primary RP to assign the names, etc. The process can even be security critical, which obviously heightens
the engineering left further.<br>
<br>
One non (saml) standard architecture point can include swapping tokens for Kerberos tickets, to leverage Kerberos enforcing functions for delegation of privilege in operating system (networked) trusted computing bases.<br>
<br>
Those two examples hide security information from idps, and also prepare for an easy exit of an idp from the sp centric architecture (when an idp changes rules, say, in an unacceptable manner to the sp affiliation.) They limit dependency, at a policy level.<br>
<br>
While it's wonderful that a contrasting idp-centric architecture exists, allowing such as a media rendering box (eg appletv) to show such as a YouTube app that signs up the device to YouTube subscription via a pc-based process *using oauth to orchestrate things*,
not all web security models are about devices and apps, or app subscriptions to media, or syncing such subscriptions across multiple devices.</div></div></div><div><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;"><br>
<br>
<br>
<br>
Sent from my Windows Phone</div></div></div><div><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;"></div>
</div>
<div dir="ltr">
<hr>
<span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">From:
</span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:n-sakimura@nri.co.jp" target="_parent">Nat Sakimura</a></span><br>
<span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Sent:
</span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">2/17/2015 8:55 PM</span><br>
<span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">To:
</span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:home_pw@msn.com" target="_parent">Peter Williams</a></span><br>
<span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Cc:
</span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:James.H.Manger@team.telstra.com" target="_parent">Manger, James</a>;
<a href="mailto:openid-general@lists.openid.net" target="_parent">openid-general@lists.openid.net</a></span><br>
<span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Subject:
</span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">Re: [OpenID] Switching from OpenID 2.0 to OpenID Connect for Google logins to <a href="http://openid.net" target="_parent">openid.net</a></span><br>
<br>
</div></div><div>
<div>
<div>Hi Peter, <br>
<br>
Could you elaborate on "this area" a bit more, please? <br>
We could certainly consider additional activities. <br>
<br>
Best, <br>
<br>
Nat<br>
<br>
On Tue, 17 Feb 2015 09:54:32 -0800<br>
Peter Williams <<a href="mailto:home_pw@msn.com" target="_parent">home_pw@msn.com</a>> wrote:<br>
<br>
> Shame openid foundation doesn't lead in this area, formentung common<br>
> architecture practices for RP communities, that are independent of<br>
> idp/cloud vendor.<br>
<br>
<br>
-- <br>
Nat Sakimura (<a href="mailto:n-sakimura@nri.co.jp" target="_parent">n-sakimura@nri.co.jp</a>)<br>
Nomura Research Institute, Ltd. <br>
<br>
PLEASE READ:<br>
The information contained in this e-mail is confidential and intended<br>
for the named recipient(s) only. If you are not an intended recipient<br>
of this e-mail, you are hereby notified that any review, dissemination,<br>
distribution or duplication of this message is strictly prohibited. If<br>
you have received this message in error, please notify the sender<br>
immediately and delete your copy from your system.<br>
</div>
</div>
</div>
______________________________<u></u>_________________<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/<u></u>mailman/listinfo/openid-<u></u>general</a><br>
</blockquote></div>
</div></div>
</body>
</html>