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

[David Nicol]

On 1/9/07, S. Sriram <ssriram at gmail.com> wrote:
> From: "David Nicol" <davidnicol at gmail.com>
>
> 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).

correct

> 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

a convenience to the user so they don't have to click the login button,
and nothing more (or less)

> 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.

imagine an IDp that (1) requires several clicks to approve of each
login request or (2) limits the number of per-user login requests

> 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.

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.

> 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 ?

whitelist with caller_id would be trivially forgeable, thus requiring the
additional log-in-to-home IDp.  A dance, as we are calling it, instead
of a handshake, of some sort is required to avoid forgery.  With federation
the dance is with the previous trusted consumer.  With prepresentation,
the user saves a click at the consumer but does not necessarilly save clicks
at her IDp, in the event that her IDp checks with her before identifying her.

With federation, the user need make no additional clicks, but the two consumers,
for security's sake, need to have a strong trust relationship in
place, to the point
of marking an identity received via federation as some color of tentative.