OASIS Charter Submission Discuss

Expand all | Collapse all

Web Services Federation (WSFED) TC Pre-Launch Teleconference

  • 1.  Web Services Federation (WSFED) TC Pre-Launch Teleconference

    Posted 04-02-2007 17:24
    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
    
    
     
    
    


  • 2.  RE: Web Services Federation (WSFED) TC Pre-Launch Teleconference

    Posted 04-05-2007 12:15
      |   view attached

    Attachment(s)

    pdf
    OASIS WSFED Comment Log.pdf   214 KB 1 version