Identity 3: Forms of Identity

Using the InternetWide Architecture, many different forms of online identity are made available to you for your everyday use. Being able to switch between these depending on the service accessed enables you great control over your online presence.

As described in the introduction to this series and in the components used for it, we ARPA2 users can exercise great control over their online presence. We will now explain what forms of identity can be unleashed.

Individuals -- with aliases and pseudonymity

We have all seen user accounts, where we receive a unique name under a "secure realm", also referred to as a domain. In terms of the InternetWide Architecture and the implementations of it as ARPA2, we always write such identities in a notation similar to email addresses,

bakker@orvelte.nep

Here, orvelte.nep is the secure realm, and bakker is a local identity, probably of an individual client, within that secure realm. Nothing new up to this point, except of course the ability to bring your own identity that supports use of this identity everywhere online.

But using the same identity can also facilitate tracking, and it can make it difficult to filter traffic. These two issues are addressed with different variations on these identities.

Totally Separated Pseudonyms

Our client known as bakker@orvelte.nep may wish to have a totally separate identity, and toggle between those as he sees fit. The second identity might be

smid@orvelte.nep

Reasons to separate identity could be many:

• The online activities in the new identity are totally different, and should stay separate, from the ones in the first identity.
• The groups in which the identities co-operate are not the same.
• The second identity may be subject to independent ownership changes.
• The user wants to act under privacy for certain online conduct.

The idea that we pursue with pseudonyms is not to be anonymous, and thus have no facilities to collect state or access accounts, but to have completely separate online identities.

In terms of security, the InternetWide Infrastructure will create fresh keys for the establishment of certificates and PGP public keys and so on. It will not make any administrative connection between the identities.

Given that we present a single sign-on framework, it is important to realise that each pseudonym is completely separated from other identities; in fact it is just an extra user identity. This means that login to each identity must be done separately; having three pseudonyms means that three "single" sign-on logins must be done per day, rather than one. This is the price to pay for privacy; it also means that each of the pseudonyms can be logged out separately, which may be advantageous.

Light-weight Aliases

Based on a client identity, variations can be made by adding a plus and (what could be called) a sub-identity. For instance, the identity

bakker+shop@orvelte.nep

could be used to signify shop-related affairs. This mechanism is lightweight, in the sense that the identity of the original account is hinted (although no formal conclusions may be drawn from this client-local naming habit) and therefore the same security keys can be shared that were defined for bakker@orvelte.nep.

This sharing of key material makes all the difference. The creation of new key material is relatively costly, and storing it most certainly is. There are bound to be limitations to the ability to stretch this key material, which are bound to translate to price levels and maximum numbers in licenses. This level of control is not reasonable for this light-weight alias.

Another advantage of sharing key material is that it is not necessary to login to each alias separately. In that sense, the alias is much lighter in use on the end user as well.

The major benefit of a alias, aside from its separate name that helps to sort traffic or give it somehow other treatments, is that it also gives rise to separate use within our access control framework which uses the local name as an index to determine what remote identities are permitted to access it. In case of bakker+shop@, the approach would be to combine whitelists and blacklists for the identity and that of bakker@, and to use the default policy from bakker+shop@. Newly contacted remote identities will end up with the identity that was used in outward direction, so that would be bakker+shop@ when that was used for communication.

This permits use cases such as:

• Block all traffic to bakker@ by default, but permit traffic to bakker+shop@ by default. When bakker@ is not used for outgoing traffic, the ACL would learn to accept only access to bakker+shop@ and similarly could the ACLs of other aliases be filled. When bakker@ is used directly, it too can learn an ACL, and its members would have access to all aliases as well. This principle acts like the aliases of an identity being separated.

• When contacting a new webshop, a new alias can be created on the fly. The authentication is founded on previously established cryptographic keys, but the new identity is strictly meant for access by the webshop. Their use of any other address can easily be blocked. When done trading, the identity can be closed. This puts the user back in control regarding "spam" from parties with whom they had a business relationship. Privacy laws don't always enforce client control over such relations, and termination of such relations is a bit vague. Using this mechanism, the client doesn't need to jump through the questionable hoops of a determined "business relationship".

Identities for Groups

In many cases, you will want to work together in a group. This is an important part of identity management, as you will often want to define access control to services in terms of a group. Why? Because it is easier to manage a group then to grant access to a list of online services. This is especially true if remote services are part of the mix; it is usually more difficult to setup their access control, while it is relatively straightforward to add or remote a member of a local group.

For this reason, the InternetWide Architecture not only lets you create users, pseudonyms and light-weight aliases, but also to create groups quickly and easily. Groups are created as lists of users, in which the creater is entered by default.

