MultiAuth handler

[SitG Admin]

>In Yahoo's case, we wanted to be able to have multiple domains share a
>central OpenID Provider service. For instance, flickr.com and yahoo.com both
>host OpenIDs that all use the Yahoo OP.
>
>I'm not sure what the use case that you're trying to support in your
>proposal. Are you suggesting a way for a user to link two OpenIDs from two
>different providers?

To maximize the effect on security they (both OpenID's/URI's) would 
have 2 different providers, yes, but it would also be possible for 
them both to (as in your case) specify Yahoo's OP as authorized to 
speak for them. (If you have the same OP speaking for more than one 
OpenID in the same login, would it then be possible for it to specify 
multiple ID's it was providing a positive assertion for, in the same 
round trip?)

The part I'm seeing is a way for users to require that RP's use their 
combined OpenID (combining multiple URI's across different domains) 
as more than backups for account recovery; if either Flickr (vouched 
for by YahooOP) or Gmail (vouched for by GoogleOP) refuses to 
authenticate the user as owning that end of an account held by 
multiple OpenID's, the RP should deny access to the user instead of 
permitting them to claim that Flickr had gone down or Gmail had 
become evil. (This might be useful only for major hosts, where users 
can rely on the URI providers *not* going down without a lot of 
warning.)

It should still be possible for Yahoo/Google to make individual 
assertions about Flickr/Gmail, but if the RP (or user's option, for 
OP-originating logins) specified that the account needed another 
OpenID (and couldn't work by itself), either YahooOP or GoogleOP 
could respond with the appropriate document *and* both OP's signature 
of it.

  . . . hmm. Once such a document were provided by, say, Google, there 
would not be any need to ask Yahoo for a copy of the same; Yahoo's 
digital signature, presumably, would provide adequate assurance (and 
save it bandwidth). With a small enough text size, it might be 
possible to standardize the repetitive areas and send the rest over a 
user's redirect, letting the RP send the seed of a document and 
requiring only public keys (from Yahoo and Google) if the cache had 
expired and/or a simple "yes/no" to confirm that the OP was still 
actively providing such a service.

Best-case scenario, that might also make it possible to minimize 
direct correlation in the data exchange between RP's and OP's, since 
(once cached) the document might be entirely recreatable by any party 
(Yahoo, Google, RP, and only the RP should really *want* it - neither 
of the OP's need to cache any of the data once they've seen a user 
log in with the other OP, assuming their private key is secure), and 
no longer needs to have sensitive components sent with every login. 
It might even look like a typical login, no hint of MultiAuth 
involved, and only the RP knows that it is collecting assertions for 
a set of OpenID's rather than a singular OpenID.

-Shade