<!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">

Hi Peter,<br>

<br>

Agreed! As I mentioned in my blog, the mechanisms in the protocol

extensions created by David are at least sufficient to start with (and

might be extended, what identity verification concerns). So the only

question remains, how can we get that assertion of proof? I made a

proposal...but maybe there are other (and better) ideas to tackle that?<br>

<br>

Peter Williams wrote:

<blockquote

 cite="mid:18498B6C4F691545B050D6A531BA44950297B346@rapmsg02.rapnt.com"

 type="cite">

  <pre wrap="">OpenID is not a trust system. Its a proof system (which is worse). It claims that a cryptographic proof allows a verifier to determine that a Provider on the net has established that user X owns/controls identifier I. This is not a new line of research, note; so no need to rush out on the patent front, folks! Research into trusted name servers/services for the internet dates back to mid 80s.

Cryptographic Proof systems (based on DH or any other public key crypto using scheme) almost always leverage automated trust systems as an underlying mechanism. The nature of public key algorithms is such that one must have a means of distributing the public key (or DH partial ) in a trustworthy manner. Otherwise, attackers spoof the keys/DH-partials to spoof the crypto, to spoof the proof, to spoof the central claim of OpenID.

The 2 questions folks are repeatedly asking are:-

1. should there be varying grades of protection for the delivery of the proof statement ("assurance levels")

2. should there be varying grades of proof offered ("denoting the 'strength' of user auth/control")

1 seems already answered. OpenID2.0 designs already decide to offer to cryptographic strength options for the mac'ing process: SHA, and SHA-256. OpenID2.0 also now recommends direct mode communciation of association-setup, also, avoiding the need to evaulate whether the user's browser is trustworthy - when redirecting the message flow over two back-back https channels.

2 seems to be "in proposal"

What is missing is the ability for the RP within the same protocol session to reject the assertion, claiming proof strength X, sending it back requiring: "Y or better".</pre>

</blockquote>

<br>

<div class="moz-signature">-- <br>

<div><font face="Arial" size="2">Regards</font></div>

<div><font face="Arial" size="2"> </font></div>

<div><font face="Arial" size="2">Signer:      Eddy Nigg, StartCom Ltd.</font></div>

<div><font face="Arial" size="2">Jabber:      <a class="moz-txt-link-abbreviated" href="mailto:startcom@startcom.org">startcom@startcom.org</a></font></div>

<div><font face="Arial" size="2">Phone:       +1.213.341.0390</font></div>

</div>

</body>

</html>