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

S. Sriram ssriram at gmail.com
Tue Jan 9 22:31:53 UTC 2007

From: "David Nicol" <davidnicol at gmail.com>

> A new term would be needed for presenting the identity with the transfer,
> as a simple convenience to the user, with the expectation that the 
> identity
> will be checked.  That is not federation,  even calling it "weak 
> federation"
> would be confusing. pre-presentation -- advance presentation -- advance
> presentation.  That's all that happens, the identity is presented in 
> advance.
> Not event in advance, just early.  early presentation?  instant 
> presentation?

Okay, if I read you correctly you note that the caller_id
(pre-presentation in your terminology) is a step that is
distinct from federation (the granting of privilege without an
additional step).

Provided openid consumers/rp's use a standard form field name
a caller_id is not needed. caller_id becomes valuable when a)
form fields use different names and b) to inform the consumer
of the callers identity and c) for federation

For federation, if the requirement is to connect back with
the originating service to get the identity, are we not
substituting one dance for another ? If so, why not stay with
the original dance.

If on the other hand the consumer builds a 'whitelist' of
referring sites that the consumer trusts, caller_id calls from
these 'whitelisted' sites would presumably need no dance.

Re: violating your principle i.e. - a trust relationship should
not be automated but facilitated. However, is that not what federation
is supposed to do i.e. automate a trust relationship and would not
a whitelist with a caller_id satisfy that criteria ?

S. Sriram 

More information about the general mailing list