Re: A standard scalable privacy-aware online account system for GNOME

On Thu, 2008-04-10 at 15:43 -0400, Colin Walters wrote:
> Hi,
> I've been working for the last day or so on designing a new account
> system.  My explicit goals included:
> * Allow for encrypted private data
> * Be as "user friendly" as possible
> * Be scalable
> * Support OpenID
> * Be easily extensible for both "internal" services as well as third
>   party services.  In particular, we want it to be easy for the current
>   XMPP/data-model "live" service to use this system for authentication
> I've written up a page with my proposed design here:
> Comments appreciated.

Thanks for writing up. I think it's definitely on a good path of
sketching out something useful that's also pretty simple and
implementable. You can definitely get yourself into problems with trying
to solve to much in this area.

Let me see if I can summarize the main points of the proposal, with my

 * We require people to validate an email or OpenID to create a new
   account, in addition to solving a captcha.

   - I think there is an inherent tension between a very directed
     interaction for initial signup:

     - What is your name, and email
     - Pick a photo
     - Pick a pass[word/phrase] to encrypt data stored on the server
     - Please accept our terms of use

   And the browser based interaction of approving an OpenID request
   or checking your email. It seemed to me that you should be able
   to create an account and log into the desktop, and then have 
   validating your email as a separate step before you could use your
   account fully.

 * There is exactly one password, the user's encryption password, which
   is never sent to the server, and which the user is responsible for
   keeping track of. We provide no key escrow or recovery mechanism, but
   we do allow setting a new password and recovering the other functions
   of your account.

   - Sounds like a reasonable formulation within the limits of what we
     can do.

 * We use a custom authentication method to authenticate the user
   the user to services. 

   -  The proposal calls for using a shared secret between the services,
      but there's no reason this couldn't be done in a more
      sophisticated fashion. There's plenty of existing practice for
      presenting a ticketsigned by an identity provider (Kerberos,
      Information Cards, etc.)

   - The more interesting question to me is how a service becomes 
      authorized to do something *on behalf* of a client. So instead of
      being analogous to OpenID, you need something analogous to OAuth.

- Owen

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]