A conference call has been scheduled for Thursday, 5 April 2007 at 11amEDT / 8amPDT to discuss the proposed charter for
the OASIS Web Services Federation (WSFED) Technical Committee.
Participants include the TC Convenor, the OASIS TC Administrator, and optionally other members of OASIS staff and TC
Proposers. Other interested OASIS Members are invited to observe.
Call in details:
US dial in: +1-605-475-8500
Skype: +9900 827 5537644
Conference Room Number: 5537644
The proposed charter is included below for reference.
Regards,
Mary
---------------------------------------------------
Mary P McRae
Manager of TC Administration, OASIS
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org
phone: 603.232.9090
---------------------------------------------------
===========
PROPOSED CHARTER FOR REVIEW AND COMMENT
OASIS WEB SERVICES FEDERATION (WSFED) TECHNICAL COMMITTEE
a. Name of the TC
OASIS Web Services Federation (WSFED) Technical Committee
b. 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.
c. 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+AF0AOw- 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.
d. 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.
e. 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.
f. Language
TC business will be conducted in English.
g. 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.
--- REQUIRED NON-NORMATIVE INFORMATION ---
a. 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.
b. 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.
c. 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.
d. On-Going Meeting Plans & 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.
e. 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
f. TC Convener
The TC Convener will be Paul Cotton, Microsoft Corporation,
pcotton@microsoft.com
References
[1] WS-Federation Version 1.1
"Web Services Federation Language" Version 1.1, December 2006
MSDN Web Services Security Specifications Index Page:
http://msdn.microsoft.com/webservices/webservices/understanding/specs/default.a
spx?pull+AD0-/library/en-us/dnglobspec/html/wssecurspecindex.asp
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
2006http://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
2006http://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 2006http://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 +ACY- Composition
http://msdn.microsoft.com/webservices/webservices/understanding/advancedwebserv
ices/default.aspx?pull+AD0-/library/en-us/dnwebsrv/html/wsoverview.asp
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://msdn.microsoft.com/library/default.asp?url+AD0-/library/en-
us/dnwssecur/html/securitywhitepaper.asp
http://www-128.ibm.com/developerworks/library/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