How to keep user signed-in (authenticated) across a distributed network.

[Vikrant Chaudhary]

Let's start by an example of a centralised social networking web-site.
When a you sign-in on a conventional social-network, you sign-in
_across_ the network.
For example, when you visit your friend's profile, your friend's
profile knows that the visiting user is authenticated and is a
"friend" and let's you view albums that are only meant for "friends".

However, in a distributed social network (which is by principle, also
decentralised), when you visit your friend's profile which is on it's
own domain, you won't be signed-in anymore, even if you were signed-in
at your own profile (which is on your own domain).
So the problem in distributed social networking is about how to keep
the user signed-in while she hops over profiles across the network.
Or in other words, when I visit any profile across the network, they
automatically recognise me instead of a manual OpenID authentication
for every new domain.
I've tried to write some solutions at this wiki, but can't be sure
unless they get some +1s.
http://code.google.com/p/kopal/wiki/Challenge

PS: I don't know much technical differences between "distributed" and
"decentralised" but I can give an example (just to make things clear)
- Folding@home is distributed but not decentralised. It needs to talk
to (and is controlled by) a centralised server.
Distributed social networks are meant to be decentralised i.e. no
central server for authentication/identification or else the whole
purpose of distributed social networking is defeated.

[Vikrant Chaudhary]

Just to make a note, I'm looking forward for an HTTP/REST
implementation of this problem (just the normal web).
(XMPP may not have this problem because of it's architecture. Don't
know much about it but this is what I predict).

On Mar 5, 4:00 pm, Vikrant Chaudhary <nas...@gmail.com> wrote:
> Let's start by an example of a centralised social networking web-site.
> When a you sign-in on a conventional social-network, you sign-in
> _across_ the network.
> For example, when you visit your friend's profile, your friend's
> profile knows that the visiting user is authenticated and is a
> "friend" and let's you view albums that are only meant for "friends".
>
> However, in a distributed social network (which is by principle, also
> decentralised), when you visit your friend's profile which is on it's
> own domain, you won't be signed-in anymore, even if you were signed-in
> at your own profile (which is on your own domain).
> So the problem in distributed social networking is about how to keep
> the user signed-in while she hops over profiles across the network.
> Or in other words, when I visit any profile across the network, they
> automatically recognise me instead of a manual OpenID authentication
> for every new domain.
> I've tried to write some solutions at this wiki, but can't be sure

> unless they get some +1s.http://code.google.com/p/kopal/wiki/Challenge

[Joseph Holsten]

On Mar 5, 2010, at 5:00 AM, Vikrant Chaudhary wrote:
> However, in a distributed social network (which is by principle, also
> decentralised), when you visit your friend's profile which is on it's
> own domain, you won't be signed-in anymore, even if you were signed-in
> at your own profile (which is on your own domain).
> So the problem in distributed social networking is about how to keep
> the user signed-in while she hops over profiles across the network.
> Or in other words, when I visit any profile across the network, they
> automatically recognise me instead of a manual OpenID authentication
> for every new domain.

Sounds like the use case for browser plugins that auto-logon (like https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager). The first time you visit your friend's profile, you should add them to your whitelist, and your auto-login plugin would know that it's allowed to discover the authn endpoint and push your credentials. Presumably both OpenID and OAuth style authentication could be appropriate, depending on what you want to do at your friend's site and how much you trust the client used to access it.

Of course, sites that aren't whitelisted shouldn't automatically cause you to authenticate.

I think some people have agreed to the right way to discover OpenID authn endpoints, but I can't seem to find that right now.
--
j

[Stephen Paul Weber]

On Fri, Mar 5, 2010 at 06:00, Vikrant Chaudhary <nas...@gmail.com> wrote:
> So the problem in distributed social networking is about how to keep
> the user signed-in while she hops over profiles across the network.
> Or in other words, when I visit any profile across the network, they
> automatically recognise me instead of a manual OpenID authentication
> for every new domain.

