<HTML dir=ltr><HEAD><TITLE>Re: [OpenID] Thinking About OpenID.com</TITLE></HEAD>
<BODY>
<DIV id=idOWAReplyText60805 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Ive been trying to bind my openid2->SAML2 gateway -- that links the Trustbearer/Rapattoni consumer's smartcard-enhaced gateway to Google Apps (at <A href="http://tb.rapattoni.trustbearer,com/consumer" target=_blank>http://tb.rapattoni.trustbearer,com/consumer</A>) -- to MyOpenID's new "domain" service.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>My domain in google-land is homepw.org, cost $10 pa. I get DNS record control, to some extent. For example, I could create the required CNAME that proves to myopenid that I do indeed have control over said domain. With that solved, my aim was next to create op.homepw.org as my "op" sub-domain, whose control will be hanlded over to myopenid.com (per the domain service). This occured fine. For the first time in 20+ years, I didnt need an netops person to fiddle DNS records! Then I got stuck:-</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Google allows the domain admin to create certain CNAMES, but perhaps not use of *.op, as in *.op.homepw.org. See pdf attachment. This pattern is needed, to get the best openid experience, of course.</FONT></DIV><FONT face=Arial size=2>
<DIV dir=ltr><BR>Can anyone confirm this? Does anyone know of a workaround? If the limit is indeed in place precluding *, I suppose I have two choices: administer 1 CNAME per userX (userX.op.homepw.org), or use the alternative openid pattern of <A href="http://op.myopenid.com/%3Cusername" target=_blank>http://op.myopenid.com/%3Cusername</A>>. A DNS -delivered Redirect can of course map lockbox.op.myopenid.com to <A href="http://op.myopenid.com/lockbox" target=_blank>http://op.myopenid.com/lockbox</A>, for "special users".</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr></FONT> </DIV></DIV>
<DIV id=idSignature37818 dir=ltr>
<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> Peter Williams<BR><B>Sent:</B> Fri 3/21/2008 8:57 PM<BR><B>To:</B> Johannes Ernst<BR><B>Cc:</B> openid-general List<BR><B>Subject:</B> Re: [OpenID] Thinking About OpenID.com<BR></FONT><BR></DIV>
<DIV dir=ltr>
<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></BODY></HTML>