1

Federated Trust Networks

James W. Van Dyke

January 2006

2

Basic Terminology

In Internet security terminology, we define a claim as a declaration made by an entity, such

as one’s name or group, and we define a security token as a collection of such claims (Kaler “WS-

Federation” 3). A proof-of-possession is information like a password or fingerprint template that a

sender provides to verify, or authenticate, his or her identity. Thus, a proof-of-possession token is a

security token containing claims along with supporting evidence to substantiate these claims (3).

After evaluating tokens and proof-of-possession data, a service determines whether to trust a

requestor’s identity claims and thereby authenticate the user based on its security policy.

Subsequently, the service performs an authorization step to determine whether the identified user

has permission to access the requested resources.

Federation

The term federation describes the process in which entities broker trust and exchange

information across organizational boundaries. WS-Federation, a specification written by IBM,

Microsoft, VeriSign, Inc., and others, defines a federation as “a collection of realms that have

established trust” (Kaler “WS-Federation” 3). As shown in Figure 3, a useful example of federation

as it exists today is the ATM banking network. Several examples of trust in this system include the

following: independent banks agree to conduct financial transactions with each other’s clients; the

client trusts that a foreign bank’s ATM will communicate his or her account number and PIN

responsibly and securely to his or her home institution to conduct the transaction; the client’s bank

trusts that the foreign bank generates a valid request on behalf of its customer; and the foreign bank

trusts that upon issuing funds to the client, the client’s home institution will transfer the appropriate

funds to it. Proponents of web services believe that new web service technologies will expand

3

federation as it exists for ATM networks into a generalized architecture that is applicable for many

types of Internet communications.

Figure 3: The Federated ATM Network

This figure demonstrates the federated-nature of the worldwide ATM Network.

Introduction

Secure federation among web services in a distributed environment fundamentally relies on

trust. Services in one domain necessarily depend on the terms of their trust relationships with other

domains when making inter-domain security decisions. Expressed as policies, trust relationships

instruct services on how to respond to a variety of security issues, including whether to fulfill a

request or to permit identity federation from another domain. Existing web service security

specifications provide mechanisms for specifying trust (WS-SecurityPolicy), communicating trust

(WS-Security, WS-Trust), and applying trust to enable federation (WS-Federation). While these

Account Number and PIN

Home Bank Network

Visiting Bank Network

Funds Network of Trust

4

specifications enhance the basic functionality and security of web services, a variety of security

obstacles remain that impede the practical integration of large-scale, loosely-coupled, heterogeneous

distributed systems on the Internet. Several fundamental questions about trust include the

following:

- How can one entity trust the security practices of another entity (e.g., authentication and

authorization procedures)?

- How are trust relationships established and defined?

- How are degrees of trustworthiness measured and communicated?

- Considering the large number of web service interactions that may occur in future wide-area

distributed systems, how can domain administrators practically enumerate all possible trust

relationships with partners?

Background and the Importance of Context Information

Many of the challenges related to trust management in a distributed environment involve

federation of identities, attributes, roles, and privileges. Authentication is the process through which

an authority verifies the identity claims of a user. One’s identity must be known (with some degree

of certainty) before attributes, roles, and privileges can be associated with the identity. Throughout

the Internet today, the most common method of authentication is certification of username (the

claim) and password (the proof of possession for the claim). Recently, however, emerging biometric

devices and other new technologies have begun to offer more robust solutions for verifying one’s

identity. These mechanisms frequently consider multiple variables and degrees of freedom when

analyzing patterns such as one’s fingerprint or iris. Such technologies eliminate the inconvenience of

memorizing passwords, and they also attach biological proof of possession claims to particular users,

5

making them difficult to falsify. From considering the differences in various authentication

methods, one can infer that that the degree to which an authority is “sure” about the identity of a

principle varies depending on the type of authentication mechanism employed.

One of the most important factors involved in effectively specifying, interpreting, and

enforcing trust policies for a given domain is the availability of useful context information about the

security claims of remote domain actors and authorities. While the policies of some services may

unequivocally trust the identity claims affirmed by an authority (for example, a service may fully trust

its own domain’s local authority as assumed below), it is more likely that resource security policies

will prefer or require more information about the context of an authority’s authentication decision

before choosing to accept it. Authentication context information provides more details about the

overall trustworthiness of a client’s identity claims. OASIS Open identifies five primary

characteristics of authentication context:

1) Identification – Identification characteristics describe the user enrollment

process. They identify the processes and mechanisms an authentication authority

employs to associate a subject with its identity or unique UserID (e.g., face-to-

face, online, shared secret).

2) Technical Protection – These characteristics describe the procedures for securing

authentication secrets/templates (e.g., credential renewal frequency, client-side

key generation). Knowledge or possession of these secrets allows a subject to

authenticate with an authority.

3) Operational Protection – These characteristics describe an authority’s procedural

security controls (e.g., security auditing and record keeping).

6

4) Authentication Method – These characteristics describe the authentication

methods/mechanisms used to authenticate users with an authority (e.g.,

password, fingerprint, smartcard, etc.).

5) Governing Agreements – These characteristics describe the legal factors involved

in an authentication process and its underlying technical infrastructure (e.g.,

liability constraints and contractual obligations).

Importance of XML Descriptions and Policies

Formal XML descriptions of authentication methods and contexts are important for

federation and the trust establishment process. These machine-readable documents remove much

of the ambiguity about authentication contexts by providing specific details about a domain’s

supported authentication mechanisms and associated technical and operational security practices.

Establishing a trust relationship between two domains begins with business negotiations.

Then, domain administrators must implement the trust relationship technically. For this step,

administrators create mapping policies that specify rules for mapping authentication and

authorization assertions from one domain to another. Authentication context descriptions assist the

administrator with this process. Administrators create policies that define mappings between local

context descriptions and those of remote domains.

SAML

Oasis has developed the Security Assertion Markup Language (SAML) as an “XML-based

framework for exchanging security information” [Committee Specification May 2002]. SAML

7

communicates security information about subjects as collections of XML assertions. In this context,

a subject is a human or computer entity with an identity determined and accepted by a particular

security domain. After performing authentication and authorization processes, a domain authority

can express claims about a subject’s identity, attributes, and privileges using SAML assertions.

SAML also defines a protocol for requesting assertions about subjects and receiving responses from

SAML authorities [1].

SAML begins to address the importance of authentication context through the use of

Authentication Context declarations. These declarations, which are XML documents included or

referenced in SAML authentication assertions, enable an authentication authority to provide

dependent services with additional information about the context of an authentication decision, such

as the method or mechanism used to authenticate a user. This additional information allows

services to assess the trustworthiness of authentication assertions. According to OASIS Open,

“…if the relying party is to place sufficient confidence in the authentication assertions it

receives from an authentication authority, it will be necessary for it to know which

technologies, protocols, and processes were used or followed for the original authentication

mechanism on which the authentication assertion is based. Armed with this information and

trusting the origin of the actual assertion, the relying party will be better able to make an

informed entitlements decision regarding what services the subject of the authentication

assertion should be allowed to access” [2].

Authentication Context Declarations

The Authentication Context specification for SAML provides XML schemas for describing

