...
- 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.