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.
- 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
| Excerpt | ||
|---|---|---|
| ||
Change the status keyword in each scenario and use case title as appropriate, linking to the meeting minutes page explaining the status change:
|
...
- 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
...
| Anchor | ||||
|---|---|---|---|---|
|
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:
...
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
| Anchor | ||||
|---|---|---|---|---|
|
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.
...
| Anchor | ||||
|---|---|---|---|---|
|
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
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C01, shows aspect of actor centricity
...
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
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C01, shows aspect of actor centricity
...
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
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C01, shows aspect of actor centricity
...
- TR-1-EntityAuthN and
- TR-2-IdPAvailibility
Actors
Inherited: IdP, RP, Subject
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C01, shows aspect of IDP centricity
...
- TR-1-EntityAuthN and
- TR-2-IdPAvailibility
Actors
Inherited: IdP, RP, Subject
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C01, shows jurisdictional structure aspect
...
This constellation blends the S32 Federation S31 Ruling Party constellations.
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C01, shows jurisdictional structure aspect
...
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.
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C10, shows aspect of jurisdictional structure
...
- Identity life cycle management (attribute updates, credential revocations)
- 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)
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C32, shows aspect of jurisdictional structure
...
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.
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C32. Federation contracts are between the IdP and Service Broker. Users contract with the IdP, and Relying Parties with the Service Broker.
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C01, shows aspect where AA is different from IdP
...
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)
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends Constellation C40, shows specific variant of C40, without introducing new actors.
...
This constellation is implemented in Canada to conform with Canadas privacy law.
...
| Anchor | ||||
|---|---|---|---|---|
|
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.
...
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
...
| Anchor | ||||
|---|---|---|---|---|
|
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
...
| Anchor | ||||
|---|---|---|---|---|
|
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
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends C01, showing aspect of payload type
...
No additional trust relationships need to be added to the basic constellation.
Actors
Inherited: IdP, RP, Subject
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends UC01, shows aspect of access type
...
- 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.
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends C32, shows aspect of method of policy mapping
Actors
Inherited: IdP, RP, Subject
...
| Anchor | ||||
|---|---|---|---|---|
|
Extends C01, shows aspect of method of policy mapping
...
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
...
| Anchor | ||||
|---|---|---|---|---|
|
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
Key | Description |
|---|---|
AA | Attribute authority |
B2B | Business to business |
CA | Certificate authority |
DNS | Domain name service |
EAA | Entity authentication assurance |
FO | Federation operator |
G2G | Government to government |
IAF | Identity assurance framework |
IDM | Identity management |
IdP | Identity provider |
PII | Personal identifiable information |
PMA | Policy management authority |
RP | Relying party |
UHO | User home organization |
...