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.

Selector examples

Examples of selectors that would match the DoNAI example.org are:

  • example.org
  • .org
  • .

Note that the prefixed dot means that any number of labels / domainComponents may be prefixed, but at least one. So .org matches example.org and research.arpa2.org, but not org itself; selectors matching org itself are org and ..

The form . represents any fully qualified domain name without user name, and it can be useful to describe default settings that apply when no other selector matches.

Examples of selectors that would match the anonymous DoNAI @example.org are:

  • @example.org
  • @.org
  • @.

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 john@example.org are:

  • john@example.org
  • @example.org
  • john@.org
  • @.org
  • john@.
  • @.

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

We defined inheritance of identities to handle related identites such as user aliases, group members and role occupants. An example would be sales representative John, or sales+john@example.org.

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:

  • sales+john@example.org
  • sales+@example.org
  • sales@example.org
  • @example.org
  • sales+john@.org
  • sales+@.org
  • sales@.org
  • @.org
  • sales+john@.
  • sales+@.
  • sales@.
  • @.

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 identity inheritance 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 john+singer@example.org as an alias, then the possibly matching DoNAI Selectors would yield a shorter list:

  • john+singer@example.org
  • @example.org
  • john+singer@.org
  • @.org
  • john+singer@.
  • @.

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 john@example.org:

  • john@example.org
  • john+@example.org
  • @example.org
  • john@.org
  • john+@.org
  • @.org
  • john@.
  • john+@.
  • @.

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 + symbol.

So we could write

+smtp@mx1.example.org

to indicate what Kerberos would call

smtp/mx1.example.org@EXAMPLE.ORG

Again, there is a catch-all, and it follows the same line of reasoning as the reduction of group and role names,

+@mx1.example.org

This means that matching ACLs might use the following notations, going from concrete to abstract:

  • +smtp@mx1.example.org
  • +@mx1.example.org
  • +smtp@.example.org
  • +@.example.org
  • +smtp@.org
  • +@.org
  • +smtp@.
  • +@.

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:

  • sales+john
  • sales+
  • sales
  • ``

The last one would be a catch-all in disguise, as can be seen when we add the default realm back again:

  • sales+john@example.org
  • sales+@example.org
  • sales@example.org
  • @example.org

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: sales@example.org
writers: sales+john@example.org

When an authenticated identity such as sales+john@example.org or sales+mary@example.org 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 readers and 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 sales@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 as sales+mary@example.org, while she would be reduced to the group identity as sales@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.

Order matters

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 @. or . depending on the form of DoNAI.

For DoNAIs that include a domain name, one ordering question remains; which of @example.com and john@.com is the most concrete? The answer is @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.

Applications

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.

Integration

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 :match type 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 *@ combination.

  • CPL is a similarly structured standard for SIP telephony filtering and redirection. It has an address-switch that can separate user and host subfields from header addresses origin, destination and original-destination. It can use is to exactly match a user or domain name; it can use subdomain-of to 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.