Abstract

This document is a product of the FI Work Group, but strongly related to the IAWG as well. It defines the constellations and use cases of Identity Federations to have a good understanding of the system under discussion when refining the scope.

Status and open issues

This document is currently under active development. Its latest version can always be found here. See the GI:Change History at the end of this document for its revision number.

1. Incomplete constellations: C21, C22, C30, C70, C90, C100
2. Discussion, if abuse-cases (C99) add value in this context, or should be moved elsewhere.
3. Align UMA Scenarios and Use Cases

Editors

Rainer Hörbe

Intellectual Property Notice

The FI Work Group operates under Creative Commons Share-Alike Attribution IPR Option and the publication of this document is governed by the policies outlined in this option.

Table of Contents

Introduction

This documents describes a set of identity management constellations to define the scope for the Federation Interoperability and IAF. Each constellation is a collection of business level use cases. Starting with a well-known baseline constellation of 3 actors (Subject, Identity Provider and Relying Party), derived constellations shall reflect variants of actors and their trust relationships by adding following aspects:

1. Completeness of trust model: Trust establishment, subject life cycle management
2. Actor centricity: Depending on the background, users, service providers or network operators might shape the constellation.
3. Jurisdictional structure:
   • Intra-organizational (single policy authority, centralized enforcement)
   • Cross-organizational (single policy authority, negotiated between autonomous actors)
   • Federation (shared or external policy authority)
   • Cross-border (across multiple national legislations)
   • Grid/cloud: is it a different structure?
4. AA (Attribute Authority) different from IdP
5. Organizational context: Enterprise user vs. consumer/natural person
6. Subject class: human user vs. device/service
7. Trust type: peer to peer, hierarchy/trust anchor, reputation based.
8. Type of communication payload: document-centric vs. session-centric (or both in case of messaging)
9. Restriction to electronic communication vs. physical access
10. Off-line mapping of EAA policies vs. automated policy negotiation in real-time
11. Relation of verifier to other actors

Trust Relationships in Federated Identity Management (Pending)

A common interpretation of trust in an identity federation is that a RP trusts the IdP to provide entity authentication at an expected assurance level. However, this view is provider-centric and incomplete, as there are several trust relationships involved:

	Asserting Actor	Trusting Actor	Kind of trust
TR-1-EntityAuthN	IdP	RP	entity authentication (including identity proofing in this context)
TR-2-IdPAvailibility	IdP	RP	short-term and long-term availability of the service
TR-3-3rdPartyDP	User	RP	data protection of content that is owned by the RP or 3rd parties and that this content is only transmitted to the authenticated user
TR-4-UserSec	User	IdP	the user's obligations to secure the authentication process (e.g. not give away credentials)
TR-5-PII@IdP-Prot	IdP	User	proper handling of PII given away in the registration process and collected at authentication time, including not abusing assertions to impersonate the user
TR-6-IDM-PII@RP	RP	User	proper handling of PII that was released with the identity assertion (might be indirectly via the IdP)
TR-7-Service-DP@RP	RP	User	data protection of content that owned by the user
TR-8-RP-Maleware	RP	User	client protection from malware in a used service
TR-9-RP2FO	FO	RP	providing the trust anchor, federation meta data and supervising the IdP
TR-10-IdP2FO	FO	IdP	providing the trust anchor and federation meta data
TR-11-RP2Ver	Ver	RP	execute authentication protocol
TR-12-IdP2RP2	RP	IdP	pay for identity service per usage
UMA			UMA-specific TR are being worked on; Terms are still different (user/subject, Host/RP)

The second and third column show how unidirectional trust relationships are defined in between actors. Not all of these trust relationships are usually associated with the term Identity Management, but are required to fulfill the complete set of security and privacy requirements by all actors.

Constellations

Constellation C01: Delegated Authentication (Pending)

This view primarily shows the separation of identity services from the RP’s service.

Prerequisite

• Subject is subscribed to IdP service
• RP delegated subject authentication (including registration) to IdP

Description

