Mathematical Modelling of Trust Issues in Federated Identity Management

Abstract

With the absence of physical evidence, the concept of trust plays a crucial role in the proliferation and popularisation of online services. In fact, trust is the inherent quality that binds together all involved entities and provides the underlying confidence that allows them to interact in an online setting. The concept of Federated Identity Management (FIM) has been introduced with the aim of allowing users to access online services in a secure and privacy-friendly way and has gained considerable popularities in recent years. Being a technology targeted for online services, FIM is also bound by a set of trust requirements. Even though there have been numerous studies on the mathematical representation, modelling and analysis of trust issues in online services, a comprehensive study focusing on the mathematical modelling and analysis of trust issues in FIM is still absent. In this paper we aim to address this issue by presenting a mathematical framework to model trust issues in FIM. We show how our framework can help to represent complex trust issues in a convenient way and how it can be used to analyse and calculate trust among different entities qualitatively as well as quantitatively.

1 Introduction

Unlike the brick and mortar world, the physical evidence and visual cues that can be used to establish trust and gain confidence are largely absent in online services. Despite this, the popularity of online services has grown exponentially in the last decade or so. The concept of trust played a crucial role in popularising online services. In fact, trust is the inherent quality that binds together all involved entities and provides the underlying confidence that allows them to interact in an online service. The mathematical modelling and analysis of different trust requirements in online services are abound and is a well established research area. Such a model helps to express and to reason with trust issues in a formal way which can ultimately help to create novel ways for determining trust among involved entities.

The concept of Federated Identity Management (FIM) has been introduced to ease the burden of managing different online identities and to allow users to access online services in a secure and privacy-friendly way [1]. FIM offers an array of advantages to different stakeholders and has gained considerable popularities in recent years. Being a technology targeted for the online setting, FIM is also bound by a set of trust requirements. Surprisingly, the mathematical representation, modelling and analysis of different trust requirements of FIM have received little attention so far. The aim of this paper is to fill this gap.

Here, we present a comprehensive mathematical framework considering different trust aspects targeted for FIM. In doing so, we show how our framework can formally express trust in FIM and how such expressions can be used to analyse and evaluate trust qualitatively and quantitatively. The main contributions of the paper are:

• 1. Inspired by the notation of trust presented in [14], we present a notation to express trust between different entities in FIM.

• 2. We use this notation to develop the first mathematical framework to model, analyse and derive trust in different types of identity federations.

• 3. We explore trust transformations resulting from interactions in FIM.

• 4. Finally, we present a simple method to evaluate trust quantitatively in FIM.

The paper is structured as follows. Section 2 provides a brief introduction to FIM and the required trust issues in this setting. Section 3 introduces the notation and the interaction model that will be used in our framework. The trust issues in different types of identity federations are modelled in Sects. 4 and 5. We show how trust transformations occur within different federations using our framework in Sect. 6 and how trust can be calculated quantitatively in Sect. 7. Section 8 discusses the related work and finally Sect. 9 concludes the paper.

2 Background

In this section, we provide a brief introduction to FIM, to different aspects of trust in general and to trust issues in FIM specifically.

Federated Identity Management. Identity Management consists of technologies and policies for representing and recognising entities using digital identifiers within a specific context [7]. A system that is used for managing the identity of users is called an Identity Management System (IMS). Each IMS includes the following types of parties: Service Providers (SPs) or Relying Parties (RPs) - entities that provides services to users or other SPs, Identity Providers (IdPs) - entities that provides identities to users to enable them to receive services from SPs and Clients/Users - entities that receive services from SPs. Among different IMS, the Federated Identity Management (FIM) has gained much attention and popularity.