Groups are subject to access control for the CRUD actions: create, read, update and delete of members. By default, a user may read and update its own membership entry, but creating a new entry (for oneself) or deleting it (for one's own entry) may or may not be controlled by the members themselves, let alone for other members.

Groups have a common name, like

ambacht@orvelte.nep

As you can see, there is no distinction in the form of identity compared to users.

Members can be assigned a subname that looks like the form for aliases, namely

ambacht+bakker@orvelte.nep

Addressing the ambacht@ address means addressing the group, while addressing ambacht+bakker@ means addressing a group member that is known within the ambacht group as bakker. There may or may not be a relation to user by the name of bakker@orvelte.nep.

What it means to talk to a group, or even a group member, depends solely on the application. When you select services to run for your identities you should take notice of the choices made here. A few examples that may or may not work as we can think of abstractly:

• Websites accessible to a group are either accessible to individual members or, more practically for remote service access, to the group as a whole; when a member is added to, or removed from the group the website will automatically adapt to the new group configuration.

• Email to a group is only permitted for group members; email is forwarded to all current group members; email history is stored in an IMAP mailbox that can be accessed by all current group members; but how is encrypted email handled?

• SIP telephony to a group rings on all the phones of all the group members; the first one to answer will get the call, and cancel the incoming call on the other devices; alternative implementations could introduce ordering, and so on.

• XMPP chat to a group is delivered on a group channel, to which group members are permitted to subscribe. When the group configuration changes, so does the access permission of group members to the group channel.

Identities for Roles

Roles are used in authorisation issues, so to answer questions like "can this user A access resource R?" -- so roles are assigned to users. A common example of a role is admin, but it might equally well be sales, research or parent to shield of parts of the infrastructure.

Users can have aliases such as john+admin but that would not be a safe way of assigning a role to a user, since aliases can be created on the fly. Instead, roles take the same external form as a group with a member; there is no need to externally distinguish about these forms, and internally a lookup will add the desired information.

Administrators might be assigned the role admin, and when John is added he might go as admin+john -- which does not refer to the user john but to his alias john+admin. Note that nobody but john can create this alias, so this use is secure.

As with a group, there is a separate key for a role that all role occupants can gain access to with their matching alias.

Distinction between Roles and Groups

Roles and groups look similar, and in many ways they are similar. Communication protocols however, are likely to treat them differently. Where a message to a group member would normally be copied to other group members, this is not the case with roles.

Users from Another Planet

Protocols generally have ways of dealing with accounts that pass on their traffic to another account. In its simplest form, this is comparable to email forwarding, but that simple form brings about many problems:

• Frameworks for spam filtering like SPF can get confused because they receive email forwarded from a source that is different from the permitted ones, namely the forwarding mail service; this however, is a local problem.

• Messages relayed to a "real mailbox" from a general name such as an info@ address are replied to from this "real" address, causing message filters to have less control over whether the reply is reliable. Note that the change of address is also not generally what the sender wants; their "real mailbox" is often of a temporary nature, perhaps because it is assigned by their current ISP.

In general, it is better to use something akin to network address translation, especially because its inherent problems for the IP protocol don't apply to the flexibly-sized strings used as identities.

If anyone flies in from another planet and should be granted an identity under a given secure realm, then a foreign identity may be assigned to the identity may be attached. For incoming traffic, this would get forwarded just like is customary for email, but there must be an arrangement for return traffic as well. The method used for this is specific to a service.

There is no reason to limit this facility, other than to make it usable only for individuals; so, individual users and pseudonyms, aliases, group members and role players can all be from outer space, as far as the identity framework is concerned; groups and roles on the other hand, are always locally defined.

Note that a service should also be selected for its support of this facility, as not all may be able to support foreign identities; in that case, the visitor from outer space cannot use that particular service, be it email, chat, telephony or whatever else is being suppressed.

Simple one-sided forwarding is explicitly prohibited under the InternetWide Architecture; it leads to hacks, and reduces the opportunity of other users to filter content.

To the Remote Service, it's All the Same

A final thing worth noting: To the remote service, that is the one to which you are bringing your own identity, all these forms of identity look the same. Sure, the use of a plus sign is more often used to do these things, but no-one can assure you that this is indeed the case as it is subject to the local policy on the client's end. And groups are not distinghuishably named from individual users, which is also relatively common. Of course pseudonyms, with their strong emphasis on absolute separation of usage patterns, most certainly are not distinguishably named.

Update 10 december 2016: The name role was applied to what is now called alias. The current use of a role as an authorization mechanism had not yet been defined.