• A subject is requesting access to a resource owned by RP
• RP is delegating authentication to IdP
• IdP will require authentication from subject, or use a valid previously authenticated session
• IdP will assert the authentication event, and possibly include subject attributes for the RP
• IdP will deliver the assertion to the RP
• RP will grant subject access to the requested resource

Trust Relationships

Even though this constellation has a minimalistic view on identity management, most trust relationships can be shown:

• TR-1-EntityAuthN
• TR-2-IdPAvailibility
• TR-3-3rdPartyDP
• TR-4-UserSec
• TR-5-PII@IdP-Prot
• TR-6-IDM-PII@RP
• TR-7-Service-DP@RP
• TR-8-RP-Maleware

Actors

IdP (Identity Provider), RP (Relying Party), Subject
Any one of these actors can be primary actor.

Constellation C10: Delegated Identity Management (Pending)

Extends and completes Constellation C01

This constellation is more complete as it includes the registration of the subject to the IdP and the establishment of trust by the RP.

Actors

Inherited: IdP, RP, Subject
Subscriber, Registration Officer

Constellation C20: Service Provider Centric model (Pending)

Extends Constellation C01, shows aspect of actor centricity

This constellations is dominated by the demand to protect the assets of a service provider (as relying party), like application data. As Identity Management is an important part of the information security management, service providers are concerned that those functions that are delegated to IdPs are executed at the same or better level as the SP would do it on its own. As a consequence, the trust relationship requirements focus on:

• TR-1-EntityAuthN
• TR-2-IdPAvailibility
• TR-3-3rdPartyDP (This is frequently managed outside the trust federation with the RP’s Terms of Use.)

This view works well for the case when enterprise work on data owned by third parties and end user privacy is of little concern, like in typical B2B and G2G constellations.

Actors

RP (primary actor), IdP, subject

Constellation C21: User Centric model (to be completed)

Extends Constellation C01, shows aspect of actor centricity

This constellation is driven by the demand to protect the privacy of a user. As a consequence, priority is given to following trust relationships:

• TR-5-PII@IdP-Prot
• TR-6-IDM-PII@RP

The desired result is, that users can control and enforce various privacy and security policies governing the exchange of identity information and PII person-to self-type applications.

Actors

Subject (primary actor), IdP, RP

Constellation C22: Network-centric RP (to be completed)

Extends Constellation C01, shows aspect of actor centricity

The primary stakeholder in this constellation is a network operator which needs to protect the network (as relying party), like service and transport management functions in PSTN, mobile and IP/multimedia networks. Trust concerns have their priorities at

• TR-1-EntityAuthN and
• TR-2-IdPAvailibility

Actors

Inherited: IdP, RP, Subject

Constellation C23: IDP+SP-centric Federation Platform (to be completed)

Extends Constellation C01, shows aspect of IDP centricity

The primary stakeholder in this constellation is a dominant SP that offers identity- and attribute services to other SPs.

(Open Issue: This analysis of the Face Book scenario might be improved)

• TR-1-EntityAuthN and
• TR-2-IdPAvailibility

Actors

Inherited: IdP, RP, Subject

Constellation C30: Intra-organizational IDM, loosely coupled units (to be completed)

Extends Constellation C01, shows jurisdictional structure aspect

Some organizations have loosely coupled organizational units with certain autonomy. There is a single policy authority with some centralized enforcement, but functions of identity management and user provisioning are delegated to subunits.

This constellation blends the S32 Federation S31 Ruling Party constellations.

Constellation C31: Ruling Party IDM (pending)

Extends Constellation C01, shows jurisdictional structure aspect

By expanding the acronym RP to “Ruling Party” the whole constellation is almost explained.
Typically one company owns the roles of RP and IdP and is the sole authority for the access policy of its service. Although the autonomous actors are in theory free to negotiate the terms of use, in practice the organizations subscribing the service will have to take or leave the terms.

This is a degenerated constellation, as this federation is not a circle of trust, but a trust hierarchy. 

Actors:
Service Provider (acting both as IdP and RP) is primary actor; Subject
Secondary RPs (with less important services) may join, but are subject to the governance of the primary RP.

Constellation C32: Identity Federation (Pending)