the context of authentication assertions. According to OASIS, declarations implementing these

8

schemas address the five primary characteristics of authentication context discussed above:

identification, technical protection, operational protection, authentication method, and governing

agreements. These characteristics describe an authentication authority’s methods for subject

enrollment, verification, template storage, token issuance, etc. For example, an assertion can specify

one of the following principle authentication mechanisms: password, restricted password, token,

smartcard, and activation pin. For authentication using restricted password, a SAML assertion can

also specify password requirements for length, alphabet (e.g., required characters, excluded

characters, etc.), and generation (e.g., chosen by the principle or auto-supplied) [3].

Authentication Context Classes

The specification also proposes the use of Authentication Context classes, which are useful

combinations of particular authentication context declarations. According to OASIS, industry

practices and technologies determine common groupings for many authentication contexts (p 21).

While many factors contribute to authentication context, authentication method is often the most

visible element. Thus, it frequently serves as a useful identifier and classifier of context classes.

Classes offer a convenient means for referencing common authentication contexts. A

simple class identifier may provide enough information for one domain to assess the trustworthiness

of the authentication assertions of another. Other domains may prefer to examine the details of

particular authentication declarations. Authentication context declarations can also express a web

service’s requirements to an authentication authority. Examples of existing Authentication Context

Classes include the following: InternetProtocol, Password, Smartcard, etc.

9

Extensibility

The SAML Authentication Context specification supports extensibility. With extensions,

authorities can use extra elements to describe additional context details about authentication

assertions.

Development of SAML

The first version of SAML, which appeared in 2002, initially incorporated basic support for

naming the authentication method associated with an authentication assertion. SAML 1.0/1.1

provided an AuthenticationMethod attribute within an AuthenticationStatement assertion which

supported the following authentication methods: Password, Kerberos, Secure Remote Password,

Hardware Token, SSL/TLS Certificate Based Client Authentication, x.509 Public Key, PGP Public

Key, SPKI Public Key, XKMS Public Key, XML Digital Signature, and Unspecified. The SAML

1.0/1.1 specification referenced external specifications and academic papers for descriptions of

some of these authentication methods, such as Secure Remote Password (SRP), but for others, such

as Hardware Token, it simply alluded to a general or unspecified authentication mechanism (e.g.,

authentication using an “unspecified” Hardware Token). In none of these cases did a reference

point to an unambiguous, machine-readable XML definition of the authentication method.

SAML 2.0, which was released on March 15, 2005, begins to address this issue with the

introduction of authentication context declarations and context classes. As stated above, assertions

in SAML 2.0 can reference one of the following pre-defined authentication mechanisms: password,

restricted password, token, smartcard, and activation pin. The specification also supports extensions

for naming custom authentication methods, such as fingerprint or signature authentication.

10

Assertions can further specify password constraints (e.g., length) and other identification, technical,

and operational protection requirements. For example, use of the PhysicalVerification element

asserts that subject identification has occurred in a physical face-to-face meeting instead of online;

use of the IPAddress element indicates that subject identification has occurred from a specific IP

address; use of the SecurityAudit element claims that procedural security auditing has been utilized;

and use of elements within the AuthenticatorTransportProtocol denotes that a certain protocol has

been used to transfer authentication information (e.g., HTTP, SSL, etc.).

Limitations of SAML –Extending SAML to Support Detailed XML Definitions of

Authentication Contexts

SAML authentication context declarations and context classes are useful for describing the

basic security characteristics of authentication instances. However, this paper claims that the current

SAML framework is overly simplistic and impractical for describing contexts with enough detail to

build large-scale, inter-domain networks of trust. This lack of support for detail limits a domain

administrator’s ability to specify security requirements, to evaluate the trustworthiness of intra and

inter-domain authentication contexts, and to define trust mapping policies based on these

requirements and evaluations. Unambiguous, comprehensive descriptions of authentication

contexts and methods are necessary to develop clear security policies and dynamic mappings of

contexts. Without precise definitions of authentication context assertions, the terms of a trust

relationship cannot be defined explicitly.

For example, a SAML declaration may assert that a particular subject has authenticated with

a smartcard. It may also assert that SSL encryption was used to encrypt the transmission of

information sent to an authentication authority. However, the details of this process remain

11

unspecified. What type or brand of SmartCard was used? What security mechanisms were in place

to protect the storage and retrieval of enrollment information? Was the smartcard authentication

coupled with a password login?

To use other authentication methods, SAML must be extended. One could add fingerprint

recognition to the list of supported authentication mechanisms with a simple extension to the SAML

2.0 specification. However, again, the details of this authentication process would remain

unavailable unless an administrator had the means to describe them sufficiently using an expanded

SAML framework. The trustworthiness of fingerprint identification depends on implementation of

features such as the following: live finger-detection support, false-positive and false rejection rates,

matching algorithms, degrees of freedom, etc. Thus, in order to evaluate a fingerprint authentication

context, XML descriptions of these features must be available for review.

Conclusion:

This paper concludes that a significantly extended SAML framework is needed to describe

contexts with sufficient detail for useful trust establishment.

Importance of Evaluating and Differentiating the Trustworthiness of Authentication Context Definitions Locally and Across Domains

Assuming that a domain has established a detailed XML definition for each of its supported

authentication contexts, it then becomes useful to differentiate the relative trustworthiness of these

contexts. Domain administrators can accomplish this goal by assigning relative levels of

trustworthiness to these contexts within the local domain. With the ability to distinguish between

these relative levels, policies can limit access to certain resources based on the trustworthiness of the

requestor’s identity claims. This access control is independent of an authorization process. In other

12

words, a policy can restrict access to a resource based on how much it trusts the identity claims of a

principle before it accepts these identity claims and performs the authorization process, which

determines whether the identified user has permission to access a requested resource. With this

system, domain policies can increase security and require higher levels of authentication

trustworthiness for sensitive resources.

Consider the following example:

We assume that resources in a given domain grant access requests before authorization

conditionally based on the trustworthiness of a requestor’s identity claims. How confident is the

resource that the requestor really is who it claims to be? For example, a secure resource may require

that a requestor authenticate with a method deemed relatively more secure than password

authentication, such as fingerprint or smartcard authentication, before granting access.

In our scenario, Domain A wants to establish a trust relationship with Domain B. We

assume that both domains support local authentication via either password or fingerprint or both.

However, we also assume that the implementations of these authentication mechanisms are not

identical in each domain. Thus, in establishing a trust relationship for federation, it is unlikely that

one domain will directly permit identity federation with a second domain without first examining the

authentication context of identity claims originating from the second domain. Both domains may

support password and fingerprint authentication, for example, but implementation details may

influence the relative trustworthiness of these mechanisms as determined by the other domain.

Domain A may conclude that identity claims verified with a certain authentication mechanism in

Domain B are sufficiently trustworthy for accessing some local resources, but unsatisfactory for

accessing other more secure resources. Before granting access to secure resources, additional local

proof of identity may be required to increase the trustworthiness of identity claims.

13

In general, one could assume that fingerprint authentication is more secure than password

authentication. But, the validity of this assumption is implementation dependent and contingent

upon a variety of other conditions, including enrollment and operational contexts surrounding an

