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 live.gnome.org page with my proposed design here: > > http://live.gnome.org/OnlineDesktop/OGOAccount > > 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 comments. * 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