Extends Constellation C10, shows aspect of jurisdictional structure

This constellation adds 2 major views:

1. Identity life cycle management (attribute updates, credential revocations)
2. Trust management (policy implementation, maintenance and enforcement)

Trust Relationships

As this federation makes the concepts of trust anchor, meta data and audit explicit, additional trust relationships are introduced:

• TR-9-RP2FO
• TR-10-IdP2FO

Actors

Inherited: IdP, RP, Subject, Subscriber, Registration Officer
Auditor, FO (Federation Operator), PMA (Policy Management Authority)

Constellation C33: Cross Border Identity Federation (pending)

Extends Constellation C32, shows aspect of jurisdictional structure

Key point is the federation across multiple national legislations. The trust framework must accommodate to different laws and a common set of federation-specific rules. The structures for policy management need to accommodate this fact. Another aspect can be the introduction of a trusted gateway that serves as a trust broker.

Sample case: the epSOS project, which provides health care professionals access to patient summaries and prescriptions across borders of European countries. The core system consists of a set of national gateways forming a circle of trust. At the point of care a query is sent to the national gateway, which brokers trust to the gateway of the country the patient is affiliated with.
above: picture from the epSOS architecture document D3.3.2 Abbreviations use: PoC: Point of Care; NCP: National Contact Point (gateway)
Trust replationships are the same as in C32 if no trust broker is used.

Constellation C35: 4-Corner Model (pending)

Extends Constellation C32. Federation contracts are between the IdP and Service Broker. Users contract with the IdP, and Relying Parties with the Service Broker.

Constellation C40: Attribute Provider separate from IdP (pending)

Extends Constellation C01, shows aspect where AA is different from IdP

Attribute providers (AP) are actors separate from IdPs, because of technical and/or business reasons. Business reasons:

• they have a different business model,
• are operated by a different legal entity (like the authoritative source), or
• there is only a partial overlap between the managed subjects.
  Technical reasons:
• Credentials are directly verified by the RP, e.g. when authenticating with a smartcard, but attributes are elsewhere.
• Attributes are queried later on demand, because the attribute list might be large, or a specific subset should be retrieved.

RP might need a trust relationship that is a subset of type TR-1. However, it is quite likely that contracts between RP and AA are different from those between RP and IdP, because if the AA is the only source of authority, there is no lever for the RP to require more than best effort. E.g. national law in most countries regulates the qualification of a medical doctor, so the attribute “ophthalmologist” can only be provided by the organization defined by law. Hence trust is based on the fact that the AA operates with due diligence and could be sued in case of a negligence, but there is no legal basis to require audits or other safeguards to prevent damages beyond unsolicitous agreements.

Actors

Inherited: IdP, RP, Subject
AA (Attribute Authority)

Constellation C41: Attribute Provider with RP

Extends Constellation C40, shows specific variant of C40, without introducing new actors.

The IdP only asserts persistent, unique IDs ("meaningless unique numbers") that are specific to a RP. Any additional attributes need to be vetted by the RP. If an entity is RP for multiple services, attributes may be shared across the entity's services.

This constellation is implemented in Canada to conform with Canadas privacy law.

Constellation C50: Enterprise user (pending)

Extends Constellation C01

Description

Primary Stakeholders in this constellation are the RP and UHO (User Home Organization, like an enterprise). The key difference to Constellation C20 (Service Provider Centric model) is that the subject is part of an organization with multiple roles. The legal counterpart to the RP is the UHO.
Identity management in the pure sense of authenticating a named subject may be delegated to an external entity, such as a CA, or can be part of the UHO.
Policy management in the sense that roles or more complex policies are assigned to subjects is best executed within the UHO, because it has the responsibility and knowledge to do this.

Example: RP is a hospital and provides an appointment service where external health care providers (HCP) can manage appointments for their clients. The application provides 3 attributes: Role (doctor, assistant, patient), department (<the list of medical departments>) and affiliation (HCP, self). The policy for a joint practice (ophthalmologist and GP) would look roughly like this:

• Doctor (ophthalmology) can manage appointments in the departments for eyes and internal medicine and add and review some medical data for her affiliated patients;
• Assistant may manage appointments for all departments (because she is assistant to the GP) for the surgery’s affiliated patients;
• Patient may view and cancel appointments related to herself.
  The doctors are responsible to assign roles within the joint practice and use an external policy management service to maintain electronic policies that can be consumed by other HCPs.
  When a user wants to perform a transaction on the appointment service, following sequence is executed:

• RP requires authentication
• User authenticates to IdP
• IdP asserts identity to RP
• RP requires policy (containing policy attributes related to the user)
• PDP asserts policy to RP
• RP takes access decision

Trust Relationship TR-3-3rdPartyDP is extended to cover the trust in policy management by the UHO.

Actors

Inherited: IdP, RP, Subject
UHO (User Home Organization), Subscriber, Policy Manager, Policy Decision Point, Registration Officer

Constellation C60: Subject Types (pending)

Extends C10 shows aspect of subject type

There are no new trust relationships. However, specific rules need to address the security challenges of autonomous devices, such as management of key material.

Actors

Inherited: IdP, RP, Subject, Subscriber;
Human subject, device/service

Constellation C70: Reputation-based Trust (t.b.d.)

Extends C32, shows aspect of trust type

The standard model is hierarchical trust. It requires some root authority, like a body issuing a self-signed trusted certificate. In most cases there are hidden or unspecified root authorities, like browser vendors with their pre-installed root certificates, or operating system vendors with preinstalled DNS root zone files.
Reputations-based systems have a process that will compute trust based on behavior of claimants and rating of members. This is not necessarily limited to humans, but could be used for IdPs and other roles in federation as well.

Actors

Constellation C80: Document-centric Transaction (pending)

Extends C01, showing aspect of payload type

Typical identity federation constellations like those describe above usually imply the session-centric model: subject authenticates to a network or an on-line service, establishes a security context performs the desired communication or transaction within this context.

Exchanging signed documents has the same basic trust relationships as the session-based model, but uses a different terminology for historical and technical reasons. The certificate authority is a case of an IdP, the document receiver who verifies the signature is a case of a relying party.

No additional trust relationships need to be added to the basic constellation.

Actors

Inherited: IdP, RP, Subject

Constellation C90: Physical Access (tbd)

Extends UC01, shows aspect of access type

Whereas all constellations mentioned above imply remote electronic authentication, the system might be applied to physical access as well. The apparatus controlling physical access could be seen as RP, so the constellation would fit to the trust federation.
However, there are some issues that suggest that identity federations should be limited to electronic communication, because

• Physical access is usually in the scope of a single enterprise, and
• Physical access might need a combination of electronic authentication and local supervision or check.

Constellation C100: Inter-Federation requiring automated policy negotiation (t.b.d.)

Extends C32, shows aspect of method of policy mapping

Actors

Inherited: IdP, RP, Subject

Constellation C110: Verifier with Relying Party (pending)

Extends C01, shows aspect of method of policy mapping

A verifier is an entity which executes the authentication protocol by validating the claimant’s credentials. The standard constellation derived from the SAML WebSSO-use case assumes that the verifier is part of the IdP. However, the PKI use cases needs the verifier to be (mostly) part of the RP. The subject authenticates to the RP using public key cryptography; just the certificate status check is using the IdP.
Another use case is the online-validation of a digital signature. A user submits a document to an online-validation service that executes the signature validation and returns the result to the user using a channel secured by TLS.

TR-11-RP2Ver is now explicit, but it would have been there in C02 already, if the role of the verifier would have been shown. It is always the RP who finally trusts the Verifier. If the Verifier is part of the IdP, it is a brokered trust with the IdP as intermediary.

Actors

Inherited: IdP, RP, Subject
Verifier

Constellation 99: Abuse Cases (pending)

Not sure if this document is a good place for this constellation. It shows typical attacks on trust relationships.

Extends Constellation C32

Actors

(Inherited) + Internal and external attackers

TO DO

Compare this document with OASIS Identity in the Cloud Use Cases.

Extend with PKI-Federation use cases.

Abbreviations

Change History