authentication process. Password authentication with secure enrollment, rigorous password

generation requirements, and encrypted exchange and storage of templates could be relatively more

secure than fingerprint authentication without these security measures. In addition, one fingerprint

authentication process could be relatively more trustworthy than another because of the particular

technologies and algorithms utilized for enrollment and verification. Fingerprint technologies vary

depending on a variety of biometric hardware and software characteristics such as the degrees of

freedom supported, false positive and false rejection rates, and support for live finger detection.

The details of the trust establishment process will be discussed later. For now, we assume

that a trust relationship (expressed as a policy document) incorporating the considerations above

already exists between domains A and B. Continuing our scenario, suppose that Domain A is a

hospital and that Domain B is a pharmacy, and that both domains have web portal interfaces for

interacting with their users. First, suppose that a doctor needs to write a prescription for a patient

locally in the hospital domain. When the doctor first authenticates with the hospital portal, suppose

that he selects authentication by password. The hospital’s access policies grant password

authentication a certain level of trustworthiness in the local domain, which allows the doctor to

perform some functions. However, suppose hospital administrators have determined that writing a

prescription requires a greater level of confidence in the identity claims of the doctor than that

achieved with password authentication. The hospital policies require a more trustworthy

authentication of the doctor’s identity. This step must occur before performing the authorization

process. In this case, we assume that the doctor authenticates a second time with a fingerprint scan

to increase the trustworthiness of his identity claims. Now, the doctor has provided two proofs of

14

possession to support his assertions. Once the hospital is sufficiently confident that its

authentication policy has been satisfied with the identity claims of the doctor, the system can

proceed to determine whether the principle has permission to access the requested resource (i.e., the

prescription service).

Now, suppose that the patient wants to submit the prescription written by his doctor to a

pharmacy. In this case, the patient first logs in to the hospital portal using his authentication

method of choice. He locates his prescription and attempts to send it to a pharmacy. During this

step, cross-domain identity federation must occur. This federation step requires that a trust

relationship exist between the pharmacy and hospital domains. The policy that defines this trust

relationship for the pharmacy outlines the domain’s security requirements and procedures for

evaluating and accepting the identity claims asserted by the hospital domain’s authentication

authority. If a strong trust relationship exists between the two domains, the pharmacy may choose

to accept authentication assertions from the hospital directly (i.e., with the same amount of trust

granted to local authentication assertions). Alternatively, the pharmacy may choose to grant the user

a limited level of authentication trust in the local domain or to examine the details of the

authentication context associated with the identity claims before making a decision. If the user’s

authentication claims meet the requirements of the pharmacy’s policy, then the domain can accept

the authentication claims verified and asserted by the remote hospital authority without requiring

local authentication. Otherwise, the user may have to re-authenticate in the pharmacy domain. The

technical details of this process will be explained in a later section.

Conclusion:

While basic SAML limits the level of detail of authentication context descriptions, it also

provides no support for characterizing differences in the relative trustworthiness of these contexts.

15

Not only would it be helpful to provide more detailed descriptions of authentication mechanisms

(e.g., beyond just claiming smartcard authentication, but also describing the security details of the

smartcard in use), but it would also be useful to identify the locally-determined relative

authentication trustworthiness of these mechanisms.

The primary reason for sharing and referencing detailed authentication context descriptions

is so that domain authorities can make policy decisions about the trustworthiness of remote

authentication claims. These policy decisions define the terms of trust relationships between

domains.

Thus, this paper proposes an extended version of SAML that embeds or references a

detailed context definition document or context class definition document within a SAML assertion.

Secondly, this paper proposes the use of trust levels (discussed below) to describe and to

differentiate between the trustworthiness of authentication contexts.

Trust Levels

A trust level can be described as a numeric value that represents the relative trustworthiness

of a specific authentication mechanism or context. A trust level included within an authentication

context definition or context class definition indicates the context’s relative trustworthiness in the

local system according to domain administrators. When associated with an authentication token and

the identity assertions about a principle, a trust level expresses an authority’s confidence in the

context of the principle’s authentication and, thus, the identity claims of the user. In other words,

the trust level conveys how “sure” an authority is that a requestor is who it claims to be. The

implementation details of trust levels will be discussed later. For now, simply recognize that when

16

an authority generates a security token for an authenticated principle, it assigns this token (and its

collection of identity claims about the principle) a certain trust level.

System administrators can designate trust levels to distinguish between the relative

trustworthiness of various authentication context and context class definitions; trust level zero likely

identifies the least secure method (perhaps anonymous access), while higher trust level values usually

indicate more secure methods (e.g., trust level one for username/password authentication, two for

fingerprint scan authentication, and three for iris scan authentication). When determining trust

levels, administrators may reference a variety of characteristics included in authentication context

and context class definitions, including a particular authentication technology’s hardware device

type, manufacturer, version, degrees of freedom, encryption support, etc. In addition,

administrators have the option of designating distinguishing subcategories for a trust level using

fractional values, as in the following example:

• Primary Trust Level = 1.0 for Username/Password Authentication

o Secondary Trust Level = 1.1 for Username/Password Authentication with a required

minimum password length of 6 characters

o Secondary Trust Level = 1.2 for Username/Password Authentication with a required

minimum password length of 6 characters and with a password containing at least

one number and/or symbol

Trust levels identify the relative trustworthiness of authentication contexts within a particular

local domain. System administrators assign trust levels to each context definition or context class

definition in a domain based on the domain’s internal procedures and policies. Likewise, they

develop access control policies referencing these definitions for each resource in the domain. While

similar or perhaps identical context definitions may sometimes receive similar trust levels across

domains, differences and variations will also appear. In other words, it is possible that different

17

domains will assign similar relative trust levels to comparable authentication methods and context

definitions, but this does not have to be the case, as trust levels are determined locally in each

domain. Trust level assignments vary depending on a domain’s own policies and the

implementation details of a particular local context.

[Need Final Scenario Details Below]

For example, two domains may both support basic fingerprint authentication. However, the

specific implementations of this authentication technology may vary in each domain. Assume that

each domain has written an authentication context definition document describing its

implementation using a standardized, XML-based, SAML-extended description language. One

domain’s implementation uses Digital Persona fingerprint scanner hardware [with these technical

details]. The implementation also includes an SSL-secured web-based authentication process and an

encrypted database for fingerprint template storage. Assume that a second domain’s fingerprint

authentication implementation uses [ANOTHER scanner hardware] and includes [SOME OTHER

implementation details].

Also, assume that the first domain assigns its fingerprint context definition a trust level

numerical value of 2.0. This assignment indicates that local domain administrators regard this

fingerprint context as relatively more trustworthy than other local contexts with trust levels less than

2.0 and relatively less trustworthy than other contexts with trust levels greater than this value. For

example, a context definition describing basic password authentication could receive a trust level of

1.0, while a context definition for iris scan authentication could receive a trust level of 3.0. In

contrast, assume that the second domain assigns a trust level of 3.0 to its fingerprint context

definition, which indicates that the context is relatively more trustworthy than other contexts with

lower trust levels, such as basic password authentication (e.g., trust level of 1.0) and e-token

authentication (e.g., trust level of 2.0).

18

Each domain can write access control policies for internal resources that incorporate

