Name of the TC

OASIS Web Services Federation (WSFED) Technical Committee

Statement of Purpose

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 [2] [7], WS-SecureConversation [3], WS-Trust [4] WS-SecurityPolicy [5]) 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 [1] submitted to the TC as referenced in this charter.

Scope of Work

The TC will accept as input the December 2006 Version 1.1 of the WS-Federation specification [1] (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 [2] [7], WS-SecureConversation [3], WS-Trust [4] and WS-SecurityPolicy [5]. 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 [2] [7], WS-SecureConversation [3], WS-Trust [4] and WS-SecurityPolicy [5], 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.

Federation Overview

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 [4] 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 [4] 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 [4] 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 [4] 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.

Federation Model

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 [4].

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 [4], WS-SecureConversation [3] and WS-Security [2] [7], 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 [4] 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 [4] based Security Token Services. This includes defining an interface that pseudonym services should support to ensure interoperability with WS-Trust [4] based Security Token Services and other service providers in a federation.

Federation Metadata

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 [12], 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 [9] where associated attribute services can be contacted

b. Metadata statements which Security Token Services can specify to indicate:

i. Key(s) the Security Token Service uses to sign tokens specified by a SecurityTokenReference element as defined in [WS-Security] [2] [7]

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 [9] for use in accessing associated pseudonym services

vi. Endpoint references as defined in WS-Addressing [9] 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:

i. Key(s) that should be used when encrypting key material targeted for this participant specified by a SecurityTokenReference as defined in [WS-Security] [2] [7]

ii. Token issuers the participant trusts, based either on a specific endpoint reference as defined in WS-Addressing [9] or the namespace for which the issuer is authoritative

iii. Endpoint references as defined in WS-Addressing [9] 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 [31].

5. Describing the use of WSDL extensibility mechanisms and the attachment mechanisms defined in WS-PolicyAttachment [13] 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

c. WS-Transfer [10] "Get" to an endpoint as described in WS-MetadataExchange [12], possibly using WS-ResourceTransfer [11] extensions to filter the information returned

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 [9] 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 [12].

11. Describing the considerations that should be applied to keys used for signing federation metadata documents.

Federated Sign-Out

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 [4] 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 [14] 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 [14].

Attribute Services

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 [6] and WS-PolicyAttachment [13].

Pseudonym Services

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 [10] and extensions defined in WS-ResourceTransfer [11] to create, update, delete, and retrieve pseudonyms and to control the scope of operations performed on a pseudonym store.

Security Tokens and Pseudonyms

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 [4] 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.

Federation Extensions to WS-Trust

Interactions between participants in a federation may be facilitated by some general purpose extensions to the token exchange mechanisms defined in WS-Trust [4].

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 [4] 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.

b. Describing how a reference token is used with WS-Security [2] [7], to associate the reference token with a protected message

c. Describing how a Security Token Service may return a reference token in a WS-Trust [4] RSTR

d. Describing how the actual token may be obtained using mechanisms defined in WS-Transfer [10] and extension defined in WS-ResourceTransfer [11]

2. Defining the syntax to scope RST/RSTR messages, as defined in WS-Trust [4], 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 [4] RequestedProofToken be returned by the Security Token Service.

4. Defining extensions to RST messages, as defined in WS-Trust [4] 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 [4] 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.

Authorization

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 [4], 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 [4] 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 [4]. 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 [4] 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 [9].

b. Additional authorization context described above.

c. The common claim dialect described above.

Indicating Specific Policy/Metadata

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.

Authentication Types

The WS-Trust [4] 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.

Privacy

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 [4] 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.

4. Defining a mechanism by which privacy statements can be obtained using mechanisms defined in HTTP, HTTPS, WS-Transfer [10], WS-ResourceTransfer [11], WS-Policy [6] or WS-MetadataExchange [12].

Web (passive) Requestors

For Web services the sections above describe extensions to WS-Trust [4] 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 [4] 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 [4] 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 [4] RST/RSTR messages. This includes describing:

i. How a Resource Provider can "send" a WS-Trust [4] RST request by redirecting the web browser to a trusted Identity Provider.

ii. How an Identity Provider can return a WS-Trust [4] RSTR response directly to the Resource Provider in a POST body.

iii. How an Identity Provider can return a handle to a WS-Trust [4] 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 [4].

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 [4] 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 [10] and WS-ResourceTransfer [11] 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 [4] 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 [4] 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.

Additional Policy Assertions

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 [6] to indicate that a relying party will accept a reference token instead of an actual token for WS-Security [2] [7] 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 [6] 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 [6] 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.

General Notes on Scope

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 [23].

Out of Scope

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

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

18. Developing the roadmaps [21], [22] or other specifications mentioned in those roadmaps, beyond the material listed explicitly as within the scope of this charter.

The TC will not attempt to define concepts or renderings for functions that are of wider applicability including but not limited to:

• Addressing
• Policy language frameworks and attachment mechanisms
• Routing
• Reliable message exchange
• Transactions and compensation
• Trust
• 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 [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.

Deliverables

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.

Anticipated Audience

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 [1]
• 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

Language

TC business will be conducted in English.

IPR Policy

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.

---

Related Work

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:

Similar Work

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 [28]
• ITU-T Recommendation X.509 [28]
• The Kerberos Network Authentication Service [29] from IETF
• Security Requirements for Cryptographic Modules [30], from NIST
• Security Assertion Markup Language (SAML) [32] from OASIS
• The Liberty Identity Web Services Framework (ID-WSF) [33], [34]

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.

Applicable Work

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

Anticipated Contributions

The current WS-Federation Version 1.1 specification [1] 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.

Date and Time of First Meeting

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.

Ongoing Meeting Plans and Sponsors

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.

Proposers of the TC

The following eligible individuals are in support of this proposal:

• Don Adams, Tibco, dadams@tibco.com
• Steve Anderson, BMC, steve.anderson@bmc.com
• Siddharth Bajaj, VeriSign, sbajaj@verisign.com
• Abbie Barbir, Nortel, abbieb@nortel.com
• Hanane Becha, Nortel, HANANEBE@nortel.com
• Jeff Bohren, BMC, jeff.bohren@bmc.com
• Toufic Boubez, Layer 7 Technologies, tboubez@layer7tech.com
• Lloyd Burch, Novell, lburch@novell.com
• Greg Carpenter, Microsoft, gregcarp@microsoft.com
• Marco Carugi, Nortel, marco.carugi@nortel.com
• David M. Connelly, Open Applications Group, dconnelly@openapplications.org
• Paul Cotton, Microsoft, pcotton@microsoft.com
• Glen Daniels, Progress Software, gdaniels@progress.com
• Doug Earl, Novell, dearl@novell.com
• Alistair Farquharson , SOA, alistair.farquharson@soa.com
• Marc Goodner, Microsoft, mgoodner@microsoft.com
• Tony Gullotta, SOA, tony.gullotta@soa.com
• Phillip Hallam-Baker, VeriSign, pbaker@verisign.com
• Patrick Harding, Ping Identity, pharding@pingidentity.com
• Mike Kaiser, IBM, mkaiser@us.ibm.com
• Chris Kaler, Microsoft, ckaler@microsoft.com
• Dana Kaufman, Forum Systems, dkaufman@forumsys.com
• Paul Knight, Nortel, paul.knight@nortel.com
• Hal Lockhart, BEA Systems, hlockhar@bea.com
• Jim Hosmer, Lockheed Martin Corporation, james.b.hosmer@lmco.com
• Kelvin Lawrence, IBM, klawrenc@us.ibm.com
• Mark Little, Red Hat, mark.little@jboss.com
• Michael McIntosh, IBM, mikemci@us.ibm.com
• Jonathan Marsh, WSO2, jonathan@wso2.com
• K Scott Morrison, Layer 7 Technologies, Inc., smorrison@layer7tech.com
• Anthony Nadalin, IBM drsecure@us.ibm.com
• Eric Newcomer, IONA, Eric.Newcomer@iona.com
• Kim Pease, Active Endpoints, kim.pease@active-endpoints.com
• Jason Rouault, HP, jason.rouault@hp.com
• Don Schmidt, Microsoft, donsch@microsoft.com
• Sameer Sharma, Lockheed Martin Corporation, sameer.sharma@lmco.com
• Yakov Sverdlov, CA, Yakov.Sverdlov@ca.com
• Gene Thurston, AmberPoint, gthurston@amberpoint.com
• Greg Whitehead, HP, greg.whitehead@hp.com
• Prasad Yendluri, webMethods, prasad.yendluri@webmethods.com

TC Convener

The TC Convener will be Paul Cotton, Microsoft Corporation, pcotton@microsoft.com

References

[Editor's Note: A couple dubious links have been fixed up in this unofficial version of the proposal; see the canonical source.]

[1] WS-Federation Version 1.1
"Web Services Federation Language" Version 1.1, December 2006

MSDN Web Services Security Specifications Index Page:
http://msdn2.microsoft.com/en-us/library/ms951273.aspx

IBM Developer Works SOA and Web Services - WS-Federation Language Page:
http://www.ibm.com/developerworks/webservices/library/specification/ws-fed/

VeriSign Web Services Security Page:
http://www.verisign.com/research/Security.Research/DEV036564.html

[2] WS-Security Version 1.0
OASIS Standard, "Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)", March 2004
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

WS-Security: SAML Token Profile 1.0
OASIS Standard, "Web Services Security: SAML Token Profile", December 2004
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf

WS-Security: REL Token Profile 1.0
OASIS Standard, "Web Services Security: Rights Expression Language (REL) Token Profile", December 2004
http://docs.oasis-open.org/wss/oasis-wss-rel-token-profile-1.0.pdf

[3] WS-SecureConversation
OASIS Committee Draft, "WS-SecureConversation 1.3", September 2006
http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512

[4] WS-Trust
OASIS Committee Draft, "WS-Trust 1.3", September 2006
http://docs.oasis-open.org/ws-sx/ws-trust/200512

[5] WS-SecurityPolicy
OASIS Committee Draft, "WS-SecurityPolicy 1.3", September 2006
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512

[6] WS-Policy
W3C Member Submission "Web Services Policy 1.2 - Framework", 25 April 2006
http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/

[7] WS-Security Version 1.1
OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)", February 2006
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

WS-Security: SAML Token Profile 1.0
OASIS Standard, "Web Services Security: SAML Token Profile 1.1", December 2006
http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf

WS-Security: X.509 Certificate Token Profile 1.1
OASIS Standard, "Web Services Security: X.509 Certificate Token Profile 1.1", February 2006
http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf

WS-Security: Kerberos Token Profile 1.1
OASIS Standard, "Web Services Security: Kerberos Token Profile 1.1", February 2006
http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf

WS-Security: UsernameToken Profile 1.1
OASIS Standard, "Web Services Security: Username Token Profile 1.1", February 2006
http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf

WS-Security: REL Token Profile 1.1
OASIS Standard, "Web Services Security: Rights Expression Language (REL) Token Profile1.1", February 2006
http://www.oasis-open.org/committees/download.php/16687/oasis-wss-rel-token-profile-1.1.pdf

WS-Security: SwAProfile 1.1
OASIS Standard, "Web Services Security: SOAP Messages with Attachments (SwA) Profile 1.1", February 2006
http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf

[8] WS -ReliableMessaging
OASIS Committee Draft "Web Services Reliable Messaging (WS-ReliableMessaging)", August 2006
http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf

[9] WS-Addressing
W3C Recommendation, "Web Services Addressing (WS-Addressing)", 9 May 2006
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509

[10] WS-Transfer
Web Services Transfer (WS-Transfer), 27 September 2006
http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/

[11] WS-ResourceTransfer
W3C Member Submission, "Web Services Resource Transfer (WS-ResourceTransfer)", August 2006
http://schemas.xmlsoap.org/ws/2006/08/resourceTransfer/

[12] WS-Metadata Exchange
Web Services Metadata Exchange (WS-MetadataExchange), August 2006
http://schemas.xmlsoap.org/ws/2004/09/mex/

[13] WS-PolicyAttachment
W3C Member Submission "Web Services Policy 1.2 - Attachment", 25 April 2006
http://www.w3.org/Submission/WS-PolicyAttachment/

[14] WS-Eventing
W3C Member Submission, "Web Services Eventing (WS-Eventing)", 15 March 2006
http://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/

[15] SOAP 1.1
W3C Note, "Simple Object Access Protocol (SOAP) 1.1", May 2000
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

[16] SOAP 1.2
W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework", June 2003
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/

[17] WSDL 1.1
W3C Note, "Web Services Description Language (WSDL) 1.1", March 2001
http://www.w3.org/TR/2001/NOTE-wsdl-20010315

[18] WSDL 2.0
W3C Candidate Recommendation, " Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language", March 2006
http://www.w3.org/TR/wsdl20/

[19] WS-I Basic Profile 1.1
WS-I Final Material, "Basic Profile Version 1.1", 2006-04-10
http://www.ws-i.org/Profiles/BasicProfile-1.1.html

[20] WS-I Basic Security Profile 1.1
WS-I Final Material, "Basic Security Profile Version 1.1", 2006-04-10
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1-2006-10-19.html

[21] Secure, Reliable, Transacted Web Services: Architecture and Composition
http://msdn2.microsoft.com/en-us/library/ms996535.aspx
http://www-128.ibm.com/developerworks/webservices/library/ws-securtrans/index.html

[22] Security in a Web Services World: A Proposed Architecture and Roadmap
http://msdn2.microsoft.com/en-us/library/ms977312.aspx
http://www-128.ibm.com/developerworks/library/specification/ws-secmap/

[23] XML Schema
W3C Recommendation, "XML Schema Part 1: Structures Second Edition", October 2004
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/

W3C Recommendation, XML Schema Part 2: Datatypes Second Edition", October 2004
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

[24] WS-Coordination 1.1
OASIS Committee Specification, "Web Services Coordination (WS-Coordination) 1.1", December 2006
http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.1-spec-cs-01.pdf

[25] WS-AtomicTransaction 1.1
OASIS Committee Specification, "Web Services Atomic Transaction (WS-AtomicTransaction) 1.1", December 2006
http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec-cs-01.pdf

[26] WS-BusinessActivity 1.1
OASIS Committee Specification, "Web Services Business Activity (WS-BusinessActivity) 1.1", November 2006
http://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-spec-pr-01.pdf

[27] XPath 1.0
W3C Recommendation, "XML Path Language (XPath) Version 1.0", November 1999
http://www.w3.org/TR/1999/REC-xpath-19991116

[28] ITU-T Recommendation X.509 (2000)
http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/2000/index.html
March 2000

[29] J. Kohl and C. Neuman
"The Kerberos Network Authentication Service 311 (V5)," RFC 1510, September 1993
http://www.ietf.org/rfc/rfc1510.txt

[30] Security Requirements for Cryptographic Modules, May 2001. See:
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

[31] W3C Recommendation, "XML-Signature Syntax and Processing", 12 February 2002
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

[32] Security Assertion Markup Language (SAML)
http://www.oasis-open.org/committees/security/

[33] Liberty Identity Web Services Framework (ID-WSF)
http://www.projectliberty.org/resources/specifications.php

[34] Liberty ID-WSF Authentication Service Specification
http://www.projectliberty.org/specs/draft-liberty-idwsf-authn-svc-v2.0-02.pdf

[Source:
oasis-charter-discuss
tc-announce
members]

---

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

---