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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tc-announce message

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


Subject: Proposed Charter for OASIS Web Services Federation (WSFED) TC


To OASIS Members:

  A draft TC charter has been submitted to establish the Web Services Federation (WSFED) Technical Committee. In
accordance with the OASIS TC Process Policy section 2.2: 
(http://www.oasis-open.org/committees/process.php#2.2) the proposed charter is hereby submitted for comment. The comment
period shall remain open until 11:45 pm EDT on 2 April 2007. 

  OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post
to this list by sending email to:
mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly archived at: 
http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by
selecting "join group" on the group home page:
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require
primary representative approval to subscribe to the oasis-charter-discuss e-mail.

  A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to
attend within four days of the close of the comment period. The announcement and call-in information will be noted on
the OASIS Charter Discuss Group Calendar.

  We encourage member comment and ask that you note the name of the proposed TC (WSFED) in the subject line of your
email message. 

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
 
OASIS Symposium:
"eBusiness and Open Standards: 
Understanding the Facts, Fiction, and Future"
15-18 April 2007 San Diego, CA USA
http://www.oasis-open.org/events/symposium/

===========
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


 



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