what has to be is stored on a consumer-app ?

Kevin Turner kevin at janrain.com
Thu Feb 16 18:26:30 UTC 2006

On Thu, 2006-02-16 at 18:33 +0100, zwiskle wrote:
> Think on this scenario:
> I am    A.livejournal.com
> Now I create on my other homepage ( e.com ) a "e.com/a" and place there
> a reference ( <link... or Yadis ) to a.livejournal.com .
> Writing now e.g. some bad comments.
> Then I _delete_ the "e.com/a" ( breaking the reference-chain ).

Yup.  OpenID, by itself, does not provide much in the way of
accountability.  The fact that someone has signed in with OpenID does
not make them trustworthy.  Nor does that the fact that you have an
OpenID recorded for them mean you can do much with it if you have a
problem with that account.

Your example here uses delegation (creating a homepage on e.com that
points to a.livejournal.com), but the issues are the same even without
that, using your server's ID directly.  It's really really cheap to set
up a new OpenID server on a new domain.  Having a consumer store both
the identity URL and the server it authenticates against adds a little
to your audit trail, but that doesn't buy you very much in most

What OpenID *does* do is give us groundwork on which we can build some
systems that do have accountability.  With this identifier that can be
authenticated in a consistent way across many sites, they can start to
say "yes, I know e.com/a is not likely to be a spammer because the
alphabet.foo community trusts him", or "e.com/a spammed my site so I
will publish a black mark on his reputation, which will either
discourage him from doing that or force him to abandon that identity."

But we haven't built those systems yet.  There's more work to do.  Which
means we better get back to codin'.

 - Kevin

(although plenty of people are working in this space right now.  Some
discussions, picked at a whim from the many that have floated across my
desktop recently, include 


More information about the yadis mailing list