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.
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
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
group+member, as a sub-identity of the
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.
xxxreceive their own keys / credentials, and their public sides will be published in LDAP for search filter
(uid=xxx)under base DistinguishedName
dc=example,dc=comto represent the DoNAI
firstname.lastname@example.org. This applies to the
groupidentities. 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+yyyare 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
email@example.com also found under base DistinguishedName
dc=example,dc=comwith search filter
(uid=xxx+yyy). This applies to the
user+groupforms. The forms publish credentials with these alternate identities, based on the same key material as for
Pseudonyms such as
zzzare different from
xxxand has its own key material, so any relation to
xxxcannot be inferred. It is a more heavy-weight, computationally more expensive identity. Internally however, it is useful to be able to login as
xxxand be able to use Pseudonyms such as
zzzwithout 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.
group+membereach have a reference to the occupant or member identity; this may be a form like
mail=foreign@domainto 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+groupare 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:
domainas the realm for the problem at hand;
sourceas the authenticated domain user or
targetas the identity being targeted;
publicas 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
targetbe constructed under
domain? And when this is done, what
publicidentity should the
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
role+ or even
user+ to indicate
any sub-user under the given primary identity
Impact on Privacy
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
pseudonym can be defined (at the expense of separate
keying material and separate login).
Much more useful are the forms
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
role+occupant address would then be
used as the
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
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
group+nat+member or whatever the mail solution
thinks is useful.
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.
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
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).