The Federated Identity Management is based on the concept of Identity Federation. A federation with respect to Identity Management is a business model in which a group of two or more trusted parties legally bind themselves with a business and technical contract [1, 17]. It allows a user to access restricted resources seamlessly and securely from other partners residing in different Identity Domains. An identity domain is the virtual boundary, context or environment in which an identity of a user is valid [17]. Single Sign On (SSO) is the capability that allows users to login to one system and then access other related but autonomous systems without further logins. It alleviates the need to login every time a user needs to access those related systems. A good example is the Google Single Sign On service which allows users to login a Google service, e.g., Gmail, and then allows them to access other Google services such as Calendar, Documents, YouTube, Blogs and so on.

Fig. 1.

Federated identity domain.

A federated identity domain can be formed by one IdP in an identity domain and a number of SPs with each SP residing in a separate identity domain (Type 1 in Fig. 1(a)). Several federated identity domains can be combined to form a larger federated identity domain where each smaller federated domain is of Type 1 (Type 2 in Fig. 1(b)). A Type 2 federation allows an IdP of a Type 1 federation to delegate the authentication task to another IdP in a different Type 1 federation. To enable this, both IdPs need to act as both IdPs and SPs. The issue of trust is a fundamental concept in FIM as different autonomous bodies need to trust each other inside the federation. Such parties inside a federation are said to form the so-called Circle of Trust (CoT).

A federation can be of two types depending on how it is created. The traditional federation, also called a Static Federation, is where the federation is created at the admin level and is bound with a legal contract using a specified set of administrative procedures. On the other hand, in a Dynamic Federation any user, not only administrators, can create the federation in a dynamic fashion without administrative intervention or a legally binding contract [3].

Trust. The concept of trust and trust management in the setting of online services is a widely studied topic and has been defined in numerous ways. For the purpose of this paper, we use the following definition taken from [11] which was originally inspired by [13].

“Trust is the extent to which one party is willing to depend on something or somebody in a given situation with a feeling of relative security, even though negative consequences are possible.”

The definition gives a directional relationship between two entities: the first is regarded as the Trustor and the second the Trustee. The trustor and trustee can be any entity, however, in the scope of this paper, only those involved in FIM will be considered (i.e. users, IdPs and SPs). The pairwise trust relations we consider are user-IdP, user-SP, IdP-SP and IdP-IdP which is inline with current IMS setting and the relationships that occur inside a federation.

Trust can be of two types: Direct Trust (DT) and Indirect Trust (IT) [12]. Direct trust signifies that there exists a trust relationship between the entities based on first hand experience and evidence. On the other hand, indirect trust, also known as Transitive Trust, is a trust relationship between two entities based on referral from one or more intermediate third parties.

Every trust relationship has a scope that signifies the specific purpose or context into which that trust relationship is valid. The trust strength (also known as the trust degree) signifies the level of trust a trustor has over a trustee [14]. The type and value used to define the level of trust will vary depending on the trust scopes as well. Trust can be defined as Mutual Trust only if there is a bi-directional trust relationship with the same trust type, scope and strength between the corresponding entities. In such case, both entities can act as the trustor and the trustee. Trust often exhibits the transitivity property [11]: if an entity A trusts another entity B and B trust another entity C, a trust relation can be derived between A and C. To derive such a transitive trust relation, the trust scope must be same. The trust transformation is the process when a trust relationship between two entities changes due to the change of trust strength while the trust type remains the same. Such a transformation occurs normally for two reasons: (i) when the trust is derived following the transitivity property and (ii) when one entity interacts with another entity to perform a certain action which ultimately triggers the change in the trust strength. The transformation can be positive, meaning the new trust strength is higher than what was before, or can be negative, meaning the new trust strength is lower than what was before.

A trust with a single scope can be defined as atomic trust. Compound trust can be defined as the combined trust of several different atomic trusts where the trustor, trustee and the trust direction and strength between them remain the same. The compound trust will also have the same trust direction and strength.

Trust Issues in Identity Management. The issue of trust is a fundamental concept in FIM as different participating organisations need to trust each other inside the federation at a sufficient level to allow them to exchange and trust user information. We will consider such trust issues using two separate instances.

