<HTML dir=ltr><HEAD></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV id=idOWAReplyText38478 dir=ltr>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Eddy Nigg (StartCom Ltd.)<BR><B>Sent:</B> Thu 3/20/2008 10:19 AM<BR><B>To:</B> Peter Williams<BR><B>Cc:</B> general@openid.net<BR><B>Subject:</B> Re: [OpenID] Thinking About OpenID.com<BR></FONT><BR></DIV></DIV>
<DIV>+1<BR><BR></DIV>
<DIV class=moz-signature>-- <BR></DIV></BLOCKQUOTE>
<DIV class=moz-signature>
<TABLE cellSpacing=0 cellPadding=0 border=0>
<TBODY>
<TR>
<TD colSpan=2>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P>Regards </P></BLOCKQUOTE></TD></TR>
<TR>
<TD colSpan=2>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P> </P></BLOCKQUOTE></TD></TR>
<TR>
<TD>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P>Signer: </P></BLOCKQUOTE></TD>
<TD>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P>Eddy Nigg, <A href="http://www.startcom.org/" target=_blank>StartCom Ltd.</A></P></BLOCKQUOTE></TD></TR>
<TR>
<TD>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P>Jabber: </P></BLOCKQUOTE></TD>
<TD>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P><A href="xmpp:startcom@startcom.org" target=_blank>xmpp:startcom@startcom.org</A></P></BLOCKQUOTE></TD></TR>
<TR>
<TD>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P>Blog: </P></BLOCKQUOTE></TD>
<TD>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P><A href="http://blog.startcom.org/" target=_blank>Join the Revolution!</A></P></BLOCKQUOTE></TD></TR>
<TR>
<TD>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P>Phone: </P></BLOCKQUOTE></TD>
<TD>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<P>+1.213.341.0390</P></BLOCKQUOTE></TD></TR>
<TR>
<TD colSpan=2>
<BLOCKQUOTE>
<HR tabIndex=-1>
</BLOCKQUOTE></TD></TR></TBODY></TABLE></DIV>
<DIV><BR></DIV>
<DIV dir=ltr>Eddy:</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>The more I look at it, OpenID2 does have a federation model. It simply takes the form of a OOB assurance/equivalence graph connecting the authorities choosing to recognise each others naming contexts, in the XRI directory.To build n reputation services, n assurance authorities (including #you, #me, and #him) simply publish their particular list of equivalences at some newly-defined SEP. Today, this list coudl easily feed into one's local system's XACML standard PEP/PDP evaulation logic, as a set of "environmental" attributes.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>This is almost identical to the DEC/CCITT model, used in the X500 era. (The DEC name server was in NCSC A1 evaluation, until the eval was pulled. The A1 assurance claims were supported by the formal model of Lampson, Burrows, Abadi & co, expressed in a custom modal logic for authentication handoffs between naming authorities.) To publish your own assurance statement, you put a list of cross-certs in your personal "directory" entry (aka contact references page, in XRI land)! </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I feel pretty confortable with the above, since I understand it - and there is solid academic review and pedigree for the references. It is is all mostly out of US patent controls, too; bar a few continuations. Its rather more complex tho than a simple file that signs a set of signed metadata files (1 per spoke in the InCommon model), or a Windows CTL (sign a list of signed X.509 certs/roots, IIS6).</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Its interesting to see all this make a come back, in a new "web-model" embodiment. I think Im going to spend the afternoon playing with the open source server, providing the name/authority resolution service. Be fun to see how the handling of knowledge management between all the naming contexts differs from what folks were doing the Internet X.500 experiment, ~20 years ago, now.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Some enterprising Semweb type doing research ould be well served to (a) implement the XRI query parser, and (b) implement the Lampson logic using the SPARQL expression-extension conventions, so as to practically enforce the relying-party's security policy using semweb categorical inferences, rather than use XACML's fixed algorithm.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Peter.</DIV></BODY></HTML>