(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
