<html><head><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.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><style><!--
.hmmessage p {
margin:0px;
padding:0px;
}
body.hmmessage {
font-family:Calibri;
font-size:12pt;
}
--></style><style><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin:0in 0in 0pt 0.5in;
}
li.MsoListParagraph, div.MsoListParagraph {
margin:0in 0in 0pt 0.5in;
}
div.MsoListParagraph {
margin:0in 0in 0pt 0.5in;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin:0in 0in 0pt 0.5in;
line-height:115%;
}
li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin:0in 0in 0pt 0.5in;
line-height:115%;
}
div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin:0in 0in 0pt 0.5in;
line-height:115%;
}
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin:0in 0in 0pt 0.5in;
line-height:115%;
}
li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin:0in 0in 0pt 0.5in;
line-height:115%;
}
div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin:0in 0in 0pt 0.5in;
line-height:115%;
}
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin:0in 0in 0pt 0.5in;
line-height:115%;
}
li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin:0in 0in 0pt 0.5in;
line-height:115%;
}
div.MsoListParagraphCxSpLast {
margin:0in 0in 0pt 0.5in;
line-height:115%;
}
.hmmessage p {
margin:0px;
padding:0px;
}
body.hmmessage {
font-family:Calibri;
font-size:12pt;
}
--></style></head><body><div data-externalstyle="false" style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif;font-size:16px;"><div>In my little demo of remoted account linking, designed merely to test “what is cheap, unfettered, and commodity, today?” I used no openid connect protocols (or other elements of standardization) for applying the linking of multiple names, from multiple IDPs. All I did was take the multi-protocol STS concept and bridge some protocols together, with a (stored) claims transformation STS ...managing “aggregated” name/identifier claims in one of the hops. Furthermore, I used commodity-grade components - as represented by the windows developer community.</div><div> </div><div>The STS concept is of course a variant of the old X.500 chaining DSA model from ISO/ITU-T, with certain peering DSAs trusted to act as authentication agents issuing and re-using signed (chained) responses signed in turn by trusted peers. Now, as then, standards for such agents never really cared about bits and bytes, active or passive flows, whether ASN.1 notation or JSON concrete encodings are used; but better architects focused on the architecting of trust “through network structures”. Obviously, even that reference is but a variant ....of message-based routing; which similarly used/uses trusted routing and re-addressing and routing/addressing of gateway endoints themselves (typically over a distinct physical circuit to solve the trusted discovery problem). </div><div> </div><div>Even in the (older) layer 5-7 InfoSec security world perhaps one remembers the old role of the MLS guard - responsible for translating security policyies from system high to low. This “geateway” required a person using a trusted process in user space to override the otherwise automatic decisions of the TCB in kernel, fiddling endlessly and automatically with a billion file blobs. In an email world particularly, the automated policy decisions of the TCB based on formal policy rules for classes and categories of data would regularly be non sensible, establishing the need for policy “overriding” - by a sensible person trying to get real work done. Security policy and governance culture (which always evolves into the big stick, as it professionalizes) got in the way of interworking as much then, as now.</div><div> </div><div>Now, the management of claims transformation for “name claims” in that windows tooling demo is essentially identical to a favorite wordpress plugin - tied to the original openid protocol and concept. To be honest, “that was openid” - in the UCI sense. The protocol on the wire and all the silly renaming of the SAML entities was irrelevant. UCI in openid was captured by users exploiting all that and being involved at the UI - and then leveraging what someone here used to call polyarchical naming structures (from graph-aware class layer 7 naming servers, ideally) - that might remote the management of the linking records.</div><div> </div><div>OK.. so while we see some graph-notions supporting webSSO arriving (in the facebook/google world, and now the Azure AD directory world) what users see and working is something simpler than graphs, XDI, XRIs, or similar. They see the UI of wordpress or the windows implementation of openid/oauth - primary examplars of which now have some or other user-facing screens that intends the user to bind multiple names to the primary account name. And unbind them, at will.</div><div> </div><div>Now this idea of explicit user control of the name linking act just happens to come as a **standard ** scaffolding pattern in the tools used by millions of Microsoft windows developers THIS YEAR. It didnt, last year (and that’s the point). The “exposure” of this pattern is now MUCH higher than it was when. I don't know how many windows developers there are, but they are all getting two doses of education by default: SSO is here and normal, and sso comes with account linking of names. Oh, and they get to use Andrew’s toolkit too...with properly architected classes for a stack of protocols.</div><div> </div><div>Now, all I did beyond what any 18 year old novice programmer can do by running a standard training example was put the standard UI functionality for that account linking into an agent acting as a protocol bridge, rather than have the functionality continue to be co-resident with the SP exposing the application logic. </div><div> </div><div>Now, if openid connect services happen to do the above using protocolar standards for the remoting act; ...then I have no objection, in principle. I could not care less whether I use ws-fedp, trusted name resolution protocol in XRI servers, or something else. That is ... so long as the remote party doing the “name claim aggregation” is an agent of the user or the SP application ... and not the projection or otherwise the agent of the IDPs. It has to be an RP-centric federation party (to use Cameron-community terminology). In my SAML1-centric terminology, it has to be supporting the interests of an SP affiliation. (One never hears such discussions in the NSTIC world, for example.)</div><div> </div><div>So the test of openid connect is not the protocol. (That's is presumably easy, and mere engineering). It’s the culture of operations, that matters. Are there going to be (multi-tenant) TTP-class providers willing to act for SP communities, and be their agent adn thus be beholden to the SP’s interests? Such a model of n-party trust formation is simply exposing "a fair” negotiation (for higher valued transactions) - as already found in (US) real estate (and (US) banking too), where EACH party has an agent, in a four corner model.</div><div> </div><div>Openid in its original UCI phase was a 4-corner model. As practiced today, its a three corner model - with IDPs also controlling or governing the act of reliance. Perhaps I should wait and see how OpenID connect is *actually delivered* by TTPs - in 3 or 4 corners. For it seems that this criterion is that which is the test of its appropriateness... beyond the market of selling javascript apps via app stores.</div><div data-signatureblock="true"><div> </div><div> </div><div>Sent from Windows Mail</div><div> </div></div> <div style="border-top-color: rgb(225, 225, 225); border-top-width: 1px; border-top-style: solid;"> <strong>From:</strong> Nat Sakimura<br> <strong>Sent:</strong> November 4, 2012 3:35 AM<br> <strong>To:</strong> Peter Williams<br> <strong>CC:</strong> openid-general@lists.openid.net<br> <strong>Subject:</strong> Re: [OpenID] One developer's first encounter with account chooser (openid connect?)<br> </div> <div> </div><div>Looks like what you have done is essentially what we call in OpenID Connect world 'aggregated claims model'. </div>
<div><br></div><div>As to the role of user centric identity (UCI) is concerned, let us look at Kim Cameron's definition. </div><div>
<div title="Page 6" class=" page">
<div class=" layoutArea">
<div class=" column">
<ul>
<li style='font-family: "Calibri"; font-size: 10pt;'>
<p><span style='font-family: "Calibri,Bold"; font-size: 10pt;'>User-centric</span><span style="font-size: 10pt;">: Structured so as to allow users to conceptualize, enumerate and control their relationships </span><span style="font-size: 10pt;">with other parties, including the flow of information. </span></p>
</li>
</ul>
</div>
</div>
</div>
<div title="Page 5" class=" page">
<div class=" layoutArea">
<div class=" column">
<ul>
<li style='font-family: "Calibri"; font-size: 10pt;'>
<p><span style='font-family: "Calibri,Bold"; font-size: 10pt;'>Identity</span><span style="font-size: 10pt;">: The fact of being what a person or a thing is, and the characteristics determining this.</span><span style="font-size: 10pt;"> </span></p>
</li>
</ul>
</div>
</div>
</div><div>(source: <span style="line-height: 19px; font-size: 15px; white-space: nowrap;"><a tabindex="-1" href="http://www.identityblog.com/wp-content/images/2009/06/UserCentricIdentityMetasystem.pdf">http://www.identityblog.com/wp-content/images/2009/06/UserCentricIdentityMetasystem.pdf</a> )</span></div>
<div><br></div><div>Taken this way, UCI is very much alive in OpenID Connect. </div><div><br></div>=nat via iPhone</div><div><br>Nov 3, 2012 11:48、Peter Williams <<a tabindex="-1" href="mailto:home_pw@msn.com">home_pw@msn.com</a>> のメッセージ:<br>
<br></div><blockquote><div><div style='font-family: Calibri,"Segoe UI",Meiryo,"Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","Khmer UI","Nirmala UI",Tunga,"Lao UI",Ebrima,sans-serif; font-size: 16px;'>
<div>I was never originally very excited by user-centric identity or the notion of the self-signed CA of SSL website (earlier) - coming partly from the highly indoctrinated, yes-sire, no sire, govt world of centralized security policy management, big sticks, mega-money, and reams of audit paperwork that nicely masks over the (typically wide) cracks - to suit the desired governance doctrine of the day.</div>
<div> </div><div>But, over the years, folks of the cryptoanarchy lilt did persuade me to recognize their cause - mostly because no harm has actually emerged. And, a certain novel trust doctrine emerged furthermore - based on low assurance crypto, and low-assurance key distribution. It scales in a manner which I think W3C founder-class thinkers once-called “webby”.</div>
<div> </div><div>Anyways, I don't hear much about “user centric” identity today. Perhaps the funding has gone away, as most folks seem to be taking a trickle of silver coin hoping for the talons of gold on offer from Augustus’ treasury. So I thought I’d go retro and just now consider the openid pitch of a few years ago (remembering who used to say what, back then). If one plays with those discarded ideas NOW - using modern forms of the technology - what can one now do? Note I way sne, not we - hoping to capture the individual as a person, distinguished from you as some corporate “subscriber”.</div>
<div> </div><div>I asked myself: is there a role for user centric identity any longer in the openid community? If so, what can one build in a day? (See <a tabindex="-1" href="http://wp.me/p1fcz8-35W">http://wp.me/p1fcz8-35W</a> for my own effort). Since the UCI term has no real meaning these days, I interpreted it in the sense of a DARPA working in the early internet: get to “survivability”, for the individual. </div>
<div><div> </div><div>Is “UCI” really dead, in openid land? Or is there a new word for it?</div><div> </div><div>Sent from Windows Mail</div><div> </div></div> <div style="border-top-color: rgb(225, 225, 225); border-top-width: 1px; border-top-style: solid;">
<strong>From:</strong> Peter Williams<br> <strong>Sent:</strong> October 27, 2012 12:39 AM<br> <strong>To:</strong> <a tabindex="-1" href="mailto:openid-general@lists.openid.net">openid-general@lists.openid.net</a><br> <strong>Subject:</strong> RE: One developer's first encounter with account chooser (openid connect?)<br>
</div> <div> </div>
<div dir="ltr">Well I should give apologies to Google, as there IS a local login function in its account creator wordpress integration. Though ...it did take a week to find it. If you type a local account name into the box labeled "email", it does a classical local login (with local password challenge). <br>
<br><div> </div> </div>
</div></div></blockquote><blockquote><div><span>_______________________________________________</span><br><span>general mailing list</span><br><span><a tabindex="-1" href="mailto:general@lists.openid.net">general@lists.openid.net</a></span><br>
<span><a tabindex="-1" href="http://lists.openid.net/mailman/listinfo/openid-general">http://lists.openid.net/mailman/listinfo/openid-general</a></span><br></div></blockquote>
</div></body></html>