<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:m="http://schemas.microsoft.com/office/2004/12/omml" 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:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
.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;}
-->
</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=MsoPlainText>1. This is something I've never understood - <u>why does
an RP need to trust an OP</u>? <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>2. I especially don't understand <u>why the RP cares
about "integrity of the authentication process".</u> <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>3. I think this is going in the wrong direction; I would
be very disappointed <u>if OpenID lost its decentralization, and I'm not sure
why people think it needs to.<o:p></o:p></u></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'>[1] seems easy to answer.
OpenID claims to provide cryptographic proof that a user controls an Identifier:
all cryptography-based proof systems require the verifier’s trust in (a) the
validity of the proof process and (b) the correctness and effectiveness of the cryptographic
mechanisms protecting the communication of proof statements. That’s the
academic answer. There are other dimensions to the trust issue; but the one I
use is seldom disputed.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'>A persuasive answer to [2] must
address “care”. The central use case for OpenID scheme’s of enabling
OPs to assert that a user controls an Identifier seems to be to facilitate logon
to webapps over the Internet, logons that thereafter encourage reputations to
be contributed, collated and published. Do I care that a savvy competitor to the
business generating my livelihood can interfere with my EBay reputation by
fracking with the OpenID technology? Yes. Do I care that my virtual E-bay reputation
in a virtual world is being hacked and potential for virtual riches are being
lost due to exploitable vulnerabilities in the virtual-OpenID scheme? No! It’s
part of the game.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'>On [3], we must first ask: What
(valuable) decentralization property is being lost? I think OpenID vastly understates
in its design rationale the benefits of its use of and advancement of decentralized,
trusted name server-based Identity protocols. However, this is my analysis of
its decentralization benefits, an analytical claim set which is rather different
to the decentralization benefits that OpenID actually claims for itself: anyone
can throw up a server and start operating, without interaction with third parties.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'>The only example I can think of
in the web-space where the right to throw up a relying party server receiving
webSSO assertions is “controlled” … is in the Shibboleth
community – an NSF “Internet2” experiment whose research
goals include addressing privacy-based release of sensitive and personal attributes.
There, “vendors” must be first “sponsored” by a
higher-ed institution before the deployment of Shibboleth RP servers will actually
officially interwork with all the (hundreds of) Providers of assertions. The sponsoring
higher-education institution is presumably vouching for – and giving starting
reputation to - that party; which can and thereafter presumably sell stuff to
students, staff and others vendors associated with Universities.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'>If we lose the central thesis
of OpenID, are we therefore now risking “succumbing” to the Shibboleth
vision of the webspace, becoming subjected to the whim of the evil overlords of
Academia?<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'>There is a personal caveat to
this issue, however. In 1995, VeriSign imposed a policy on browser vendors that
they shall undergo a quick eval of their client SSL code, before being licensed
to use the VeriSign PKI roots, controlling access to Netscape https listeners.
Far from evil or exploitative of monopoly power, this policy existed because the
same critical crypto error/bug from some source file everyone started with was
being repeated over and over again, compromising the security of – and overall
reputation of - SSL. Quick inspection; massive community benefit. We had to just
put up with the evil overlord label that came along with the policy, being web martyrs.<o:p></o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span style='color:black'><o:p> </o:p></span></p>
</div>
</body>
</html>