A video of an iOS implementation is available.
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.
As soon as a software is installed that supports user identities, a user is presented with a screen to identify.
The user enters her email and a new residence identifier is generated 1 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.
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.
To delete an identity, slide across on an iPhone.
The identity is permanently removed from this residence.
- In the web, a secure client storage doesn't exist.
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?