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

David Nicol davidnicol at gmail.com
Tue Jan 9 20:54:31 UTC 2007

to have real SSO without additional logins, even a single click is a good
thing to some, and a bad thing to others.  The consumer-consumer
instant federation protocol should be separate from the openId protocol
rather than buried in it.  The audiences for the two specifications
are different,
as one is concerned with creating compliant providers and the other with
playingnicely consumers.

The proposed level of MAY, SHOULD, etc seems correct.

The argument against dynamic extensions of initial links could
be solved by defining a "pre-login" protocol that would pass the
identity of the user to the peer consumer ahead of time, so the
new consumer can give the user a session in advance just in case
they want one.  Although that may be a bad idea too, cluttering up
people's cookie files and having to respond to all the login-or-not questions
from fancy IDps that always check before serving.

Another alternative to embedding data in the QUERY_STRING is embedding
data in the PATH_INFO

<a href="http://anotherservice.example.com/splash.html"> visit the
other service </a>
 visit the other service, already logged in with openID

Can't really get much simpler than that.  Instant federation data for
a service would
include the answer to the question "How do I present the openID of a
logged-in user
to you?"

a layer of abstraction and a call-back from the receiving consumer would remove
the identity from the get data, if we are worried about cache listing attacks or
stuff like that.

<a href="http://anotherservice.example.com/splash.html"> visit the
other service </a>
 visit the other service, already logged in with openID

anotherservice receives that link and makes a request to thisservice,
presenting the
coupon, and getting joeuser's openID URL, which it then uses to
authenticate joeuser
according to joeuser's terms.  The coupons are one-time-use and expose
very little
risk.  Assume federated consumers can communicate with each other.

would the abstraction here buy anything for the complexity?

between trusted consumers, federation could mean fewer login dances.  By
standardizing a federation method, federating two consumers will require an
administrative decision and a configuration step, rather than weeks of

On 1/9/07, Martin Atkins <mart at degeneration.co.uk> wrote:
> Lukas Rosenstock wrote:
> >
> > If the URL to a page that includes an OpenID login form contains the key
> > openid_url with a valid OpenID URL as value in its query, this page SHOULD
> > [...] immediately redirect to the IdP to verify the identity
>  >
> While this is not strictly the case, this is shaving far too close to
> "GET request performing an action" for my liking. The actual action of
> initiating the login request (which causes a shift in state at both the
> RP and the OP) should always be done by the user hitting a "Log In"
> button; I don't want to get to the situation where I follow a random
> link to some other site and suddenly I've implicitly initiated a login
> request.
> I have no problem with pre-populating the login box, however.
> I probably also wouldn't take such issue with Site A containing a button
> titled "Log in to Site B" which causes a POST request to Site B which
> initiates the login there. It's that it's a POST request initiated by a
> button press that I'm adamant about, for the sake of keeping the UI sane
> and as predictable as possible.
> (If two sites want to co-operate to do something sub-optimal they can go
> right ahead. We shouldn't spec anything of that sort as a standard,
> however.)
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general

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

More information about the general mailing list