The first, called High Level trust, is the abstract level of trust that is assumed between federated entities (IdPs and SPs) in a federation. This level of trust is common in the existing literature on FIM. For example, it is common to express that two entities trust each other if they belong to the same CoT. In such an expression, the trust is treated at an abstract level and is used mostly to signify their architectural relation inside a federation.

The second, called Fine-grained trust, is a detailed expression of trust including the scope between entities (including users) in a federation. The expression may (optionally) include a trust type or strength. Inspired by the requirements outlined in [8, 12], the authors in [2] have outlined a set of fine-grained trust requirements in the traditional federation which are applicable for both Type 1 and Type 2 federations. We will use their requirements to represent fine-grained trusts in Sect. 4.

Trust in a dynamic federation is modelled using three classes of entities [3]: Fully Trusted entities are IdPs and SPs in the traditional SAML (Security Assertion Markup Language) federation which have a legal contract between them [18]; Semi-trusted entities are SPs in a dynamic federation that have been added dynamically to an IdP inside the federation under some conditions without a contract and to whom any user of the IdP has agreed to release a subset of her attributes and Untrusted entities are IdPs and SPs in a dynamic federation which have been added dynamically under some conditions without a contract. A detailed discussion of these classes can be found in [3].

3 Notation

In this section we will introduce the notation that will be used to build up the model. We use $E$ to denote the set of entities, with $U$ the set of users, $SP$ the set of service providers and $IDP$ the set of identity providers. Since each user, SP and IdP is also an entity, we have $E = U \cup IDP \cup SP$. In addition, $\mathcal {F}$ denotes the set of federations and will use subscript from $\mathcal {F}$ to define the contexts of entities (i.e. the federation in which they belong). For example, $E_f$ will be used to denote the sets of entities in a federation $f$. We use $T$ to denote the set of trust types. As explained above, we consider two types of trust: direct trust (denoted by $DT$) and indirect trust (denoted by $IT$). Therefore, $T = \{ DT , IT \}$.

We use $S$ for the set of trust scopes. Different trust scopes can be defined depending on the trust requirements. We consider the following trust scopes for FIM based on the fine-grained trust requirements of [2]:

• $REG$ is trust in the implementation of the registration process;

• $STO$ is trust in secure attribute storage;

• $AUTHN$ is trust in the implementation of the authentication mechanism;

• $AP$ is trust in allowing the use of anonymous or pseudonymous identifiers;

• $CONSENT$ is trust in the release of only those attributes consented to;

• $ABU$ is the trust that an entity will not abuse attributes released to it;

• $CARE$ is the trust an entity handles her attributes with adequate care;

• $HON$ is the trust that an entity provides attribute values honestly;

• $ACDA$ is the trust that an entity adheres to the agreed policies and procedures during access control and delegated access;

• $SRV$ is the trust in service provisioning;

• $MIN{\text{- }}ATT$ is the trust that an entity requests only minimal attributes;

• $REL$ is the trust in an entity correctly releasing attributes;

• $ND$ is the trust in an entity adhering to the non-disclosure of attributes;

• $FED$ is trust between federated entities.

We consider the following types of trust strengths in FIM.

Subjective Trust. This defines the subjective trust a user may have in IdPs and SPs in a federation and will be denoted with $conf$. It can have different levels, however, we have opted for three levels: LOW (L), MED (M), HIGH (H).

Level of Assurance (LoA). This defines the trust strength between federated IdPs and SPs and is used during service provisioning. It is based on the NIST LoA guidance of 1 to 4 where Level 1 can be used to model the lowest trust and Level 4 the highest [15]. It will be denoted as $loa$ with values from 1 to 4.

