<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
We toyed with this idea in Liberty for SAML but never did anything with
it - partly
because it would already work out of the box with SSO protocols as they
are if the RP coordinates the multiple authentications.<br>
<br>
We did think of optimizations whereby you could eliminate some
redirects by having&nbsp; (in OpendID terminology) the
first RP indicate to the first OP the second OP in the openid.return_to
-&nbsp; I'm not sure this would
be legal in OpenID?<br>
<br>
A bit weird, as from the second OP's PoV, it would be getting an
unsolicited response from
the first OP and would have to interpret it as an implicit request for
authentication ....<br>
<br>
Alternatively, the RP could indicate to the first OP that it wanted to
chain requests to the second OP. <br>
<br>
Neither model would seem to mitigate the 'bad OP' risk.<br>
<br>
The other issue is how to describe such distributed authn in PAPE or
equivalent.<br>
<br>
paul<br>
<br>
David Fuelling wrote:
<blockquote
 cite="mid:51dae84d0811291041n799b79ccx554774cec41c19f6@mail.gmail.com"
 type="cite">Hey List,<br>
  <br>
I've been thinking about the security of OpenID lately, dreaming about
the day when I'll be able to use OpenID at my bank's website.&nbsp; One
issue that I keep coming back to is that my OP (or a rogue employee at
my OP) could masquerade as me at OpenID-enabled RP's across the web
since the OP is a single authentication point in the OpenID ecosystem.<br>
  <br>
To mitigate this problem, one idea I have would be to utilize a
2-headed OpenID auth scheme, whereby a "higher security" RP (like my
bank) would require OpenID authentication assertions from two separate
OP's.&nbsp; This would preclude somebody at OP #1 from masquerading as me,
since any RP would require a second auth from a different OP, outside
the control of the first OP.<br>
  <br>
On the face of it all, this approach would seem to require two
different OpenIDs (one for each OP).&nbsp; However, using Yadis/XRDS, one
could specify a primary and secondary OP for a particular OpenID.&nbsp;
Assuming that the user is logged-in to both OP's, this dual-auth may
even go un-noticed by the user.&nbsp; Of course, an RP could also just allow
the user to select two different OP's to use for auth assertions at
login time.&nbsp; <br>
  <br>
I suppose there are several ways to make this happen, but I'd
appreciate any feedback on this idea...<br>
  <br>
Thanks!<br>
  <br>
David<br>
  <br>
  <pre wrap=""><hr size="4" width="90%">
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext"
 href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
  </pre>
  <pre wrap=""><hr size="4" width="90%">
No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.552 / Virus Database: 270.9.11/1819 - Release Date: 29/11/2008 10:37 AM
  </pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1"><img
 src="cid:part1.03030107.07070802@rogers.com" alt="ConnectID"
 style="border: 0pt none ;"></a></div>
</body>
</html>