authentication trust level requirements. More sensitive resources, for example, can require higher

authentication trust levels before fulfilling access requests. If a requestor attempts to access a

resource without a sufficient trust level (as specified by its access control policy), the resource will

deny the request unless the user or service first provides additional proof of its identity by

reauthenticating using a more trustworthy authentication method or context.

When users or services which have authenticated in one domain attempt to cross into

another trusted domain, identity federation occurs. In this process, a second domain determines if

and to what degree it will trust the identity assertions made about a subject from the authentication

authority in the first domain. Mapping policies in the second domain define the terms of its trust

relationship with the first domain, and vice versa. These policies specify trust level, context, userid,

pseudonym, role, and attribute mappings.

We assume that the two domains in the scenario above have previously conducted business

negotiations and defined the terms of a mutual trust relationship. At that time, each domain

independently translated these agreements into machine-readable policies. One domain’s policy

establishes a one-way trust relationship with the other domain. Both domains must create a policy

to enable a two-way trust relationship. In creating a policy, one domain can reference another’s

authentication context definitions and context class definitions to determine acceptable

authentication requirements and mappings for the local domain. As will be explored in more detail

below, one domain can characterize its trust relationship with another remote domain by mapping

combinations of both authentication contexts and trust levels. Use of trust levels facilitates dynamic

trust, as will also be discussed below.

19

Trust Level Definitions

Trust Level Definitions are essential for communicating trust levels and degrees of

trustworthiness in the trust establishment process. Trust Level Definitions are XML documents

that describe the details of a trust level, including its reference name, floating point value, context

definition members, and other security requirements and characteristics (e.g., url, expiration, etc. as

discussed in the Future Work section). A trust authority hosts trust level definitions for a domain

and often publishes them for public access. In this system, every trust level is referenced by a

unique name rather than its numerical value. The domain’s trust authority resolves local trust level

names and returns their associated trust level definitions and numerical values. As mentioned above,

the trust level definition contains the trust level’s numerical value, a reference list of associated

context definitions that meet the trust level’s security criteria, and other assertions. Trust level

names can correspond to associated context names or can follow any other naming convention as

determined by domain administrators.

For example, assume that a domain creates a trust level definition with the name

“HighSecurity” and assigns it a numerical value of 3.0. The domain’s trust authority hosts this

definition and publishes it for public access. The definition contains references to several context

definitions supported in the local domain, including Password, E-token, and Fingerprint. These

context definitions describe the details of the Password, E-token, and Fingerprint authentication

methods. Domain administrators conclude that the Fingerprint context meets the trust level’s

criteria directly, but they determine that the Password and E-token contexts must be combined to

achieve an equivalent level of trustworthiness. The “HighSecurity” trust level definition

documents these policy decisions. In other words, administrators regard the Fingerprint and

Password+E-token authentication contexts as equally trustworthy and worthy of a trust level value

of 3.0 relative to other local contexts. We assume that some resource services in the local domain

20

maintain access policies that require the “HighSecurity” trust level. These policies mandate that

access requests contain authentication tokens with a trust level of “HighSecurity” or higher before a

service can accept a requestor’s identity claims.

Trust Level Definition Names:

Intelligent programming practices encourage the use of constant variable references instead of

inline values within program code. Similarly, this system references a trust level using its name

rather than its absolute numerical value. This approach is useful for the following reasons:

- Administrators can change the internal specifics of context definitions without affecting

domain policies as long as the changes do not affect the context’s trust level.

- Services can contact trust authorities to reference the most up-to-date definitions associated

with a name, to obtain a list of acceptable contexts associated with a definition, and to

compare the relative trustworthiness of a trust level associated with a principle’s identity

claims and a trust level associated with an access policy.

Additional Trust Level Characteristics:

The following list identifies additional characteristics of the proposed trust level scheme:

• The actual value definitions of trust levels may be arbitrary; however, the relative

trustworthiness of various levels and contexts (as perceived or designated by administrators

of a given trust domain) should be preserved in the scheme.

• Resource services can specify trust level requirements in their security policies. For example,

a certain web service may require all requestors to be authenticated with a trust level of

“MediumSecurity” or “PatientRecordSecurity” or higher. These names reference trust level

definitions hosted by the local domain’s trust authority. Given the trust level name of an

21

authentication context and the trust level name in a policy assertion, the trust authority can

reference its trust level definitions and determine the relative trustworthiness of the two trust

levels.

• Resource security policies can choose to specify actual authentication context requirements

instead of or in addition to general trust level requirements. For example, an individual

policy may choose to accept certain contexts linked to a trust level definition, but not others.

• Trust level definitions can include one or more authentication context definition references

and/or combinations of context references. These definitions can also include references to

other trust level definitions (e.g., a combination of two trust level definitions).

• A trust level may incorporate combinations/summations of multiple authentication contexts.

For example, a trust level of 3.0 could be satisfied by fingerprint authentication alone or by a

combination of both password and e-token authentication.

• Trust level and context definitions should be standardized at least within a local trust domain

(i.e., the domain served by a single authentication authority). A trust authority in the local

trust domain should maintain trust level and context definitions so that designations are

consistent across the entire local trust domain. Trust levels and contexts may be

standardized by hierarchies of trust authorities or perhaps by a central, widely-recognized

trust authority. Policies should exist within each lower hierarchy and local domain on how

to map a trust authority’s trust level and context definitions and designations to those of the

local domain.

• Domain administrators must determine domain-consistent policy procedures for adding,

modifying, and deleting trust level definitions. For example, if resource access policies in a

domain actively reference a trust level definition called “HighestSecurity,” administrators

must determine a consistent procedure to follow when adding new trust level definitions.

22

Specifically, for example, if the domain adopts a new, supported authentication method,

should this method become a new context requirement for the existing “HighestSecurity”

trust level, or should administrators create a new trust level above the “HightestSecurity”

level that incorporates this context? Trust authority and policy administrators must agree

upon an acceptable approach for this issue.

• Trust authorities should have policies for mapping outside trust level and context definitions

to definitions consistent with the trust level scheme of the local trust domain. A particular

trust level or context in one domain may map to a higher or lower trust level in a second

domain, depending on existing trust relationships and associated policies defined for the

various trust domains. For example, the trust authority for domain A may map domain B’s

trust level 3 designation to a trust level of 2; however, the authority for domain A may map

domain C’s trust level three designation to a trust level of 1.

Please see the Future Work section of this paper for additional details about trust levels and trust

vectors.

Trust Establishment

In the scenario above, we assumed that a trust relationship already existed between domains

A and B. The following discussion describes how to establish such a trust relationship. First,

following business security policies and procedures, administrators in each domain independently

identify the authentication contexts and methods supported in the local system. Then, domain

administrators write SAML-extended XML definition documents for each context. Administrators

also determine the trustworthiness of contexts and assign a name and relative trust level to each

context definition. Next, if these definitions are intended for public use and inter-domain

23

federation, they publish them on the domain’s publicly-accessible trust authority. Administrators

also publish a trust level definition document for the domain, which includes an XML description of

each trust level’s security characteristics and list of contexts. Within each domain, administrators

