This is a collection of material, mostly formal standards and some implementation conventions, describing the use of SAML metadata to express trust and assurance-related information across protocols.
- Metadata Interoperability Profile
- Committee Spec describing the use of metadata to explicitly bind keys to entities/roles, without regard for protocol (so composes with any metadata "protocol profile" for expanding metadata usage beyond SAML). As defined, this profile allows a metadata document to be self-describing with regard to how to evaluate a security message from a partner, or encrypt a message to one. Metadata "as is" can't be used to express trust anchors to be used to verify certificates at runtime. It can be done with extensions (e.g., Shibboleth defined one), but there is no standard extension for it. This makes it impossible to express the trust policy to be applied in the metadata itself, when runtime PKIX is used, and is one reason that cross-federation metadata becomes a problem when PKIX is involved (because it's incomplete).
- Profiles of SAML Metadata for WS-Federation, IMI, and OpenID
- These are profiles for using SAML Metadata for descriptive/configurative purposes and for establishing "control" of endpoints by protocol participants, similar to how it's used in SAML proper. They compose, where applicable, with the IOP work in terms of trust management, which in the IMI case addresses major deficiencies with the use of commercial (and usually meaningless) SSL credentials. The WS-Fed and OpenID profiles are the product of Shibboleth Project work. The IMI proposal is part of the SAML 2.0 Token Profile that may be voted to CS the day after I'm writing this. These are noted to demonstrate how one can manage a multi-protocol federation scenario with one metadata approach in an implementation.
- Metadata Extension for Entity Attributes
- Committee Spec describing a metadata extension for attaching SAML Attribute or Assertion elements to an entity's metadata, for the purposes of defining information about it, constraints on its behavior, etc. In third-party signed metadata, as is common with scaled SAML federations today, attributes can be attached directly and signed as part of the overall document (by a trust framework provider in the ICAM terminology?) In a scenario where metadata was self-signed or just hosted naked over SSL, the extension allows for third-party signed assertions to be attached, so you can include attestations to the data from someone other than the metadata signer or web host.
- SAML Identity Assurance Profiles
- Committee Draft defining a SAML Attribute that expresses a set of "assurance profiles" that an Identity Provider is claimed to conform to. The notion is that the Attribute would be used with the previous extension to embed one or more profile identifiers into an IdP's metadata to establish the profiles to which it has been certified by a trust framework provider (assuming the metadata were signed by that TFP, for example). This spec will probably go back for some re-working editorially, but the only normative content is stable.
- SAML Metadata Profile for Algorithm Support
- Committee Draft clarifying the use of existing elements for expressing support for encryption algorithms. This also adds new elements for expressing support for signing algorithms. In cross federation situations, not everyone will support exactly the same algorithms. As an example the US Gov mandates SHA2 hash algorithms for all signing after Dec 31,2010. While US RP may require this other RP may not yet support it. A given IdP may need to configure signing or encryption algorithms on a per SP basis. IMI has similar issues. This is currently a Working Draft but is an example of some of the meta-data that may be required across federations.
- IdP Discovery and Login UI Metadata Extension Profile
- Working draft from the Shibboleth Project, not yet submitted to OASIS (XML namespace likely to change). SAML metadata provides a mechanism for expressing some of the information necessary for SAML entities to successfully communicate with each other. However, in most SAML profiles there is also a user agent, usually representing an actual person, that also participates in the profiled message exchanges. This document defines a set of extensions to metadata that provide information necessary for user agents to present effective UIs and, in the case of IdP discovery, help recommend appropriate choices to the user.
- vCard XML schema
- This could be used to extend the Contact element of meta-data. The XMPP project is in the process of updating there specs to refer to this version produced by the CalDav group.
Putting this all together, the point is that a consuming TFP could obtain metadata as often as necessary from a number of "input" TFPs and in a single document, establish the means for ongoing trusted communication across all the relevant protocols with all of the qualifying IdPs, including, for example, filtering out IdPs that failed to meet necessary assurance standards.