To describe one or more DoNAIs, a so-called selector is introduced. This is a pattern that follows the meaning of a DoNAI, and is much simpler in form than generic regular expressions; because of that it is much less error-prone and even suitable for end-users.
A DoNAI selector, or selector for short, is a pattern describing one of:
- A full DoNAI, to be matched exactly;
- A DoNAI without a username part;
- A DoNAI with the beginning of the domain name stripped;
- A DoNAI without a username and with the beginning of the domain name strippeed.
Examples of selectors that would match the DoNAI
Note that the prefixed dot means that any number of labels / domainComponents
may be prefixed, but at least one. So
research.arpa2.org, but not
org itself; selectors matching
. represents any fully qualified domain name without user name,
and it can be useful to describe default settings that apply when no other
Examples of selectors that would match the anonymous DoNAI
Note how the form
@. represents any user, including the anonymous user,
at any domain. It can therefore serve to describe default settings for
users, as the analogon to what
. does for any domain name without user name.
Examples of selectors that would match the DoNAI
Note how a form with a user name always retains the
@ to make it
distinguishable from the domain name form; this means that a DoNAI can
mix the two forms without ever causing interference.
Sub-names in Selectors and their Iteration
Here, there are a few extra levels caused by the components in the
user name; we allow DoNAI Selectors
sales+ to indicate all the member
names under the
sales group, as well as the group identity which each
member can also assume. Note that this is quite different, because the
group identity conceals the group member identity. The breakdown of the
identity from concrete to abstract now is:
Note that this is a listing of possible matching DoNAI Selectors; it can
be reached through iteration on a group member identity, and also for
a role occupant's identity. However, considering the arrow directions for
it should be noted that a user alias cannot and must not be reduced to the
user identity; the alias has no authority to be reduced to the barren
user. So, if we were talking about
firstname.lastname@example.org as an alias,
then the possibly matching DoNAI Selectors would yield a shorter list:
The opposite does work, but iteration over all aliases is not considered
feasible; therefore, the reduction from a user to include aliases would
be as follows, assuming once more that the topic is
The inheritance diagram is clearly very important when constructing the possible DoNAI Selectors that could match. This is also true because of the additional authorisation possibilities caused by mapping of foreign identities to local ones. It is worth noting that there are only two schemes for unrolling local user names, and so a simple indication to this end might suffice.
DoNAI Selectors for Hosted Services
TODO: Whether the proposal in this section is possible across the board of the InternetWide Architecture has not been completely resolved. Tread with caution, but be informed of possible future changes.
The DoNAI form considers domain names to be identities in their own right. In reality however, they are almost always used for a particular service, and that is a meaningful addition to the identities used.
During authentication, a host may represent a user under the realm for that host. This is the case for SMTP clients and servers for example, but it is not the case for an HTTP client. Clearly, the addition of a service on top of a mere host name is valuable when it comes to controlling access.
During authorisation, this is even clearer. The ability to access a certain resource may depend on the service needing to access it, and it will often be for reasons of maintenance or overviewing. Add to that the desire to have plugin services from anywhere in the World, and we have a strong case for keeping them separated (although in that case the host name would already suffice for most uses).
The format we shall use falls within the definitions of the
Network Access Identifier, but is considered an illegal construct
in our user name notation; it is a user name starting with a
So we could write
to indicate what Kerberos would call
Again, there is a catch-all, and it follows the same line of reasoning as the reduction of group and role names,
This means that matching ACLs might use the following notations, going from concrete to abstract:
The notations starting with
+@ indicate any service, but very deliberately
in a notation that is distinct from what we would call valid user identities.
Implied Selector Domains
TODO: The following grammar is ambiguous until we decide we can strike the domain name form of the DoNAI (see previous section). Tread with caution, but be informed of possible future changes.
Very often, DoNAI Selectors are used in a context where a default domain is completely obvious. In such cases, the domain may be left out, and the only thing to specify would be the user name portion:
The last one would be a catch-all in disguise, as can be seen when we add the default realm back again:
Very often, this processing of names will be applied to authenticated user names, intending to match against the domain name of the targeted realm. Such DoNAI Selectors may occur in black and white lists, or in lists of permitted readers and writers. For instance, one might have:
readers: sales writers: sales+john
This is silently expanded with the context's default realm to form
readers: email@example.com writers: firstname.lastname@example.org
When an authenticated identity such as
email@example.com is now stepwise abstracted as specified above,
then Mary will match only the
readers through reduction of her
group member name to the group name, and John will match both but settle
on the most concrete match, which is against
writers. Since common
access control will look in both
writers to find if a
peer has read access, it will grant both with read access, but only
John would be able to write to the resource protected by this ACL.
Note the subtle difference, had we written
readers: sales+ writers: sales+john
The same privileges would have applied to John and Mary, but someone who
degraded their identity to the
firstname.lastname@example.org form, perhaps through
explicit authorisation as that identity, would not be able to enter
anymore. This can be useful to support tracing the identity of the
group member as a distinct person. The ability to degrade identity to
that of a group member can be useful when visiting a remote realm,
precisely for reasons of traceability but also to simplify access control.
Given the last definition, Mary will still be visible inside the system
email@example.com, while she would be reduced to the group
firstname.lastname@example.org in the original example. Which may not
be such a problem for reading anyway.
Operations with selectors and DoNAIs
The operations supported on selectors are comparisons with a DoNAI. The result is either a match or no match, so yes or no.
Comparisons always fail when the DoNAI is in the domain form and the selector is in user form.
Comparisons always fail when the DoNAI is in the user form and the selector is in domain form.
There is no "less than" style of comparison between DoNAIs and selectors.
There is no comparison between selectors.
One might say that DoNAI A is more specific than DoNAI B when the set of selectors matching A is a subset of the set of selectors matching B.
When comparing a DoNAI to a selector, there may be more than one match. The most concrete selector always wins, and more general definitions are ignored (unless explicitly included by whatever data is being handled).
This means that selectors are usually tried in an order from concrete to
abstract. The most concrete version is a full DoNAI form, the most
abstract form is either
. depending on the form of DoNAI.
For DoNAIs that include a domain name, one ordering question remains;
john@.com is the most concrete? The answer
@example.com because any setup that is specific to a host should be
usable to override settings (for specific users) of a realm.
In the examples provided at the top of this page, the lists are ordered from concrete to abstract. This order should also be the order in which selectors are looked up, if they happen to be a key somewhere.
There are many places where DoNAI selectors can be applied.
When describing black lists and white lists, selectors can be useful to describe all accounts under a realm at once; for instance, an entire company can be reduced to a spammer. Local overrides may be made for individuals within that company, if so desired.
When setting the places where one of your identities can be used, it is possible to define a range of sites, and possibly a specific remote user that may see the identity.
The most general forms can be used to create default settings; the forms that start with a username can be used to create user-specific defaults.
There are several forms of filtering, selection and redirection in the protocols in use on the Internet today. Generally, these rule sets take the form of nested if-then-else constructs with a range of conditions; generally, these conditions relate to addresses and will support (at least) a simple set of wildcard symbols that are easily generated from the DoNAI selector form.
For example, the DoNAI selector form translates quickly to other formats:
Sieve is the general standard format for mail filters. It has a
:matchtype that uses a wildcard symbol
*that would be prefixed to any
.that starts a domain name pattern, to make it
*.. Similarly, it would modify an
@without preceding username into a
CPL is a similarly structured standard for SIP telephony filtering and redirection. It has an
address-switchthat can separate
hostsubfields from header addresses
original-destination. It can use
isto exactly match a user or domain name; it can use
subdomain-ofto match the part after an initial
.in a domain name. It might have difficulty matching arbitrary user names though, but might avoid mentioning them at all.