Changes between Initial Version and Version 1 of doc/developer/OpenID

03/01/07 15:53:29 (15 years ago)

New design-ish document


  • doc/developer/OpenID

    v1 v1  
     2Original author: Benoit Grégoire, last modified: 2007-03-01 
     3= Why OpenID = 
     4Supporting OpenID would be a very good thing.  There are PHP libraries available so it wouldn't be too hard to implement, and Wifidog is exactly the type of software it was meant for. 
     6However OpenID is a very misunderstood specification.  What OpenID basically does (and all it does) is provide a mechanism to prove that one (or more) person owns a URL.  It also allows two independent systems on the Internet to know that two users with the same OpenID are indeed the same user (or group of users) 
     8== Single sign-on == 
     9OpenID's main benefit is single sign on.  In fact, it works almost exactly like the way the wifidog gateway currently authenticates a user against the auth server.  And for the user, not having to remember (and give us...) yet another password for wifidog is something that will make many people very happy. 
     11== Wifidog federation == 
     12OpenID is not, however, a distributed trust model.  It is also not, in and of itself, a way for two systems to share a common userspace.  So it does not make it as much easier for us to do federation as one may think. 
     14We can't simply say:  "Trust any open id at (for example) the identity provider".  It would work, but would defeat the main purpose of OpenID by forcing every user doing roaming to sign in using the URL of a specific IdP. 
     16We could however use OpenID as the backend to exchange credentials.  Somebody selects NYC wireless from a popup (can't skip that step unlike the above), and types in his username only (which may be his OpenID, but doesn't have to be).  Wifidog can then custom-build an OpenID query (which is not the way OpenID usually works) to be sent to the NYC wireless auth server using the OpenId protocol.  The user logs-in there (or is possibly further delegated to another OpenId server), and then get's back to the original auth server, logged-in.  That's very secure for the user (less so for the group).  But it should work, even if that's not really what OpenID was designed for. 
     18= Implementation = 
     19There are off course several thorny UI questions to answer. 
     21On the backend implementation side, there are three almost independent features to build: 
     22 * Allow wifidog to act as an OpenID consumer, and allow the user to convert an existing account, or sign up a new account using OpenId. 
     23 * Allow wifidog to act as an OpenID server (identity provider), and make it delegate if the user is already using OpenId.  
     24 * Allow wifidog to use a remote auth server's identity provider as an authenticator for a Network (it does depend on #147:  network peering to work, but that's trivial).  
     26So I think that using OpenID for single sign on is VERY desireable.  Using it for federation is an option among others to consider.