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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

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


Subject: RE: Web Services Federation (WSFED) TC Pre-Launch Teleconference


To help with the WSFED TC pre-launch teleconference, I have organized all of the comments on the charter into a single document which I have attached to this message.

/paulc
WSFED TC Convener

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (613) 225-5445 Fax: (425) 936-7329
mailto:Paul.Cotton@microsoft.com





> -----Original Message-----
> From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
> Sent: April 2, 2007 1:24 PM
> To: oasis-charter-discuss@lists.oasis-open.org
> Cc: 'Staff-Standards'; Paul Cotton; Greg Carpenter
> Subject: Web Services Federation (WSFED) TC Pre-Launch Teleconference
>
> 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/defa
> ult.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/advancedwe
> bserv
> 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
>
>
>

OASIS WSFED Comment Log.pdf



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