Mockups on user identity

gistfile1.md

Mockups on user identity

A video of an iOS implementation is available.

User identity

The idea of a user identity is a simple one with a goal to eliminate the requirement of a user entering a password. Any other requirement, including storing, transmitting and hashing should stay the same.

Introduction

As soon as a software is installed that supports user identities, a user is presented with a screen to identify.

Identify

The user enters her email and a new residence identifier is generated ¹ both securely persisted on the client. On an iPhone that should be the keychain. A request is sent to the server to approve the new residence.

The server sends an email to the user to verify the new residence. Once the residence has been approved, its identifier and the user email are hashed and persisted. This becomes the residence of the user identity which is used for a future identification.

Sign in

The now owner of the identity, can use it to sign in remotely to the server and retrieve her data. The user identity along with the residence identifier should be transmitted using a secure channel and compared against the hash stored in the server.

Deleting an identity

To delete an identity, slide across on an iPhone.

The identity is permanently removed from this residence.

Loose ends

1. In the web, a secure client storage doesn't exist.

Footnotes

1. The most simple form of the residence identifier can be a UUID. ↩

Some very good points here, I'm adding some food for thought.
I don't feel comfortable with the 'clone' functionality, mostly due to the naming, but there's also one thing, think of the following case:

• I have an identity on my iPhone
• I want to use the app from my iPad, so I sit back on the couch, and download the app. It turns out, I can't use it right away, but I have to 'clone' the identity from the iPhone first. Most probably a show-stopper for most users.

What I'm suggesting here (it's only partially resolving this issue), is to initiate the clone functionality from the new client, so the flow could be something like this:

• I'm downloading the app, and insert my username(?). The app talks to the global data depository, notices that there's already a user with those credentials, and sends a 'It looks like you're trying to access your data from an iPad (IP: x.x.x.x), grant permissions?" to the original identity client, in this case the iPhone.
• By granting permissions from the original identity client, you're making sure that there's not identity theft.

Just adding some food for thought.

After having a discussion with @leotsem and a reminder of @mozilla persona by @daleharvey have updated both posts to reflect the changes.

The goal is to make a simplified system that handles user identification with existing practices and tools.
See no need in creating one that is either complicated for the server or the client.

@leotsem, what if my original device gets stolen/broken? What if I need to "sign in" on my iPad but my iPhone isn't to hand?

@minignong if you need to sign in on your iPad, you just check your email.

Not sure on the stolen/broken part and what worries you.

1. iPhone gets stolen, people can login without a password.
   A. How is using a password, always signed in, any different?

@qnoid, my point was in reference to @leotsem when it was said "by granting permissions from the original identity client". In this scenario, the original identify client is the (now stolen) iPhone. So yes, the thief can access my Facebook without a password - like normal. But now the thief can also authenticate other devices too. On the thief's iPad, he enters your username. On my stolen iPhone, he confirms the identity. Now the thief has activated a service on his device now too.

@minignong got it now. The confusion started because I have since updated the post. So this is no longer an issue.

This is very interesting, thanks for sharing. Reiterating the iPad use case, I can enter the username/email of anyone I know, and that person will be getting an email. This makes it quite easy to spam other people's inbox and was wondering what were your thoughts on this?

You could probably set up something server-side that only allows 1 "sign in" request per device identifier, but I would still find it disturbing to get emails saying "Click this link to link up Joe's iPhone with your identity". A password recovery tool allows for the same kind of email spam but makes it much more cumbersome to achieve. Here I just have to enter the username/email of someone I know and that person will get an email... thoughts?

You are welcome Sam. (@samvermette)

Don't have experience in handling spam but don't see how this is any different from any other use case.

In any case, don't even see how effective spam can be since there is no control of the email content. Other than to annoy people in an effort to hurt your brand.

If someone was to abuse your service, would expect them to do it at an HTTP level, rather from within the app.
Dealing with spam is another topic altogether though. (identifying heuristics, blocking IPs)

If you still feel uncomfortable with the idea, I guess a simple CAPTCA in the app will do the trick?

By the way, there is now an iOS implementation with a lot more info on the subject. Also, a website that plan to list any apps using the above method. If you go ahead an implement it, let me know and will put your app up.

Thanks for your feedback.

Well I was really just curious about your thoughts on this. For most of my apps I use the device UDID to authenticate with the server, without asking the user for an email or whatsoever. You're right the abuse case I described is just like any other abuse, and that this is a whole other topic to discuss.

Thanks for the reply!