If you are creating an online application or community that handles personal information you want to know who is currently online. The old way involves creating a user profile with a password.
The world has changed a lot the last 20 years. It has become a lot more common to use several different devices. For example, browser at home, browser at work, personal phone, tablets, smart TV, and maybe more. It has also become more common to switch to new devices or new applications more often. Password managers on devices or in browsers has made some of this easier, but not all of it. It has also been common to use logins and identities from Google, Twitter, Facebook, Github, Apple of Microsoft. There is often a problem with sites offering different login methods. You may not remember which account was used for the site. This will lead to problems with multiple registrations.
There are also common patterns of using fake accounts or fake identities in order to not give away personal information. Many people also has different accounts for different parts of their life. One for work, one for their hobby, one for family, that has different profile pictures, email addresses, names and information. The desire for personal integrity results in a lot of problems for the same person then they don't remember which account they wanted to use for the specific site. They may also accidentally use a family account in work context or some other mix up.
I spent some time thinking about solutions for these problems in 2016 with the goal of creating a library for minimizing the barrier and time for registration, login and merging of account from the different login options. Since I have been working on voting applications I have also been interested in how to avoid multiple registrations, fake accounts and security.
Many of the larger federated login providers has made a lot of work for account management. But we can't depend on them since a lot of people don't want to use them. That means that we must implement those thing, including identity verification, account recovery and identification of stolen accounts.
The base concepts for this is
- Identity — are you who you say you are?
- Integrity — are there no one else using your account?
A design for login and identity framework
This will handle people that has several accounts under the same login providor. (For example, more than one facebook account.) It will also handle shared accounts such as organisation role accounts or shared family accounts. And it will separate the public profile from the login method.
We use three layers:
- acting identity — The internal private system id representing a single person
- provisional identity (pi) — One or more profiles or organizational roles, that may be used as public profiles and may have other provisional identities as parents or childs. They can belong to zero or more acting identities.
- account — The actual login methods, like lokal user/password, federated login from Google, Facebook, et al. Each account information will be bound to at least one provisional identity, that will keep that information in sync with the login account.
Provisional identity
A provisional identity (pi) can have:
- lots of connected accounts
- personal data, like birthdate, residence, occupation
- One or more PERSONAS, that is a public PROFILE that may have ROLES
- AUTHORITY to access or edit other NODES including identities
Merging of accounts
A pi may connect to an account belonging to another pi. If it is a SHARED account that might be okey, but it can't be used for personal login. A connection could be suggested for an ORGANISATIONAL identity with shared personal authority.
If one of the pi are empty except for the account connections; the connections may be moved to the non-empty pi.
If both pi have content, a merge can be suggested.
A merge will create a new pi. The two old pi will be marked as read only. The merged data will be created in the new pi. The old data will be marked as deleted or copied with pointers to the new pi. It must be possible to restore the pi to the state before the merge if needed.
The actual merging of data can be done automatically or with the help of the user. The two versions could be displayed side by side. All typoes of data should have consistency rules as to if they can co-exist or not. Conflicts has to be resolved. Event data from the pi, like forum posts, can mostly be copied by linking them to the new pi.
The merge could stay in that form for a long time. When everything from an account has been merged, it will be disabled. Either hidden or marked as history. The merge could consist of just ingoring everything thats not copied automatically.
The ACTING identity is the active pi, that is not in merge state och deleted state. The acting identity can point to one or more pi that each may point to other pi. But they should all be resolved to a singel pi and all others are marked as history or be relations to other nodes.
Trust measurement
Each pi has an identity score for how sure we are that the information represents a real person and that the accounts belong to that person. Each account also has an identity score.
Each pi and account also has an integrity score for how sure we are that only authorized AGENTS has access to it.
The combination of identity and integrity score gives a indentity trust score (ITS).
For certain threshholds of ITS; each account will be asked for permission. And the accounts and pi with the highest its will be prefered.
This system is intended to be usable both for high and low its. Easy ONBOARDING but higher levels of identidy score for high-trust ACTIONS (like voting).
The acceptance for changing identity information including accounts will include AUTHENTICATION, NOTIFICATION, VERIFICATION and different WAITING persiods. Additional identity PROOF might be requested.
SIGNALS will be gathered for building up identity and integrity scores. It will also include relations to accounts and pi based on digital and spatial overlap. That includes people who live together or otherwise share accounts in some way. That would include accidental logins to accounts that are later DISCONNECTED.
Accounts can be disconnected and pi DELETED. A deleted pi would imply that all theirs connected accounts will be disconnected. The accounts will be open for connection to other pi but with a lower its by the fact of the signal from the relationship with the previous pi.
We should let people easily delete accounts, even if they still exist as history.
Personas
Everything visible to the outside, are filtered through personas. A pi can act as a persona and as such have outside facing data like profile pictures and presentatons. Other data like the real name must be merged to the acting identity.
Personas can be gathered or initiated by the account connected. If another account is connected and data imported, it may connect that account to another persona pi, and create a new acting identity. Personal data will be merged and the two personas can be kept or merged to one.
New personas can be created, without connecting accounts, as child nodes to the acting identity.
The persona should only be used then its purpose is clear, as in that different profiles can be used in different circles. One for friends, another for family, another for political affiliation, one for each workplace, one for each community. Only as needed. Especially in cases when the person wants to have some degree of anonymity or wants to be known by an alias.
A persona may also be coupled to a specific organization, as in that the person has one or more relations to thar organisation. They might be roles, responsabilities, authorizations, membership or just interest. The persona is used if the relationship to the org needs to be grouped. There could be connected accounts specifically belonging to that org.
auto-login-pwa
I started on a system for implementing this, using browser credential management api and thinking about session management and login flow, across multiple tabs.
