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

[Colin Walters <walters redhat com>]

On Mon, 2008-04-14 at 16:54 -0400, Owen Taylor wrote:

>  * 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.

We need two flows in general:

1) I have a computer with an existing GNOME installation, and want to
   sign up to get the online features
2) New GNOME user

The proposed design was for 1), but I think what you're saying is we can
do better for 2).  That makes sense.  I'll see if I can try to create
that.

>  * 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.

Yeah, I didn't like the Weave approach of having account access be tied
to a password.

>  * 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.)

Hmm...true.  The more I think about the design, the more it feels like
the way we're using the cookie has some similarites to Kerberos.  Of
course a huge difference with Kerberos is we're based on email address
ownership, and not a password.

I'll think about this a bit more, because one thing that the current
proposal doesn't attempt to address at all is how an organization might
configure it to talk to an internal server.

>    - 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.

Yep.  OAuth is high on my list of things to learn.  From the little I
know though, I believe this proposal could be extended to support it
without conflicting with the architecture.