Re: [Social] Authentication

[Ian Denhardt]

On Wed, 9 Jun 2010 15:52:58 +0200
Melvin Carvalho <address@hidden> wrote:

> 2010/6/9 Sean Corbett <address@hidden>
> 
> > Hi guys,
> >
> > After starting to think about the design for the social networking plugins
> > for StatusNet, Ian and I realized that implementing any of these plugins
> > can't really happen before we implement a suitable authentication scheme to
> > manage permissions... We *could* go ahead and write a photo gallery, but
> > this would be rather counterproductive as we'd have to tack on access rules
> > after the fact, which would make things a lot messier.
> >
> > This is, of course, one of the big issues facing the project; thus, we
> > should probably tackle this problem by implementing a proper authentication
> > and permissions scheme before we start worrying about adding additional
> > social network functionality. Ian and I think that FOAF+SSL is the way to go
> > given its popularity its simplicity, popularity on the discuss list, and the
> > fact that we have quite a few people who are knowledgeable of it.
> >
> 
> I'd say +1 to supporting FOAF+SSL ... I'd be willing to donate code /
> libraries to the FSF that I've been working with ... maybe need a bit of
> time to clean them up slightly
> 
> One important note is that supporting FOAF+SSL does not mean that you cant
> support a rich array of authentication methods also such as OpenID /
> username+password etc.  Which order you do them in is up to you ...

While this is a possibility, I have a concern regarding supporting
multiple authentication schemes. For a standard to be useful as such,
it needs to be practical to implement it. If it's too difficult, at
best implementations will 'sort of' work with the standard, which isn't
good enough. My worry is that if we decide to support a wide array of
auth schemes, then to be able to reliably federate with the rest of the
world, each implementation will have to support *all* of them, and so
it will be very difficult to implement. I don't want us to get into a
situation where it can't be depended on that two different pieces of
software supporting the "gnu social protocol" can't be assumed to be
able to federate successfully. At the very least, if we are to support
multiple auth schemes at all, the protocol should mandate *one* scheme
that will always be available if nothing else is.

> 
> The basic flow is something like:
> 
> $id = Authenticate();
> 
> Now your $id is a pointer to your FOAF.  Which in turn exposes your friends,
> avatar, nick etc.  We're also working on some web scale ACL libraries to
> control who sees what, which again, I'm sure we'd be happy to donate to the
> FSF.
> 
> 
> >
> > --sean
> >
> >


-- 
Ian Denhardt <address@hidden>