[OpenID] caller_id + federation (was: call it federation (was: thoughts on a consumer drivenidp affiliate program ))

[S. Sriram]

From: "David Nicol" <davidnicol at gmail.com>
>
> and a request from a known-whitelisted REFERER would be
> trivially forgeable. With federation, the first site becomes the IDp
> for the second site, and the users own IDp does not need to be
> bothered.
>
Okay, to recap caller_id would be useful inasmuch it helps the consumer
bypass requesting the user to fillin their id and click login, the consumer
would intiate the openid login process. In respect of federation, the
consumer would perform a handshake with the idp to get the openid
and would than log the user in.

So, a drop-in OpenId federator that understood the following two calls
should do the trick

(1) ?caller_id=<openid here>&continue=<destination url here>
(2) 
?caller_pass=http://idpservice.urltogetidfrom?coupon=id&continue=<destination 
url>

In both cases, consumer c(w)ould do a whitelist lookup even before 
undertaking
the requested excercise.

In case (1) the consumer would initiate an openid login dance
In case (2) the consumer would intiate a handshake with idpservice at url 
provided with
coupon id and retrieve an openid which the consumer than would use to log 
the
enduser with.

S. Sriram