Hi Shade, 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? Allen On 2/7/10 1:08 AM, "SitG Admin" <[email protected]> wrote: > (For lack of a better subject line . . . ) > > The recent discussion of head...@uri->discov...@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. > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
