<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:1875341692;
mso-list-type:hybrid;
mso-list-template-ids:596308180 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>One thing we might recognize as a community that there are now
three sub-communities messaging on openid (and 1.5 years ago there was only one
– and it had a typical evangelist-phase tone). <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Certain potential adoptees (as an industry) almost bought into
the message of 1.5 years ago (the paradigm shift of user centric content, delegation
operated by parties other than OPs, user portability, correlation of ids with
content left at a hundred RPs, …) as a reason to pick openid SSO over
SAML SSO, etc). That message is now “almost” being repudiated. Perhaps
folks remember when there was the notion that ancien security was out, and nuveau
“identity” was in? Anyone who thought in the memes of “security”
was not going to get “identity” in the web2.0 era (despite I&A
being one of the staples of any “corporate” security program).
Within a year, things reverted somewhat to normal (focusing on the CISO’s
needs and the standard governance points).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There is the google message – making openid into a solid piece
of enterprise middleware that can facilitate app outsourcing by enterprises to cloud
providers – and thence link enterprises to consumers/subscribers. Instead
of ws-federation redirect URI or ws-trust, do openid redirects. Let host-meta
el al do for app domains what sts metadata would otherwise do when orchestrating
the proxying of w-security/ws-trust communications through a value-adding SOA cloud
provider.<o:p></o:p></span></p>
<p class=MsoListParagraph><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> <o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There is the relic of the social network message – making openid
into a trust fabric for the public space (accessing even .gov under that
community’s paranoid privacy practices). These web2.5 memes address long
term social issues around privacy policies and the fundamental TTP trust
relationship megaportals have with consumers. (This whole issue set recaptures
the moment of VeriSign birth to my mind, in a earlier era.) Today, this is
perhaps most obviously represented by LiveID – the public portal of half
a billion users (where I’m trying to distinguish the LiveID pitch from
the Azure group’s pitch, just within the Microsoft’s own storyline)<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There is the continuing message from several sources –
derived from the SUN/Concordia message of about 2 years ago –that openid
is forever a lightweight SSO (in comparison to SAML2). It is as yet technically
“unfinished” and cannot be legitimately applied yet to anything of
any sensitivity or criticality -- until “elementary” technical and
governance issues have been addressed (see above). Half the time this comes across
as the old SAML vendor community attempting to invoke market delaying tactics
(bad! on them), and half the time it seems to be about the SAML technical folk re-invigorating
their community for a multi-protocol world that can share the stage with openid
and ws-fed [and perhaps even foaf+ssl] (good! on them).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Ive never been before to a internet identity workshop, which I
hope to do next week. I’m hoping it will somehow address the changing of
the message on user centric’ness in identity systems. I don’t believe
it’s something than can simply be spun away.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Dirk Balfanz [mailto:balfanz@google.com] <br>
<b>Sent:</b> Monday, October 26, 2009 1:51 PM<br>
<b>To:</b> Peter Williams<br>
<b>Cc:</b> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] user centric delegation vs portability: LRDD :
competing threats: the consumer's fear hypothesis<o:p></o:p></span></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoNormal style='margin-left:.5in'>Hi Peter, <o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>thanks for your thoughtful
response. <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>As I see it, provider-independent
identities are merely a means to an end. They shouldn't be the one-and-only
litmus test applied to single sign-on solutions.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>To me, what's important is that
users can get quickly to a personalized experience across the web. That is -
when I see a new web site, and it promises a useful service (which requires an
account), I can immediately start using it. With just a few clicks, I can tell
the service who I am, connect it to other services I use that it needs data
from, etc.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>I like the idea of provider-independent
identities. It is one (although not the only) way to allow me to continue to
use said service even when/if I leave my identity provider. However, that's but
one of many considerations we need to make. If the only technical solution we
can come up with is one that (1) features provider-independent identities and
(2) increases hurdles to personalized web content (e.g., is too difficult to
use by the majority of users), I have to admit I would start looking into
whether relaxing requirement (1) could possibly help with problem (2) (not
saying that currently OpenID falls into this category - just illustrating my
priorities). <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>It's true that I am a bit nervous,
from a security point-of-view, about the delegation model used by OpenID today.
As OpenID moves into the mainstream, I'm worried that a single
"defacing" attack (i.e., one in which an attacker alters the content
served from a certain server) can move the identity provider for a whole DNS
domain to some machine under the control of an attacker. <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Finally (as John points out),
delegation and provider-independent identities certainly aren't prevented by
the proposed OpenID discovery mechanism. Sites like Blogger or Facebook, etc.,
could leave it up to their users to pick (and change) OpenID providers. If you
have your own domain, you can pick (and change) your identity provider. But if
you're one of 300,000 IBM employees, there are certain things you can't pick
about your work account - you can't pick your email provider, you can't pick
your calendaring software, and you can't presumably pick your identity provider
- professionals at IBM who get paid to worry about this stuff will pick one for
you that they are reasonably sure will not, say, put into jeopardy the 401k
accounts of the combined IBM workforce (because, hypothetically speaking, IBM
uses OpenID to log their employees into <a href="http://fidelity.com">fidelity.com</a>). <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>We need a single sign-on solution
for the Web that works both for Blogger/Facebook/consumer use case as well as
the IBM use case.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><br>
Dirk.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:
12.0pt;margin-left:.5in'><o:p> </o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>On Sun, Oct 25, 2009 at 3:57 PM,
Peter Williams <<a href="mailto:home_pw@msn.com">home_pw@msn.com</a>>
wrote:<o:p></o:p></p>
<p class=MsoNormal style='margin-left:.5in'><br>
I found the writeup at <a href="http://hueniverse.com/2009/09/openid-and-lrdd/"
target="_blank">http://hueniverse.com/2009/09/openid-and-lrdd/</a><br>
convincing, technically. It moved the whole set of technical delegation<br>
issues forward. It told a story. It was well written.<br>
<br>
A. It reminded me of what Ping Identity once proposed for<br>
dynamically-sharing SAML metadata between IDPs and (affiliations of) SP:<br>
use a url-factory rule to deduce a URI from a domain name, get metadata from<br>
said URL, and apply https/domain-cert controls to test for a saml entities<br>
authority... to make assertions for that domain name. Optionally, sign the<br>
metadata (much as one optionally signs XRDs). All Pretty obvious stuff<br>
...but effective.<br>
<br>
B. It reminded me of the leap forward of myopenid, when hosting outouurced<br>
OPs via OPX (which uses DNS control principles to enable domain admins to<br>
prove the delegated domain is authorizing the outsourcer to speak for it).<br>
<br>
C. And, it reminded me of openid2, in that there are various flow fallbacks.<br>
These allows communities to choose different flows (and thereby address<br>
different players issue sets) when delegating and locating providers.<br>
<br>
What I didnt like what the bias I heard throughout the writeup - concerning<br>
the criteria I described in C.<br>
<br>
Unlike the openid communities traditional mission (empower users, and give<br>
them control over their data and names), there was a fear message at the<br>
heart of it: focus on all that which COULD go wrong. And into that fear<br>
rides the fearless knight on a white horse... the OP.<br>
<br>
The fear said, users are easily duped and cannot in any case be trusted to<br>
get it right - unlike the corporate CISO in whom we must trust. (Peter is a<br>
CISO, by the way). Furthermore, we will bias the fallbacks so corporate CIOs<br>
can control, before users control. If this was law, folks just coded their<br>
bias in favor of the CIO and against the user/subscriber - through the<br>
formulation of the legal presumptions.<br>
<br>
Now, this bias may well be fine (if your audience is corporate buyers of<br>
outsourced apps, leveraging openid protocols to get login sessions and<br>
attributes). And, perhaps that is who the vendor is pitching its LRPP<br>
technology to .<br>
<br>
But, surely, the openid movement more generally needs to be focussed more<br>
widely than only corporate sales -it also has consumer interests to<br>
consider. If it fails here, it will risk falling into the pit that SAML fell<br>
into - and fail to stay current with the larger currents of the web itself.<br>
Historically (in the years before openid challenged SAML), every corporate<br>
SAML link took a year, cost a million, was the bane of the CIO life, and<br>
noone did two if they could avoid it.<br>
<br>
Now, as oft associated with the Facebook brand, there are interplays between<br>
the corporate control and consumer rights - particularly over data ownership<br>
and identity control isues. And some mega-brands do better than others in<br>
getting the balance right (and some actively hamper the user when<br>
dis-associating from the brand, once things go sour). Some brands infamously<br>
create explicit exit barriers (preventing you from exporting your contacts<br>
to a file, say, or impose legal controls that limit just who you may (NOT)<br>
choose to also work with).<br>
<br>
When considering whether LRPP MAY be right for openid movement, we must<br>
reflect that the openid movement is -or at least WAS - in the middle of<br>
these issues, and took a position. It traditionally allowed for identifier<br>
portablity and data rights. If you were to lose rights of access at an OP<br>
(paypal dumps peter for violating service rule X) ... delegation ensured<br>
that this 1 OP's suspension of Peter made no difference to Peter's private<br>
life and Peter's relationship with RPs (becuase the protocols automatically<br>
fell back on the next OP to which peter had delegated YOUR name). Peter<br>
either could take such pre-cautions, or not - depending on his needs.<br>
<br>
What Im hearing in the LRPP story is not consistent with the original openid<br>
user-centric story - targeting social networks (vs corporate application<br>
outsourcing). The fear line seems to be implicitely denying the legitimacy<br>
of user centric identity. In its marketing line, it seems to be saying that:<br>
its far more important for consumers to be free of fear, than be free of
a<br>
provider (when the relationship goes sour).<br>
<br>
Interesting changes going on in this movement!<br>
<span style='color:#888888'><br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a
href="http://www.nabble.com/user-centric-delegation-vs-portability%3A-LRDD-%3A-competing-threats%3A-the-consumer%27s-fear-hypothesis-tp26052720p26052720.html"
target="_blank">http://www.nabble.com/user-centric-delegation-vs-portability%3A-LRDD-%3A-competing-threats%3A-the-consumer%27s-fear-hypothesis-tp26052720p26052720.html</a><br>
Sent from the OpenID - General mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<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></span><o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
</div>
</body>
</html>