Introduction

The term Security Domain (SD) is not part of the OIDC or OAuth2 specifications. Hence it does not have a definition directly related to these specifications.

Nevertheless, the term is widely used in different security contexts, yielding numerous variants of a definition. This document tries to clarify the term in Buypass context and how this affect our customers and integration partners. 

Note that the term is more evident in the Buypass OIDC interface than in the older IPS-Bx interface. In the IPS-Bx interface the security domain is indirectly selected based on the issuer, MerchantID, instruments and IdPreferences chosen for the integration.

It is important to realize that even if the description of a SD can be very similar to that of an IdP, at the same time, an IdP only implement parts of the scope covered by a SD. 

Terminology

• Security Domain - Defined and described in this document
• Identity Provider (IdP) - A system that creates, maintains, and manages identity information for principals (users, services, or systems) and provides principal authentication to other service providers (applications) within a federation or distributed network.[IdP]
• Relying Party (RP) The entity looking to verify the identity of the end user. A Service Provider relies on a trusted IdP or Security Token Service (STS) for authentication and authorization. In the WS-Federation and OIDC models a Service Provider is called a “Relying Party” (RP). [RP]

General definitions

These are examples of some general definitions found in various standards and relevant documentations:

"A foundation for IT security is the concept of security domains and enforcement of data and process flow restrictions within and between these domains.

A domain is a set of active entities (person, process, or device), their data objects, and a common security policy." NIST SP 800-33

"A system or subsystem that is under the authority of a single trusted authority. Security domains may be organized (e.g., hierarchically) to form larger domains." NIST SP 800-57

"...collection of hardware and personnel operating under a single security authority and performing a common business function. Members of a security domain will of necessity share a high degree of mutual trust, due to their shared aims and objectives." RFC 3183

To summarise, it is evident that the definitions of the generic term can be applied to various forms of security systems and applications. Another termed used, ex. by Microsoft, is trust domain and is based on the same basic idea.

Security domains vs. user accounts

Examples of SDs can easily be found in several internet services, services we use on daily basis. However, they are not called "Security Domains", rather we call them accounts, logins or providers; ex Facebook account or Google account. Or to be more generic: Social login providers.

The typical social login providers are:

• Facebook
• Google
• LinkedIn
• Twitter

Note that all of these providers represent their own SD. And since the services are competitors when it comes to user accounts, they do not share anything.

Each of the login providers have:

• Separate user registration processes (they have their own requirements for identity proofing, even if they are pretty similar)
• Separate user data (collection, self service and maintenance)
• Separate authentication mechanisms (password, OTP, mobile-apps, MFA policies and so on)
• Separate terms of conditions, consent and other legal agreements
• Separate registry of allowed relying parties/clients/applications/services that can use their login service (still, a service can register with several of the providers)
• Separate protocols and integration libraries (They all have customisation on protocols like OIDC, SAML or they implement their own variants)
• ....

I sum, they all are separate issuers within their own SD, controlling all aspects of business rules, policies and implementation details within the domain.

Other examples of providers of their own SDs are various net-shops and other services:

• Komplett (only allows their own login accounts)
• BankID 
  
• SPID
  
• Any net-shop or service without Social login or ID-Porten login or other external provider integration.

But from an end-user perspective, SDs appear in the form of user accounts and various authentication mechanisms for using the accounts. The user accounts represent a context that the end-user can relate to.

Hence the end-users understand that they as individuals have one or more accounts that are independent of each other (most understand that changing the password on the Facebook account does not affect their Google account).

From a system/service perspective, we often implicitly refer to SDs as Identity Providers (IdPs). Note however that technical definition of an IdP is just a subset of the full technical and non-technical scope of a SD.

For example, the issuer within an SD can issue certificates in the context (identities, policies and processes) of the SD, but this is not done by the IdP as a technical component.

Relying on Security Domains

Given an application/service with an identification and/or authentication requirement, it need to rely on some form of identity proofing process, user data, proper authentication and so on, to fulfil these requirements.

No matter if the service implement this functionality itself or rely on some 3rd party to do the job (becoming a Relying Party (RP)), the requirements are the functional definition of a SD.

In other words, the RP relies on the SD to "implement" it's requirements. Note that the SD, as described above, can be more than just a technical IdP, but also processes, legal or other non-technical requirements.

The critical part here is to define what the service can rely on. Need the identity (and identity data) be verified towards some official registry (f.ex. Folkeregisteret) or are the data pseudonymous or end-user claimed (not verifiable). And what about the authentication methods? How confident can he RP be that the user "in front of the keyboard" is who they claim to be?

Typical examples of such different RP use cases are:

1. The RP need to know the identity of the user with a high degree of certainty
2. The RP does not really care about the identity of the user, but it is important to recognise user X every time he/she accesses the service
3. The RP does not care about the identity, but some claim/attribute of the user (ex. age) and need to trust this only data with a high degree of certainty.

The key concept here is that the RP relies on a SD, identified by an issuer. This trust can be represented by trusting a certificate or trusting an IdP service.

Federating domains

Often, a service actually defines its own SD, and as part of the domain definition/policy, the domain can trust (rely on) other SDs. This is often referred to as federated trust. The screen below is showing the login screen for https://www.strava.com. The user can choose to register with the service locally or use one of the trusted/federated SDs, namely Facebook and Google.

This same concept can also be extended to IdPs, creating chains and trees of trust relationships. Two well known examples of this are ID-Porten og HelseID.

ID-Porten federation model

All ID-Porten customers (government agencies as NAV and Skatt) are Relying Parties in this context, and relies on the SD of ID-Porten. The SD is defined by a set of laws and regulations (ex. Esignaturloven, Kravspesifikasjon for PKI i offentlig sektor and Rammeverk for autentisering og uavviselighet, now outdated awaiting updated eIDAS compatiple regulations).

Based on these policies, the ID-Porten SD can tryst/rely on other SDs. As a consequence, ID-Porten has set up trust the the SDs defined by BankID, Buypass and Commfedes:

This trust is transparent for the ID-Porten customers. The ID-porten customers still rely on the definition of the ID-Porten SD and trusts that this contract is upheld.

Note that the end-user in this case, must choose what account to use to log on to ID-Porten. I case of the Buypass ID account, only that accounts authentication mechanisms are valid.

HelseID federation model

The HelseID federation platform is built an even more complex federated trust model, where ID-Porten is only one of the trusted SDs. Like the government agencies, HelseID trusts ID-Porten, but they also trust other (local hospital) SD. One could say that HelseID sets up a forest of SD trust relationships.

Basically the services/RPs rely on the HelseID SD for authentication, and much the same way as ID-Porten delegates the actual authentication to 3rd parties like Buypass and BankID, HelseID takes this one step further: HelseID trusts ID-Porten, but also hospitals and or other institutions with local SDs. HelseID sets the requirements for what SDs they trust, thereby defining the SD and what the services can rely on.

This way, instead of services having to rely on multiple SDs and multiple IdPs, they can rely on the HelseID SD and HelseID will hide this complexity. At the same time providing "SSO" solution across multiple organisations and institutions.

For end-users, this means that they can log in to their normal/local account (f.ex. at Ullevaal Hospital) and then access services provided by another hospital (f.eks. Tromsø) without needing to register an account at HelseID or at Tromsø hospital.

Identifier mapping

All services that require authentication (logon) normally stores some data associated with the end-user. This data need to be referenced using some user-identifier. Such identifiers can be everything from a user-selectable username, to email, phone number or Social Security Number (SSN).

In all cases, it is up to the service/the RP, to map their internal representation of a user identification to that of the SD being used for authentication (note that an SD can specify more than one identifier for a user/system).

For services using SSN, this is pretty easy, as the SSN is a unique identifier and shared between both the service/RP and the IdP/SD. For the Strava example above, it can be a bit more complicated to do the mapping.

The identifier used at Google might be different than the one used at Facebook. For example name@google.com vs name@facbook.com, which email was registered at Strava?. 

This presents a challenge for Strava as a service/RP if the end-user logs on with both IDs. How is the RP suppose to know that the to authentications should be mapped to the same data for the Strava service?. 

It is important to recognise this challenge, when setting up trust between SDs and between SDs and services, and note that the combining of several SDs for the same individual on one service can be challenging for the RP if the SDs have different identifiers.

The Issuer identifies the domain

The basic reference for a SD is an issuer. It does not really make sense to have multiple issuers in the same SD.

The issuer can be defined as the entity issuing an electronic IDs according to the rules and policies defined for a SD. 

Note that it is possible to define rules, regulations and policies for a SD (this is what the government in Norway does with the Kravspesifikasjon for PKI i offentlig sektor) without being an explicit issuer. But the entities that implement these requirements, BankID, Buypass and Commfedes are all issuers on their own, hence defining their own separate SDs, that all happen to follow the same basic rules and regulations. In other words, the Norwegian government defines the framework and the issuers implement the models.

So, in the same way a Certificate Authority (CA) issue digital certificates (and hence become s the issuer of the certificate), a Credential Service Provider (CSP) issue tokens and credentials to a subscriber/user (hence becoming the issuer of the electronic ID).

