Identity issues

I got slightly sidetracked on the way to the TRAC, but I've
been
thinking about identity and blogging. I really, really,
really don't
want to have to add yet another login/password pair to a
commenter's
keychain if I can possibly help it. 

But, it would be cool for people to have some way of
identifying
themselves in some trusted fashion (so that, for example
comments made
by signed in users get added straight away, but all other
comments get
put into a queue pending approval). 

My thinking on this is that we need to come up with some
sort of
an identity control API. We define the ways in which Typo
interacts
with an authentication service, things like:

   authenticator.session_is_authenticated?(session)
   authenticator.session_user(session) - returns a user
object
   authenticator.authenticate(controller, session) - May do
redirects,
                                                     hence
the controller

Then our user object will carry information like:

   user.memento - Unique string identifying this user (for
use in any
                  authorization system)
   user.email
   user.display_name
   user.icon
   user.url
   user.authenticated? 

Possibly more, possibly fewer. Methods like #icon can
obviously return
an empty string...

Once we've worked out the protocols (and tweaked our
current
identification mechanism to use them) it should be
relatively easy to
write adaptors for Flickr; Yahoo; Google; OpenID; some kind
of dumbass
captcha system, if you really insist but don't expect it to
get
accepted into the trunk; or whatever other authentication
services
exist or arise.

Of course, methods like
'authenticator.session_is_authenticated?' will
generally be accessed via helper methods like:

   session.authenticated?

Right, brain dump over, I shall proceed to the Trac
directly.

Note: Authentication is *not* the same as Authorization.
About the
only thing I'm sure of regarding authorization is that we
shall have
something. 

Note2: This isn't even remotely imminent. I'm just
sketching here.

-- 
Piers Cawley <pdcawleybofh.org.uk>
http://www.bofh.org.uk/
_______________________________________________
Typo-list mailing list
Typo-listrubyforge.org
http:
//rubyforge.org/mailman/listinfo/typo-list

Yes .

There are a couple things that I'd like to see.  First,
OpenID is
probably the most useful one today, because it gets us
LiveJournal,
and I *think* that TypeKey is supposed to be OpenID-able
soon, if it
isn't already.

The flip side of this is that Typo should be an OpenID
server, too, so
we can publish our own identities.  This way Typo users will
be able
to authenticate ourselves to each other.

I can work on the server side if you want to handle the
client side.
At some point we'll need to add a check so that we won't
try to use
OpenID to authenticate against ourself--on single-threaded
servers
(Webrick, single-port Mongrel, single-dispatcher fcgi)
that'll
deadlock.


Scott

On 7/13/06, Piers Cawley <pdcawleybofh.org.uk> wrote:
> I got slightly sidetracked on the way to the TRAC, but
I've been
> thinking about identity and blogging. I really, really,
really don't
> want to have to add yet another login/password pair to
a commenter's
> keychain if I can possibly help it.
>
> But, it would be cool for people to have some way of
identifying
> themselves in some trusted fashion (so that, for
example comments made
> by signed in users get added straight away, but all
other comments get
> put into a queue pending approval).
>
> My thinking on this is that we need to come up with
some sort of
> an identity control API. We define the ways in which
Typo interacts
> with an authentication service, things like:
>
>    authenticator.session_is_authenticated?(session)
>    authenticator.session_user(session) - returns a user
object
>    authenticator.authenticate(controller, session) -
May do redirects,
>                                                     
hence the controller
>
> Then our user object will carry information like:
>
>    user.memento - Unique string identifying this user
(for use in any
>                   authorization system)
>    user.email
>    user.display_name
>    user.icon
>    user.url
>    user.authenticated?
>
> Possibly more, possibly fewer. Methods like #icon can
obviously return
> an empty string...
>
> Once we've worked out the protocols (and tweaked our
current
> identification mechanism to use them) it should be
relatively easy to
> write adaptors for Flickr; Yahoo; Google; OpenID; some
kind of dumbass
> captcha system, if you really insist but don't expect
it to get
> accepted into the trunk; or whatever other
authentication services
> exist or arise.
>
> Of course, methods like
'authenticator.session_is_authenticated?' will
> generally be accessed via helper methods like:
>
>    session.authenticated?
>
> Right, brain dump over, I shall proceed to the Trac
directly.
>
> Note: Authentication is *not* the same as
Authorization. About the
> only thing I'm sure of regarding authorization is that
we shall have
> something.
>
> Note2: This isn't even remotely imminent. I'm just
sketching here.
>
> --
> Piers Cawley <pdcawleybofh.org.uk>
> http://www.bofh.org.uk/
> _______________________________________________
> Typo-list mailing list
> Typo-listrubyforge.org
> http:
//rubyforge.org/mailman/listinfo/typo-list
>
_______________________________________________
Typo-list mailing list
Typo-listrubyforge.org
http:
//rubyforge.org/mailman/listinfo/typo-list

If you're delving into OpenID support, there is code out
there to  
use.  Matt Pelletier gave a presentation on OpenID support
at  
RailsConf.  There is a consumer plugin available:

http://identity.eastmedia.com/identity/show/Consumer+
Plugin

and development ongoing for Rails support for identity
servers too.

You can see example consumer code in Rick Olson's
Rails-Weenie app:

htt
p://svn.techno-weenie.net/projects/rails_help/

General info:

http://identity.eastme
dia.com/
http:/
/wiki.rubyonrails.org/rails/pages/OpenID


--
Josh Susser
http://blog.hasmanythr
ough.com




On Jul 13, 2006, at 6:31 AM, Scott Laird wrote:

> Yes .
>
> There are a couple things that I'd like to see. 
First, OpenID is
> probably the most useful one today, because it gets us
LiveJournal,
> and I *think* that TypeKey is supposed to be
OpenID-able soon, if it
> isn't already.
>
> The flip side of this is that Typo should be an OpenID
server, too, so
> we can publish our own identities.  This way Typo users
will be able
> to authenticate ourselves to each other.
>
> I can work on the server side if you want to handle the
client side.
> At some point we'll need to add a check so that we
won't try to use
> OpenID to authenticate against ourself--on
single-threaded servers
> (Webrick, single-port Mongrel, single-dispatcher fcgi)
that'll
> deadlock.
>
>
> Scott
>
> On 7/13/06, Piers Cawley <pdcawleybofh.org.uk> wrote:
>> I got slightly sidetracked on the way to the TRAC,
but I've been
>> thinking about identity and blogging. I really,
really, really don't
>> want to have to add yet another login/password pair
to a commenter's
>> keychain if I can possibly help it.
>>
>> But, it would be cool for people to have some way
of identifying
>> themselves in some trusted fashion (so that, for
example comments  
>> made
>> by signed in users get added straight away, but all
other comments  
>> get
>> put into a queue pending approval).
>>
>> My thinking on this is that we need to come up with
some sort of
>> an identity control API. We define the ways in
which Typo interacts
>> with an authentication service, things like:
>>
>>    authenticator.session_is_authenticated?(session)
>>    authenticator.session_user(session) - returns a
user object
>>    authenticator.authenticate(controller, session)
- May do  
>> redirects,
>>                                                    
 hence the  
>> controller
>>
>> Then our user object will carry information like:
>>
>>    user.memento - Unique string identifying this
user (for use in any
>>                   authorization system)
>>    user.email
>>    user.display_name
>>    user.icon
>>    user.url
>>    user.authenticated?
>>
>> Possibly more, possibly fewer. Methods like #icon
can obviously  
>> return
>> an empty string...
>>
>> Once we've worked out the protocols (and tweaked
our current
>> identification mechanism to use them) it should be
relatively easy to
>> write adaptors for Flickr; Yahoo; Google; OpenID;
some kind of  
>> dumbass
>> captcha system, if you really insist but don't
expect it to get
>> accepted into the trunk; or whatever other
authentication services
>> exist or arise.
>>
>> Of course, methods like
'authenticator.session_is_authenticated?'  
>> will
>> generally be accessed via helper methods like:
>>
>>    session.authenticated?
>>
>> Right, brain dump over, I shall proceed to the Trac
directly.
>>
>> Note: Authentication is *not* the same as
Authorization. About the
>> only thing I'm sure of regarding authorization is
that we shall have
>> something.
>>
>> Note2: This isn't even remotely imminent. I'm
just sketching here.
>>
>> --
>> Piers Cawley <pdcawleybofh.org.uk>
>> http://www.bofh.org.uk/

_______________________________________________
Typo-list mailing list
Typo-listrubyforge.org
http:
//rubyforge.org/mailman/listinfo/typo-list

An alternative to adding full OpenID server support to Typo
would be
to delegate to another server like pip.verisignlabs.com or
myopenid.com.

For example, on my domain brianellin.com, I delegate to
myopenid.com.
I can verify my identity w/o having to run my own server,
and I can
choose the server that best fits my needs.

Implementing delegation in Typo would require adding an
interface in
the admin section for delegation information (server url,
delegate
url, xrds url), and then adding that info to the HEAD
section of the
front page.  Thats it!

Brian Ellin
JanRain, Inc.



On 7/13/06, Scott Laird <scottsigkill.org> wrote:
> Yes .
>
> There are a couple things that I'd like to see. 
First, OpenID is
> probably the most useful one today, because it gets us
LiveJournal,
> and I *think* that TypeKey is supposed to be
OpenID-able soon, if it
> isn't already.
>
> The flip side of this is that Typo should be an OpenID
server, too, so
> we can publish our own identities.  This way Typo users
will be able
> to authenticate ourselves to each other.
>
> I can work on the server side if you want to handle the
client side.
> At some point we'll need to add a check so that we
won't try to use
> OpenID to authenticate against ourself--on
single-threaded servers
> (Webrick, single-port Mongrel, single-dispatcher fcgi)
that'll
> deadlock.
>
>
> Scott
>
> On 7/13/06, Piers Cawley <pdcawleybofh.org.uk> wrote:
> > I got slightly sidetracked on the way to the TRAC,
but I've been
> > thinking about identity and blogging. I really,
really, really don't
> > want to have to add yet another login/password
pair to a commenter's
> > keychain if I can possibly help it.
> >
> > But, it would be cool for people to have some way
of identifying
> > themselves in some trusted fashion (so that, for
example comments made
> > by signed in users get added straight away, but
all other comments get
> > put into a queue pending approval).
> >
> > My thinking on this is that we need to come up
with some sort of
> > an identity control API. We define the ways in
which Typo interacts
> > with an authentication service, things like:
> >
> >   
authenticator.session_is_authenticated?(session)
> >    authenticator.session_user(session) - returns a
user object
> >    authenticator.authenticate(controller, session)
- May do redirects,
> >                                                   
  hence the controller
> >
> > Then our user object will carry information like:
> >
> >    user.memento - Unique string identifying this
user (for use in any
> >                   authorization system)
> >    user.email
> >    user.display_name
> >    user.icon
> >    user.url
> >    user.authenticated?
> >
> > Possibly more, possibly fewer. Methods like #icon
can obviously return
> > an empty string...
> >
> > Once we've worked out the protocols (and tweaked
our current
> > identification mechanism to use them) it should be
relatively easy to
> > write adaptors for Flickr; Yahoo; Google; OpenID;
some kind of dumbass
> > captcha system, if you really insist but don't
expect it to get
> > accepted into the trunk; or whatever other
authentication services
> > exist or arise.
> >
> > Of course, methods like
'authenticator.session_is_authenticated?' will
> > generally be accessed via helper methods like:
> >
> >    session.authenticated?
> >
> > Right, brain dump over, I shall proceed to the
Trac directly.
> >
> > Note: Authentication is *not* the same as
Authorization. About the
> > only thing I'm sure of regarding authorization is
that we shall have
> > something.
> >
> > Note2: This isn't even remotely imminent. I'm
just sketching here.
> >
> > --
> > Piers Cawley <pdcawleybofh.org.uk>
> > http://www.bofh.org.uk/
> > _______________________________________________
> > Typo-list mailing list
> > Typo-listrubyforge.org
> > http:
//rubyforge.org/mailman/listinfo/typo-list
> >
> _______________________________________________
> Typo-list mailing list
> Typo-listrubyforge.org
> http:
//rubyforge.org/mailman/listinfo/typo-list
>
_______________________________________________
Typo-list mailing list
Typo-listrubyforge.org
http:
//rubyforge.org/mailman/listinfo/typo-list

Piers Cawley wrote:
> I got slightly sidetracked on the way to the TRAC, but
I've been
> thinking about identity and blogging. I really, really,
really don't
> want to have to add yet another login/password pair to
a commenter's
> keychain if I can possibly help it. 
>
> But, it would be cool for people to have some way of
identifying
> themselves in some trusted fashion (so that, for
example comments made
> by signed in users get added straight away, but all
other comments get
> put into a queue pending approval). 
>   

I vote for OpenID. There are more exciting wheels to
reinvent.


mathew
_______________________________________________
Typo-list mailing list
Typo-listrubyforge.org
http:
//rubyforge.org/mailman/listinfo/typo-list