The model underlying authorisation (authz) in the InternetWide Identity Framework is detailed below. It assumes that an authenticated (authn) identity has been established, and that a possibly different identity is being requested while accessing a resource.

This model is work in progress.

Authorisation Inquiries

When posing authorisation questions, the following ingredients are provided:

  • Authenticated identity in the form of a DoNAI
  • Requested identity in the form of a DoNAI
  • Targeted local identity in the form of a DoNAI (optional)
  • A list of requested resources, as a concatenation of binary UUIDs

The purpose of these inquiries is to determine whether all of the following hold:

  • The authenticated identity provides access to the requested identity
  • The responded identity provides access to the targeted local identity, if provided
  • The responded resource is the first of the requested resources with an accepting ACL entry
  • The access mode flags are one-character rights according to the accepting ACL entry
  • The responded identity is the requested identity, unless overridden by the accepting ACL entry

Carefully note the different forms of identity in use:

  • Requested identity intends to set the acting object identity
  • Responded identity approves a value as the acting object identity
  • Targeted identity intends to communicate with subject identity

Access to Requested Identity

The authorisation model is founded on a mapping A->B that indicates that an authenticated identity A can request an identity for B. The mapping fulfils a number of useful properties:

  • Reflexivity: For every known user A, an entry A->A exists in the mapping
  • Transitivity: When A->B and B->C are in the mapping, then so is A->C

The reach of the mapping (meaning, B in A->B) is defined as a DoNAI, so it has the complete form and is not a Selector. This is required to provide certainty over the existence of the precise form of requested identifiers.

The domain of the mapping (meaning, A in A->B) is a DoNAI Selector, and the most concrete is the one that applies. Implementations will usually start from the authenticated identifier and iterate upwards using the DoNAI Selector logic, and match each by looking it up in the A->B mapping.

Note that this has no impact on transitivity; if a somewhat abstract B occurs in B->C mappings, then it is not possible to find an A->B mapping, and so the question whether A->C occurs in the mapping is moot. What is useful to know however, is that a mapping A->B could map to DoNAI B, which matches with DoNAI Selector B', and occurs in mapping B'->C. In this case, A->C also occurs in the mapping.

As a generalisation of common abstraction, where the form user@domain abstracts to @domain, there is an intermediate form for group+subname@domain namely group+@domain that may occur in the domain of the mapping. This supports matches against group members. One example could be the privilege of group members to speak on behalf of the group: group+@domain->group@domain would set this ability. Note that transitivity with the extension to DoNAI Selectors is also useful; if john@domain->list+john@domain and list+@domain->list@domain are in the mapping then so is the direct john@domain->list@domain mapping -- John can speak on behalf of List, just like any other member of List, and the mapping to the named list member settles precisely that.

The only question of interest for authorisation issues that remains, is whether "A->B" is in a mapping.

Access to Requested Resource

Access to each resource is defined by its own Access Control List. Meaning, the authorisation model supports lookup of an ACL based on the resource UUID.

The model of an ACL is a list of entries that each state

  • A DoNAI Selector to be applied to the requested identity
  • Access mode flags to be applied in case of a match; no flags indicates rejection
  • Optionally, a responded identity in case of a match (or a mapping of some kind)

The list is applied in order of occurrence; the first entry that matches defines the final outcome. This usually means that concrete entries are listed before general entries.

Access to Target Identity

For this test, the authorisation model can provide a white list and/or a black list. Note that not providing a list is different from providing an empty list! When neither white list nor black list is provided, the default policy is to accept authorisation. when only a white list is provided, the default policy is to reject authorisation; when a black list (and possibly a white list) is provided, the default policy is to accept authorisation;

The things looked up in the black and white lists are A->B mappings, where A is the responded identity (which is the requested identity with possible override in the ACL) and B is the targeted identity. These A->B mappings follow the same construct as described under Access to Requested Identity, but it does not have the same properties of reflexivity and transitivity.

Searching the white and black lists starts at the concrete target identities for A and B, and moves only A up in abstraction level until a match for A->B is found in either the white list or the black list. The match at this abstraction level is used in what follows. In case either of the lists is not provided, it will not match anything.