Note that for Qualified Certificates (like the one described by Kravspesifikasjon for PKI i offentlig sektor), these two entities are combined. However, that a CA can issue Qualified Certificates in several SDs (the CA does not identify the SD), but the CSP issuer does, as it is designated as the issuer of the SD (defining the rules for and trusting certificates issued by the CA).

The scope of a domain

The defined scope (and intent) of a domain can be of various sizes. The SDs represented by ID-Porten and HelseID include rules and policies for both identification, authorisations and attributes/claims. 

But a a SD can be as simple as user defining user accounts with username and password for a net-shop, or even simpler, just some authentication method.

A typical example of this is an SD dedicated to Multi Factor Authentication (MFA). The SD does not itself have any knowledge about identities or claims/attributes, it only verifies that someone controls a phone number. In itself, such an SD does not make much sense, but in a trust relationship with another SD it suddenly has value.

High complexity leads to questionable trust

I theory, there is nothing that prevents the implementation of multiple levels/types of identities, authentication mechanisms and claims/attributes verification within a single SD.

One could for example have both verified identities (verified by looking up the identity in Folkeregisteret) mixed with online registered/claimed identities (using email and name) and then relay the difference between these identities to the RPs as token claims. In addition one could have the user log on using several different types of authentication methods. everything form Qualified Certificates on smart-cards and USB tokens to passwords or OTP codes using SMS and mail. The different authentication methods will have different levels of security, which again can be communicated to the RP using claims.

Claims and attributes about a user can also be mixed. Some might be verifiable, stemming from Folkeregisteret or other authoritative sources, but others might just be claims entered by the user him/her self or looked up from some other internet service (like Facebook). This can be data like email address, postal address or phone number. Yet again the level of trust when it comes to the claims/attributes must be communicated to the RP.

The resulting complexity for the RP to handle, given such a complex SD policy, is substantial. As an effect of this complexity, much of the actual security is in fact moved to the RP. The IdP representing the SD in this case, is not much more than a glorified directory service. The RP basically has to check all incoming claims and data and implement rules and policies accordingly. The question the RPs will constantly strive with is: what can they actually trust?

In addition, the RP must be prepared and define policies for several more or less realistic combinations.

How should an RP handle the example above? The identity proofing is low (not really verified), but the authentication method is relatively strong, meaning that the RP can be pretty sure its the same user as last login. But the claims about the user are only verified in the simplest form.

To prevent leaving it up to the RPs to do all the policy decisions, reduce the value of delegation and reduce security, it is better to have a more strict definition for a SD and rather defined trust to create flexibility for complex use cases.

An example of this would be to have an SD with proven identities (and QC as authentication) enable use of social media providers (like Facebook) as authentication mechanisms for some RPs. In such a case, all RPs can trust that the actual identity is verified, but the authentication method may vary depending on the use case. The implementation of such an authentication mechanism is done by trusting another SD for a narrow defined scope.

Identifying an electronic ID

As described above, the SD is what describes the context of an electronic ID. The SD is what defines what the RPs can rely on, what the RPs can trust. It is also important to see that an electronic ID can be distributed both electronically (by IdPs and federation protocols) or with physical tokens like smart cards and USB dongles. In any case the ID is issued in the context of an SD. 

At the same time, an ID need one or more unique identifiers (to separate one ID/user/account from all others). But note that such an identifier is often not unique across SDs. SSN is an example of a unique identifier for an individual, but it does not say anything about context in terms of an electronic ID. It would be like having a home made ID-card with a SSN on it, showing it in the bank and trying to withdraw money. The SSN and ID-card has no value without trusting the issuer of card (and hence the SD represented by that issuer).

In other words: an electronic ID will always need two components to be uniquely identified: 

1. A user/account-ID (ex. SSN, email, UUID or other)
2. Am issuer identifier (ex. a name, a URL or some other key)

The resulting two-component key uniquely identifies the user and its context, in other words: identifies the eID.

To summarise

• The end-user perspective of a Security Domain is a user account.
• A user ID/account or certificate representing the ID, is always issued in context of an SD.
• It is up to the RPs to decide what SDs (what issuers) to trust. Even if an SD adopt and are in conformance of the strictest of government requirements, the issuer still need to be trusted by the RPs.
• SDs may trust other SDs as long as their requirements are met.
• A user ID/account or certificate can not span SDs, but SDs can trust each other (federation).
• Several SDs can have the same rules and requirements, that does not mean they are related or have any form of dependency.
• A person/subject can be represented in multiple SDs, without any dependency between the users accounts.
• Allowed/available authentication mechanisms/methods are decided by the SDs.
• The scope and complexity of a SD must be carefully decided to avoid pushing unnecessary complexity to the RPs.
• An electronic ID can only be identified in with the combination of a user ID and an issuer ID.