OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsfed message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsfed] Issue PR001: Revise federation metadata document structure toeliminate ambiguities and improve interoperability


I think that this is a good idea, this brings the federation metatdata a bit more in-line. This does look like it may take some changes on the SAML side, have they signed up to do these ?

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Inactive hide details for Geoff Bullen ---08/04/2008 11:47:38 AM---This is issue PR001.Geoff Bullen ---08/04/2008 11:47:38 AM---This is issue PR001.


From:

Geoff Bullen <Geoff.Bullen@microsoft.com>

To:

Don Schmidt <donsch@windows.microsoft.com>, "wsfed@lists.oasis-open.org" <wsfed@lists.oasis-open.org>

Date:

08/04/2008 11:47 AM

Subject:

[wsfed] Issue PR001: Revise federation metadata document structure to eliminate ambiguities and improve interoperability





This is issue PR001.

From: Don Schmidt [mailto:donsch@windows.microsoft.com]
Sent:
Friday, August 01, 2008 5:31 PM
To:
wsfed@lists.oasis-open.org
Subject:
[wsfed] New Issue: Revise federation metadata document structure to eliminate ambiguities and improve interoperability

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.

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

Proposed Solution
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


Don Schmidt
Principal Program Manager
Microsoft Corporation
425-703-2655



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]