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

David Nicol davidnicol at gmail.com
Tue Jan 9 22:04:52 UTC 2007


thanks for the +1.  As I understand the term, "federation" in a SSO sense
means that my identity at the first place is good at the second place without
an additional step.  I proposed a callback mechanism for this kind of federation
between trusted identity consumers, which is something -- a trust
relationship --
that should absolutely not be automated.  facilitated, but not automated.

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?





On 1/9/07, S. Sriram <ssriram at gmail.com> wrote:
>
> This makes sense as one could have pre-written drop-in federators
> in php, python etc. that consumers can drop-in to their websites.
>
> What the federator [(sic)] drop-in would need is
> - a hook to read from a whitelist
> - A call to the consumers login routine
> - a redirect to a continue url
>
> So the calling url could be
> <a
> href=http://anotherservice.example.com/bin/instantfederation?caller_id=http://joeuser.example.com&continue=http://anotherservice.example.com/section>
> http://joeuser.example.com : click to visit your pre-logged in section at
> the other service</a>
>
> S. Sriram

that url would be not for the federation service but simply for the
early presentation
service.  And no access control is needed there.

 The federation  (with callback, and no additional login dance) service
 standard would include in its definition ways to communicate these things:
 - the continue url
 - the user coupon (a capability key to exchange for the identity)
 - the coupon exchange url, where the coupon is presented for the trusted id
and this drop-in has a hook for specifying what you are calling the whitelist,
which would be a pointer to a function that takes the above data and makes
a choice as to if we are going to present the coupon or not.  Examples in
the documentation for the plug-in would implement a list of coupon exchange
urls that we trust, but the plugin will hopefully support regular expressions
and whatnot without having to pry the lid off.

-- 
pre-Α, Α, Β, rc, release.


More information about the general mailing list