Scope comparison of Identity vs. Trust Federation

To map and compare the scope of federation frameworks I wrote up this set of trust relationships. The terminology is primarily a mix from Kantara Initiative and OIX. The starting point was a review of the Kantara Identity Assurance Framework, that is focused quite clearly on Entity Authentication Assurance (#1 in the requirements list). In the list/picture below I try to show the additional relationships that are not addressed. So items 1 and 6 are part of the IAF, but not the rest.

It as also worth to mention that identity assurance does not cover all security requirements of the RP to the Subject. E.g. doctor Alice needs to access a EHR at doctor Bob's system. Bob needs to assure the identity of Alice (for the audit trail) and a valid role "General Practitioner" (ignoring the patient consent for simplification). The assertion of identity and authorization, however, is not complete. Bob has to assure that the data is only used for the requested purpose, and Alice does not disclose the data to unauthorized entities. That requirement is usually fulfilled by sector-specific laws and regulations, but it is still a requirement. And Bob might need to require specific controls on top of legislation, like secure printing for hardcopies generated from the data. And besides the confidentiality requirement Bob will have an availability requirement to the IdP as the data access will be provided 7x24.

 

Some not so well-known abbreviations:

  • PMA: Policy Management Authority
  • RA: Registration Authority
  • SoA: Source of Authority (for attributes)
  • FO: Federation Operator

List of requirements forming a base for trust relationships:

  • 1. EAA: Entity Authentication Assurance (used also for Entity Attribute Assurance?)
  • 2. ToU (Terms of Use) contain Confidentiality requirements by the RP to the user
  • 3. User requirements to RP:
  • 3a. LoP: Privacy beyond idm-specifc PII (like OIX's Levels of Protection)
  • 3b. Information security (like protection against malware on server and correct processing of IdP assertions and meta data)
  • 4. SLA/IdP: Service level (Availability, liability) of the IdP from the RP's perspective. Same for AP: SLA/AP.
  • 5. SLA/RP: Service level of the RP to the user
  • 6. SLA/FO: Agreements between FO and IdP, AP, RP.
  • 7. User requirement to IdP (and AP)