develop local policy documents for every web service resource (written using WS-Policy or

XACML). Some services may require more secure/trustworthy authentication mechanisms than

others. Thus, access control policies may include context and/or trust level requirements. We

assume that all resource policies at least minimally require a digitally signed security token issued by

the local authentication authority to accompany any request. This process will be described in more

detail in the implementation section below. Once domain administrators have created definitions

for authentication contexts and written policy requirements for resource services, authentication

access control can function in the local domain. At this point, domain administrators have also

completed the necessary preparations to facilitate inter-domain trust establishment.

Trust establishment between domains begins with business negotiations. To enable identity

federation, each domain must write access control and mapping policies that define the terms of its

trust relationships with other domains. These policies, which are interpreted and enforced by each

domain’s local authentication authority, specify the terms for accepting identity claims from remote

domains into the local system. Specifically, mapping policies specify how authentication

information, such as UserIDs, context definitions, attributes, and trust levels, map from a remote

domain to the local domain. Trust level mappings indicate the amount of trust granted to principles

from remote domains. Trust relationships between domains can be liberal or conservative based on

these mappings. As noted before, we assume that resource services implicitly trust the

authentication decisions of their local domain authority.

When an individual domain creates a mapping policy for another domain, a one-way trust

relationship exists. Both domains must establish policies for two-way trust. Domain administrators

24

determine the specifics of mapping policies by referencing and comparing the context and trust level

definitions for both the local and remote domains. Domains can publish these XML definitions

publicly on their trust authorities, allowing domains to compare remote definitions with their own

contexts to determine appropriate mappings.

Why Trust Levels Are Useful

Trust levels describe the relative trustworthiness of authentication contexts in a domain.

Ideally, access policies should not be concerned with the details of a context, but only with its

relative trustworthiness. Abstracting authentication trustworthiness away from specific context

descriptions is useful for several reasons:

- Within a single domain, use of trust levels eliminates the need for individual resource access

control policies to reference the details of particular context definitions. On a basic level,

resource services are not directly concerned with the details of a particular authentication

process; this information is needed only in so far as it helps determine the trustworthiness of

a requestor’s identity claims. However, if this determination is first made by a trusted

authority, such as a domain’s recognized authentication authority, resource services can

simply trust this authority’s judgment, which is reflected as a trust level assertion. Then, a

resource must only determine whether the trust level asserted about an identity meets its

policy requirements.

- Use of trust levels abstracts, encapsulates, and separates the details of context definitions

into different bins of trustworthiness. With this approach, only a few entities in each

domain, including the authentication authority and trust authority, must deal with the

specifics of context definitions. If context definitions change, domain administrators must

25

reevaluate the definitions and revise the trust level assertions associated with them as

appropriate. Individual resource services can remain oblivious to the implementation details

of contexts if they trust the local authority.

Possible Mapping Implementations

A variety of possible mapping policy implementations exist in this system. Below, we review

several possible schemes using combinations of trust level definition and context definition

mappings. We do not make any absolute value judgments on the particular usefulness of these

techniques.

Trust Level to Trust Level Mapping

Trust Level to Trust Level Mapping involves mapping a trust level definition from a remote

domain to a trust level definition in the local domain. Mapping is necessary because the

determination of trust levels and relative trustworthiness is domain-specific. Domain administrators

define policy documents that specify these mappings, and authentication authorities interpret these

documents and enforce them. This approach abstracts away references to specific authentication

context definitions in each domain and considers only the relative trustworthiness of contexts. If

two contexts share the same trust level, domain administrators assert that these contexts are equally

trustworthy in the local domain. Thus, for example, one domain supporting five authentication

context definitions could group these contexts into five or fewer trust level designations (grouping

two contexts into the same trust level asserts that they share the same relative trustworthiness in the

local domain).

Trust Level to Trust Level Mapping is potentially useful for low-security applications across

domains or for communications among highly trusted partners, including intra-domain

26

communications and interactions among close business associates. The scheme is also potentially

effective in general trust establishment situations when detailed trust level definitions exist or when

standardized trust level definitions from commonly trusted authorities are in use. However, for

other situations, the mapping process is likely to be less useful because of the following concerns:

- If detailed trust level definitions do not exist: Unless a high level of trust already exists

between two domains, how can domain administrators determine mapping between abstract

trust levels without examining the specific context definitions associated with each trust

level?

- How do domains communicate changes in authentication contexts and methods to other

domains when these changes do not affect publicly available trust level definitions? How do

domains trust the general updating and reporting of context definitions and trust level

definitions across domains?

- How does one domain trust that another domain will legitimately authenticate a user before

assigning it an appropriate trust level? How can one domain guarantee that another domain

has followed and verified the context requirements that it asserts? Is third-party auditing,

standardization, and certification possible?

Note that Trust Level to Trust Level Mapping may be useful for low-security applications. For

example, one domain may grant limited trust to another domain’s authentication assertions by

mapping them automatically to a low trust level in its local domain. Also, note that the Trust Level

to Trust Level Mapping scheme may facilitate dynamic trust as described in the Future Work section

of this paper. For example, one domain may trust the identity assertions of another even if an

explicit trust relationship does not exist between the two domains if both of them support

standardized trust level or trust group definitions.

27

Context to Trust Level Mapping

Context to Trust Level Mapping involves mapping a context definition from a remote

domain to a trust level in the local domain. In this case, domain administrators evaluate the

trustworthiness of a remote domain’s context definitions and assign trust level values to them for

local use. Administrators can compare these remote context definitions to local definitions and

determine their relative trustworthiness in the system. Like above, this mapping is also expressed as

a policy document enforced by the local authority. Thus, when a user attempts to pass from a

foreign domain into the local domain (we assume that a trust relationship exists between the two

domains), the local authentication authority checks the authentication context associated with the

user’s identity claims and maps the context to an appropriate trust level in the local domain based on

mappings defined in the access policy. Note that the trust authority in each domain publishes

authentication context and trust level definitions for reference by other domains.

This paper maintains that the Context to Trust Level approach is the most practical mapping

scenario for inter-domain trust establishment. It is useful for several reasons:

- Unlike with Trust Level to Trust Level mapping, domain administrators have direct access to

remote context definitions with this mapping scheme. Thus, as long as administrators are

confident in the context information provided by the remote domain, they can evaluate a

context definition and make their own determination on its trustworthiness compared to

other local contexts. With Trust Level to Trust Level mapping, administrators do not have

access to remote context definitions, only remote trust level assertions. It is difficult to

determine appropriate mappings between trust levels across domains without context

definitions (unless comprehensive trust level definitions are available), as a trust level is

meaningful only as a value relative to other trust levels in a particular domain.

28

- One domain can modify its trust relationship with another domain as new remote contexts

become available or as existing remote context definitions change. With direct access to

remote context descriptions, a domain can make mapping decisions at any time based on

explicit context information. In contrast, the layer of abstraction afforded by trust levels

removes this direct access to context information. Trust levels are more versatile, but they

reduce detail and thus necessitate an added layer of implicit trust between two domains.

Concerns:

- In order for this mapping scheme to function effectively, domains must adopt a

standardized language for describing authentication contexts. Thus, this paper suggests the

development and use of a standardized, extended version of SAML for this purpose.

