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
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,
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
email@example.com may wish to have a totally separate
identity, and toggle between those as he sees fit. The second identity might
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.
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
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
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
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@ 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
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
admin, but it might equally well be
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
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.Go Top