Drummond Reed wrote: > Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea > notion for a site advertising the location of the P3P privacy policy: it > defined a standard HTML/XHTML link tag that could be put on any page of a > site that told the browser where to locate the P3P policy document for the > site (or for any portion of the site). > > http://www.w3.org/TR/P3P/#ref_syntax > > Are you proposing the same thing for OpenID login? >
Yes, that is the idea. I don't have time at this moment to write out a full proposal, so I'll just quickly summarize/ramble... Right then. On any page of the RP, they can write: <link rel="openid.rp" href="http://www.mysite.com/openid" /> [1] Now, if we make to that URL the same kind of request that a return_to URL expects to receive, the RP has almost everything it needs to get going with the request. Unless I've missed something, all it's missing is the public identifier the user has selected — what he would have entered into the form under normal circumstances. So we define an extra parameter oirp.identifier to carry that. Now with only minimal changes to the RP we have an interface that a clever client can use to login without forms. This just leaves the rich client to IdP communication. As I noted in a similar message on the other mailing list, this doesn't actually *need* to be a standard at all — the IdP could just issue a plugin which works only with that IdP. That's a lot of duplication of work, however. So what we need is another standard protocol by which the rich client can request a signature; the input argument is the IdP Token, or claimed_identity as the auth spec calls it. Since there has thus far been no communication between RP and IdP, "dumb mode" must be used; the IdP returns a signature and a handle to the rich client, which it then sends on to openid.rp as described above. The RP can then resolve the presented identity to find the IdP and validate the signature. This is really just a variation on the HTTP auth proposal. The differences are: * Rich client passes args to RP via query string rather than WWW-Authenticate header. * We actually specify a protocol for the communication between the rich client and the IdP, unlike my HTTP auth proposal which left that out of scope. Note that HTTP auth can potentially make use of this protocol too. * There's a separation between the URL where you discover the OpenID support and the URL where you make use of it. With HTTP auth, you just make a request and get back a 401 Unauthorized, or you just "know" the URL ahead of time. Really, the above could use the HTTP auth protocol to talk to the RP's endpoint, but I selected the above because it makes the required RP changes much simpler — just support an extra argument in your return_to handler. [1] This is just an example. We'd probably use Yadis in practice, since that would give us versioning for free and the ability to add other services. However, this would make implementation marginally harder for plugin developers as they now need to do more than just grovel around in the DOM of each page as it is loaded, and it'll create an extra overhead for any page that has an X-Yadis-Location, regardless of whether this particular service is listed. I'll leave it to others to debate whether to use Yadis, a custom LINK REL, or some META element. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs