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
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
