ARPA2 Common Libraries  2.2.14
Actor Identities after Access Control

Authentication mechanisms output a visitor's Remote Identity, which is a user identity defined under a domain. Actors can be added to a Remote Identity to map it onto a local userid, as defined by a service domain. Actor Identities may depend on the scene being played, that is, Access Control can grant the privilege when acting like a local identity as provided during Access Control.

Acting and scenes are mere metaphors, but they are a reasonable fit to the technical facility of pulling a Remote Identity into a domain and treating it like an internal Identity. This has several uses:

The general idea is that Access Control delivers an Actor when it grants permission. An empty form of Actor Identity is defined to say this is not really an Actor so that it can be recognised in handling routines, which may then publish the Remote Identity instead. When an Actor is defined, then the challenge to a service is to conceal the Remote Identity from anyone but the administrator, and substitute the Actor Identity in its place. For example, email would alter addresses in headers and envelope and many other protocols would do the same. Web-based documents would be listed for the Actor Identity if available, not for the Remote Identity.

When we say "Actor" we actually mean "Actor Identity".

Push and Pull Services

Whether the translation from Remote Identity can be unidirectional depends on whether it is a Push or Pull Service.

When we say "Push Service" we usually mean "Push-and-Pull Service", with an exception when we explicitly speak of a "Push-Only Service".

Static and Dynamic Actors

On the stage, there are two kinds of Actor, namely those cast to a named role, and those who play an unidentified role in the background. In terms of the ARPA2 Identity model, a similar distinction is made.

An example of this distinction is clear for group handling. Subscribed members would be allocated a member name, and their identity would be of the <group>+<member>@<domain> form. Guest posting is possible through Dynamic Actors. Whether the reverse mapping is stored determines whether a Pull Service can send responses to the guest; without this stored information, the guest may still be granted access to any group resources, but only through Pull Services.

Parsed Actors

The data structure a2act_t represents Actors, much like a2id_t represents a normal ARPA2 Identity. There are a few differences to note:

Groups make a Scene

The idea of an ARPA2 Group is bold, but incredibly useful: every member of a group is given an address within the group, and it looks like <group>+<member>@<domain> so that routing always passes through the <domain> that defines the <group>, and so that the <member> name is local to the group. Actual communication needs to translate from/to an actual delivery address for the addressed <member> names. Clever forms of syntax have been devised to address one, multiple or all-but certain <member> names.

Upon arrival of communication for a group, the sender becomes an Actor, and by doing this starts to look like its member name. When passing out traffic to a group, the addressed group members translate to a delivery address, often including the one that the sender originally used.

The <group> is an example of a <scene>. The customary use of a <member> is for subscribing members but, if supported, visitors may obtain a dynamic name and continue. Whether this is permitted is up to Access Control for the <group>@<domain>.

Going NAT

NAT is terrible. It disables peer-to-peer freedom, and as long as we consider IPv4 worth supporting it means that we need to use intermediate servers for all we do. And that is not always in the interest of privacy (and if you don't care about yours, you may be dragging down others with your carelessness). Clearly, for the Internet Protocol the addition of NAT blocks progress.

The problems with NAT are mostly due to limited port spaces, and the lack of clarity about bidirectional translation, and support for end-to-end connections. For the much larger address space of Actors, this need not be a problem. The Static Actor may be considered equivalent to port forwarding, which works well in every situation. The Dynamic Actor may use a timeout if this is desired for policy reasons, such as storage restrictions for Push Services.

So on the whole, the problems with NAT for IPv4 do not seem to reproduce when we translate ARPA2 Identities to Actors.

API for Actors

A few support functions are defined to work with a2act_t structures:

#include <arpa2/identity.h>
bool a2act_parse (a2act_t *out, const char *in, unsigned inlen);
bool a2act_isempty (const a2act_t *tested);
bool a2act_isstatic (const a2act_t *tested);
bool a2act_isdynamic (const a2act_t *tested);
bool a2act_isdynamicrecipe (const a2act_t *tested);

The parser function works along the lines of a2id_parse(), and the others test if the Actor is empty, static, dynamic or recipe-for-dynamic. Rules are likely to hold recipes for dynamic addresses, which must then be passed through a2id_sign() to complete them to the dynamic form.

The most interesting places where an Actor structure pops up is when a Remote Identity is passed into an Access Control function:

#include <arpa2/identity.h>
#include <arpa2/access_comm.h>
a2id_t *remote = ...;
a2id_t *local = ...;
access_comm_level out_level;
a2act_t out_actor;
bool ok = access_comm (remote, local, ..., &out_level, &out_actor);

This tries to communicate from remote to local, using whatever protocol, and if out_level is set to access_comm_whitelist then the value in out_actor should be interesting to use.

For Document Access, the pattern is almost the same:

#include <arpa2/identity.h>
#include <arpa2/access_document.h>
a2id_t *remote = ...;
char *xsname = ...;
access_rights out_rights;
a2act_t out_actor;
bool ok = access_document (remote, xsname, ..., &out_rights, &out_actor);

In both patterns, most upcoming functions calls would mention remote and &out_actor together.