Federation Trust. The last type concerns the trust strength between federated IdPs and SPs with respect to their architectural relations. It is denoted with $fed{\text{- }}trust$ and can take four different values: UNTRUSTED (UT), SEMI-TRUSTED (ST), RESTRICTED-TRUSTED (RT) and FULLY-TRUSTED (FT). The lowest trust strength UT means a trustor does not trust a trustee at all and is associated between entities federated in a dynamic fashion or between entities in a transitive trust in static federations (see below). The strength ST means a trustor trusts a trustee upto a certain level. An example is the trust strength between a dynamically federated IdP and an SP and the fact that the IdP may not want release sensitive attributes to the SP as there are no formal agreement between them. The strength RT is higher than ST, but lower than FT. Such a strength is exhibited when the trust relationship between a trustor and trustee is derived using transitivity and the trustor may not fully trust the trustee as there are no formal agreements between them. The strength FT signifies the highest strength and is exhibited when the trustor and trustee are part of a traditional federation. The federation trust strengths are ranked:

$$ UT < ST < RT < FT \, . $$

To indicate an entity $e_1 \in E_f$ (the trustor) has $t \in T$ trust over an entity $e_2 \in E_f$ (the trustee) in a federation $f \in \mathcal {F}$ with a trust scope of $s \in S$ and the trust strength of $v$, we will use the following notation, inspired by [14]:

where $v$ represents the trust strength (either $conf$, $loa$ or $fed{\text{- }}trust$). To express the same trust $t$ between two entities $e_1$ and $e_2$ with same trust strength $v$ in a number of different scopes, $s_1,\dots ,s_n$, we extend the notation to:

If there exists a mutual trust ($t$) between two entities in the same trust scope ($s$) with the same trust strength ($v$), we use the notation:

3.1 Interaction Model

To enable a protocol flow in a federation, each entity interacts with another entity in order to perform an action at another entity. A user interacting with an IdP to authenticate herself by providing an identifier (e.g. username) and a credential (e.g. password) is example of an interaction. Interaction between entities to perform an action can cause the trust between the involved entities to transform. The interaction model consists of the actions that an entity can perform at another entity in a federation. Such interactions must be carried out using a communication channel. We will use the notation $CHANNEL$ to define the set of channels. Two types of channels will be considered: secure channels, denoted $SC$, model secure HTTPS connections whereas unsecured channels, denoted $UC$, model unsecured HTTP connections.

To denote an interaction that represents an entity $e_1$ performs action $a$ at entity $e_2$ using communication channel $c$, we will use the following notation: $c(e_1 \mathop {\rightsquigarrow }\limits ^{a} e_2)$. There could be many interactions in a federation, however, to the scope of this paper, we restrict attention to the following interactions:

• $c(u \mathop {\rightsquigarrow }\limits ^{\textit{RG}} idp )$ representing user $u$ registering at IdP $idp$ through channel $c$;

• $c( u \mathop {\rightsquigarrow }\limits ^{A} idp )$ representing user $u$ authenticating herself at IdP $idp$ through channel $c$;

• $c( idp \mathop {\rightsquigarrow }\limits ^{\textit{AP}} u )$ representing IdP $idp$ allowing user $u$ to use anonymous or pseudonymous identifiers through channel $c$;

• $c( idp \mathop {\rightsquigarrow }\limits ^{\textit{C}} u )$ representing IdP $idp$ providing user $u$ with the opportunity to provide consent for releasing selected attributes through channel $c$;

• $c( idp \mathop {\rightsquigarrow }\limits ^{\textit{RL}} sp )$ representing IdP $idp$ releasing user $u$’s selected attributes to the SP $sp$ through channel $c$.

4 Trust Modelling in Traditional (Static) Federations

In this section, we model trust between different entities in traditional federations. We will consider first high level trust and then fine-grained trust.

4.1 High Level Trust Modelling

We can express the high level trust in a Type 1 federation $f \in \mathcal {F}$ between an IdP $idp \in IDP _f$ and an SP $sp \in SP _f$ by:

This signifies that $idp$ and $sp$ have a mutual direct trust in the scope of the federation. Since it is a Type 1 federation, the entities trust each other fully, hence the trust strength is fully trusted ($FT$).

