OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))

[Martin Atkins]

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.