What is this site about?

A realm is a network environment with a shared security context. Usually, a realm is matched with one or more domain names and perhaps physical LANs, and it groups Users and Machines in such a way that they can work together.

There are various systems to achieve an internal realm, although most come down to a combination of Kerberos (for authentication) and LDAP (for configuration information). Examples of such systems are Active Directory, Samba and FreeIPA.

As soon as we try to communicate across the boundaries of our internal realms, we need to establish some form of crossover trust. The kind of thing that is usually possible is to couple two systems of the same implementor in a fixed and predetermined trust relationship; but what is much more difficult is to do this on the fly, between hitherto unknown parties and across variations in technical implementation.

Why is realm crossover useful?

The short answer is to point out the trend on websites who welcome users that login with another web service. Unfortunately, this can only work with a few popular login webservices, and these are generally run by large corporations that may have secondary motivations for accessing the account and gathering information from it. As long as this is not done, then at least the usage patterns of server logins are likely to be tracked.

Generally, it is desirable to control your own identity provider, served by a local security realm that organises your users and your machines. From this provider, you should be ablt to approach remote services (including but certainly not limited to websites) without a need to login with whatever credential mechanism the remote service would otherwise use. This is what realm crossover is about.

How can realm crossover be realised?

Usually, there are a few components that can be identified in a system that permits use of remote services.

1. A local security realm authenticates the user.
2. A network identifier of the form user@domain.name, or more generally a DoNAI, is provided to the user in the form of a verifiable credential.
3. The user approaches a remote service with this credential, where its authenticity can be established.
4. An authorisation server trusted by the remote service decides whether the authenticated identity is granted access.

All this may be implemented by sending a client program back and forth between services; but that depends on the protocol being used. For HTTP, it is quite common to be redirected from a targeted website to an authorisation site, which may in turn be in touch with a local identity provider.

These local identity providers hand out verifiable credentials. Verification may be implemented with digital signatures, made with a key that can be looked up under the domain.name included in the identifier. Or the verification could be done through a callback mechanism, for which a domain-bound service responds whether or not the credential is authentic.

Who is working on realm crossover?

There are a number of projects that are developing realm crossover mechanisms. Please see the side bar for more information.

This site is run by OpenFortress and NLnet as part of the InternetWide project. Its practical project is hosted as an ARPA2.net project.