Let us now consider a Type 2 Federation consisting of two Type 1 federations, say $f_1, f_2 \in \mathcal {F}$. Since $f_1$ and $f_2$ are Type 1 federations, we have for $i \in \{1,2\}$, $idp _i \in IDP_{f_i}$ and $sp _i \in SP_{f_i}$:

Trust between an IdP $idp _1 \in f_1$ and an IdP $idp _2 \in f_2$ deserves further attention. Since they are in a Type 2 federation, these IdPs will act as both IdPs and SPs depending on the use-cases. Without specifying which entity acts as what, we can model the underlying trust relations between these IdPs as follows:

Next we model the trust transitivity property of [11] by introducing the following rules to derive a transitive trust between entities in a Type 2 Federation.

Rule 1

(Trust Type in a Transitive Trust). A derived transitive trust between entities in a traditional Type 2 Federation must be of indirect trust type.

Rule 2

(Trust Strength in a Transitive Trust). The strength of the derived trust is that immediately below the lowest value of the intermediate trusts except when no such value exists, in which case the strength will be the lowest value.

The trust type between the entities changes in a transitive trust since they are not directly connected with each other. Changes in the trust strength between entities in a transitive trust is because there need not exist a formal agreement between the entities, and hence the rule ensures that the derived level of trust is the lowest among (or lower than) any intermediate trust levels in the transitive path. The rule also includes a limiting condition to ensure that the trust strength does not reduce to an undetermined value as it is reduced along a transitive path of trust.

Next, let us consider a Type 2 Federation consisting of two Type 1 federations $f_1, f_2 \in \mathcal {F}$. For $sp _1 \in SP _{f_1}$, $idp _1 \in IDP _{f_1}$ and $idp _2 \in IDP _{f_2}$ the transitive trust between $sp _1$ and $idp _2$ can be derived using Rule 1 and 2 as follows:

We can use these rules to derive trust between any number of entities in a Type 2 federation. For example, consider three federations $f_1,f_2,f_3 \in \mathcal {F}$ with three different IdPs $idp _1 \in IDP_{f_1}$, $idp _2 \in IDP_{f_2}$ and $idp _3 \in IDP_{f_1}$. Furthermore, suppose there is a Type 2 federation between $f_1$ and $f_2$ and another between $f_2$ and $f_3$, and hence both $idp _1$ and $idp _2$, and $idp _2$ and $idp _3$ are directly connected. For an SP $sp _1$ in federation $f_1$ we can derive the trust relations between $sp _1$ and $idp _3$ using Rule 1 and 2 and the following proof tree:

4.2 Fine-Grained Trust Modelling

Now, we model fine-grained trust for a Type-1 Federation as outlined in [2]. In the following scenarios, each trust will include a strength $conf$ or level of assurance $loa$ in a Type 1 federation $f \in \mathcal {F}$ between a user $u \in U_f$, IdP $idp \in IDP_f$ or SP $sp \in SP_f$. The trust strength $conf$ is assumed when one of the entities is a user and $loa$ when the trust is between an IdP and SP.

User Trust in the IdP

T1. The user trusts that the IdP has correctly implemented user registration procedures and authentication mechanisms (denoted T2 in [8]):

Note the direction between the said entities. Since it is not a mutual trust, the direction of trust is from the user to the IdP. Also, as there are two trust scopes (registration and authentication).

T2. The user trusts that the IdP allows the user to utilise anonymous or pseudonymous identifiers (denoted T1 in [8]):

T3. The user trusts that the IdP will release only those attributes to the SP that the user has consented to:

T2 and T3 can be combined to denote the user trusting the IdP to protect the privacy of the user through the following rule for compound trust of privacy.

Rule 3

(Compound Trust of Privacy). A compound trust of Privacy ($PRIV$) is a user’s trust in the IdP to preserve its privacy to an SP using anonymous or pseudonymous identifiers (T2) and trust in allowing the user to choose and provide consent regarding the attributes that it wants to release to the SP (T3). Formally we have:

As mentioned earlier, the trust direction and strength must be same in T2 and T3 and the compound trust will inherit these values.

T4. The user trusts that the IdP has satisfactory mechanisms to store user attributes safely and securely:

User Trust in the SP

T5. The user trusts that the SP will ask only for the minimum number of user attributes that are required to access any of its services:

T6. The user trusts that the SP will not abuse the released user attributes and will use them only for the stated purpose(s):

IdP and SP Trust in the User

T7. The IdP trusts that the user handles their authentication credentials with adequate care (denoted as T3 in [8]):

T8. The SP trusts that the user is honest while providing attributes to an IdP:

IdP Trust in the SP

T9. The IdP trusts that the SP adheres to the agreed privacy policies regarding non-disclosure of user data (denoted as $IdP{\text{- }}T.1$ in [12]):

In other words, the SP will not abuse the released user attributes and will use them only for the stated purpose(s). The policy might include that the SP will not cache any user-attributes other than those which are absolutely necessary. This is to ensure that the IdP can always provide the updated attributes regarding the user. In cases where the SP needs to cache any attributes (e.g. IdP-supplied identifiers), the SP must inform the IdP.

T10. The IdP trusts that the SP adheres to the agreed policies and procedures, if they are available regarding access control and delegated access:

If there are no such policies or procedures, this requirement is ignored.

Like Rule 3, we can combine T9 and T10 to define a compound trust through the following rule.

Rule 4

(Compound Trust of Policy). A compound trust of Policy, denoted as $POL$, is an IdP trust in a SP adhering to the non-disclosure of attributes and not abusing the released attributes (T9) and maintaining the agreed policies and procedures regarding access control and delegated access (T10). Formally:

As before, the trust direction and strength must be same in T9 and T10 and the compound trust also will have that same trust direction and trust strength.

SP Trust in the IdP.

T11. The SP trusts that the IdP has implemented adequate procedures for registering users and for issuing credentials (denoted as T7 in [8]):

This captures the realistic scenarios where a LoA value, determined and released by the IdP, is used by the SP to evaluate the level of trust it can have on the IdP in a specific trust scope. A lower LoA value may influence the SP to place a lower trust and similarly a higher LoA value may influence the SP to have a higher trust on the IdP for a particular scope.

T12. The SP trusts that the IdP will authenticate the user appropriately as per the requirement and will release user attributes securely:

We combine T11 and T12 to define a compound trust using the following rule.

Rule 5

(Compound Trust of Registration-Authentication). A compound trust of Registration-Authentication, denoted as $RAUTH$, outlines the SP trust that the IdP registers users securely (T11) and authenticates users and releases attributes as per the requirement (T12). Formally, we have:

5 Trust Modelling in Dynamic Federations

In this section, we model trust between different entities in traditional federations. We only consider high level trust as the fine-grained trust for this federation is similar to traditional federations.

Type 1 Federation. Here, we have two different types of trust. To an SP, each dynamically added IdP will be treated as untrusted. Formally, in a Type 1 federation $f \in \mathcal {F}$ for $sp \in SP_f$ and dynamically added $idp \in IDP_f$:

However, to the IdP, the SP can be untrusted or semi-trusted depending to conditions discussed previously:

Type 2 Federation. This is similar to the traditional Type 2 federation as discussed previously, except there is no mutual trust between dynamically added entities and static entities, hence we consider each trust direction separately.

Using Rule 1 and 2 we can derive a transitive trust between any two entities in a dynamic federation as follows. For $f_1, f_2 \in \mathcal {F}$, $sp _1 \in SP_{f_1}$, $sp _2 \in IDP_{f_2}$, $idp _1 \in IDP_{f_1}$, $idp _2 \in IDP_{f_2}$ and where $idp _2$ has been added dynamically into federation $f_1$ and $sp _2$ has been added dynamically into federation $f_2$:

Since, $idp _1$ acts as the SP to $idp _2$ and a dynamically added IdP is always treated as an untrusted entity to a SP, the trust from $idp _1$ to the $idp _2$ is regarded as untrusted. A few more derivation are given below:

This derives the transitive trust between $idp _2$ and $sp _1$.

This derives the transitive trust between $sp _2$ and $idp _1$ and below we derive the transitive trust between $idp _1$ and $sp _2$.

6 Trust Transformation with Interactions

We have seen how trust is transformed due to transitivity. Next, we explore how it is transformed due to interactions. We use the following notation to denote a change of trust from $T_1$ to $T_2$ for an interaction $A$: . Sometimes, we logically join (using the “$\wedge$”  operator) more than one interaction to signify the fact that more than one interaction is required to trigger a trust transformation.

Trust Transformation in Static Federations. Our first example explores how the trust can be transformed between a user (the trustor) and an IdP (the trustee). At the initial stage, the confidence (trust strength) of the user could be low. Once the user is registered and authenticated using a secure communication channel (e.g. HTTPS), the trust strength could increase to medium since it reflects that the IdP is careful to maintain the confidentiality and integrity of her data. For a federation $f \in \mathcal {F}$, $u \in U_f$ and $idp \in IDP_f$, this is modelled by:

The user may have another boost in trust when she has a positive interaction with the IdP for a period. One example is the use of a consent form that allows the user to select the attributes that she wants to release to an SP, and thus allows her the option to provide consent to release data to the SP. Formally:

Our second example involves transforming privacy trust with interactions. The involved interactions are the IdP allowing the user to use anonymous or pseudonymous identifiers and offering the opportunity to provide consent regarding attributes. The trust strength will initially be low and will transform to either medium or high depending on different factors. Example factors are a user-friendly interface that makes it easier for the user to choose anonymous or pseudonymous identifiers or allows the user to choose attributes and provide consent. The trust transformation is modelled by:

Trust Transformation in Dynamic Federations. For federation $f \in \mathcal {F}$, $u \in U_f$, $idp \in IDP_f$ dynamically added by $u$ and $sp \in SP_f$, the trust transformation occurs only if $u$ has agreed to release her attributes from $idp$ to $sp$:

7 Quantifying Trust

In real life, trust is an analogue property, and hence it is difficult to represent with discrete values. However, it might be useful to compute the trust between involved entities using discrete values when the entities belong to a computational system and require a discrete value to represent the trust in that system. Among three pieces of information used to represent trust (type, scope and strength), we only use type and strength to compute a trust value. This is because scope only represents a context, a qualitative attribute, in which trust holds, while both type and strength can be represented numerically. For example, direct trust represents a higher confidence as it is based on first-hand experience, unlike indirect trust. We introduce the following formula to quantify trust in a federation $f \in \mathcal {F}$ between entities $e_1,e_2 \in E_f$ for trust scope $s$ where $e_1$ is the trustor and $e_2$ is the trustee:

$$ QT ^{e_2}_{e_1}(s) = t ^{e_2}_{e_1}(s) \cdot v ^{e_2}_{e_1}(s) $$

where $QT ^{e_2}_{e_1}(s)$, $t ^{e_2}_{e_1}(s)$ and $v ^{e_2}_{e_1}(s)$ represent the quantified trust, trust type and strength of $e_1$ over $e_2$ in the scope $s$ for federation $f$.

In the formula the trust strength quantifies how much trust one entity may have over another entity and the trust type signifies the confidence on that quantification. Trust type can be thought as the weight of the trust strength. Note that, this is one way of quantifying a trust and there are other possibilities.

We now consider a few examples. As stated above to quantify trust we need to give values to trust types and strengths. Regarding types, we assign 1 and 2 to indirect and direct trust respectively, and for strength, we assign $1$, $2$ and $3$ to $conf$ and $1$, $2$, $3$ and $4$ to $fed{\text{- }}trust$.

