Trusted interactions within the InCommon Federation are dependent on its Participants and Federation Operator adhering to policy and technology specifications that are contained in a multitude of documents; it can be daunting to get your arms around everything. For that reason, the following two documents serve as guides:

  1. Trusted Relationships for Access Management: The InCommon Model describes the who, what, and why of the trust relationships that exist within the InCommon Federation. Those relationships are both organizational and technological in nature.
  2. SAML V2.0 Deployment Profile for Federation Interoperability provide guidance for deployers of federated technology services that are trusted and interoperable.

This document aims to connect the dots between the technological trust relationships in (1) and the guidance provided to enhance trust in (2). Note that both documents address critical issues that are not addressed here. This document addresses only the overlapping issues.

Federation Metadata (the "Trust Registry")

As described in Trusted Relationships for Access Management: The InCommon Model nearly all information related to trust among federation participants is distributed via InCommon's metadata (the "Trust Registry"). For each entity (identity provider or service provider), this trust-enhancing information that affects software deployment includes:

  • certifications that have been achieved for the entity
  • signing keys to enable verification that an entity is what it says it is
  • encryption keys to enable privacy of information exchange

There are also signing keys that are used to verify the metadata itself, independent of the entity.

This makes adherence to several of the criteria in SAML V2.0 Deployment Profile for Federation Interoperability essential for a secure, trusted relationships in the federation. These appear in multiple sections of the document:

  • 2. Common Requirements
    • 2.2. Metadata and Trust Management
      • SDP-MD01 to ensure the timeliness of the entity's copy of the metadata
      • SDP-MD02 to verify the authenticity of retrieved metadata (i.e., that it was truly generated by InCommon)
      • SDP-MD03 to ensure the current validity of retrieved metadata
      • SDP-MD05 through SDP-MD08 to ensure that the signing and encryption keys used for data exchange between identity providers and service providers exist and meet minimum requirements to support strong cryptographic operations
  • 3. Service Provider Requirements
    • 3.1 Web Browser SSO
      • 3.1.3. Subject Identification
        • SDP-SP16 and SP-SP17 to ensure that identifiers are scoped to be globally unique, and that scopes are asserted only by authenticated identity providers
    • 3.3. Metadata and Trust Management
      • SDP-SP37 and SDP-SP38 to ensure that assertions received from partner identity providers are authentic and private
      • SDP-SP39 to declare service endpoints and their encryption keys
  • 4. Identity Provider Requirements
    • 4.1 Web Browser SSO
      • 4.1.3. Subject Identifiers
        • SDP-IDP14 to declare the scopes that have been authorized for this identity provider
    • 4.3. Metadata and Trust Management
      • SDP-IDP32 to ensure the authenticity of requests from service providers
      • SDP-IDP33 to declare service endpoints and their signing keys

Interestingly, Scope is the only "certification" that is addressed in the deployment profile. I guess that's OK, but it'd be nice if there were some mention of the issue would have been nice.

Trustworthy Deployment and Operation

It is implicit in Trusted Relationships for Access Management: The InCommon Model that the software deployed for identity providers and services providers is trustworthy, as well as the deployment and operation of that software. In general, SAML V2.0 Deployment Profile for Federation Interoperability speaks to numerous issues related to robust deployment and operation; all of its criteria must be addressed. The following, however, are specifically related to the trustworthiness of deployments. Where applicable, supporting criteria of the form "IIP-xxxx" from the Deployment Profile's companion document, SAML V2.0 Implementation Profile for Federation Interoperability, are provided. Do we want to reference implementation criteria? I've done only one below (SDP-G01) as an example.

  • 2. Common Requirements
    • 2.1. General
      • SDP-G01 to ensure reasonable time synchronization between identity providers and service providers, as well as between all entities and the Federation Operator (See also IIP-G01.)
    • 2.3. Cryptographic Algorithms
      • SDP-ALG01 to ensure the use of suitably strong cryptographic algorithms.
  • 3. Service Provider Requirements
    • 3.1. Web Browser SSO
      • 3.1.1. Requests
        • SDP-SP03 to avoid the need for third-party cookies
        • SDP-SP07 to enable use of specific authentication methods (e.g., multi-factor authentication)
      • 3.1.2. Responses
        • SDP-SP09 and SDP-SP10 to ensure the transmission of responses is private
    • 3.2. Single Logout
      • 3.2.1. Requests
        • SDP-SP27 to avoid the need for third-party cookies
        • SDP-SP28 to ensure the authenticity of single logout requests
      • 3.2.2. Responses
        • SDP-SP33 to ensure the authenticity of single logout responses
  • 4. Identity Provider Requirements
    • 4.1 Web Browser SSO
      • 4.1.1. Requests
        • SDP-IDP04 and SDP-IDP-05 to ensure proper handling of signed request from service providers
        • SDP-IDP06 to ensure the authenticity of service providers' service endpoints
        • SDP-IDP07 to ensure proper handling of forced re-authentication requests from service providers
      • 4.1.2. Responses
        • SDP-IDP09 and SDP-IDP11 to ensure the authenticity of responses to service providers, and that the information exchange is private
    • 4.2. Single Logout
      • 4.2.2. Request Content
        • SDP-IDP26 to ensure the authenticity of single logout requests
      • 4.2.3. Responses
        • SDP-IDP30 to ensure the authenticity of single logout responses


  • No labels