- In the current scheme, neither changes to context and trust level definitions nor notifications

of these events in one domain automatically propagate to other domains that reference

them. In other words, updates are available if pulled from a domain’s trust authority, but

they are not pushed automatically to dependent users. Further research is needed to explore

possible solutions for actively notifying other domains of definition changes. Note,

however, that trust level and context definitions do have simple creation and expiration

dates. [possible example – discover authentication flaw, need to propagate to trusted

partners]

29

Other Possible Mapping Schemes:

Trust Level to Context Mapping

This mapping is unlikely to be useful because it involves mapping a relative, abstract value

from one domain to a specific definition in another domain.

Context to Context Mapping

This mapping is unlikely to be useful because context definitions contain detailed

information about specific authentication contexts which cannot be mapped directly to other

context definitions unless the definitions are identical (or sufficiently similar to satisfy a domain’s

policy requirements).

30

Introduction to Trust Authorities

In the system described above, trust authorities maintain repositories of context, context

class, trust level, trust group (this term will be discussed in the Future Work section), and policy

definitions for one or more trust domains. They respond to definition inquiries from requestors and

send digitally-signed replies. With access to authentication context and trust level definitions, trust

authorities can evaluate the relative trustworthiness of combinations of trust level or authentication

context names. For example, the policy enforcement point of a resource service may contact a

domain’s trust authority to compare the relative trustworthiness of a particular token’s trust level

with the trust level specified in its policy document.

Trust authorities may be widely trusted and recognized, similar to the way that certificate

authorities such as VeriSign are trusted, or they may be local for individual domains or groups of

domains. Thus, networks and hierarchies of trust authorities may exist. Trust authorities provide

interfaces for entities to establish, to update, and to reference definitions (and also policies, if a

domain shares them). Trust authorities standardize the most recent versions of such definitions and

policies within domains and groups of domains so that they are interpreted consistently. In some

ways, the responsibilities of trust authorities resemble those of a distribute file system server that

maintains access permissions and versioning.

Entities may choose to publish their context, context class, trust level, and trust group

definitions publicly via a trust authority. Public definitions specify a domain’s basic requirements for

negotiating new trust relationships. When hosted by well-recognized trust authorities, they also help

standardize basic context, trust level, and trust group definitions for classes of business or

government transactions, etc.

Groups of entities may also establish a trust authority to manage a common set of context,

context class, and trust level definitions and security requirements. Entities may consult these

31

documents whenever conducting business with members of this group to determine the appropriate

communication and security procedures to follow.

32

Implementing Simple Trust Relationships

So that users do not have to authenticate their identities each time they access distributed

resources within a domain, administrators can specify security policies that establish implicit trust

relationships between services and a local security token service (STS) authentication authority. An

STS is a web service that authenticates principles and issues signed security tokens, which are

collections of one or more claims asserted about authenticated identities. An STS evaluates a

principle’s “proofs of possession” during authentication, and it determines whether to trust its

identity claims and thus to issue the principle a signed security token asserting this identity to

services and authorities that trust the STS (see the term’s definition in the glossary for more

information).

As shown in Figure 1, we assume that all web services in a single trust domain are configured

to trust security tokens issued and digitally signed by the domain’s local STS. Thus, before a client

attempts to access a secure resource, it first contacts the local security token service for the

resource’s domain to request a token. Upon successful client authentication, the security token

service issues the user a signed security token. Subsequently, the client can embed this security

token in web service requests within the domain. If the resource service’s security policy trusts

tokens signed by the local authority, the service can accept the identity claims contained in the

client’s token and proceed to the authorization process. If the authenticated user has permission to

access the requested resource, the web service can respond appropriately. Note that the client can

present its security token on subsequent requests to services in the local trust domain without

reauthenticating with the STS until the token expires.

33

Figure 1: Basic Trust Relationship

This figure shows the basic scope of trust between a client, an STS, and a service in a trust domain (Smith).

The process described above becomes more complicated when communications cross

organizational boundaries. Consider two separate organizations (i.e., two separate trust domains)

that share a preexisting trust relationship. We assume that policies for services in each domain

require requestors to hold security tokens issued by their respective local security token services.

Thus, if a client from one domain contacts a service in a second domain, the process takes the

following steps as shown in Figure 2: the client sends claims and proof-of-possession information

to its local security token service and requests a security token. Upon successful authentication, the

security token service issues the client a signed security token. At this point, the client can use this

token to access services in the local trust domain; however, in this case, the client intends to access a

remote resource. As stated earlier, the two security token services in this scenario have a previously

established trust relationship, which is reflected in each of their security policies. In order to access

a resource in the other trust domain, the client must acquire a security token from the resource

34

domain’s security token service. When the client contacts the remote STS, it presents the security

token from its local STS. The resource domain’s STS checks its security policy to determine how to

handle the client’s request based on the established trust relationship. If the policy permits, the STS

issues a signed security token to the client, which it can then use to access resources in the remote

service’s trust domain. The queried resource follows an authorization policy before fulfilling the

client’s request.

Figure 2: Basic “Direct Trust” Federation

This figure shows a basic federated trust relationship between two trust domains (Kaler “WS-Federation”).

Overview of Core Web Service Technologies

Three primary technologies form the foundational layer upon which to build web services.

These are the Simple Object Access Protocol (SOAP), the Web Services Description Language

(WSDL), and Universal Description, Discovery, and Integration (UDDI). Web services use SOAP

to communicate. This protocol specifies the format and content for messages exchanged between

web services (Gudgin 1). WSDL standardizes how organizations describe the capabilities and

functionality of their web services. WSDL documents publish public interfaces for web services.

35

Potential clients can use this information to determine whether a certain web service satisfies their

needs. Developers also reference WSDL documents when creating applications that interact with

web services (Christensen 1). UDDI defines a “whitepage directory” of web services that allows

clients to search for services that suit their needs (Wolter 1).

Overview of Supporting WS Specifications

While initial core web service technologies did not support security, OASIS and other

standards consortiums and groups of companies have suggested several new specifications to

address many of the security scenarios discussed previously. The WS-Security specification defines

mechanisms for protecting web service communications, including the use of encryption and digital

signatures to protect message integrity and confidentiality (Kaler “WS-Security” 1). The WS-Trust

specification suggests methods for exchanging security tokens between web services (Kaler “WS-

Trust” 1). WS-Policy and WS-SecurityPolicy specify how web services can express policies

regarding their security practices and requirements (Hondo “WS-Policy” 1). WS-Federation, using

WS-Trust as a protocol for communicating trust, discusses how to broker trust relationships

between web services across organizational and business boundaries (Kaler “WS-Federation” 1).

WS-SecureConversation proposes an end-to-end solution for maintaining message confidentiality.

A variety of other supporting specifications also exist, and some have yet to be written (Kaler “WS-

SecureConversation” 1).

36

[This section needs updates]

Research Community Contributions

Because web services are a new technology and the development of related security

standards is an ongoing process, there are many current research projects on the topic. A group of

researchers from Hewlett Packard Laboratories published a paper on creating third-party trust

services for web service systems. The paper identified the advantages of reusing commonly

implemented trust and security mechanisms via web services, and it also argued that software

