[OpenID] 2-Headed OpenID Auth for Increased Security?

Peter Williams pwilliams at rapattoni.com
Wed Dec 3 15:24:45 UTC 2008


I dont see why this is that un-openid. It seems mostly built into the architecture of AX, and AX's relationship to openid auth's identity validation procedures.

One RP can already induce an AX update to one or more RPs.

That RP is entitled - under UCI - to now be act as an  OP.

I still cannot tell from the AX text whether that second RP (1) can or cannot originate an unsolicited assertion, and (2) assuming it can, whether its AX fetch response MAY,SHOULD or MUST contain identity field populated (making the AX fetch response also an authentication statement when populated).

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Paul Madsen
Sent: Wednesday, December 03, 2008 3:34 AM
To: SitG Admin
Cc: general at openid.net
Subject: Re: [OpenID] 2-Headed OpenID Auth for Increased Security?

SitG Admin wrote:
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.

Exactly - the exciting answers here will not be "HOW can we do it?" but "WHY should we do it?".


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?

What do you mean by the first RP?
yes, 'first' is redundant, there is only the one


My understanding of the process here (my own poor statements notwithstanding) is that the user would have multiple *URI's*, each with their own OP, and use all of these with a single (suspicious) RP.
yes, and by default the sequence would be

RP-OP1-RP-OP2-RP

a permutation would have the first OP, after authenticating the user, redirect the browser to the second OP rather than back to the RP. Only after authenticating would the browser be sent to the RP

RP-OP1-OP2-RP

But this  muddies up the request/response model and creates privacy implications

if its the RP doing the coordinating, its not clear to me what the relevance of XRDS to enable or optimize this.  If an RP cares enough to require 2 authns, it will likely have its own idea as to what OPs are appropriate, notwithstanding any 'primary' or 'secondary' designations



-Shade


--
[cid:image001.gif at 01C95518.378C2FC0]<http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081203/3957a1b8/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 8744 bytes
Desc: image001.gif
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081203/3957a1b8/attachment-0002.gif>


More information about the general mailing list