Fig. 2.

Quantifying trust example.

We can now quantify trust in the federations illustrated in Fig. 2. The left box of Fig. 2(a) illustrates a Type 1 static federation while Fig. 2(a) and (b) illustrate a Type 2 static and dynamic federations respectively. The direct trust between $sp _1$ and $idp _1$ for the Type 1 static federation is given by:

$$ QT ^{ idp _1}_{ sp _1}( FED ) = 2 \cdot 4 = 8 $$

since the entities have direct trust between them ($t ^{ idp _1}_{ sp _1}( FED ) = 2$) and they fully trust each other ($v ^{ idp _1}_{ sp _1}( FED ) = 4$).

For the static Type 2 federation in Fig. 2(a), the indirect trust between $sp _1$ and the $idp _2$ is given by:

$$\begin{aligned} QT ^{ idp _2}_{ sp _1}( FED ) \; = \; 1 \cdot 3 \; = \; 3 \end{aligned}$$

This is because the entities have indirect trust between them ($t ^{ idp _2}_{ sp _1}( FED ) = 1$) and according to Rule 2, the trust strength between them ($v ^{ idp _2}_{ sp _1}( FED ) = 3$).

Similarly, for the dynamic Type 2 federation in Fig. 2(b) and calculating the indirect trust between $sp _1$ (the trustor) and the $idp _2$ (the trustee), where the trust strength between the transitive entities are not same, we have:

$$\begin{aligned} QT ^{ idp _2}_{ sp _1}( FED ) \; = \; 1 \cdot 1 = \; 1 \end{aligned}$$

8 Related Work

A few major papers on the general topic of trust and trust management can be found in [5, 9–11, 16]. These works mainly concentrated on the discussion and analysis of trust and trust management and the discussion of trust regarding identity management was mainly absent.

A comprehensive taxonomy of trust requirements for the FIM can be found in [2]. Unfortunately, the requirements have been outlined in textual formats and none of requirements has been modelled and analysed mathematically. The authors in [14] have presented an integrated trust management model with respect to context-aware services. The model is based on different trust relationships which have been analysed using mathematical notations. The paper did not consider the underlying trust requirements that hold together the involved entities in that trust relationship. In this paper we have adopted their notation to illustrate the trust relationship. Huang et al. [6] have presented a trust calculus targeted for the PKI (Public Key Infrastructure) and have shown how the calculus can be used to derive trust between entities in a certification chain. The focus of their work is quite different than ours in the sense that they did not deal with any underlying trust requirements in the FIM. The authors in [4] have presented a formalisation of authentication trust for the FIM. The authors did not consider any other trust requirements, and hence their formal representation is not comprehensive in nature.

9 Conclusions

Trust in the traditional Type 1 Federation is a complex issue with the involvement of several different autonomous parties and their disparate security domains. The complexity increases with the introduction of a Type 2 Federation. The advent of the dynamic federation adds up another layer of complexity. Even though there exist numerous works on the mathematical modelling of trust in the online setting, there is a gap on the mathematical modelling and analysis of trust in the setting of FIM. In this paper we have introduced a mathematical framework to represent and analyse complex trust issues in FIM. We have used our model to represent trust in different settings. We have introduced a model of interactions for FIM and have shown how interactions and the trust transitivity can transform trust. Finally, we have proposed a simple formula to quantify trust. Our model can be used in a wide range of applications. It can be used to express and derive trust between any number of entities in any type of federations. A larger federation where there are many IdPs and SPs that exhibit a highly dynamic nature where changes are common. Trust transformation using interactions can be the ideal way to represent trust in such a dynamic environment. Finally, the way we have evaluated trust can be used to assess trust between any entities in a federation or to assess the quality of service provided by an IdP or an SP. Next, we plan to use our model to analyse other aspects of identity management such as attribute aggregation and mobile identity management.