There are ambiguities in the definition of the federation metadata document structure in section 3 of the current draft of the WS-Federation specification. Attempts to prototype an STS configuration tool using metadata published by a federation partner have indicated that these ambiguities are serious enough to prevent automation and pose a significant risk to interoperability.
Federation metadata is defined as an XML document that contains elements which describe properties of endpoints. These elements fall into two general categories:
-- service instance elements used to identify a physical instance of a specific type of web service (e.g. <fed:TokenIssuerEndpoints>)
-- service capability elements used to describe a property of a web service (e.g. <fed:TokenSigningKeyInfo>)
Three service instance elements (<fed:TokenIssuerEndpoints>, <fed:PseudonymServiceEndpoints> and <fed:AttributeServiceEndpoints) can provide meaningful information in a federation metadata document without any additional qualification. The remaining service instance elements, and all of the service capability elements, do not provide meaningful information unless they are associated with one of the previous three service instance elements. However, the current federation metadata document structure defines all elements as peers, and provides no mechanism for associating them beyond grouping them in a single federation metadata document section. This leads to the following ambiguities.
(a) There is no mechanism to indicate the correct association if multiple service instance and service capability elements exist in the same section of a federation metadata document. For example, if a there are elements for two different token issuing services and two different signing keys, there is no mechanism to indicate which key is used by which service.
(b) There is no mechanism to indicated related service instance elements. Some types of service instances must be related to another type of service instance to be meaningful. For example, a sign-out subscription service (<fed:SingleSignOutSubscriptionEndpoints>) element is not meaningful unless it is related to a service that enables sign-on, such as an STS (<fed:TokenIssuerEndpoints>).
(c) There is no service instance element for identifying a generic Relying Party service that is only a consumer of security tokens, attributes or pseudonyms. There are only elements for identifying services that are issuers.
The federation section construct allows a service provider to publish distinct metadata for each federation in which it participates in a single federation metadata document. The FederationID attribute is provided to enable partners to locate the correct metadata when configuring federated relationships. The FederationID attribute MAY be included in security token requests to specify the federation context in which the request is being made by the Relying Party.
(d) There is no mechanism to coordinate the use of a consistent FederationID attribute value between the participants in a particular federation.
(e) There is no mechanism for an Identity Provider to determine that a Relying Party has the right to assert a specific FederationID attribute value in a service request.
These ambiguities could be addressed by introducing additional structure in the existing WS-Federation definition for federation metadata. However, this would partially duplicate work that has already been accomplished in the Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 specification [Samlv2Meta]. The <md:EntityDescriptor> element appears to have most of the necessary properties to address issues (a), (b) and (c). While the<md:EntitiesDescriptor> element appears to have the necessary properties to address issues (d) and (e).
Re-using the [Samlv2Meta] constructs will simplify development, and improve interoperability, for parties that must either implement or deploy products based on both the WS-Federation and SAML protocols. Please see the attached document for details of a proposal that will eliminate the existing federation metadata document structure ambiguities by extending existing [Samlv2Meta] constructs to support WS-* requirements. Note, the proposal only requires changes to the federation metadata document structure. There is no need to change existing mechanisms and protocols defined in WS-Federation for locating or retrieving a federation metadata document.
Key contributors to the SAML standard have reviewed this proposal for technical correctness. They verified that the proposed extensions to SAML metadata are consistent with the schema of [Samlv2Meta]. They also have expressed their willingness to make any necessary errata changes to [Samlv2Meta] and to foster cooperation between the SS and WSFED TCs to ensure that this harmonization effort is successful
Principal Program Manager