When crossing over between identity realms, internal identities are not always revealed externally. In general, there may be a translation or mapping from an individual to a group or role, from a user to its domain, and so on.

Concealing Internal Identities

Identities that a user needs to access internal services may sometimes be considered sensitive. In general, they may be too detailed, for instance when a person is to act on behalf of a group, or from the perspective of one role being fulfilled. This calls for a flexible translation scheme for identities, or in ARPA2 speak, of DoNAIs.

Consider john@example.com who wants to use realm crossover technology to access a service. Perhaps he wants to contact a remote sales department to fetch a formal proposal.

John will be on holiday next week, and his collegue Mary may need to pickup on the offer if it takes that long. To cover for such events, they use a group identity, or perhaps it could be called a role, named purchasing@example.com, that they use for such external contacts.

John is logged on internally as john@example.com and Mary authenticates locally as mary@example.com. This is useful, because it helps to keep their internal administration separate -- each also fulfills other tasks, and those do not always overlap.

When approaching the remote sales service, using any protocol at all, the name of the receiving end is matched by the identity perimeter in the database that the identity manager keeps around. The match is based on a DoNAI selector, so it might be a general match or one that is specific for the target service. The result is that John's internal authentication is used to assert his extern identity as purchasing@example.com, which is asserted to the World using any realm crossover technologies.

Controlled Access to Services

On the sales server, access control does a general verification if the approaching purchasing@example.com DoNAI is granted access to the requested sales server DoNAI. The sales server is only published to established business relations, of which John and Mary's purchasing department is one.

In the ARPA2 approach to identity management, it is important to understand how the identity perimeter helps to establish a more refined image of the remote user. The ability to treat access based on a role DoNAI makes it simpler for the service-side to manage access rights. First, because the client realm manages responsibilities for the members that are currently enabled under the given role. When Mary leaves the purchasing@example.com group, she will not be permitted to speak on behalf of that department any more, but this is an internal affair on the client side, so remote sales contacts will not need to alter their access rules. John and Mary also feel the benefit of using roles, as they can act to the outside world from their various roles, displaying a different identity to different remote contacts -- each of which sends back any information to the DoNAI of the respective role, which helps them to sort and select such traffic. The holiday scenario is just one example of this.

Since John's inquiry is granted, his service request passes on to the sales server, where some actions will be subjected to more refined authorisation control; as a client, John has been classified for orders up to a certain amount, and his credentials do not include permission to modify the articles being offered, or the prices being charged for them. The local authorisation scheme implements this by ordering the purchasing@example.com external identity into a group, from which the server derives such privileges. This sort of detailed service authorisation is exchanged between the local authorisation database and the server.

User Management -- well beyond Password Mangement

As will be clear from this, the full-blown ARPA2 identity infrastructure goes well beyond the mere management of a user name with a password, as is commonly used on web sites. First, because there are advanced security mechanisms such as TLS-KDH to create a single-signon service for the client; second, because there are powerful facilities for controlling one's online identity, and make it dependent on the party being spoken to.

The general flow of control as sketched in the diagram above constitutes of the following steps:

• Authentication of a client against a local identity manager;
• Identity translation to assert an external identity as is suitable for contact with a remote service;
• Identity assertion by the client side towards the service side;
• Authorisation for access to the service, based on a confirmed external identity;
• Service management largely comes down to granting a mixture of external and internal identities access to internal services.

Note that a service may also act as an internal service, and that access to it may be granted on grounds of internal identities as well. This may mean more detailed access control to internal users. Since internal users often fall under one (or a few) domain names, it is straightforward to formulate a DoNAI selector that grants such internal access, and couple it to specific rights.

Bidirectional Contact

The diagram shown above clearly shows a client and server side of a communication. Note that this is just a representation of the two sides, but that the reverse is likely to apply on return traffic. In support of this, the default ARPA2 policy is to permit such return traffic whenever outgoing identity mapping is being setup. Basically, when you send an email your should not be surprised to get a reply ;-)

The most detailed form of bidirectional traffic is of course peer-to-peer contact. This is not much different from client-to-server contact; the initiative is just easier reversed. This is also in line with the default policy to permit incoming traffic that returns on outgoing traffic, so it is not problematic in terms of identity provisioning under ARPA2.

The one thing that requires special attention on peer-to-peer contact is that there usually is some form of registration and lookup for identities; this will often refer to a session that spans accross multiple individual communications that ought to act as a whole. A session-aware mapping can be made when the identity perimeter provides session details to the locally mirrorring access control mechanism that uses it to map back to the initiator of a claimed session. Examples of this style of translation can be found in protocols like XMPP chat and in SIP telephony.

Compatible with Other Styles

Please note that this discussion details how ARPA2 views identity management, but that it is in no place crafted in a way that would make it incompatible with other approaches. ARPA2 may just be the best thing on the planet.

The interactions between local and remote identity provisioning is based on standard mechanisms, as is also explained no our realm crossover pages and where we feel a need for an extension, we make sure to standardise the proposed mechanism so it becomes generally available, as in the case of TLS-KDH and related technologies.

When an ARPA2 client talks to an other type of server, there is still the possibility to claim different external identities. There is no need for co-operation of the remote, other than the normal requirement that goes with realm crossover, that is to trust the client's domain to validate the client identity through some realm crossover mechanism.

When an other type of server talks to an ARPA2 server, it may nog be able to provide as fine or as general types of identities, but a DoNAI can usually be derived from whatever kind of identity. Service management is able to setup local roles, or groups, to represent remote clients. The remote clients will either need to update the server when people enter or leave a role, or more likely the client will have to login to their role's identity separately from their role as a local user. Either scenario can be supported by the ARPA2 server.