Our work on Identity is ultimately for controlling access to
online services. We now introduce our thoughts on Access Control.
The whole story is complex, but an analogy to the phone system can
help to explain it.
This article is part of a series on access control and is related to another series on identity.
In this article, the general concepts of Access Control in the InternetWide Architecture will be explained. They will be part of the ARPA2 common support library that we develop alongside.
If you prefer to read about examples before you read about these general ideas, look for later contributions in this series of articles.
Barring access
Have you ever wanted to block calls to your phone from marketeers? Have you ever felt the wish to pull protective rubber sheathing around your email address, so it cannot be intruded by virusses? Welcome to the topic of Access Control.
These examples are concerned with the area of communication, but there could be other application areas, such as access to documents, to the source code of software or computation models that you are developing, or even for physical access to your home.
We shall use the analogy of the phone system to explain the abstract concepts that we designed to let you express your wishes for Access Control. The mechanisms are general and therefore a bit complex, but the result is a highly practical outcome -- like the phone system.
Country Codes are like dialing Hosted Domains
If you know the country of your callee, you should lookup the corresponding country code and enter it after the international prefix. For instance, dial +31 to reach the Netherlands.
Countries are the start of authority; they are sovereign entities. On the Internet, authority to reign starts with a domain name. Once you registered your own name, you are the sovereign over that domain. To take away your domain from you would take nothing short of a war.
Countries are just a name; to come alive they need territory, a soccer team and railways. In short, you need a kingdom. Compare this to hosting a domain name and erecting services for it. You might do this on your own if you are technically inclined, or you could outsource it to an external hosting provider.
ARPA2 Access Control involves mixing your domain name with a database secret for the hosting provider. This results in a "Domain Key" to predial your online kingdom. The Domain Key is not meaningful on its own; it merely routes access attempts to your online territory.
After dialing a country code, you can no longer choose to connect to other countries.
Domain Keys are derived using a secure hash. This is a forward-only computation, meaning that this code cannot be dissected to learn about the database secret for the hosting provider, or even the domain name. This means that it is not possible to derive the Domain Key for another domain from the Domain Key for yours.
Area Codes for dialing Application Types
Once you accessed the country, you continue dialing the area code for your callee. The country's switches use this to route your call to an area in the called country.
Metropolitan Areas represent communities that live and work together, and usually have tightly entangled communications. There is less talk between areas than within, and such connections take an explicit choice.
On the Internet, we can distinguish application types, and it makes sense to keep these separate by default. Your settings for access control of communication are simply different from your settings of who can view the photos on your website, who may access your documents, and so on.
ARPA2 Access Control derives a Type Key that can be configured into software that services a particular application area for your domain. For instance, communication may not only be available over email or chat, but parts like teleconferencing may be disclosed through a web server. All these bits of software can use the same Area Code that identifies an application area for your domain.
The area code is local to the country you just dialed. For instance, +3123 would be the area Haarlem (023) in the Netherlands (+31). But in the UK (+44), the area code +4423 would land you in Portsmouth (023) or Southampton.
Your hosting provider derives the Type Key by mixing your Domain Key with an "Access Type" code that covers the application area. This Access Type can be shared by all domains, but the resulting Type Key will be different for each domain. ARPA2 Access Control uses the 128-bit binary code of a well-known UUID for this purpose. The nice thing of the UUID system is that it is easy to create your own UUID for a new Access Type, so even if some applications are registered, this is not being enforced.
The purpose of well-known UUID values is that they can span across many pieces of software and allow integration and collaboration of many individual parties. You might have a lovely cloud storage tool, but it may be just one of many ways in which you access your documents, and you would like to have one place to control document accessibility.
To use communication once more as an application: It has an UUID of
b4f0fc38-d4d7-3bb9-ad69-5bf75efc46dd derived in a standard computation
from the DNS name communication.uuid.arpa2.org that falls under our
control. This Access Type can be mixed with any Domain Key to form
a unique Access Type that will not clash when they are looked up.
After dialing a area code, you can no longer choose to connect to other areas.
The area codes are derived using a secure hash. This is a forward-only computation, meaning that the area code cannot be dissected to learn about the country code, not even if the applicaton type is known. This implies that it is not possible to derive another domain's area code from your domain's area code, not even for the same application.
Residential Numbers for dialing Individual Resources
Once you accessed the area, you continue dialing the residential number for your callee. The area's switches use this to route your call to the phone jack in your callee's home. For example dial +3123456789 to reach John in Haarlem, the Netherlands.
Pfew, you finally reached your target. Now the phone can start ringing, at least when John's phone is not configured to block your Caller ID, or even all calls from your country/area codes with no exception for your Caller ID.
In Access Control, we want to specify access to a diversity of online resources; for communication it would be specific to users and for document access it may be specific to file folders. This may apply to pretty much anything, but a classification is possible when we consider the application type.
ARPA2 Access Control speaks of Access Names and represents them in general terms as a UTF-8 String. This general definition allows software to provide general support for this pinning-down of resources.
The string format of this Access Name is specified by the Access Type. For communication, it is the local userid. For document access control, it defines a path construct used to reach the document.
Application code usually finds this information in a query. Email would find it the Access Name as the beginning of an email address; document management systems find it as a path starting from a given document root and in the last part of a URL.
Access Control can now be reduced to a database lookup, which involves following elements (shown in the picture below):
- Your Type Key, representing an application under your domain
- The Access Name for the resource being accessed
- The Remote Selector (or "Caller ID") trying to gain access
Just like you may want to block all calls from an entire country or area, you can specify similar things for the Remote Selector. This is the topic of a full Identity or a Selector that matches many, to be discussed soon in another blog post. The software for ARPA2 Access Control looks for a few more things than just the concrete remote identity, but in general the most concrete one found decides on the Access Rights granted to the remote. This allows you to block an entire domain but then let certain users in that domain back in.
The Key to Access Control
Since we are intent on distributing our online presence to third-party service providers with access control centralised at an identity host, we need some complexity in terms of this key derivation as sketched before. It is highly efficient and hardly takes an effort while accessing services, but the structure helps to keep better control over your online presence.
The picture below shows the structure of key derivation for
ARPA2 Access Control; as you can see, the service software
is configured with a Type Key and needs to format application
data into an Access Name. It then iterates over the remote
user to evaluate access from several levels --beyond just
john@example.com this would be willing to fallback to
@example.com, @.com and @.-- with a simple lookup in
a key-value database. We use a highly efficient memory-mapped
database for doing this in our software.
Technicalities of Trunking
The phone system consists of switched circuits, connected by trunks. A trunk may carry multiple calls at the same time. When one trunk breaks down, the call is routed over another trunk. These technicalities are concealed from the users of the system.
Type Keys are general enough that they could get distributed over multiple providers. This explains why we employed forward-only computations. But it also implies that Access Control information should be shared between providers.
This is possible by inserting an extra number with every entry in the database. By default, it is set to 32 bits. This extra number is like a trunk code; it is concealed from the user, but very important in routing information.
The extra number allows us to dissect an Access Control database. Different sections may have come from different providers or, if we are the source of information, may be targeted at different providers. In general, the idea is to be able to have one large database, using one efficient access mechanism to serve a bulk of customer domains, but still be able to manage sections of the data in a generic manner. For instance, when resyncing to the access control information from another provider it is helpful to cull old data; all data in a section can be safely removed before it is replaced. Transactional boundaries help to shield user processes from ever observing it.
This is just an example; a few more uses can be imagined. It is not of importance to users, but hosting providers can rest assured: we got you covered.
Metaphorically Speaking
We hope that this informal introduction will help your understand the general concepts that we shall introduce next in this series.
Go Top