Identity

Identity
=====

This module provides a framework for capturing the identity of an anonymous user, associating data with that identity, and customizing user experience based on those data. Think of identities as users “light” - they have associated properties and permissions, but don’t require account creation or login. Or think of them as sessions which can be re-instantiated via a link or by providing a piece of identifying information.

Why Identities?
Often, we want to encourage participation in a site without requiring a visitor to go through the process of creating an account. This usually involves saving data into the visitor’s session, but what happens if the visitor changes browsers or clears cookies? With Identities, we can preserve state across sessions, providing visitors with links or codes which allow them to retrieve their state. Some use cases:
Allowing visitors to perform an action only if they’ve received an invitation, without requiring them to log-in or create an account
Allowing visitors access to protected pages and resources only if they’ve provided their email address.
Prepopulating a form with responses collected from another form.
Providing a “continue” link in an email which allows a user to return to a previous state, e.g. a shopping cart or questionnaire.

What is an Identity?
Simply, an Identity is a Drupal entity with a human-readable name (the “identifier”) and arbitrary associated data. Common identifiers are email addresses or names, but anything is possible. Identities are stored in the database just like users, and there can be a “current identity” analagous to the currently logged-in user.

How do we capture identity?
Generally, identity is captured via a form submission. The visitor provides some identifying information, and this is stored to an Identity entity, along with any other data the visitor provides. The bundled identity_webform module implements this for webform submissions, but it could easily be extended -- a comment form, a checkout form, a node author form or what have you.

How does identity persist?
Once an identity is established, it is saved into the session (or into a custom cookie, see below). The data associated with that identity are available on every page load, and can be augmented -- e.g., we could keep a record of every page visited, or every node authored, or every product “liked”. But those data survive the destruction of the session. They are available for tracking purposes, and can be re-instantiated by re-establishing the identity.

How is identity re-established?
Let’s say you’re not a registered user. You’ve spent a lot of time creating a post, but have to leave your computer. You revisit the site from another computer and want to continue your work. If we’ve captured your identity, we can provide you with a way of saying “it’s me”. The bundled identity_key module provides a mechanism for creating links which can be used to establish identity.

IMPORTANT SECURITY CONCERNS
Bear in mind - if you collect sensitive personal information you should require a login to access it. You need to judge very carefully what establishing an identity gives a visitor access to. For example, you would NEVER save credit card information to an identity, and then allow anyone who knows the email address of the originating identity to access that information. The identity_key module provides a variety of methods for securing the links that establish identity, including expiration, limits on number of uses, and even requiring a passphrase. But if the data you are saving are truly private, you should not be using Identities; you should require users to create an account and password.

What can we do with Identity?
Almost anything. Panels and Views access plugins are provided. Also, Identities are exposed to Rules and Tokens (via Entity API), so you can customize content and workflow. Node Access and Context implementations are on the roadmap.

Side Note: Identities as Users
Essentially, identities are like users, except they are invisible to the visitor.
- No login/logout
- No "my account" page
- One user can have multiple identities
- Can be expired
One solution would have been to create some new permissions -- e.g. “log in/out own account”, “view own profile”, etc. Then an anonymous, identified user would simply be a regular authenticated user with very limited permissions.

This has the advantage that all existing systems (rules, context, panels, permissions, node access, etc.) which tie into the Drupal user/role system would work out of the box.

However, it’s kind of a hack. We’d have to take over /user, /user/login, /user/register, etc. in order to provide a truly anonymous experience, and we’d be violating assumptions that might be made by both core and contrib about what it means to be “logged in”.