Based on DoNAIs and DoNAI selectors, a general form of access control can be defined. Any protocol that uses a DoNAI to identify local and remote peers can be made to enforce these.
Forms of Identity
Note that identities are of various forms of identity but
that they are not externally distinguishable and, as a result, are treated
similarly during access control. There is one exception however: host and
domain identities contain no userpart and no
@. Even the
selector for host/domains types differ from those for
user/group/role/alias types by the presence and absense of the
In many situations, servers are permitted to speak on behalf of their users; protocols such as SMTP email and XMPP chat make cross-realm contacts between servers, not users, and when this is done it must be that a user can be represented by their server.
One subtle aspects is worth mentioning; a host may identify itself by a
servername that is merely an indirection noted in DNS through a
SRV reference under the represented domain name.
Since there are mechanisms that can assure that a remote peer matches the DoNAI that they claim, it is possible to subject any exchange with them to access control.
All Protocols at Once
In the interest of privacy, self-control and spam prevention, access control should be specific to the local user. This means that users are able to configure their personal preferences concerning who may access them. As one example, consider an email list which only permits submissions by the members of the list.
The ARPA2 approach to access control is not specific to protocols, however. The reasoning is that members of an email list will usually also be welcomed to contact us over chat, telephony and perhaps a web interface. The notion of group membership therefore applies accross protocols. This bypasses a lot of overzealous control of access, whithout sacrificing control. If need be this behaviour can be overridden -- but the default is to treat access control for all protocols at the same time.
Groups of Remote DoNAIs
It is often desirable to grant similar permissions to many remote peers at once, referring to their grouping. In terms of a DoNAI, this ususally means that they reside under the same (sub)domain, and/or that they use the same username under a given umbrella domain.
In terms of the DoNAI, this means that remote peers should not be described at the concrete level of a DoNAI, but at the more general level of a DoNAI Selector.
Form of Access Rules
A rule that describeds access rules basically describes privileges for a combination of a local peer (through a DoNAI) and a remote peer (through a DoNAI Selector). Since DoNAI Selectors follow a hierarchy, it is possible to start with a remote peer's DoNAI and make stepwise generalisations until a match is found. The most concrete remote DoNAI Selector that matches sets the rule, anything more general is ignored.
The rule assigns an action to the combination found. The general nature of these actions is one of the following:
- Whitelisting means that access is granted
- Blacklisting menas that access is refused
- Graylisting means that access can be taken under consideration
The implementation of graylisting depends on the protocol at hand. For email, it might mean refusing it for the time being, or asking the recipient to make a choice. For chat, it might mean that an access request is proposed. For telephony, it might mean that an interactive challenge such as entering a read-out code is requested.
Since access rules apply to all protocols, it is feasible to support crossover between protocols; for instance, a graylisted email may first have to be repeated, after which a subscription request is proposed to one's chat service. When the chat connection is established or rejected, the graylisted is changed into a whitelisted or blacklisted rule, respectively.
There are two documents describing the implementation of DoNAI-based access control in detail:
These documents detail how plugin services can access information about users, aliases, groups and other forms of identity that we intend to support. The work is being implemented in the libarpa2service project and is intended as a basis for services to build upon.
The libarpa2service project implements everything in C, as this is the most portable library language. We anticipate future versions in many other languages, but until our understanding of services has hardened out by completing the ServiceHub phase of the InternetWide Architecture, our current advise is to wrap the C library for reasons of future compatibility.