WSFED: Proposed Charter
Proposed Charter for OASIS Web Services Federation (WSFED) TC
Subject: Proposed Charter for OASIS Web Services Federation (WSFED) TC From: "Mary McRae" <email@example.com> To: <firstname.lastname@example.org>,<email@example.com> Date: Mon, 19 Mar 2007 19:18:14 -0400
To OASIS Members:
A draft TC charter has been submitted to establish the Web Services Federation (WSFED) Technical Committee. In accordance with the OASIS TC Process Policy section 2.2: (http://www.oasis-open.org/committees/process.php#2.2) the proposed charter is hereby submitted for comment. The comment period shall remain open until 11:45 pm EDT on 2 April 2007.
OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending email to: mailto:firstname.lastname@example.org All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail.
A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to attend within four days of the close of the comment period. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar.
We encourage member comment and ask that you note the name of the proposed TC (WSFED) in the subject line of your email message.
"eBusiness and Open Standards:
Understanding the Facts, Fiction, and Future"
15-18 April 2007 San Diego, CA USA
OASIS Web Services Federation (WSFED) Technical Committee
- Proposed Charter for Review and Comment
- Name of the TC
- Statement of Purpose
- Scope of Work
- Federation Overview
- Federation Model
- Federation Metadata
- Federated Sign-Out
- Attribute Services
- Pseudonym Services
- Security Tokens and Pseudonyms
- Federation Extensions to WS-Trust
- Indicating Specific Policy/Metadata
- Authentication Types
- Web (passive) Requestors
- Additional Policy Assertions
- General Notes on Scope
- Out of Scope
- Anticipated Audience
- IPR Policy
- Required Non-Normative Information
OASIS Web Services Federation (WSFED) Technical Committee
The purpose of the Web Services Federation (WSFED) Technical Committee (TC) is to extend the basic federation capabilities enabled by Web service Security specifications (WS-Security  , WS-SecureConversation , WS-Trust  WS-SecurityPolicy ) to provide advanced federation capabilities. This includes, but is not limited to: structure and acquisition of federation metadata; sign-out notifications; the use of pseudonym and identity mapping services and attribute services in conjunction with Security Token Services; claims-based authorization; and protection of a principal's privacy with respect to claims asserted in security tokens. In addition, the TC will define an HTTP serialization mechanism allowing the richness of WS-Trust security token based mechanisms for SOAP Web services - brokered trust relationships and distributed authentication and authorization - to be used in browser-based scenarios. This work will be carried out through continued refinement of the Web Services Federation Language Version 1.1 specification  submitted to the TC as referenced in this charter.
The TC will accept as input the December 2006 Version 1.1 of the WS-Federation specification  (the Input document) as published by BEA Systems Inc., BMC Software, CA Inc., IBM Corporation, Layer 7 Technologies, Microsoft Corporation, Novell Inc., and VeriSign Inc. Other contributions and changes to the input documents will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter. OASIS members with extensive experience and knowledge in these areas are particularly invited to participate.
To facilitate the establishment of federations across organizational boundaries, and to extend the scope of identity management and security benefits provided by Security Token Services, additional facilities are needed beyond what is provided in WS-Security  , WS-SecureConversation , WS-Trust  and WS-SecurityPolicy . These specifications describe mechanisms for using security tokens to broker trust and secure message exchanges between SOAP Web services, and for using policy to express the security tokens required by a service. Building on the foundation of WS-Security  , WS-SecureConversation , WS-Trust  and WS-SecurityPolicy , a federation protocol should include mechanisms for a Security Token Service to advertise the details of the tokens it can issue (e.g., token and claim types). A federation protocol should also address the relationship of advanced federation services (e.g., Pseudonym services or Authorization services) to baseline Security Token Services. In addition, a federation protocol should describe the message syntax and protocol extensions that participants in a federation must use to communicate with these advanced federation services and the security policy extensions that should be supported for successful interaction with such services.
The following sub-sections describe the charter of the Web Services Federation (WSFED) TC with respect to these areas. The scope of the TC's work is to continue further refinement and finalization of the Input Documents to produce as output modular specifications that standardize the concepts, WSDL documents and XML Schema renderings of the areas described below.
A federation is a collection of realms (security domains) that have established relationships whereby a Resource Provider in one realm can provide authorized access to a resource it manages based on statements about a principal (such as identity or other distinguishing attributes) that are asserted by an Identity Provider (or any Security Token Service in another realm). The terms Identity Provider and Security Token Service are used synonymously in this charter and work description.
WS-Trust  provides the foundation for federation by enabling Security Token Services to broker trust between a Resource Provider and other service providers that are prepared to vouch for the identity, pseudonyms or other attributes which they have associated with a specific principal. WS-Trust  introduces protocol mechanisms independent of any particular application for requesting, issuing, renewing and validating security tokens which can be exchanged to authenticate principals and protect resources.
Building on the WS-Trust  foundation a Federation protocol provides mechanisms that simplify interactions between the participants. A well-documented method for exchanging federation metadata makes it easy to bootstrap trust relationships and to determine policies for obtaining services. Cross-organizational identity mapping and distributed sign-out improve the utility and security of accessing federated service providers. Federation protocol extensions to WS-Trust  provide a framework for delivering advanced services by integrating pseudonym, attribute and claims-based authorization services with generic Security Token Services. Pseudonym services and the claims-based authorization model can be used to satisfy user privacy requirements across realm boundaries in a federation. A Resource Provider can describe the set of attributes required to access a resource and an Identity Provider can assert that a particular principal possesses those attributes, without divulging the actual identity of the principal. Finally, within the limitations of standard web browser clients, the security token based capabilities provided by WS-Trust and federation protocol extensions can be made accessible via HTTP 1.1 mechanisms to be used in browser-only scenarios.
The basic goal of federation is to facilitate the sharing of security principal attributes across trust boundaries to establish a security context (or a federation context) for that principal which a relying party can use to grant/deny access to a resource. Establishing a federation context when Identity and Resource Providers operate in different realms requires agreement on what attributes are required and frequently requires agreement on mechanisms for securely transporting those attributes over unprotected networks. It is necessary for participants in a federation to communicate these requirements over a wide variety of trust and communication topologies. This requires the exchange of metadata describing endpoint references where services may be obtained, plus the security policies and communication requirements that must be observed when accessing those endpoints. The exchange of this metadata is further complicated because the participants in a single federation may have different policies and service providers may participate in multiple federations.
This work will focus on:
1. Describing techniques for establishing a federation context for a principal across organizational boundaries. This includes describing how a common digital identity might be shared by out-of-band mechanisms, or how digital identities managed by separate organizations might be mapped using extensions to WS-Trust .
2. Describing how federation metadata can be expressed, discovered and retrieved to determine the policies of participants within a federation with whom a requestor is going to communicate.
3. Describing how the security token exchange and usage patterns provided by WS-Trust , WS-SecureConversation  and WS-Security  , can be combined and extended to trust relationships that enable advanced federation services.
4. Describing an abstract model for using attribute services in conjunction with WS-Trust  based Security Token Services. Describing implementation or communication details will not be addressed as indicated in the Out of Scope section below.
5. Describing how pseudonym services may be used in conjunction with WS-Trust  based Security Token Services. This includes defining an interface that pseudonym services should support to ensure interoperability with WS-Trust  based Security Token Services and other service providers in a federation.
Organizations typically decide to federate based on business or legal relationships. After a federation has been created, the participants must publish and exchange configuration information (i.e., federation metadata) that allows them to identify the services exposed to participants in the federation and the policies for accessing them. For Web services, this information can be expressed as statements in federation metadata documents and may include endpoint references (EPRs) and security policies which list the security tokens and claims required to access those end points. A mechanism must be established for determining the authenticity of metadata documents. Since a service may be exposed in multiple federations it must be possible to identify the metadata that applies to each distinct context. In addition, it is desirable to help automate this configuration process.
This work will focus on:
1. Defining the XML document format of a federation metadata document to identify the services exposed to participants in the federation and the communication and security policies which must be satisfied for accessing those services. This includes describing mechanisms for naming and referencing specific metadata documents for distinct federations.
2. Defining how to indicate the correct federation metadata document, or the correct section within a single document, when a participant is active in multiple federations. This includes defining a federation identifier for separating metadata for different federations in a single document. It also includes a reference mechanism for pointing to other federation metadata using URIs or Metadata Reference elements as defined in WS-Metadata Exchange , as well as, the rules that must be followed for combining federation metadata documents. This also includes defining how a metadata statement may be associated with multiple different federations.
3. Identifying the different roles that participants in a federation may perform: Requestors, Security Token Services and Service Providers. This includes defining the specific metadata statements that a participant can specify within a metadata document based on its role. These statements include the following cases.
a. Metadata statements which any role can specify to refer requestors to:
i. Endpoints where metadata documents can be obtained
ii. Endpoint references as defined in WS-Addressing  where associated attribute services can be contacted
b. Metadata statements which Security Token Services can specify to indicate:
ii. Types of tokens the Security Token Service can issue
iii. Types of claims the Security Token Service can issue
iv. Issuer namespace(s) for which the Security Token Service is authoritative
v. Endpoint references as defined in WS-Addressing  for use in accessing associated pseudonym services
vi. Endpoint references as defined in WS-Addressing  for use in accessing associated sign-out subscription services
vii. Policy with respect to automatic pseudonym mapping
c. Metadata statements which a Security Token Service or relying party can specify to indicate:
ii. Token issuers the participant trusts, based either on a specific endpoint reference as defined in WS-Addressing  or the namespace for which the issuer is authoritative
iii. Endpoint references as defined in WS-Addressing  for sending sign-out notifications
4. Describing how a digital signature should be used to ensure data integrity and authenticity of a federation metadata document so that the document is protected outside of a SOAP message exchange. This includes describing the required pairing of signature and canonicalization mechanisms that must be observed when signing with XML Digital Signature .
5. Describing the use of WSDL extensibility mechanisms and the attachment mechanisms defined in WS-PolicyAttachment  to publish a federation metadata document for retrieval by other participants in a federation.
6. Describing how a federation metadata document may be published for retrieval by other participants in a federation using DNS mechanisms to identify the "default path" (i.e., network location) where the federation metadata document may be obtained. This includes defining DNS naming conventions for constructing the default path and describing the use of DNS SRV records for locating servers on that path.
7. Describing how a federation metadata document should be retrieved by a requestor. This includes describing the following transport mechanisms that may be used and the associated security considerations.
a. HTTP GET to a URL constructed from the default path
b. HTTPS GET to a URL constructed from the default path
8. Describing the recommended order in which the transport mechanisms for retrieving federation metadata documents should be attempted.
9. Defining the syntax for a header as defined in WS-Addressing  that requestors may use to enable service providers to optimize SOAP requests for federation metadata documents.
10. Defining a dialect that must be used when retrieving federation metadata documents using the metadata unit inclusion mechanisms from WS-MetadataExchange .
11. Describing the considerations that should be applied to keys used for signing federation metadata documents.
The purpose of federated sign-out is to cause federation participants to clean up any cached state or security tokens for a principal that are no longer required because the principal's session is being terminated. Federated sign-out is different than token cancellation as defined in WS-Trust  since federated sign-out applies to all tokens and all target sites for the principal within the federation.
This work will focus on:
1. Describing the advisory nature of the sign-out mechanism and declaring that correct operation of all participants in a federation must not depend upon the successful processing of sign-out messages.
2. Defining a sign-out message and its recommended usage pattern. This includes defining a common syntax for the sign-out message regardless of which participant in the federation sends the message.
3. Describing the processing model for both issuers and receivers of sign-out messages. This includes describing the potential failure cases if messages are delivered serially by chaining through all participants, and a parallel delivery mechanism to address these concerns.
4. Describing how sign-out messages for a principal could be scoped to different resources within a federation. This includes describing both global and selective sign-out mechanisms.
5. Describing how to subscribe for sign-out message notifications by using subscription mechanisms defined in WS-Eventing  and the subscription endpoint in a federation metadata document. This includes describing how these subscriptions can be filtered using the XPath filter defined in WS-Eventing .
The participants in a federation may not always be able to establish a federation context for a principal using only the claims obtained from security tokens. For example, after a principal's original request has been authenticated a Resource Provider may determine that additional information is required to authorize access to advanced functionality. A service provider can address this situation by operating an attribute service that requesters may use to obtain this additional information.
This work will focus on:
1. Describing how a logical data organization and namespace can be layered over any physical repository to provide additional information about any type of principal in a way that is interoperable with Web services. This does not include describing details regarding implementation of an attribute service or how to communicate with it, as indicated in the Out of Scope section below.
2. Describing that an attribute service should be able to supply attributes for any type of principal found within a federation, including resources as well as users and programs.
3. Describing the granularity of access control and privacy protection that an attribute service should be capable of supporting based on the privacy requirements of the principals for which it holds data. This includes declaring that these requirements may be expressed and scoped using mechanisms defined in WS-Policy  and WS-PolicyAttachment .
A pseudonym service is a special type of attribute service which provides alternate identity information for principals. It may provide distinct pseudonyms for different scopes, that is, for access to different Resource Providers. A pseudonym service may maintain and provide security tokens for access to different scopes.
This work will focus on:
1. Describing how a logical data organization and namespace can be layered over any physical repository to provide to pseudonyms for principal in a way that is interoperable with Web services.
2. Describing how pseudonyms may be general purpose, or may be scoped for use with specific relying parties.
3. Describing how pseudonym services may associate security tokens with pseudonyms so that both may be obtained in a single operation.
4. Describing the granularity of access control and privacy protection that a pseudonym service should be capable of supporting based on the privacy requirements of the principals for which it holds data.
5. Defining interfaces that pseudonym services must support for requesting and managing pseudonyms. This includes the use of mechanisms defined in WS-Transfer  and extensions defined in WS-ResourceTransfer  to create, update, delete, and retrieve pseudonyms and to control the scope of operations performed on a pseudonym store.
A pseudonym service can store tokens associated with a pseudonyms to simplify retrieving a pseudonym and associated tokens in a single security token request.
This work will focus on:
1. Describing how a pseudonym service can associate security tokens with pseudonyms for use with specific target services. This includes describing patterns for obtaining these tokens, including a principal proactively obtaining the tokens and including them in a service request or a Resource Provider using a pseudonym to retrieve the associated tokens.
2. Describing how a pseudonym service that is combined with a Security Token Service may map pseudonyms to issued tokens. This includes describing how the mapping may be automatically performed based on the target service for the token. It also includes defining extensions to the WS-Trust  RST/RSTR syntax for requestors to manually specify how pseudonyms should be mapped.
3. Describing how proof keys generated for security tokens may be stored for retrieval by requestors directly from a linked pseudonym service. This includes a discussion of passwords, asymmetric and symmetric keys.
Interactions between participants in a federation may be facilitated by some general purpose extensions to the token exchange mechanisms defined in WS-Trust .
This work will focus on:
1. Describing how reference tokens may be exchanged between participants in a federation using the mechanisms described in WS-Trust  in cases where it may be more efficient or practical to return a handle to the token instead of the actual token. This includes describing usage patterns for reference tokens and the syntax that must be observed when de-referencing them.
a. Defining the syntax for reference tokens including Token type, serial number, token hash and one or more EPRS where the actual token contents can be obtained.
c. Describing how a Security Token Service may return a reference token in a WS-Trust  RSTR
2. Defining the syntax to scope RST/RSTR messages, as defined in WS-Trust , to a specific federation context when Security Token Services or relying parties participate in multiple federations and allow token requests at a single endpoint
3. Defining the syntax for a target service to obtain a proof key as part of the response to a security token Validate request so that subsequent messages can be validated by the target service directly. This includes defining syntax for requesting a WS-Trust  RequestedProofToken be returned by the Security Token Service.
4. Defining extensions to RST messages, as defined in WS-Trust  to obtain dynamically generated pseudonyms, including the processing rules for such an RST. This includes defining the syntax that the requestor may use to specify the desired pseudonym information.
5. Defining the syntax for extending RST messages, as defined in WS-Trust  to enable target services to specify their requirements for the freshness of credentials used by principals to authenticate to Security Token Services. This includes defining syntax for the following options.
a. Specifying whether tokens issued on the basis of cached authentication state are acceptable, or whether it is desired that principals authenticate themselves for every token request.
b. Specifying a desired upper bound on the elapsed time between issuing a security token and the last time the Security Token Service required the principal to authenticate.
An authorization service is a special type of Security Token Service which provides decision brokering services for participants in a federation. While the internal processing of an authorization service is implementation specific, interoperability requires development of a common model for interacting with authorization services, and extensions to RST/RSTR mechanisms, as defined in WS-Trust , for communicating request and policy inputs and decision outputs.
This work will focus on:
1. Describing how an authorization service may be implemented as a Security Token Service placed between the requestor and the desired target service and granting/denying the request by issuing/not issuing security tokens required by the target service. This includes describing an abstract mechanism for comparing the claims required by the target service to the claims proven by the requestor to determine if the requestor is authorized.
2. Defining the required function of an authorization service to ensure that the requestor has presented and proven the claims required to access the target service.
3. Defining the syntax for conveying the authorization context of an RST or RSTR, as defined in WS-Trust  that is, providing additional contextual data that may influence token requests but may not be included in the contents of the issued token. This includes defining syntax for the following properties:
a. Conveying the context item as a name/value pair.
b. Specifying the type of the context item via a URI.
c. Specifying the scope (requestor, target, action) of the context item via a URI.
d. Specifying the value as a simple string or a custom representation. 4. Defining a dialect for expressing common claims in a format-neutral way in a manner consistent with the expression of Claim Dialects, as defined in WS-Trust . This includes defining syntax for the following properties of a claim:
a. Specifying the type of the claim via a URI.
b. Indicating whether the claim is required or optional.
c. Specifying the value of the claim as a string.
5. Defining a profile of WS-Trust  in the form of processing rules for RST/RSTR messages that must be observed by Authorization services and requestors. This includes a description of the required use and treatment of:
a. Addressing headers as defined in WS-Addressing .
b. Additional authorization context described above.
c. The common claim dialect described above.
When a requestor attempts to access a target service there may be additional security or contextual requirements based on the specifics of the request. A mechanism allowing the target service to indicate that additional security semantics apply to the request is required, enabling the requestor to reconstruct the request and try again.
This work will focus on:
1. Defining a specialized SOAP fault that a target service can use to dynamically indicate that a request cannot be satisfied because additional security semantics apply.
2. Describing how the additional semantics are expressed and embedded in the SOAP fault so that the requestor can retry the operation if it is able.
The WS-Trust  specification defines the AuthenticationType parameter to indicate the type of authentication required (or performed) with respect to a particular security token request. However, no particular types are defined or required. To facilitate federations, it is useful to establish some optional pre-defined authentication types.
This work will focus on:
1. Defining a set of URIs for specifying common authentication types to be used for the wst:AuthenticationType parameter in RST and RSTR messages. This includes specifying pre-defined URIs to identify the following authentication mechanisms:
a. Unknown level of authentication.
b. Default sign-in mechanisms.
c. Sign-in using SSL.
d. Sign-in using SSL and a security key.
e. Sign-in using SSL and a "strong" password.
f. Sign-in using SSL and a "strong" password with expiration.
g. Sign-in using Smart Card.
Requests made to service providers for security tokens or authorization decisions may include information that is subject to personal or organizational privacy requirements. It is necessary to provide mechanisms for requestors to indicate any restrictions on the use and distribution of such sensitive information, including its disclosure in security tokens they request.
This work will focus on:
1. Describing how requestors can communicate their requirements for protecting the confidentiality of sensitive information provided in an RST or included in an RSTR and/or the issued token.
2. Defining a syntax that allows requestors to specify that the confidentiality of individual sensitive claims in a security token should be protected by encryption when it is not required or advisable to encrypt the entire token.
3. Defining extensions to RST/RSTR syntax defined in WS-Trust  for a requestor to express its privacy requirements and for a Security Token Service to indicate the mechanisms actually used for the issued token as follows:
a. Specifying parameter values that must be returned in an RSTR.
b. Specifying parameters that an STS must use if it issues a token.
c. Specifying that claim values present in an issued token must be echoed in an RSTR.
For Web services the sections above describe extensions to WS-Trust  for brokering trust and exposing and consuming services between the participants of a federation. Web browser requestors typically cannot directly issue SOAP requests. Consequently, syntax is required for expressing the WS-Trust  protocol and federation extensions in a browser-only environment using widely supported HTTP 1.1 mechanisms (GET, POST, redirects, and cookies).
This work will focus on:
1. Describing examples of common federation operations that can be performed by causing web browsers to transport encoded WS-Trust  protocol messages and federation extensions described above between service providers. This includes describing the browser message patterns that should be used to perform these operations.
a. Describing common patterns for performing a Sign-On operation by using a web browser requestor to transport WS-Trust  RST/RSTR messages. This includes describing:
i. How a Resource Provider can "send" a WS-Trust  RST request by redirecting the web browser to a trusted Identity Provider.
ii. How an Identity Provider can return a WS-Trust  RSTR response directly to the Resource Provider in a POST body.
iii. How an Identity Provider can return a handle to a WS-Trust  RSTR response in a GET query string parameter, which the Resource provider may use to retrieve the issued token directly from the Identity Provider.
iv. How a Resource Provider can consume the issued token directly, or rely upon an intervening Identity Provider to translate it by causing the web browser requestor to perform additional redirection and POST operations.
v. How a home realm discovery service can be used to determine the Identity Provider associated with the web browser.
b. Describing common patterns for performing a Sign-Out operation by using a web browser requestor to transport federated sign-out messages. This includes describing:
i. How a web browser can initiate the process by selecting a sign-out URL at either the requestor's Identity Provider or a Resource Provider.
ii. How the requestor's Identity Provider should keep track of the Resource Providers that must be notified.
iii. How the requestor's Identity Provider may use the web browser to send sign-out messages to Resource Providers.
iv. The processing that should be performed by an Identity Provider or Resource Provider when it receives a sign-out request.
c. Describing common patterns for using Attribute services by using a web browser to transport protocol messages described above for using an Attribute service.
d. Describing common patterns for using Pseudonym services by using a web browser to transport protocol messages described above for using a Pseudonym service.
e. Describing how artifacts or cookies can be used to cache state, authentication information or issued tokens to prevent requestor interaction on every request for security token or a resource.
f. Describing security mechanisms that should be used with bearer tokens or reference tokens to prevent attacks.
2. Defining the syntax for encoding WS-Trust protocol message elements and attributes, and federation extensions described above, as parameters that may be transported as HTTP 1.1 GET query string parameters or POST body fields and parameters. This includes defining the syntax for the set of required and optional parameters needed to convey the subset of protocol semantics that can be expressed using industry standard, unmodified browser clients.
a. Declaring how parameters should be used with HTTP 1.1 GET (specified in query string) and POST (specified in body) methods.
b. Defining parameters for coding attributes that are common to most WS-Trust protocol messages and federation extensions described above, including the following:
i. The protocol action to be performed.
ii. The URL to which responses should be directed if not pre-determined by policy.
iii. A context parameter for using a browser to preserve its state during HTTP 302 redirects.
iv. The federation context in which the request is being made.
c. Defining parameters for encoding attributes of WS-Trust RST messages and federation extensions described above., including the following:
i. The URI of the requesting realm.
ii. The desired freshness of the principal's authentication.
iii. The realm of the web browser requestor's Identity Provider which can be used to facilitate deployment of a centralized home realm discovery service and reduce user interaction.
iv. A request parameter conveying a RequestSecurityToken element or a complete Security Token Request message as defined in WS-Trust .
v. A URL where the RST can be retrieved when it is not practical or desirable for the web browser requestor to transport it.
d. Defining parameters for encoding attributes of WS-Trust  RSTR messages and federation extensions described above, including the following:
i. A result parameter to hold the RSTR.
ii. A URL where the RSTR can be retrieved when it is not practical or desirable for the web browser requestor to transport it.
e. Defining parameters for encoding federated sign-out messages.
f. Defining parameters that for encoding protocol message exchanges with Attribute services.
g. Defining parameters for encoding protocol message exchanges with Pseudonym services including encoding of pseudonym requests and responses conveyed in SOAP envelopes or via WS-Transfer  and WS-ResourceTransfer  Get operations.
3. Describing detailed examples of message flows for web browser requestors when using HTTP 1.1 mechanisms to deliver the parameter encoded equivalent of WS-Trust  protocol messages and the federation extensions described above.
a. Describing mechanisms for a Resource Provider to determine the Identity Provider for a particular web browser requestor also referred to as Home Realm Discovery. This includes:
i. Describing common mechanisms for determining the home realm.
ii. Describing an implementation of a Home Realm Discovery Service consistent with the protocol encoding for Passive web requestors described above
4. Defining minimum requirements - that is a subset of the web browser requestor syntax described above - to ensure interoperability of federated web single sign-on implementations. This work will focus on:
a. Defining required and optional parameters that an implementation must be able to support for encoding attributes of WS-Trust  RST/RSTR messages and federation extensions described above.
b. Defining the required syntax for returning an issued token. This includes describing syntax for either returning the token directly via the web browser requestor, or indirectly by returning a handle which the relying party must use to retrieve the token from the Security Token Service
c. Describing mechanisms for returning signed security tokens and unsecured tokens.
d. Defining parameters that an implementation should be able to support for encoding attributes of federated sign-out messages.
This work will focus on defining policy assertions enabling participants in a federation to advertise support for federation protocols and features described above.
1. Defining an assertion as related to WS-Policy  to indicate that a relying party will accept a reference token instead of an actual token for WS-Security   protected messages to this endpoint. This includes defining the syntax for specifying how the reference token must be formatted.
2. Defining an assertion as related to WS-Policy  to indicate that token request or responses for this endpoint use the web browser requestor protocol and must be protected using a transport mechanism. This includes defining a syntax to specify the following binding properties:
a. The transport mechanism to use.
b. The required token type for authentication, which includes allowing for the use of reference tokens.
c. Only signed tokens are accepted.
d. Only bearer tokens are accepted.
e. Use of shared cookies for home realm discovery. This only includes definition of an assertion to indicate that shared cookies are used. The specific contents of such cookies or the mechanisms for obtaining them are not addressed as stated in the Out of Scope section below.
3. Defining an Authorization assertion as related to WS-Policy  to indicate support for the authorization mechanisms described above. This includes defining a syntax for specifying the following policy requirements:
a. The service requires the use of common claim dialect as described in the "Authorization" section above.
b. The service supports the SOAP Fault described in the "Indicating Specific Policy/Metadata" section above.
c. The service supports the processing of additional authorization context in an RST as described in the "Authorization" section above.
The output specifications will uphold the basic principles of other Web services specifications of independence and composition and be composable with the other specifications in the Web services architecture, such as the specifications listed in the References section, numbers 1-18, 24-26. The TC may also take into consideration the following specifications/works listed in the References section, numbers 19-22, 24-27.
If any of the above specifications is outside of a standardization process at the time this TC moves to ratify its deliverables, or is not far enough along in the standardization process, any normative references to it in the TC output will be expressed in an abstract manner, and the incarnation will be left at that time as an exercise in interoperability.
While composition with other specifications is a goal of the TC, it is also a goal to leave the specifics of how that composition is achieved outside the scope of this TC.
Each of the protocol elements will use implementation and language neutral XML formats defined in XML Schema .
The following is a non-exhaustive list. It is provided only for the sake of clarity. If some function, mechanism or feature is not mentioned here, and it is not mentioned in the Scope of Work section either, then it will be deemed to be out of scope.
The TC will not define a mapping of the functions and elements described in the specifications to any programming language, to any particular messaging middleware, nor to specific network transports.
The following items are specifically out of scope of the work of the TC:
1. Definition and management of trust policy expressions (that is, statements about who is trusted to make what claims about an entity); these are different from the in-scope "Policy assertions" referred to in the Scope of Work section above.
2. Mechanisms and protocols for establishing federations beyond those described in the input document.
3. Definition of specific authorization context data used in federation extensions to WS-Trust .
4. Definition of specific claim types represented using common claims dialect extensions described in the Authorization section above.
5. Specific contents of shared domain cookies used in home realm discovery and mechanisms used to obtain them.
6. Definition of claim types carried in privacy parameters as described in the Privacy section above.
7. Definition of the form and content of privacy statements.
8. Token revocation notifications and revocation management (e.g., via CRLs).
9. Schemas for specific tokens issued, renewed, cancelled or validated as part of the trust process.
10. The establishment of trust between two or more business parties.
11. Definition of new key derivation algorithms.
12. Definition or description of the contents and use of status messages in response to sign-out messages.
13. Definition or description of a specific type of attribute service or a specific data organization or repository for implementing an attribute service or the protocol for accessing such a service.
14. Definition or description of the types or contents of attribute data elements to be provided by an attribute service.
15. Definition or description of an interface or protocol for communicating with an attribute service.
16. Definition or description of a specific data organization or repository for implementing a pseudonym service.
17. Definition of additional negotiation and challenge protocol mechanisms
The TC will not attempt to define concepts or renderings for functions that are of wider applicability including but not limited to:
- Policy language frameworks and attachment mechanisms
- Reliable message exchange
- Transactions and compensation
- Secure Conversations
- Metadata Exchange
- Resource Transfer
Where required these functions are achieved by composition with other Web services specifications.
The TC will not attempt to define functionality duplicating that of any normatively referenced specification in the input WS-Federation Version 1.1 . If the referenced specification is outside of a standardization process at the time this TC moves to ratify its deliverables, or is not far along enough in the standardization process, any normative references to it in the TC output will be expressed in an abstract manner, and the incarnation will be left at that time as an exercise in interoperability.
The TC has the following set of deliverables:
A revised Web Services Federation Version 1.2 specification and associated Schemas and WSDL. A Committee Specification is scheduled for completion within 18 months of the first TC meeting.
These specifications will reflect refinements, corrections or material technological improvements with respect to the input documents and in accordance with this charter.
Ratification of the above specification as an OASIS standard, including a brief period to address any errata will mark the end of the TC's lifecycle.
The anticipated audience for this work includes:
- Vendors offering Web services products
- Other specification authors that need federation capabilities for Web services such as those described in the WS-Federation 
- Software architects and programmers, who design, write or integrate applications for Web services
- End users implementing Web services-based solutions that require advanced federation mechanisms
TC business will be conducted in English.
This TC will operate under the "RF (Royalty Free) on RAND Terms" IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy, effective 15 April 2005.
As the specifications developed by the WSFED TC are part of the Web services Architecture, and must work well with other specifications within that architecture, the following work may be relevant to this WSFED TC:
The specifications developed by the WSFED TC address functionality required for Web services that is not addressed in other security related activities. The WSFED TC will be informed by the following:
- Internet X.509 Public Key Infrastructure Qualified Certificates Profile 
- ITU-T Recommendation X.509 
- The Kerberos Network Authentication Service  from IETF
- Security Requirements for Cryptographic Modules , from NIST
- Security Assertion Markup Language (SAML)  from OASIS
- The Liberty Identity Web Services Framework (ID-WSF) , 
The proposers of this TC recognize there are other possible approaches to federation and believe that the defined Scope of Work of this TC addresses many functional use cases of these parallel efforts. The proposers of this TC seek involvement from authors of other such activities and the contribution of their expertise and experience, and intend to work in harmony with them in the creation of the product of this technical committee.
- OASIS Web Services Security (WSS) TC. The WSFED TC will ensure that its specifications compose with the WSS TC specifications.
- OASIS Web Services Secure Exchange (WS-SX) TC. The WSFED TC will ensure that its specifications compose with the WS-SX TC specifications.
- W3C WS-Policy Working Group. The WSFED TC will ensure that its specifications compose with the W3C WS-Policy Working Group specifications.
The TC may decide to establish liaisons with other groups as needed. Responsibilities for such liaison will be defined by the TC at that time.
The current WS-Federation Version 1.1 specification  is expected to be contributed to this TC by BEA Systems Inc., BMC Software, CA Inc., IBM Corporation, Layer 7 Technologies, Microsoft Corporation, Novell Inc., and VeriSign Inc.
The first meeting of the WS-SX TC will be a two day face to face meeting held in Redmond, WA on Wednesday and Thursday, June 6-7, 2007 from 9:00 am to 5:30 pm local time. This meeting will be sponsored by Microsoft Corporation.
It is anticipated the WSFED Technical Committee will meet via teleconference every week at a time determined by the TC members during the TC's first meeting.
It is anticipated that the WSFED Technical Committee will meet face to face, every quarter if needed, at a time and location to be determined by the TC members.
Actual frequency of face to face and teleconference meetings will be determined by TC members.
One of the proposers, as listed below, will sponsor the teleconferences unless other TC members offer to donate their own facilities. If no other TC proposers offer to sponsor teleconference facilities, Microsoft or IBM will donate their facilities. If OASIS establishes a phone bridge system as is being discussed, the TC will consider use of that bridge system.
The following eligible individuals are in support of this proposal:
- Don Adams, Tibco, email@example.com
- Steve Anderson, BMC, firstname.lastname@example.org
- Siddharth Bajaj, VeriSign, email@example.com
- Abbie Barbir, Nortel, firstname.lastname@example.org
- Hanane Becha, Nortel, HANANEBE@nortel.com
- Jeff Bohren, BMC, email@example.com
- Toufic Boubez, Layer 7 Technologies, firstname.lastname@example.org
- Lloyd Burch, Novell, email@example.com
- Greg Carpenter, Microsoft, firstname.lastname@example.org
- Marco Carugi, Nortel, email@example.com
- David M. Connelly, Open Applications Group, firstname.lastname@example.org
- Paul Cotton, Microsoft, email@example.com
- Glen Daniels, Progress Software, firstname.lastname@example.org
- Doug Earl, Novell, email@example.com
- Alistair Farquharson , SOA, firstname.lastname@example.org
- Marc Goodner, Microsoft, email@example.com
- Tony Gullotta, SOA, firstname.lastname@example.org
- Phillip Hallam-Baker, VeriSign, email@example.com
- Patrick Harding, Ping Identity, firstname.lastname@example.org
- Mike Kaiser, IBM, email@example.com
- Chris Kaler, Microsoft, firstname.lastname@example.org
- Dana Kaufman, Forum Systems, email@example.com
- Paul Knight, Nortel, firstname.lastname@example.org
- Hal Lockhart, BEA Systems, email@example.com
- Jim Hosmer, Lockheed Martin Corporation, firstname.lastname@example.org
- Kelvin Lawrence, IBM, email@example.com
- Mark Little, Red Hat, firstname.lastname@example.org
- Michael McIntosh, IBM, email@example.com
- Jonathan Marsh, WSO2, firstname.lastname@example.org
- K Scott Morrison, Layer 7 Technologies, Inc., email@example.com
- Anthony Nadalin, IBM firstname.lastname@example.org
- Eric Newcomer, IONA, Eric.Newcomer@iona.com
- Kim Pease, Active Endpoints, email@example.com
- Jason Rouault, HP, firstname.lastname@example.org
- Don Schmidt, Microsoft, email@example.com
- Sameer Sharma, Lockheed Martin Corporation, firstname.lastname@example.org
- Yakov Sverdlov, CA, Yakov.Sverdlov@ca.com
- Gene Thurston, AmberPoint, email@example.com
- Greg Whitehead, HP, firstname.lastname@example.org
- Prasad Yendluri, webMethods, email@example.com
[Editor's Note: A couple dubious links have been fixed up in this unofficial version of the proposal; see the canonical source.]
 WS-Federation Version 1.1
"Web Services Federation Language" Version 1.1, December 2006
MSDN Web Services Security Specifications Index Page:
IBM Developer Works SOA and Web Services - WS-Federation Language Page:
VeriSign Web Services Security Page:
 WS-Security Version 1.0
OASIS Standard, "Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)", March 2004
WS-Security: SAML Token Profile 1.0
OASIS Standard, "Web Services Security: SAML Token Profile", December 2004
WS-Security: REL Token Profile 1.0
OASIS Standard, "Web Services Security: Rights Expression Language (REL) Token Profile", December 2004
OASIS Committee Draft, "WS-SecureConversation 1.3", September 2006
OASIS Committee Draft, "WS-SecurityPolicy 1.3", September 2006
W3C Member Submission "Web Services Policy 1.2 - Framework", 25 April 2006
 WS-Security Version 1.1
OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)", February 2006
WS-Security: SAML Token Profile 1.0
OASIS Standard, "Web Services Security: SAML Token Profile 1.1", December 2006
WS-Security: X.509 Certificate Token Profile 1.1
OASIS Standard, "Web Services Security: X.509 Certificate Token Profile 1.1", February 2006
WS-Security: Kerberos Token Profile 1.1
OASIS Standard, "Web Services Security: Kerberos Token Profile 1.1", February 2006
WS-Security: UsernameToken Profile 1.1
OASIS Standard, "Web Services Security: Username Token Profile 1.1", February 2006
WS-Security: REL Token Profile 1.1
OASIS Standard, "Web Services Security: Rights Expression Language (REL) Token Profile1.1", February 2006
WS-Security: SwAProfile 1.1
OASIS Standard, "Web Services Security: SOAP Messages with Attachments (SwA) Profile 1.1", February 2006
 WS -ReliableMessaging
OASIS Committee Draft "Web Services Reliable Messaging (WS-ReliableMessaging)", August 2006
W3C Recommendation, "Web Services Addressing (WS-Addressing)", 9 May 2006
Web Services Transfer (WS-Transfer), 27 September 2006
W3C Member Submission, "Web Services Resource Transfer (WS-ResourceTransfer)", August 2006
W3C Member Submission, "Web Services Eventing (WS-Eventing)", 15 March 2006
 SOAP 1.2
W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework", June 2003
 WS-I Basic Profile 1.1
WS-I Final Material, "Basic Profile Version 1.1", 2006-04-10
 WS-I Basic Security Profile 1.1
WS-I Final Material, "Basic Security Profile Version 1.1", 2006-04-10
 Secure, Reliable, Transacted Web Services: Architecture and Composition
 Security in a Web Services World: A Proposed Architecture and Roadmap
 XML Schema
W3C Recommendation, "XML Schema Part 1: Structures Second Edition", October 2004
W3C Recommendation, XML Schema Part 2: Datatypes Second Edition", October 2004
 WS-Coordination 1.1
OASIS Committee Specification, "Web Services Coordination (WS-Coordination) 1.1", December 2006
 WS-AtomicTransaction 1.1
OASIS Committee Specification, "Web Services Atomic Transaction (WS-AtomicTransaction) 1.1", December 2006
 WS-BusinessActivity 1.1
OASIS Committee Specification, "Web Services Business Activity (WS-BusinessActivity) 1.1", November 2006
 ITU-T Recommendation X.509 (2000)
 Security Requirements for Cryptographic Modules, May 2001. See:
 W3C Recommendation, "XML-Signature Syntax and Processing", 12 February 2002
 Liberty Identity Web Services Framework (ID-WSF)
 Liberty ID-WSF Authentication Service Specification
Prepared by Robin Cover for The XML Cover Pages archive. See other details in the news story "Proposed Charter: OASIS Web Services Federation (WSFED) Technical Committee."