Trust Federation Constellations
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.
Incomplete constellations: C21, C22, C30, C70, C90, C100
Discussion, if abuse-cases (C99) add value in this context, or should be moved elsewhere.
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
- 1 Introduction
- 2 Trust Relationships in Federated Identity Management (Pending)
- 3 Constellations
- 3.1 Constellation C01: Delegated Authentication (Pending)
- 3.2 Constellation C10: Delegated Identity Management (Pending)
- 3.3 Constellation C20: Service Provider Centric model (Pending)
- 3.4 Constellation C21: User Centric model (to be completed)
- 3.5 Constellation C22: Network-centric RP (to be completed)
- 3.6 Constellation C23: IDP+SP-centric Federation Platform (to be completed)
- 3.7 Constellation C30: Intra-organizational IDM, loosely coupled units (to be completed)
- 3.8 Constellation C31: Ruling Party IDM (pending)
- 3.9 Constellation C32: Identity Federation (Pending)
- 3.10 Constellation C33: Cross Border Identity Federation (pending)
- 3.11 Constellation C35: 4-Corner Model (pending)
- 3.12 Constellation C40: Attribute Provider separate from IdP (pending)
- 3.13 Constellation C41: Attribute Provider with RP
- 3.14 Constellation C50: Enterprise user (pending)
- 3.15 Constellation C60: Subject Types (pending)
- 3.16 Constellation C70: Reputation-based Trust (t.b.d.)
- 3.17 Constellation C80: Document-centric Transaction (pending)
- 3.18 Constellation C90: Physical Access (tbd)
- 3.19 Constellation C100: Inter-Federation requiring automated policy negotiation (t.b.d.)
- 3.20 Constellation C110: Verifier with Relying Party (pending)
- 3.21 Constellation 99: Abuse Cases (pending)
- 4 TO DO
- 5 Abbreviations
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:
Completeness of trust model: Trust establishment, subject life cycle management
Actor centricity: Depending on the background, users, service providers or network operators might shape the constellation.
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?
AA (Attribute Authority) different from IdP
Organizational context: Enterprise user vs. consumer/natural person
Subject class: human user vs. device/service
Trust type: peer to peer, hierarchy/trust anchor, reputation based.
Type of communication payload: document-centric vs. session-centric (or both in case of messaging)
Restriction to electronic communication vs. physical access
Off-line mapping of EAA policies vs. automated policy negotiation in real-time
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