MultiAuth handler

[SitG Admin]

(For lack of a better subject line . . . )

The recent discussion of headers at URI->discovery at XRD->OP got me 
thinking; if Yahoo can outsource its XRD document(s) to 
yahooapis.com, why can't it, say, outsource its XRD's to 
yahoo-google-apis.com? This isn't to say that ALL major IDP's (usage 
here: URI hosting) should use a common central XRD host (SP?), nor 
that Yahoo/Google should store all their XRD's there. Indeed, there 
should be protection in case some phisher registers 
"google-yahoo-apis.com".

Disclaimer: the following is not a proposal, and I am still not sure 
if it is out of spec or merely me finally understanding something 
that has been *in* spec (or planned for OpenID v.next) all along.

Envision an XRD containing 2 (or more^1) OP's for 2 (or more) URI's, 
with digital signatures from each SP (URI hosts), further specifying 
(within the signed data) that this OpenID is only to be used for 
MultiAuth and that all signatures must be present/valid before 
accepting document. The user can then assert their (digital) identity 
as "someone with these accounts at Google *and* Yahoo".

SP's would also have to act as RP's, for this to work; until and 
unless the user confirmed to SP->Yahoo that they were also the holder 
of the paired account at SP->Google, the SP->Yahoo would refuse to 
sign any other (new) XRD.

Google could still point to another XRD, one with its own signature 
(and perhaps another's, besides Yahoo's), but this would not be the 
same as the "This user is the owner of this URI at Google *and* that 
URI at Yahoo.", and RP's would only need to keep track of the two 
URI's, trusting that neither SP by itself would be able to generate 
*all* the needed signatures to validate a new XRD listing both those 
URI's as a MultiAuth pair with some compromised OP's.

This would add greatly to the understanding and work required of new 
RP's to use OpenID, but it could be minimized by saying "If you 
aren't going to implement (support for) this - ignore these, and 
refuse to accept them."

-Shade

^1) Or potentially just one, even, but that would be weaker for its 
single point of takeover.