This is a very early DRAFT set of Phase 2 Recommendations.

Phase 2 Recommendations

The following Phase 2 deliverables were included in the Phase 1 Implementation Plan:

1. Elicit and capture short to mid-term requirements for metadata aggregation
   • Multiple metadata aggregates will be deployed in conjunction with Phase 1
2. Devise a plan to transition the metadata signing algorithm to SHA-2
   • SHA-2 is an important driver for Phase 1
   • The Phase 1 Implementation Plan stipulates that all SAML deployments shall consume metadata signed with a SHA-2 digest algorithm by June 30, 2014.
3. Determine the desirability, feasibility, and impact of changing the InCommon metadata distribution point
   • A new vhost for XML metadata distribution will be introduced in Phase 1

The following Phase 2 deliverables are included in this Phase 2 plan:

1. Conduct a pilot study that explores the utility of per-entity metadata
2. Conduct a feasibility study of the potential needs and uses of hardware security modules
3. Participate in the samlbits.org project

Some Phase 2 deliverables have so far not been discussed:

1. per-organization metadata
2. metadata aggregates based on self-asserted entity attributes
3. support for both XML and JSON formats (both signed)

Multiple Metadata Aggregates

• Multiple metadata aggregates were introduced in Phase 1 to facilitate the migration to SHA-2:
  1. production metadata aggregate
  2. fallback metadata aggregate
  3. preview metadata aggregate
• Initially, the production metadata aggregate will be signed using a SHA-2 digest algorithm while the fallback metadata aggregate will be signed using the SHA-1 digest algorithm. By the end of Phase 1, the two aggregates will be sync'd.
• The preview metadata aggregate has no actual purpose in Phase 1. It was introduced in Phase 1 merely for completeness.
• The long-term intended uses of the metadata aggregates are documented in the wiki. (This wiki page is considered to be a Phase 2 deliverable.)
• It is anticipated and in fact RECOMMENDED by this WG that the uses of these metadata aggregates will be expanded over time to facilitate a broad range of metadata deployment scenarios.

Per-Entity Metadata: A Pilot Study

As the federation grows larger, and campuses consider using the metadata management process for larger numbers of SP, the stress on the batch-oriented distribution model used for SAML metadata today will increase. While it's noteworthy that we are nowhere near real limits on that mechanism, there has already been progress on both specifications and software to supplement the use of files with a more granular model for metadata distribution without losing the notion of third-party certification that underlies the current federation model.

While there are certainly many ways one might change this model, the concrete proposal that has so far been implemented in limited fashion is based on a REST-like API over HTTP for requesting and receiving signed, per-entity metadata in a negotiated format (typically SAML's XML format).

A pilot study is proposed that explores the utility of this approach as an alternative to metadata aggregates, and evaluates current implementations of this model to discover problems or identify new requirements.

1. The pilot will be focused on use of the Metadata Query Protocol (Internet-Draft tracker, working area).
2. A call for participation will be made to both deployers and software projects, the latter directed at projects that either have working code or are interested in developing it. The Shibboleth Project has already delivered production SP releases with this support, and is willing to work with the pilot study while developing the IdP capability, yet to be released.
3. The pilot may or may not make use of the existing InCommon metadata signing infrastructure and/or key.
4. Any overlaps or synergies with the samlbits.org conversation will be explored.

Hardware Security Modules: A Landscape Study

Conduct a study on the potential uses of Hardware Security Modules (HSMs) to secure XML signing keys and other high-value secrets.

1. An HSM for the current metadata signing key
   1. On-premise deployment
   2. Impact: The current metadata production process that results in three (3) signed SAML metadata aggregates (production, preview, fallback)
2. An HSM for a new metadata signing key
   1. On-premise or cloud deployment
   2. Impact: A new post-process that consumes the InCommon production metadata aggregate and produces a set of signed, per-entity metadata
   3. Impact: A new post-process that consumes the InCommon production metadata aggregate and an alternate source of metadata (such as the eduGAIN metadata aggregate) to produce a combined metadata aggregate
3. An HSM for a new IdP signing key
   1. On-premise or cloud deployment
   2. Impact: The production Multifactor IdP Proxy, an instance of simpleSAMLphp