<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Vipin Rathor wrote:
<blockquote
cite="mid:33ab2aef0802282319y6d41b9d6m9c3f3473df85f1ed@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">This only solves the problem of eavesdropping, not trust.
</pre>
</blockquote>
<pre wrap=""><!---->I'm disagree with this. As per my understanding, the digital
certificate provides integrity, authentication and non-repudiation.
(<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Public_key_certificate">http://en.wikipedia.org/wiki/Public_key_certificate</a>). And with the
help of trusted third-party (CA), it provides trust relationships.
Is there something with OpenID requirements, that I'm not getting?</pre>
</blockquote>
Yes, please let me explain it and also answer other replies on the
subject.<br>
<br>
Who is the relying party (RP)?<br>
<br>
- In the case of OpenID the relying party is the web site which sets up
a facility to allow login with an OpenID. This is different as compared
to secured web sites in PKI, where the visitor of a web site is the
relying party. Therefore with OpenID the one relying on the information
received from the provider is the web site, not the user and not the
provider.<br>
<br>
<br>
What is it that we as the relying party want?<br>
<br>
- The RP wants to be assured, that <br>
<br>
<blockquote>1.) The provider indeed authenticated the user according to
a certain established standard. In OpenID language this is what the
PAPE extension is for. PAPE allows the RP to request certain
authentication policies which the provider implements or not. (See
<a class="moz-txt-link-freetext" href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.html#anchor13">http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.html#anchor13</a>
)<br>
<br>
2.) That the operator operates his facility to a certain level of
accepted standard and security. That is, because if the operator
doesn't, the above assurances have no value altogether.<br>
<br>
</blockquote>
What does SSL solve for the exchange of data between the provider, user
and the RP? Eavesdropping. Not much more, because the RP (which is a
web site after all) isn't going to validate who the operator is (except
in a white list scenario). The RP doesn't care really WHO he is, but
rather HOW he operates. Does this explains it?<br>
<br>
<br>
<div class="moz-signature">-- <br>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td colspan="2">Regards </td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
<tr>
<td>Signer: </td>
<td>Eddy Nigg, <a href="http://www.startcom.org">StartCom Ltd.</a></td>
</tr>
<tr>
<td>Jabber: </td>
<td><a href="xmpp:startcom@startcom.org">startcom@startcom.org</a></td>
</tr>
<tr>
<td>Blog: </td>
<td><a href="http://blog.startcom.org">Join the Revolution!</a></td>
</tr>
<tr>
<td>Phone: </td>
<td>+1.213.341.0390</td>
</tr>
<tr>
<td colspan="2"> </td>
</tr>
</tbody>
</table>
</div>
</body>
</html>