You want cross-site cookies. The easiest way to approximate this is
with client-side TLS certificates. Then when you visit a site, your
browser says "so and so certifies that this person is such and such an
identifier". Very underexplored territory.

--
Stephen Paul Weber, @singpolyma
Please see <http://singpolyma.net> for how I prefer to be contacted.
This message was sent from the GMail webmail interface. It's probably
not signed. This is a problem.

[Robert]

There's a more comprehensive thread about this somewhere in the group.  Just do a search.

--
You received this message because you are subscribed to the Google Groups "Diso Project" group.
To post to this group, send email to diso-p...@googlegroups.com.
To unsubscribe from this group, send email to diso-project...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/diso-project?hl=en.

[Chris Messina]

The problem you described is solved by federation, or automating
authentication.

The former calls for a technology like SAML and may be enhanced
through trust frameworks (like the one recently approved by the US
Government: http://openid.net/docs/Open_Trust_Frameworks_for_Govts.pdf).

The later can be solved by modifying OpenID and websites that support
OpenID, or by adding OpenID to the browser, as we did with the
experimental IDIB plugin for Flock:

http://code.google.com/p/idib/

Either the website automatically talks to your identity provider (by
querying your browser, a list of known IDPs, or a central service), or
your browser pushes your identity provider to the website (RP). See
also:

http://sites.google.com/site/oauthgoog/Home/pds

Chris

On Mar 5, 9:51 am, Robert <langb...@gmail.com> wrote:
> There's a more comprehensive thread about this somewhere in the group.  Just
> do a search.
>

> On Fri, Mar 5, 2010 at 11:37 AM, Stephen Paul Weber <singpol...@gmail.com>wrote:
>
>
>
> > On Fri, Mar 5, 2010 at 06:00, Vikrant Chaudhary <nas...@gmail.com> wrote:
> > > So the problem in distributed social networking is about how to keep
> > > the user signed-in while she hops over profiles across the network.
> > > Or in other words, when I visit any profile across the network, they
> > > automatically recognise me instead of a manual OpenID authentication
> > > for every new domain.
>
> > You want cross-site cookies.  The easiest way to approximate this is
> > with client-side TLS certificates.  Then when you visit a site, your
> > browser says "so and so certifies that this person is such and such an
> > identifier".  Very underexplored territory.
>
> > --
> > Stephen Paul Weber, @singpolyma
> > Please see <http://singpolyma.net> for how I prefer to be contacted.
> > This message was sent from the GMail webmail interface. It's probably
> > not signed.  This is a problem.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Diso Project" group.
> > To post to this group, send email to diso-p...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > diso-project...@googlegroups.com<diso-project%2Bunsubscribe@google groups.com>

[Luke Shepard]

This can be done with OpenID and without any browser extensions.

The main difference between the "decentralized" and "distributed" social networks as you described is that the individual site does not know who the user's provider is. Facebook Connect is distributed - identity works across thousands of websites - but it is centralized, in that there is a single identity store. The main missing piece is a way to know who the user's provider is.

Once you know the provider, then each site can just make a checkid_immediate request against the provider to get logged in state.

For those who didn't click through, the decisions listed in the Kopal wiki are:

 1/ Keep track of the provider by appending a GET parameter. This will not work in practice as it's far too fragile.

 2/ Browser plugin. I think this is not going to work on its own as adoption is a problem. Even a distributed social network will want to support IE6, IE7, and other existing browsers.

 3/ Use a centralized authentication server.

A fourth option is some sort of discovery service which hosts a shared cookie telling what provider to use. The closest proposal I've seen is Eric Sachs': http://sites.google.com/site/oauthgoog/Home/pds . That's not perfect, but ultimately I think something like that will provide the mechanism here.

To unsubscribe from this group, send email to diso-project...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/diso-project?hl=en.

--
- Luke Shepard
773-742-9163