engineering practices should be expanded to consider the operational aspects of these service

components. While the Hewlett Packard paper does not suggest specific solutions to the problem,

this thesis proposes a system architecture based on trust levels, trust groups, and trust authorities

that addresses several related concerns (Baldwin 507).

Research at the University of Vermont identified two primary impacts of web services on

companies in the technology industry: “1. outsourcing many traditional IT activities as credible and

reliable providers of services emerge; and 2. leveraging internal capacities to design distinctive web

services that can be sold to other organizations” (Ratnasingam 5). Referring to technology trust

issues related to web services, University of Vermont Professor Pauline Ratnasingam suggests, “For

any web services scheme to work, attention must be paid to rigorous authentication, integrity, non-

repudiation, encryption, and security matters that enforce technology trust” (Ratnasingam 6).

37

Importance of Context Information in Implementation

As discussed in Chapter Two, if a user or service demonstrates sufficient proof of identity to

a security token service authority (i.e. sufficient proof to satisfy its security policy), the STS can

choose to accept the credentials provided by the user, to verify them, and subsequently to issue a

signed security token to the user for use in its local trust domain. Various types of security tokens

exist, including x.509, Kerberos, and XML-based tokens, such as a Security Assertion Markup

Language (SAML) token (Hondo “WS-Policy” 1). After obtaining a local STS-issued token, the

client can embed it within web service requests as proof of identity.

Without having contextual information about the authentication process, a resource cannot

distinguish between a security token issued with password authentication and a token issued with

fingerprint authentication. Thus, an individual resource’s security policy cannot require that

requestor tokens meet a minimum level of identity authentication trustworthiness beyond what is

minimally required by the local authentication authority (the STS).

This problem is particularly evident in situations involving multiple trust domains. For

example, assume that STS-A in domain A and STS-B in domain B have previously established a

mutual trust relationship. Now, suppose that a user in domain A authenticates with STS-A and then

attempts to access a resource web service in domain B. Following simple federation procedures as

discussed previously, assume that the resource requires each requestor to have a security token

signed by its local STS authority before it will attempt to authorize the user for access. Thus, the

user must present its token from STS-A to STS-B for token exchange to obtain a locally issued

token for domain B. Based on previous business negotiations, STS-B’s security policy specifies

whether it will trust security tokens issued by STS-A. However, unless STS-A provides

authentication context and trust level information with its tokens, STS-B cannot condition this

38

decision based upon the trustworthiness of the particular authentication mechanisms employed by

STS-A to verify the identity of the user. What if STS-A’s authentication mechanism is acceptable

for certain resource services within STS-B’s domain, but not for others? What if STS-A changes its

mechanisms for authenticating users but does not notify STS-B? Without authentication context

and trust level information to process, STS-B must simply choose either to accept or to reject STS-

A’s identity assertions. This decision cannot depend on the context of the identity verification

process in domain A.

39

Sample Token and Context Class Descriptions

Domain Security Token Services (STSs) issue SAML-compliant security tokens extended

with TrustLevel support. These XML security tokens contain a collection of SAML assertions.

SAML-Compliant Token

• The token contains a collection of SAML Assertions, including a unique identifier for the

principle, creation and expiration times, etc.

• It references an authentication context class whose definition (schema) is hosted on the

issuing domain’s trust authority.

• It contains a SAML-extended element called TrustLevel that identifies the token’s

authentication trust level in the issuing domain. The TrustLevel value is a unique name

(string) which references a trust level definition hosted on the issuing domain’s trust

authority. This trust authority can evaluate the relative trustworthiness of the token’s trust

level compared to other trust levels supported in the local domain (e.g., the minimum trust

level required by a service’s access policy in the local domain). The trust level name may

correspond to the name of the token’s authentication context class. The issuing domain’s

trust authority web service accepts authentication context names and trust level names and

returns either their XML definitions or evaluations of their relative trustworthiness

compared to other definitions.

• It contains another SAML-extended element called TrustAuthority which identifies the URL

of the trust authority that hosts the context class definitions and trust level definitions

referenced in the token.

40

Authentication Context Class

• This class implements an instance of a custom Authentication Context Class schema.

• It contains a collection of SAML assertions.

• It contains a SAML-extended element called TrustLevel which identifies the relative

trustworthiness of the authentication context class compared to other contexts supported in

the domain. The TrustLevel value is a name (string) which references a trust level definition

hosted by the local domain’s trust authority.

[Attachment: Example XML for Token and Context Class]

41

Future Work

This section discusses extensions to our current system implementation. Our research group

aims to incorporate many of these ideas into the next generation of our system. The improvements

primarily focus on facilitating dynamic trust and expanding context and trust level definition

descriptions.

Introduction to Trust Groups

BACKGROUND AND MOTIVATIONS

Services in various domains trust each other because of previously established trust

relationships. These trust relationships, defined in each service’s policy document, identify how a

service should handle requests from other principles. Because we assume that all services in a trust

domain implicitly require requestors to have security tokens issued by the domain’s local STS, the

STS is ultimately responsible for evaluating possible trust relationships, issuing security tokens, and

making policy decisions (e.g., mapping contexts and trust levels to the local domain) based on these

trust relationships. A fundamental question, however, is how are these trust relationships

established between domains initially? From a business perspective, it is likely that forming a trust

relationship with another organization first involves negotiating contracts and business agreements

before it reaches the technical implementation stage. Subsequently, administrators or designers must

manually document such relationships in policy documents using the WS-Policy and WS-

SecurityPolicy specifications (Nadalin “WS-SecurityPolicy” 1) or XACML. As stated previously in

the Introduction, considering the large number of interactions in future distributed web service

systems, it may be impractical for administrators of one domain to write such policy documents

42

manually for all partners, especially the minor ones. Thus, this paper proposes the use of trust

groups, in part, to facilitate dynamic trust relationships.

As discussed below, a second motivation for the use of trust groups is that they provide an

easy, practical, and powerful mechanism for consolidating context and trust level definitions and

other security requirements for groups of web services and domains.

PROPOSED TRUST GROUPS CONCEPT

This architecture proposes the use of trust groups to address the issues discussed above. A

trust group can be described as a collection of security requirements agreed upon by administrators

for a group of trust domains and claimed or validated by a trust authority. These security

requirements could include minimum context and trust level criteria, policy requirements specified

using WS-Policy and WS-SecurityPolicy (e.g., requiring the use of a certain encryption algorithm as

described in WS-Security) or XACML, and other custom membership policy claims. Custom

membership policy claims may include custom-defined and custom-enforced metrics such as

rankings, reliability levels, privacy categories, data update frequency values, domain namespaces,

membership lists, supported platforms, etc. Such criteria are largely subjective; however, if trust

group members define them in such a way that trust authorities can validate their compliance among

members (automatically or manually, perhaps through an application or auditing process), they can

be useful in enabling dynamically established trust relationships.

This paper defines dynamically established trust relationships as those in which there is no

need for administrators to create explicit policies to govern trust relationships. Rather, for example,

an STS’s policy can specify that it requires a requestor to have a security token with a minimum trust

level (as assigned by a recognized and trusted authority) or have membership in a certain trust group

before it will issue it a local security token (or at least a security token with a higher trust level). In

