WS-Federation FAQ


1. What is the rationale behind this standardization effort? What is the
motivation of the sponsors/authors?

The rationale is to standardize certain protocols which were developed, documented and tested by a number of software companies. The sponsors hope to achieve widespread interoperability as well as discovering and correcting any errors or ambiguities.

2. What is the scope of this effort? What is explicitly out-of-scope,
and why?

The scope of the effort is described in great detail in the Charter. Briefly the scope if to specify Identify Federation protocols by building on existing standards such as WS-Security, WS-SecureConversation and WS-Trust. 

3. Are there existing comparable or overlapping standards, or comparable 
standardization efforts currently under way (inside or outside OASIS)?
How does the work of this technical committee relate to these?
What distinguishes this TC from similar work?
How do the differences add value?

There is some functional overlap between the work of this TC and that of the Security Services TC (SAML). SAML uses a SAML-specific approach limited to SAML tokens to implement identity federation. WS-Federation uses a more general approach based on WS-Trust and potentially employing a number of token types, including SAML tokens.

4. Is the product of this technical committee intended to be used in
conjunction with other standards or complementary technologies?
What are these?
How does this work relate to these (is the usage of these complements
mandatory? optional? restricted or profiled?)

This work builds on WS-Security, WS-SecureConversation and WS-Trust which in turn build on XML Signature, XML Encryption, SAML, X.509 and Kerberos. In general, the use of these underlying standards is required when the functionality they provide is needed, but not otherwise. For example, an implementation which does not require encryption is not required to use XML Encryption.

5. Can you give some example of concrete applications that will benefit
from standardizing the specifications from this TC?

Any infrastructure requiring Identity Federation based on Web Services Standards may make use of this work.

6. Is it anticipated that TC deliverables will be broadly used, 
deployed, and/or implemented?
Or are the deliverables intended for a narrow audience, possibly 
including only the TC membership?

It is expected they will be broadly used, based on implementations provided by software vendors and open source projects. The total number of distinct implementations is likely to be much smaller than the number of deployed systems.

7. Do you see external factors that should help a broad acceptance and 
deployment of the specifications from this TC?
And factors that may potentially hinder a broad acceptance and deployment?

Market confusion between WS-Federation and the SAML Browser Profiles might inhibit acceptance.

8. Do you know of companies or industry verticals that have already 
expressed interest in using the specification(s) produced by the TC in
their products or services?

Products based on privately published versions of this specification are already being deployed.

9. Regarding the adoption of this specification(s) by a vendor for its 
products: is this a decision that vendor companies can make individually,
or are the interoperability aspects important enough to require
industry-wide, coordinated adoption ?

Broad Interoperability is essential to the usefulness of this specification.

10. Have the authors and their companies considered further ways to 
promote the produced specification(s) after completion (PR, marketing,
campaigns, industry consortia....)

These are being pursued by individual companies at this time.

11. What are the security implications, if any, of this effort?

This is a security specification. Its security properties are fundamental to its usefulness.