Upon a match, the white list and black list are used instead of the default policy. When neither black list nor white list matches, the default policy is used. When the black list matches (regardless of whether the white list matches), the policy is to reject authorisation; when only the white list matches, the policy is to accept authorisation; when both match, the gray listing policy is followed.

Generic Model for Gray Listing

In some uses of black and white listing, the gray listing facility is triggered. This is especially the case when both black and white lists are present, and both match at the same abstraction level. Normally, this will be due to the presence of a catch-all pattern such as @. in both lists. Note that gray listing expresses an open facility to anyone who provides fair proof of their identity.

The purpose of gray listing is to sufficiently rely on an identity found to add it to the white list; or perhaps to mistrust it so utterly that it ends on the black list (though that usually calls for manual intervention by the targeted user). To be able to do this, a challenge is posed to the user to demonstrate owning the responded identity. Such identities are usually more concrete than the entry causing the gray listing conclusion, os adding it to either white or black list should avoid future conclusions to gray list.

As is the case with white and black listing, the gray listing mechanism applies across protocols and services; it only is involved with the responded and targeted identities. As a result, passing from gray listing to white listing can be done under one service, and the granted access applies to other services as well. This means that services must either employ reasonable gray listing tests or treat gray listing as a rejection.

The task of handling gray listing is an authentication task, not an authorisation task. For this reason, the authorisation solution will not evaluate whether gray listing has been properly performed; instead, it will process decisions from the services that perform the actual gray listing authorisation. Such services should hold or defer the requested interaction until the gray listing entry has resolved into a white list entry.

When authorisation receives a positive response the a gray listing challenge, it ensures that the A->B entry uses concrete identities A and B; it then ensures that A->B is in white listed and not black listed. This avoids future gray listing responses on future communication attempts.

The general requirement for a properly functioning InternetWide Identity Infrastructure is that a challenge (which may simply be a one-time pass code to be repeated) is delivered to a service in the remote domain through an encrypted connection, where the domain name is authenticated as part of the encryption. This can be easily achieved through most mechanisms, without going as far as requiring end-to-end encryption (which would only be necessary, and probably not sufficient, in situations of mistrust in the remote domain's internal security). It is desirable to use 128-bit challenge codes or, if they are shorter, to permit only one chance of guessing them.

A generally usable mechanism will be provided for gray listing resolution, and it is possible to pass gray listing requirements to this dedicated service. For now, the mechanism will work by first attempting XMPP, with a fallback to SMTP. The mechanism will be available with Diameter over SCTP/IPv6 with DTLS protection, and it exchanges the same Access-Request and Access-Accept (or Access-Reject) that would otherwise be exchanged with authorisation after receiving its Access-Challenge. The task of the general mechanism may take much longer than a normal exchange.

Avoiding Gray Death

It is important (and easy) to avoid problems due to gray listing. Imagine initiating communication with a new person, and landing in a gray listing policy. This requires a callback to our account, but if that too hits upon gray listing, then the traffic can continue forever. This is what we have creatively called the problem of "gray death".

The solution is straightforwardly simple. Before starting external communication to a (potentially new) partner, that new partner is placed on the white list.

So, before sending from A to B, authorisation is used to test communication authorisation from B to A; if this hits upon gray listing, then the gray listing challenge is immediately met for the B to A direction. After this has been done, it is safe to send from A to B. Note that the instant white listing is specifically done for traffic to to the local account, which is generally safe to do.

When a service makes a callback for the purposes of a gray list check, it is explicitly assuming that the original sender has indeed opened up their filters for the return traffic. A forged sender address however, could run into a service that did not, and should of course fail. This means that the acceptance of future traffic is not yet setup, and that repeated attempts to connect result in failure of the gray listing attempt -- but it should not be turned into a black list entry, because it is the actual sender address that is to blame.

Gray listing may require contact with a human, and in case of forged senders this would bother another human than the authentic sender. This is not much different than the current practice of emails being sent to the supposed sender. To limit the stress of such abuses, maximum checking of validity of sender addresses is advised before initiating gray listing, with mechanisms like SPF and DKIM in the case of email.

LDAP Object Model

To be defined as part of the ServiceHub phase of the InternetWide plan: an LDAP object model that can be used on separate hosting for identity and services.

The objective is to use SteamWorks to subscribe to the ACL portion of each resource, but have better privacy protection for the A->B mapping.