43

this case, the local STS may not be directly familiar (i.e. have a specific trust relationship) with the

particular foreign STS that signs the requestor’s security token. However, if the local STS can obtain

verifiable attribute information about the foreign STS from a trusted trust authority, then its policy

may instruct the local STS to trust the token and its associated identify claims (at least for a low trust

level value) and to issue the requestor a local security token. This description makes an important

distinction between trusting an authority that asserts the trustworthiness of a domain (i.e., explicit

trust, which may be direct or indirect via a third-party trust authority) and trusting an authority that

verifies information about a domain. The trust authority does not assert direct claims about the

trustworthiness of a domain; rather, the inquiring entity is free to make its own conclusions based on

the provided information (i.e., dynamic trust). It is likely that dynamic trust would not be practical

for high-security, privacy-sensitive scenarios. Likewise, it would also probably not be useful for

establishing trust with large, important partners. Rather, dynamic trust could be used for frequent,

low-priority and low-risk trust relationships, such as those described below.

Consider the procedure for establishing dynamic trust in the following scenario. Assume

that the University of Virginia Health System has previously established business trust relationships

with several pharmacies, including CVS, Revco, and Wal-mart. Thus, if web services hosted by

these three entities present security tokens signed by their respective STSs to the local health

system’s STS, they can obtain locally issued tokens for the UVA Health System domain in

accordance with the domain’s policy requirements. Then, if authorized, these requestors can

communicate with services in the UVA Health System trust domain.

In order to simplify the process of establishing trust relationships with health systems, also

assume that a recognized consortium of pharmacies has created a trust group with certain

membership requirements that it has defined and hosted with a recognized trust authority. This

trust group defines minimum security and privacy requirements for participating domains, and it

44

requires new candidates to apply for membership and to participate in a thorough auditing process

for compliance before gaining membership in the group. If a new candidate successfully meets the

membership requirements, the trust group administrator can contact the trust authority and add it to

the list of members in the trust group.

The UVA Health System decides that it trusts the pharmacy consortium to evaluate its

members. Thus, in order to benefit its customers and patients who use several of the pharmacies in

the consortium, UVA decides to grant a minimum level of trust (e.g., a trust level of one) to all

members of the consortium’s trust group. The UVA Health System can contact the trust authority,

which it also trusts and through which the consortium created its trust group, to verify certain

member lists and membership requirements. Thus, if a request accesses the UVA Health System

domain with a security token signed by a foreign STS that is a member of the trust group, the local

STS can grant the service a local security token (at an appropriate trust level as specified in its policy)

even though the local domain does not have an explicit trust relationship (neither direct nor indirect)

with the foreign domain. This is an example of a dynamic trust relationship. Note that the local

STS may condition issuing the token on a variety of factors related to the original security token,

including the associated trust level, trust group, issue time, etc.

In addition to facilitating dynamic trust, trust groups are also useful because they allow

entities to consolidate and to standardize trust level definitions and other security requirements for

groups of partners through a commonly trusted trust authority. Rather than including a list of

members, a domain may simply use a trust group to specify security requirements for potential

partners and trust relationships.

The proposed conception of a trust group is broader than that of a SAML authentication

context class. Context classes are useful for standardizing and referencing collections of

authentication context requirements. They are especially useful for grouping context requirements

45

based on common industry practices and technologies. Like a trust level definition, however, a trust

group is a broader representation of trust. Trust groups may include one or more context class

definitions. A trust group is simply an agreement in which members choose to use common context

definitions and trust level definitions for communications within the group. When one trust group

member encounters the security assertions of another member, the first member can choose to trust

the second’s assertions (with a certain level of trust) based simply on what it knows about the

domain from its trust group membership. This decision can be made independently of any explicit

trust relationship between the two domains. In this sense, trust groups enable dynamic trust.

Trust Level Vectors

Future extensions of the trust level concept could incorporate a variety of additional metrics about

authentication trustworthiness. Some of these ideas are listed below:

- Trust Levels could represent more than just relative trustworthiness as a linear concept.

Trust Levels could incorporate a vector of values that describe different aspects of relative

trustworthiness, including biometric trustworthiness, what-you-have/know trustworthiness,

trustworthiness based on access method or origin (e.g., mobile access, remote/local access,

etc.), trustworthiness based on degree of separation from original authentication point, etc.

- Rather than simply indicating whether one trust level is relatively more secure than another,

the system could be expanded to measure and also to convey by some more robust means of

quantification how much one level is relatively more or less secure than another. Note that

trust level definitions in the current implementation include floating point values which

quantify their relative levels of trust in the domain. However, this value in inconsequential

beyond its use in determining whether one level is more or less trustworthy than another

unless domain administrators apply a standard method for measuring and assigning

46

numerical values to trust levels. For example, in the current system, the difference in

trustworthiness between trust levels three and two is not necessarily the same as the

difference between trust levels two and one.

- Trust authorities could standardize and regulate trust levels. Then, fewer questions and

discrepancies about relative interpretations of trust would arise.

47

GLOSSARY OF TERMS

Claim A claim is a declaration made by an entity (e.g. name, identity, key,

group, privilege, capability, attribute, etc).

Direct Trust Direct trust is when a relying party accepts as true all (or some subset of) the claims in the token sent by the requestor.

Direct Brokered Trust Direct Brokered Trust is when one party trusts a second party who, in turn, trusts or vouches for, the claims of a third party.

Federation A federation is a collection of realms that have established trust. The level of trust may vary, but typically includes authentication and may include authorization.

Indirect Brokered Trust Indirect Brokered Trust is a variation on direct brokered trust where the second party can not immediately validate the claims of the third party to the first party and negotiates with the third party, or additional parties, to validate the claims and assess the trust of the third party.

Security Token A security token represents a collection of claims.

Signed Security Token A signed security token is a security token that is asserted and cryptographically signed by a specific authority (e.g. an X.509 certificate or a Kerberos ticket)

Proof-of-Possession Proof-of-possession is authentication data that is provided with a message to prove that the message was sent and or created by a claimed identity.

Signature A signature is a value computed with a cryptographic algorithm and bound to data in such a way that intended recipients of the data can use the signature to verify that the data has not been altered since it was signed by the signer.

Security Token Service (STS) A security token service is a Web service that issues security tokens (see WS-Security). That is, it makes assertions based on evidence that it trusts, to whoever trusts it. To communicate trust, a service requires proof, such as a security token or set of security tokens, and issues a security token with its own trust statement (note that for some security token formats this can just be a re-issuance or co-signature). This forms the basis of trust brokering.

Trust Trust is the characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make set of assertions about a set of subjects and/or scopes.

Trust Domain/Realm A Trust Domain/Realm is an administered security space in which the source and target of a request can determine and agree whether particular sets of credentials from a source satisfy the relevant security policies of the target. The target may defer the trust decision to a third party (if this has been established as part of the agreement) thus including the trusted third party in the Trust Realm.

*Terms and Definitions from Kaler, Chris, et al. “Web Services Federation Language (WS-Federation).” Online

article, 8 July 2003. IBM, Microsoft, RSA Security Inc., and VeriSign. 22 March 2004. <http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-federation.asp>.