On Mon, Dec 1, 2008 at 7:20 AM, Paul Madsen <span dir="ltr"><<a href="mailto:paulmadsen@rogers.com">paulmadsen@rogers.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div 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 (in OpendID terminology) the
first RP indicate to the first OP the second OP in the openid.return_to
- 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.</div></blockquote><div><br>Well, if OPs knew how to do some sort of "auth request chaining", then I suppose the RP would need to verify each auth assertion anyway, so I don't think a rogue OP1 could try and do anything sneaky (like replacing OP2 with OP1), because the auth verification would fail back at the RP. Unless I'm missing something.<br>
<br>That said, it does seem much simpler to just have the RP do the multiple redirects and authenticate to multiple OP's (like what David Recordan suggested in the first response of this thread). That way each OP auth can be treated as a discrete authentication (allowing different PAPE responses for each OP to be sent back to the RP). Plus, OpenID auth wouldn't really need to change to make this happen.<br>
<br>I guess the real issue is the integrity of the XRDS info.<br></div></div><br>