<div>Well, I looked at SAML Simple Sign before putting this tag-value-izing thing. This portion is very sketchy right now and I am not even sure if I will keep it. However, I wanted to examine the programing ease and extensibility etc. before discarding it especially when we consider the fact that we do not want to parse the XRD as row string but as validated XML and process after it. <div>
<br></div><div>The point I wanted to illustrate was however not this. The current proposal has <CertURI> inside XRD. </div><div>The cert that is pointed by this CertURI must have SubjectUniqueIdentifier which is equal to the <CanonicalID>. The certificate authority MUST guarantee that SubjectUniqueIdentifier will never be reassigned to another subject. Beside the usual checking of the cert for validity (including whether the root is trustworthy from the point of view of the community etc.), the user of this XRD checks if they are equal. </div>
<div>This gives insurance against domain loss/change. </div><div><br></div><div>For the original flow that David came up with, see my slide from the last iiw[1] slide 6. </div><div>This is the same as what David illustrated, I think. </div>
<div><br></div><div>[1] <a href="http://www.slideshare.net/nat_sakimura/introduction-to-openid-tx-proposed-extension-presentation">http://www.slideshare.net/nat_sakimura/introduction-to-openid-tx-proposed-extension-presentation</a></div>
<div><br></div><div>=nat</div><div><br><div class="gmail_quote">On Tue, Dec 2, 2008 at 2:56 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Every time I see oauth, I worry / as the document can only be verified by closed system parties. While this is one means to loading in a trust model to discovery, this was not the control we were seeking to implement. We want trust out of the equation in openid: to be added separately.<br>
<br>
What openid needs is a open systems signing model for an xrd (just as saml-sigs already do for xrd in the trusted resolution of an xri) ( by default) - eg xmldsig. I've no objection to xmldsig using both certs (for open systems) AND oauth (for closed system overlays) for key management.<br>
<div><div></div><div class="Wj3C7c"><br>
-----Original Message-----<br>
From: George Fletcher <<a href="mailto:gffletch@aol.com">gffletch@aol.com</a>><br>
Sent: Monday, December 01, 2008 9:43 AM<br>
To: OpenID List <<a href="mailto:general@openid.net">general@openid.net</a>><br>
Subject: Re: [OpenID] 2-Headed OpenID Auth for Increased Security?<br>
<br>
<br>
Ben Laurie wrote:<br>
><br>
><br>
> On Mon, Dec 1, 2008 at 4:11 PM, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a><br>
> <mailto:<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>>> wrote:<br>
><br>
> FYI, see<br>
><br>
> <a href="http://wiki.oasis-open.org/xri/XrdOne/SimpleSign" target="_blank">http://wiki.oasis-open.org/xri/XrdOne/SimpleSign</a><br>
><br>
><br>
> I have no idea why that proposes to use OAuth encoding for the<br>
> signature. Why not simply sign the document as is?<br>
+1 (this is the approach taken by the SAML SimpleSign binding[1])<br>
<br>
[1] <a href="http://wiki.oasis-open.org/security/SimpleSignBinding" target="_blank">http://wiki.oasis-open.org/security/SimpleSignBinding</a><br>
><br>
> It also doesn't talk at all about how one gets to trust the signing<br>
> cert or who should sign what.<br>
><br>
><br>
> =nat<br>
><br>
> On Mon, Dec 1, 2008 at 10:41 PM, Ben Laurie <<a href="mailto:benl@google.com">benl@google.com</a><br>
> <mailto:<a href="mailto:benl@google.com">benl@google.com</a>>> wrote:<br>
><br>
><br>
><br>
> On Mon, Dec 1, 2008 at 1:23 PM, Peter Williams<br>
> <<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a> <mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>>> wrote:<br>
><br>
> Xrd or xrds?<br>
><br>
><br>
> XRD.<br>
><br>
><br>
> Interesting! if you go xrd. Then you can do dnssec-like<br>
> namespace controls, much like the trusted resolution mode<br>
> of xri.<br>
><br>
><br>
> Not yet all that familar with fully blown XRD, so I'll have to<br>
> take your word for this - but I am familiar with DNSSEC, so<br>
> I'm wondering what you mean by a "namespace control"?<br>
><br>
><br>
> Rather than be dnssec static, however, signatures on xrd<br>
> could also serve as security tokens, citable on the peer<br>
> (web) services ("managed" by the xri/uri). Butler lampson<br>
> will be in heaven.<br>
><br>
> ________________________________<br>
> From: Ben Laurie <<a href="mailto:benl@google.com">benl@google.com</a> <mailto:<a href="mailto:benl@google.com">benl@google.com</a>>><br>
> Sent: Monday, December 01, 2008 5:13 AM<br>
> To: Peter Williams <<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a><br>
> <mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>>><br>
> Cc: Eric Norman <<a href="mailto:ejnorman@doit.wisc.edu">ejnorman@doit.wisc.edu</a><br>
> <mailto:<a href="mailto:ejnorman@doit.wisc.edu">ejnorman@doit.wisc.edu</a>>>; OpenID List<br>
> <<a href="mailto:general@openid.net">general@openid.net</a> <mailto:<a href="mailto:general@openid.net">general@openid.net</a>>><br>
> Subject: Re: [OpenID] 2-Headed OpenID Auth for Increased<br>
> Security?<br>
><br>
><br>
><br>
> On Sun, Nov 30, 2008 at 5:56 PM, Peter Williams<br>
> <<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a><br>
> <mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>><mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a><br>
> <mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>>>> wrote:<br>
> Time to take the extension power of XRDS, and apply<br>
> xmldsig "detached signature(s)"<br>
><br>
> Signing XRD is pretty much what we're proposing for the<br>
> next generation...<br>
><br>
><br>
><br>
> This would be using similar mechanism as used in<br>
> Authenticode, where designers applied 3rd-party<br>
> countersigning and 4th-party timestamping to solve<br>
> validity problems - at internet scale. Different parties<br>
> (OP, discovery agents, validation) can then cooperate, in<br>
> the inherently suspicious world of open systems.<br>
><br>
> The Shib/Apache-xmltooling toolset has all the mechanisms<br>
> required to make power-use of the flexibility of the<br>
> xmldsig standard (as do many other tools). Being very,<br>
> very flexible in its references, it's easy to screw up<br>
> application of xmldsig, producing unwanted sideeffects tho.<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a><br>
> <mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a>><mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a><br>
> <mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a>>><br>
> [mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a><br>
> <mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a>><mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a><br>
> <mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a>>>] On Behalf Of Eric Norman<br>
> Sent: Sunday, November 30, 2008 9:50 AM<br>
> To: OpenID List<br>
> Subject: Re: [OpenID] 2-Headed OpenID Auth for Increased<br>
> Security?<br>
><br>
><br>
> On Nov 30, 2008, at 9:35 AM, Andrew Arnott wrote:<br>
><br>
> > I like the idea.... but the XRDS would have to<br>
> mandatorily not be<br>
> > hosted by either OP (which right now is commonly done),<br>
> since that OP<br>
> > would still ultimately have total assertion power by<br>
> temporarily<br>
> > manipulating the XRDS file to point to two OP endpoints<br>
> that were both<br>
> > controlled by the evil party.<br>
><br>
> Be careful. "Hosted by" does not necessarily imply "content<br>
> controlled by".<br>
><br>
> Eric Norman<br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@openid.net">general@openid.net</a><br>
> <mailto:<a href="mailto:general@openid.net">general@openid.net</a>><mailto:<a href="mailto:general@openid.net">general@openid.net</a><br>
> <mailto:<a href="mailto:general@openid.net">general@openid.net</a>>><br>
> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@openid.net">general@openid.net</a><br>
> <mailto:<a href="mailto:general@openid.net">general@openid.net</a>><mailto:<a href="mailto:general@openid.net">general@openid.net</a><br>
> <mailto:<a href="mailto:general@openid.net">general@openid.net</a>>><br>
> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@openid.net">general@openid.net</a> <mailto:<a href="mailto:general@openid.net">general@openid.net</a>><br>
> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Nat Sakimura (=nat)<br>
> <a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
><br>
><br>
> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> general mailing list<br>
> <a href="mailto:general@openid.net">general@openid.net</a><br>
> <a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
><br>
<br>
--<br>
Chief Architect AIM: gffletch<br>
Identity Services Work: <a href="mailto:george.fletcher@corp.aol.com">george.fletcher@corp.aol.com</a><br>
AOL LLC Home: <a href="mailto:gffletch@aol.com">gffletch@aol.com</a><br>
Mobile: +1-703-462-3494<br>
Office: +1-703-265-2544 Blog: <a href="http://practicalid.blogspot.com" target="_blank">http://practicalid.blogspot.com</a><br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>
</div></div>