Identity 6: Inheritance of Identities

// under architecture identity hosting

This article explains how we perceive the relations between the various kinds of identities that we described before. Spefically, we turn to inheritance between identities.

As we develop the kinds of identity that we need to implement our ideals of improved security and privacy through identity control, we refine the InternetWide Architecture into what is needed in an ARPA2 project's technical detail level, and how we can relate this to current-day open source software.

The normal user login is made using the initial user identity supplied to the user by the administrator of their domain name. Users may then continue to setup aliases, pseudonyms, memberships of groups and occupancy of roles. This gives the user great control over how they appear to the outside world under our Bring Your Own IDentity (BYOID) concept.

Having multiple identities is only usable in practice when one login suffices to get to all those identities. This is why we speak of inheritance -- access to one identitie implies access to the rights granted to another. This is often a directed operation (namely, in the direction of the arrows in the diagram above), because a group should not be able to use the access privileges of its members, for instance.

(We have a few undecided issues, denoted with dashed lines in the diagram, and that is whether pseudonyms should be completely separated (as their key material is) and therefore warrant separate login; and whether there is a use for having an alias for group membership, as we have it for role occupance; finally, whether external users should in certain circumstances be granted rights to a local user name / account. But we're getting ahead of ourselves.)

What the Inheritance Diagram Means

The user identity is the primary point of login for a user. Have a look at the three user+yyy forms pointed at from the user identity; these three forms are controlled by the user, who creates them on top of the primary user id. We might think of them as sub-identities, and their different name grants us variation in access control even when it is visible that the names are derived from a primary identity.

Aliases are just that, but when used like user+role (or user+group), the basic idea is that the occupancy of a role (or membership of a group) receives explicit an notation for the user. It is this form that then subsequently enters into a role or group, in which the user is represented as role+occupant or group+member, as a sub-identity of the role or group primary identity. This enables a form of address translation, where a user is represented externally with another identity, and with the key material that is designated for use with the role or group. The sharing of key material with other role uccupants or group members is vital in the equivalent handling of group members or role occupants; when one person with an administrator role is out on sick leave, another may take over; when one member in the purchasing group receives encrypted messages, the other group members can read them too.

Role occupants have a distinguished sub-identity to facilitate continued communication with an inidividual role occupant, even when they all behave as one; group members have a distinguished sub-identity to distinguish a poster in a pseudonymous manner. For roles, the usual response will go to the role occupant, whereas for groups it will normally go to the group as a whole.

Note the inclusion of foreign role occupants and group members as though they were local members. This is not just a consequence of our intended support for BYOID, it is also a modern alternative to what we've been hacking away at with mechanisms such as email lists; such a list could become a group and it must be capable of welcoming foreign members, under access control rules that match the group's feeling of privacy. Note how a sub-identity will be assigned to each (foreign) group member as it would for any local user.

Groups can be nested. Let's say that you have a breakdance club which also hosts hiphop dancers, then you can create two groups for the types of dancer, and combine these groups into a club members group. It is theoretically possible that cyclic group definitions arise in this manner, in which case we do not define behaviour (but will try to implement recursive references as empty lists wherever possible, to have meaningful semantics and to be able to suppress error messages, but we give no guarantees at this point).

Roles are used for access control, and nesting them is probably confusing. We therefore have not offered nesting facilities for roles. What is possible however, is to assign role occupance to not only individual internal and external users, but also to groups of users. Since roles are about access, they are not parts of groups. Access to group settings would be assigned to roles, but that is a different matter from allowing roles as group members, which, once again, would be confusing and is therefore not defined.

Impact on Authentication

With authentication or authn, we mean the mechanisms that prove the ownership of one's identity. It involves credentials of a cryptographic nature, such as a certificate, public key or ticket. In much of what we do, we use the LDAP global directory to provide information on credentials supported by a domain.

One of the major tasks in the IdentityHub project phase is to create credentials for authentication and publish their public sides in the LDAP Global Directory under a managed domain.

• Primary identities xxx receive their own keys / credentials, and their public sides will be published in LDAP for search filter (uid=xxx) under base DistinguishedName dc=example,dc=com to represent the DoNAI xxx@example.com. This applies to the user, pseudonym, role and group identities. Foreign users are not incorporated, but are expected to facilitate their identities in a similar or otherwise cross-realm acceptable manner.

• Secondary identities such as xxx+yyy are stored as directory objects underneath the ones matching (uid=xxx), and they can be sought in the same manner to not require knowledge of the sub-identity idea in remote dependants; so xxx+yyy@example.com is also found under base DistinguishedName dc=example,dc=com with search filter (uid=xxx+yyy). This applies to the user+alias, user+role, role+occupant, group+member and user+group forms. The forms publish credentials with these alternate identities, based on the same key material as for xxx@example.com.

• Pseudonyms such as zzz are different from xxx and has its own key material, so any relation to xxx cannot be inferred. It is a more heavy-weight, computationally more expensive identity. Internally however, it is useful to be able to login as xxx and be able to use Pseudonyms such as zzz without separate login. It is the user's choice whether he wants this (for reasons of complete separation) or not. Pseudonyms require creation permissions at the level of the domain user, unlike aliases for which each user has complete control.

• The forms role+occupant and group+member each have a reference to the occupant or member identity; this may be a form like uid=user+role or uid=group or mail=foreign@domain to indicate local and remote elements incorporated into the structure. Such remote elements might be pre-selected by using an alias reserved for that purpose on the remote end, which is why the alias forms user+role and user+group are demonstrated in this diagram. Note that the referenced LDAP entries may or may not exist; when they don't, the facility is simply not available and group membership or role occupance should not be considered complete.

Where public credentials are shown, there is an additional facility of a PKCS #11 reference that is only visible to the originating user. This can be used to gain access to the credentials. While this may sound like a recursive definition of private key material, it is actually useful to hop from one authentication method onto another. We use it to initially login using Kerberos, and from there be able to gain access to private keys stored in PKCS #11 for use with X.509 and OpenPGP.

Impact on Authorisation

The arrows indicate access from one identity form to another. The direction of the arrows is meaningful. The complexity of the pointing structures makes it likely that we will derive the forms beforehand and unite the information into a table or view that details just:

• domain as the realm for the problem at hand;
• source as the authenticated domain user or foreign@domain user;
• target as the identity being targeted;
• public as the published identity when using the target.

Most authorisation questions should end up making requests to this table, but the basic question would be

Can a path from source to target be constructed under domain? And when this is done, what public identity should the source take on?

For the future ServiceHub phase, we will attempt to not distribute this table as-is, because that would publish more information about a domain than strictly required, so there is room for a more subtle approach. The model however, would still aim to answer these same questions.

Each resource would have an access control list or ACL to identify the various identities that are granted access. Roles are not enforced in this process, but they are highly advised in the support of easily configured access control based on general inidiactions -- such as an admin role that can occur in many places, but that only needs to be modified in one place to add a user to this role, or more importantly, to retract it. One place where a role is not ideal, is when group members have access to group privileges.

Note that this framework defines who may use what identities on top of their current ones; it does not indicate that one user can communicate with another. This is a separate matter altogether, that we will discuss separately under the concept of black and white listing.

We introduce a form group+ or role+ or even user+ to indicate any sub-user under the given primary identity group, role or user.

Impact on Privacy

The form user+alias is not a good way to conceal one's identity, but when user has more restricted access control, it suffices. In other cases, a totally independent pseudonym can be defined (at the expense of separate keying material and separate login).

Much more useful are the forms role+occupant and group+member which conceal the actual username behind it, even though it may be practical to choose voluntarily to indicate the user: for example, john may choose to be take on the admin role as admin+john, but that would be his choice.

When logging or publishing activities form a group or role, then the sub-identities are used to indicate the user. For example, on an email list, which is automatically setup for every group, the sub-identity of the group would be used in the From header when an email is forwarded to the group.
For groups as well as roles, the To header would be set to the group or role by the sender, unless he wants to address an individual member or occupant, whose group+member or role+occupant address would then be used as the To address.

When traffic passes back to the group (or role), then access control is applied as it is needed for sending to the group or role; and when it matches, then the reply can be forwarded to the local or remote user. Once again, reply settings are made to pass traffic through the group or role.

The result is that group members have the option of being somewhat anonymous. Administrators would still be able to find the member's identity, even when it is remote, but normal group members would not.

The manner in which group members or role occupants pass response traffic through the group or role means that they appear to their remote correspondent party as though they really are acting on behalf of the group or role; this is why we suggested the trick of using this mechanism for generic addresses such as info@ or support@ under domain names. This enables replies from the same identity and is therefore helpful in maintaining black and white lists that permit response traffic base on outwards contact attempts. Unlike NAT for IP addresses, which suffers from a lack of storage space, the sizeable nature of higher-level protocols such as email permit the insertion of another address in an email address. For example, as a special sub-identity group+nat+member or whatever the mail solution thinks is useful.

Post Scriptum

Addition 2016-12-30: There may be good reasons to permit references from user to user; this could support pseudonyms without explicit login into the other identities. A great convenience, but it also means that we must account for cycles in the users. A similar problem is less useful, but still not impossible between groups.

This calls for special algorithms, namely for the computation of transitive closures. Probably the best algorithm for this is Floyd-Warshall which not only computes the existence of a path, but it even provides the length of the path, which is helpful in determining which from a selection of available alternatives would be the preferred choice. There are even slight modifications that construct a shortest path in only modest extra storage space.

The Floyd-Warshall algorithm consumes O(N^3) time and O(N^2) space, given that there are N identities involved. We can drastically cut back on this time through a number of optimisations, such as partitioning beforehand, and/or computing partial graphs only, such as looking just at users at one moment, or looking just at groups (after incorporating group members) at another moment and then doing the fairly straightforward composition in the aftermath. This greatly reduces the graph sizes, and therefore the number of cycles to be expected. Though tricks might help to extend the graph, it is possible that a complete recomputation is needed after removing arrows from the graph.

An alternative algorithm exists, namely Dijkstra's algorithm which is more efficient in sparse graphs, running in O(N^2.log N) and, possibly more efficient under proper conditions. The algorithm compute for a single shortest path, which means that its results do not yield a good overview and are therefore less suitable for caches, but it may be possible to mix the two approaches when known pieces of the cache have been invalidated by changes.

Addition 2017-01-01: Happy new year... with a few decisions made to the inheritance diagram. The Pseudonym has been introduced as a real target, pointed at by the Primary user identity. This means that inheritance from user to pseudonym has now been decided as a possibility. This means changing the user name and associated key material without a separate login. Not the only way to go, but it can surely save a lot of work. Foreign identities now link to the Pseudonym, instead of the Primary user. Furthermore, the user+group variation has been accepted, because it can be very useful to pick this alias locally before moving over to a foreign realm. Although this use was already possible with the plain user+alias form, it is now more visible through its parallel to the local diagram. Also note that this enables multiple memberships of a group, so lonely people can finally talk to themselves (and people who are curious in both meanings can test group facilities by talking to themselves).

Go Top