<HTML dir=ltr><HEAD></HEAD>
<BODY style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<DIV id=idOWAReplyText96201 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT>Sorry. it was far too densely written. Just ignore it. </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I've been trying for hours trying to get myopenid domains to work. Its hard to tell whether its a simple implementation flaw or.. more likely.. I just dont understand some element of the model. When I'm thinking too hard, the writing quality suffers: so ... apologies! </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I may have to join a JanRain support list, to get some help on addingsome users to a MyOpenI domain. I think Im now officially stuck.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> Johannes Ernst<BR><B>Sent:</B> Sat 3/22/2008 12:01 AM<BR><B>To:</B> Peter Williams<BR><B>Cc:</B> openid-general List<BR><B>Subject:</B> Re: [OpenID] Thinking About OpenID.com<BR></FONT><BR></DIV></DIV>
<DIV>Apologies, but I have no idea what you just said, neither syntactically nor semantically ;-)
<DIV><BR>
<DIV>On 2008/03/21, at 20:57, Peter Williams wrote:<BR class=Apple-interchange-newline>
<BLOCKQUOTE type="cite">
<DIV>
<DIV id=idOWAReplyText40819 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>writer to reader crypto policy via public key crypto and cert-based key distribution prevents dis-intermediation by RP proxies, allowing ORCON (originator control) over the controls on the IDP to be actually impacting the RP in question (not some proxy). This has been well known since the early 70s, and was applied through the 80s in secure phone and data networks. The advantage of trusted message switchin , using symmetric crypto, is that it allows for backtracking-based sp-initated flows, with dis-intermediation "options" : plugins, call outs, choices, policy enforcements determined and enforced by the distributed agents along the handoff line (vs in the logic defined by a centralized PKI control system). The war between the approaches of writer-to-reader vs trusted messaging has been going on for 30 years, in military MHS design.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>On a different topic, I note that (https) home_pw.myopenid.com has semantic annotations - using the vcard tags. is it your idea that one or other AX provider would use that page as an authoritative source of attributes, to be sent to RPs?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV></DIV>
<DIV id=idSignature68925>
<DIV><FONT face=Arial color=#000000 size=2><SPAN style="FONT-SIZE: 7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B><SPAN style="FONT-SIZE: 7.5pt">Chief Information Security Officer<BR>Mobile (805) 416-6305</SPAN></FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Johannes Ernst<BR><B>Sent:</B> Fri 3/21/2008 12:39 PM<BR><B>To:</B> Chris Drake<BR><B>Cc:</B> openid-general List<BR><B>Subject:</B> Re: [OpenID] Thinking About OpenID.com<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>On 2008/03/20, at 3:34, Chris Drake wrote:<BR>> 7) Legal responsibilities - probably not one that Providers are happy<BR>> with, but, it's not the RPs fault if a customer account is<BR>> plundered because of fault with the login system - freeing up the<BR>> RP from the legal liability/responsibility of that issue (eg: the<BR>> customer would sue the Provider, not the RP)<BR><BR>Actually, no. The customer would sue both the RP and the OP, and the <BR>RP would sue the OP -- at a minimum ;-) And one of the problems with <BR>have with OpenID so far is that legal discovery would be very hard <BR>because nobody could prove to anybody what they have done or not.<BR><BR>(This is one of the reasons why I originally picked GPG as the crypto <BR>for LID instead of symmetric keys that we have in OpenID -- if the RP <BR>keeps the incoming requests around, the RP can show them later in <BR>legal discovery and say "see, nobody could have produced this <BR>signature at the encoded time stamp other than somebody in the <BR>possession of the private key, and that's not us, so we get to go home <BR>free")<BR><BR>I continue to believe that we'll have to address this problem sooner <BR>or later ... even if some people on this list seem to have some kind <BR>of public-key phobia ;-)<BR><BR>Cheers,<BR><BR><BR><BR>Johannes.<BR><BR><BR><BR>Johannes Ernst<BR>NetMesh Inc.<BR><BR><BR></FONT></P></DIV></DIV></BLOCKQUOTE></DIV><BR></DIV></DIV></BODY></HTML>