[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [board] Proposed Charter for OASIS Web Services Federation (WSFED) TC
In response to the request for OASIS member comment on the proposed WS-Federation charter [1] Nokia notes the following concerns. The proposed WS-Federation charter: 1. Normatively references numerous private specifications that are not standards and not in the standards process (or are only submissions): WS-Transfer, WS-ResourceTransfer, WS-MetadataExchange, WS-Eventing, 2. Normatively references IBM/Microsoft roadmaps as "the web architecture", 3. Specifies that the WS-Fed TC will define how canonicalization is to be performed with XML Signature, despite the existence of the W3C XML Security Specifications Maintenance WG [2] for this purpose, 4. Incorrectly references WS-Trust and WS-SecureConversation committee drafts rather than OASIS standards, 5. References the WS-Policy submissions rather than W3C WS-Policy CR, and without mentioning that the WS-Policy Recommendations are to be referenced when completed, 6. References committee specifications, instead of standards: WS- ReliableMessaging, WS-Coordination, WS-AtomicTransation, WS- BusinessActivity, 7. May need to better address the risk of all the chartered work being completed within the 18 months allocated, and 8. Includes some strange characters in the charter text: "t [4 +AF0AOw- that". Thank you regards, Frederick Frederick Hirsch Nokia [1] <http://lists.oasis-open.org/archives/members/200703/msg00018.html> [2] <http://www.w3.org/2005/Security/xmlsig-charter> On Mar 19, 2007, at 7:18 PM, ext Mary McRae wrote: > To OASIS Members: > > A draft TC charter has been submitted to establish the Web > Services Federation (WSFED) Technical Committee. In > accordance with the OASIS TC Process Policy section 2.2: > (http://www.oasis-open.org/committees/process.php#2.2) the proposed > charter is hereby submitted for comment. The comment > period shall remain open until 11:45 pm EDT on 2 April 2007. > > OASIS maintains a mailing list for the purpose of submitting > comments on proposed charters. Any OASIS member may post > to this list by sending email to: > mailto:oasis-charter-discuss@lists.oasis-open.org. All messages > will be publicly archived at: > http://lists.oasis-open.org/archives/oasis-charter-discuss/. > Members who wish to receive emails must join the group by > selecting "join group" on the group home page: > http://www.oasis-open.org/apps/org/workgroup/oasis-charter- > discuss/. Employees of organizational members do not require > primary representative approval to subscribe to the oasis-charter- > discuss e-mail. > > A telephone conference will be held among the Convener, the OASIS > TC Administrator, and those proposers who wish to > attend within four days of the close of the comment period. The > announcement and call-in information will be noted on > the OASIS Charter Discuss Group Calendar. > > We encourage member comment and ask that you note the name of the > proposed TC (WSFED) in the subject line of your > email message. > > Regards, > > Mary > > --------------------------------------------------- > Mary P McRae > Manager of TC Administration, OASIS > email: mary.mcrae@oasis-open.org > web: www.oasis-open.org > phone: 603.232.9090 > > OASIS Symposium: > "eBusiness and Open Standards: > Understanding the Facts, Fiction, and Future" > 15-18 April 2007 San Diego, CA USA > http://www.oasis-open.org/events/symposium/ > > =========== > PROPOSED CHARTER FOR REVIEW AND COMMENT > > OASIS WEB SERVICES FEDERATION (WSFED) TECHNICAL COMMITTEE > > a. Name of the TC > > OASIS Web Services Federation (WSFED) Technical Committee > > b. Statement of Purpose > > The purpose of the Web Services Federation (WSFED) Technical > Committee (TC) is > to extend the basic federation capabilities enabled by Web service > Security > specifications (WS-Security [2,7], WS-SecureConversation [3], WS- > Trust [4] WS- > SecurityPolicy [5]) to provide advanced federation capabilities. > This includes, > but is not limited to: structure and acquisition of federation > metadata; sign- > out notifications; the use of pseudonym and identity mapping > services and > attribute services in conjunction with Security Token Services; > claims-based > authorization; and protection of a principal's privacy with respect > to claims > asserted in security tokens. In addition, the TC will define an HTTP > serialization mechanism allowing the richness of WS-Trust security > token based > mechanisms for SOAP Web services - brokered trust relationships and > distributed > authentication and authorization - to be used in browser-based > scenarios. This > work will be carried out through continued refinement of the Web > Services > Federation Language Version 1.1 specification [1] submitted to the > TC as > referenced in this charter. > > c. Scope of Work > > The TC will accept as input the December 2006 Version 1.1 of the WS- > Federation > specification [1] (the Input document) as published by BEA Systems > Inc., BMC > Software, CA Inc., IBM Corporation, Layer 7 Technologies, Microsoft > Corporation, Novell Inc., and VeriSign Inc. Other contributions and > changes to > the input documents will be accepted for consideration without any > prejudice or > restrictions and evaluated based on technical merit in so far as > they conform > to this charter. OASIS members with extensive experience and > knowledge in these > areas are particularly invited to participate. > > To facilitate the establishment of federations across organizational > boundaries, and to extend the scope of identity management and > security > benefits provided by Security Token Services, additional facilities > are needed > beyond what is provided in WS-Security [2,7], WS-SecureConversation > [3], WS- > Trust [4] and WS-SecurityPolicy [5]. These specifications describe > mechanisms > for using security tokens to broker trust and secure message > exchanges between > SOAP Web services, and for using policy to express the security > tokens required > by a service. Building on the foundation of WS-Security [2,7], WS- > SecureConversation [3], WS-Trust [4] and WS-SecurityPolicy [5], a > federation > protocol should include mechanisms for a Security Token Service to > advertise > the details of the tokens it can issue (e.g. token and claim > types). A > federation protocol should also address the relationship of > advanced federation > services (e.g., Pseudonym services or Authorization services) to > baseline > Security Token Services. In addition, a federation protocol should > describe > the message syntax and protocol extensions that participants in a > federation > must use to communicate with these advanced federation services and > the > security policy extensions that should be supported for successful > interaction > with such services. > > The following sub-sections describe the charter of the Web Services > Federation > (WSFED) TC with respect to these areas. The scope of the TC's work > is to > continue further refinement and finalization of the Input Documents > to produce > as output modular specifications that standardize the concepts, > WSDL documents > and XML Schema renderings of the areas described below. > > Federation Overview > > A federation is a collection of realms (security domains) that have > established > relationships whereby a Resource Provider in one realm can provide > authorized > access to a resource it manages based on statements about a > principal (such as > identity or other distinguishing attributes) that are asserted by > an Identity > Provider (or any Security Token Service in another realm). The > terms Identity > Provider and Security Token Service are used synonymously in this > charter and > work description. > > WS-Trust [4] provides the foundation for federation by enabling > Security Token > Services to broker trust between a Resource Provider and other service > providers that are prepared to vouch for the identity, pseudonyms > or other > attributes which they have associated with a specific principal. > WS-Trust [4] > introduces protocol mechanisms independent of any particular > application for > requesting, issuing, renewing and validating security tokens which > can be > exchanged to authenticate principals and protect resources. > > Building on the WS-Trust [4] foundation a Federation protocol > provides > mechanisms that simplify interactions between the participants. A > well- > documented method for exchanging federation metadata makes it easy > to bootstrap > trust relationships and to determine policies for obtaining > services. Cross- > organizational identity mapping and distributed sign-out improve > the utility > and security of accessing federated service providers. Federation > protocol > extensions to WS-Trust [4] provide a framework for delivering > advanced services > by integrating pseudonym, attribute and claims-based authorization > services > with generic Security Token Services. Pseudonym services and the > claims-based > authorization model can be used to satisfy user privacy > requirements across > realm boundaries in a federation. A Resource Provider can describe > the set of > attributes required to access a resource and an Identity Provider > can assert > that a particular principal possesses those attributes, without > divulging the > actual identity of the principal. Finally, within the limitations > of standard > web browser clients, the security token based capabilities provided > by WS-Trust > and federation protocol extensions can be made accessible via HTTP 1.1 > mechanisms to be used in browser-only scenarios. > > Federation Model > > The basic goal of federation is to facilitate the sharing of > security principal > attributes across trust boundaries to establish a security context > (or a > federation context) for that principal which a relying party can > use to > grant/deny access to a resource. Establishing a federation context > when > Identity and Resource Providers operate in different realms > requires agreement > on what attributes are required and frequently requires agreement > on mechanisms > for securely transporting those attributes over unprotected > networks. It is > necessary for participants in a federation to communicate these > requirements > over a wide variety of trust and communication topologies. This > requires the > exchange of metadata describing endpoint references where services > may be > obtained, plus the security policies and communication requirements > that must > be observed when accessing those endpoints. The exchange of this > metadata is > further complicated because the participants in a single federation > may have > different policies and service providers may participate in multiple > federations. > > This work will focus on: > > 1. Describing techniques for establishing a federation context for > a principal > across organizational boundaries. This includes describing how a > common > digital identity might be shared by out-of-band mechanisms, or how > digital > identities managed by separate organizations might be mapped using > extensions > to WS-Trust [4]. > 2. Describing how federation metadata can be expressed, discovered and > retrieved to determine the policies of participants within a > federation with > whom a requestor is going to communicate. > 3. Describing how the security token exchange and usage patterns > provided by > WS-Trust [4], WS-SecureConversation [3] and WS-Security [2,7], can > be combined > and extended to trust relationships that enable advanced federation > services. > 4. Describing an abstract model for using attribute services in > conjunction > with WS-Trust [4] based Security Token Services. Describing > implementation or > communication details will not be addressed as indicated in the Out > of Scope > section below. > 5. Describing how pseudonym services may be used in conjunction > with WS-Trust > [4] based Security Token Services. This includes defining an > interface that > pseudonym services should support to ensure interoperability with > WS-Trust [4] > based Security Token Services and other service providers in a > federation. > > Federation Metadata > > Organizations typically decide to federate based on business or legal > relationships. After a federation has been created, the > participants must > publish and exchange configuration information (i.e. federation > metadata) that > allows them to identify the services exposed to participants in the > federation > and the policies for accessing them. For Web services, this > information can be > expressed as statements in federation metadata documents and may > include > endpoint references (EPRs) and security policies which list the > security tokens > and claims required to access those end points. A mechanism must be > established for determining the authenticity of metadata > documents. Since a > service may be exposed in multiple federations it must be possible > to identify > the metadata that applies to each distinct context. In addition, > it is > desirable to help automate this configuration process. > > This work will focus on: > > 1. Defining the XML document format of a federation metadata > document to > identify the services exposed to participants in the federation and > the > communication and security policies which must be satisfied for > accessing those > services. This includes describing mechanisms for naming and > referencing > specific metadata documents for distinct federations. > 2. Defining how to indicate the correct federation metadata > document, or the > correct section within a single document, when a participant is > active in > multiple federations. This includes defining a federation > identifier for > separating metadata for different federations in a single > document. It also > includes a reference mechanism for pointing to other federation > metadata using > URIs or Metadata Reference elements as defined in WS-Metadata > Exchange [12], as > well as, the rules that must be followed for combining federation > metadata > documents. This also includes defining how a metadata statement may be > associated with multiple different federations. > 3. Identifying the different roles that participants in a > federation may > perform: Requestors, Security Token Services and Service > Providers. This > includes defining the specific metadata statements that a > participant can > specify within a metadata document based on its role. These > statements include > the following cases. > a. Metadata statements which any role can specify to refer > requestors to: > i. Endpoints where metadata documents can be obtained > ii. Endpoint references as defined in WS-Addressing [9] > where > associated attribute services can be contacted > b. Metadata statements which Security Token Services can > specify to > indicate: > i. Key(s) the Security Token Service uses to sign tokens > specified by > a SecurityTokenReference element as defined in [WS-Security] [2,7] > ii. Types of tokens the Security Token Service can issue > iii. Types of claims the Security Token Service can issue > iv. Issuer namespace(s) for which the Security Token > Service is > authoritative > v. Endpoint references as defined in WS-Addressing [9] > for use in > accessing associated pseudonym services > vi. Endpoint references as defined in WS-Addressing [9] > for use in > accessing associated sign-out subscription services > vii. Policy with respect to automatic pseudonym mapping > c. Metadata statements which a Security Token Service or > relying party can > specify to indicate: > i. Key(s) that should be used when encrypting key > material targeted > for this participant specified by a SecurityTokenReference as > defined in [WS- > Security] [2,7] > ii. Token issuers the participant trusts, based either on > a specific > endpoint reference as defined in WS-Addressing [9] or the namespace > for which > the issuer is authoritative > iii. Endpoint references as defined in WS-Addressing [9] > for sending > sign-out notifications > 4. Describing how a digital signature should be used to ensure data > integrity > and authenticity of a federation metadata document so that the > document is > protected outside of a SOAP message exchange. This includes > describing the > required pairing of signature and canonicalization mechanisms that > must be > observed when signing with XML Digital Signature[31]. > 5. Describing the use of WSDL extensibility mechanisms and the > attachment > mechanisms defined in WS-PolicyAttachment [13] to publish a > federation metadata > document for retrieval by other participants in a federation. > 6. Describing how a federation metadata document may be published > for retrieval > by other participants in a federation using DNS mechanisms to > identify the > "default path" (i.e. network location) where the federation > metadata document > may be obtained. This includes defining DNS naming conventions for > constructing the default path and describing the use of DNS SRV > records for > locating servers on that path. > 7. Describing how a federation metadata document should be > retrieved by a > requestor. This includes describing the following transport > mechanisms that > may be used and the associated security considerations. > a. HTTP GET to a URL constructed from the default path > b. HTTPS GET to a URL constructed from the default path > c. WS-Transfer [10] "Get" to an endpoint as described in WS- > MetadataExchange [12], possibly using WS-ResourceTransfer [11] > extensions to > filter the information returned > 8. Describing the recommended order in which the transport > mechanisms for > retrieving federation metadata documents should be attempted. > 9. Defining the syntax for a header as defined in WS-Addressing [9] > that > requestors may use to enable service providers to optimize SOAP > requests for > federation metadata documents. > 10. Defining a dialect that must be used when retrieving federation > metadata > documents using the metadata unit inclusion mechanisms from WS- > MetadataExchange > [12]. > 11. Describing the considerations that should be applied to keys > used for > signing federation metadata documents. > > Federated Sign-Out > > The purpose of federated sign-out is to cause federation > participants to clean > up any cached state or security tokens for a principal that are no > longer > required because the principal's session is being terminated. > Federated sign- > out is different than token cancellation as defined in WS-Trust [4] > since > federated sign-out applies to all tokens and all target sites for > the principal > within the federation. > > This work will focus on: > > 1. Describing the advisory nature of the sign-out mechanism and > declaring that > correct operation of all participants in a federation must not > depend upon the > successful processing of sign-out messages. > 2. Defining a sign-out message and its recommended usage pattern. > This > includes defining a common syntax for the sign-out message > regardless of which > participant in the federation sends the message. > 3. Describing the processing model for both issuers and receivers > of sign-out > messages. This includes describing the potential failure cases if > messages are > delivered serially by chaining through all participants, and a > parallel > delivery mechanism to address these concerns. > 4. Describing how sign-out messages for a principal could be scoped to > different resources within a federation. This includes describing > both global > and selective sign-out mechanisms. > 5. Describing how to subscribe for sign-out message notifications > by using > subscription mechanisms defined in WS-Eventing [14] and the > subscription > endpoint in a federation metadata document. This includes > describing how these > subscriptions can be filtered using the XPath filter defined in WS- > Eventing > [14]. > > Attribute Services > > The participants in a federation may not always be able to establish a > federation context for a principal using only the claims obtained > from security > tokens. For example, after a principal's original request has been > authenticated a Resource Provider may determine that additional > information is > required to authorize access to advanced functionality. A service > provider can > address this situation by operating an attribute service that > requesters may > use to obtain this additional information. > > This work will focus on: > > 1. Describing how a logical data organization and namespace can be > layered over > any physical repository to provide additional information about any > type of > principal in a way that is interoperable with Web services. This > does not > include describing details regarding implementation of an attribute > service or > how to communicate with it, as indicated in the Out of Scope > section below. > 2. Describing that an attribute service should be able to supply > attributes for > any type of principal found within a federation, including > resources as well as > users and programs. > 3. Describing the granularity of access control and privacy > protection that an > attribute service should be capable of supporting based on the privacy > requirements of the principals for which it holds data. This includes > declaring that these requirements may be expressed and scoped using > mechanisms > defined in WS-Policy [6] and WS-PolicyAttachment [13]. > > Pseudonym Services > > A pseudonym service is a special type of attribute service which > provides > alternate identity information for principals. It may provide > distinct > pseudonyms for different scopes, that is, for access to different > Resource > Providers. A pseudonym service may maintain and provide security > tokens for > access to different scopes. > > This work will focus on: > > 1. Describing how a logical data organization and namespace can be > layered over > any physical repository to provide to pseudonyms for principal in a > way that is > interoperable with Web services. > 2. Describing how pseudonyms may be general purpose, or may be > scoped for use > with specific relying parties. > 3. Describing how pseudonym services may associate security tokens > with > pseudonyms so that both may be obtained in a single operation. > 4. Describing the granularity of access control and privacy > protection that a > pseudonym service should be capable of supporting based on the privacy > requirements of the principals for which it holds data. > 5. Defining interfaces that pseudonym services must support for > requesting and > managing pseudonyms. This includes the use of mechanisms defined > in WS- > Transfer [10] and extensions defined in WS-ResourceTransfer [11] to > create, > update, delete, and retrieve pseudonyms and to control the scope of > operations > performed on a pseudonym store. > > Security Tokens and Pseudonyms > > A pseudonym service can store tokens associated with a pseudonyms > to simplify > retrieving a pseudonym and associated tokens in a single security > token > request. > > This work will focus on: > > 1. Describing how a pseudonym service can associate security tokens > with > pseudonyms for use with specific target services. This includes > describing > patterns for obtaining these tokens, including a principal proactively > obtaining the tokens and including them in a service request or a > Resource > Provider using a pseudonym to retrieve the associated tokens. > 2. Describing how a pseudonym service that is combined with a > Security Token > Service may map pseudonyms to issued tokens. This includes > describing how the > mapping may be automatically performed based on the target service > for the > token. It also includes defining extensions to the WS-Trust [4] > RST/RSTR > syntax for requestors to manually specify how pseudonyms should be > mapped. > 3. Describing how proof keys generated for security tokens may be > stored for > retrieval by requestors directly from a linked pseudonym service. > This > includes a discussion of passwords, asymmetric and symmetric keys. > > Federation Extensions to WS-Trust > > Interactions between participants in a federation may be > facilitated by some > general purpose extensions to the token exchange mechanisms defined > in WS-Trust > [4]. > > This work will focus on: > > 1. Describing how reference tokens may be exchanged between > participants in a > federation using the mechanisms described in WS-Trust [4] in cases > where it may > be more efficient or practical to return a handle to the token > instead of the > actual token. This includes describing usage patterns for > reference tokens and > the syntax that must be observed when de-referencing them. > a. Defining the syntax for reference tokens including Token > type, serial > number, token hash and one or more EPRS where the actual token > contents can be > obtained. > b. Describing how a reference token is used with WS-Security > [2,7], to > associate the reference token with a protected message > c. Describing how a Security Token Service may return a > reference token in > a WS-Trust [4] RSTR > d. Describing how the actual token may be obtained using > mechanisms > defined in WS-Transfer [10] and extension defined in WS- > ResourceTransfer[11]. > 2. Defining the syntax to scope RST/RSTR messages, as defined in WS- > Trust [4], > to a specific federation context when Security Token Services or > relying > parties participate in multiple federations and allow token > requests at a > single endpoint. > 3. Defining the syntax for a target service to obtain a proof key > as part of > the response to a security token Validate request so that > subsequent messages > can be validated by the target service directly. This includes > defining syntax > for requesting a WS-Trust [4] RequestedProofToken be returned by > the Security > Token Service. > 4. Defining extensions to RST messages, as defined in WS-Trust [4] > to obtain > dynamically generated pseudonyms, including the processing rules > for such an > RST. This includes defining the syntax that the requestor may use > to specify > the desired pseudonym information. > 5. Defining the syntax for extending RST messages, as defined in WS- > Trust [4] > to enable target services to specify their requirements for the > freshness of > credentials used by principals to authenticate to Security Token > Services. > This includes defining syntax for the following options. > a. Specifying whether tokens issued on the basis of cached > authentication > state are acceptable, or whether it is desired that principals > authenticate > themselves for every token request. > b. Specifying a desired upper bound on the elapsed time > between issuing a > security token and the last time the Security Token Service > required the > principal to authenticate. > > Authorization > > An authorization service is a special type of Security Token > Service which > provides decision brokering services for participants in a > federation. While > the internal processing of an authorization service is > implementation specific, > interoperability requires development of a common model for > interacting with > authorization services, and extensions to RST/RSTR mechanisms, as > defined in > WS-Trust [4], for communicating request and policy inputs and > decision outputs. > > This work will focus on: > > 1. Describing how an authorization service may be implemented as a > Security > Token Service placed between the requestor and the desired target > service and > granting/denying the request by issuing/not issuing security tokens > required by > the target service. This includes describing an abstract mechanism for > comparing the claims required by the target service to the claims > proven by the > requestor to determine if the requestor is authorized. > 2. Defining the required function of an authorization service to > ensure that > the requestor has presented and proven the claims required to > access the target > service. > 3. Defining the syntax for conveying the authorization context of > an RST or > RSTR, as defined in WS-Trust [4+AF0AOw- that is, providing additional > contextual data that may influence token requests but may not be > included in > the contents of the issued token. This includes defining syntax > for the > following properties: > a. Conveying the context item as a name/value pair. > b. Specifying the type of the context item via a URI. > c. Specifying the scope (requestor, target, action) of the > context item > via a URI. > d. Specifying the value as a simple string or a custom > representation. > 4. Defining a dialect for expressing common claims in a format- > neutral way in a > manner consistent with the expression of Claim Dialects, as defined > in WS-Trust > [4]. This includes defining syntax for the following properties of > a claim: > a. Specifying the type of the claim via a URI. > b. Indicating whether the claim is required or optional. > c. Specifying the value of the claim as a string. > 5. Defining a profile of WS-Trust [4] in the form of processing > rules for > RST/RSTR messages that must be observed by Authorization services and > requestors. This includes a description of the required use and > treatment of: > a. Addressing headers as defined in WS-Addressing [9]. > b. Additional authorization context described above. > c. The common claim dialect described above. > > Indicating Specific Policy/Metadata > > When a requestor attempts to access a target service there may be > additional > security or contextual requirements based on the specifics of the > request. A > mechanism allowing the target service to indicate that additional > security > semantics apply to the request is required, enabling the requestor to > reconstruct the request and try again. > > This work will focus on: > > 1. Defining a specialized SOAP fault that a target service can use to > dynamically indicate that a request cannot be satisfied because > additional > security semantics apply. > 2. Describing how the additional semantics are expressed and > embedded in the > SOAP fault so that the requestor can retry the operation if it is > able. > > Authentication Types > > The WS-Trust [4] specification defines the AuthenticationType > parameter to > indicate the type of authentication required (or performed) with > respect to a > particular security token request. However, no particular types > are defined or > required. To facilitate federations, it is useful to establish > some optional > pre-defined authentication types. > > This work will focus on: > > 1. Defining a set of URIs for specifying common authentication > types to be used > for the wst:AuthenticationType parameter in RST and RSTR messages. > This > includes specifying pre-defined URIs to identify the following > authentication > mechanisms: > a. Unknown level of authentication. > b. Default sign-in mechanisms. > c. Sign-in using SSL. > d. Sign-in using SSL and a security key. > e. Sign-in using SSL and a "strong" password. > f. Sign-in using SSL and a "strong" password with expiration. > g. Sign-in using Smart Card. > > Privacy > > Requests made to service providers for security tokens or > authorization > decisions may include information that is subject to personal or > organizational > privacy requirements. It is necessary to provide mechanisms for > requestors to > indicate any restrictions on the use and distribution of such > sensitive > information, including its disclosure in security tokens they request. > This work will focus on: > 1. Describing how requestors can communicate their requirements for > protecting > the confidentiality of sensitive information provided in an RST or > included in > an RSTR and/or the issued token. > 2. Defining a syntax that allows requestors to specify that the > confidentiality > of individual sensitive claims in a security token should be > protected by > encryption when it is not required or advisable to encrypt the > entire token. > 3. Defining extensions to RST/RSTR syntax defined in WS-Trust [4] > for a > requestor to express its privacy requirements and for a Security > Token Service > to indicate the mechanisms actually used for the issued token as > follows: > a. Specifying parameter values that must be returned in an RSTR. > b. Specifying parameters that an STS must use if it issues a > token. > c. Specifying that claim values present in an issued token > must be echoed > in an RSTR. > 4. Defining a mechanism by which privacy statements can be obtained > using > mechanisms defined in HTTP, HTTPS, WS-Transfer [10], WS- > ResourceTransfer [11], > WS-Policy[6] or WS-MetadataExchange [12]. > > Web (passive) Requestors > > For Web services the sections above describe extensions to WS-Trust > [4] for > brokering trust and exposing and consuming services between the > participants of > a federation. Web browser requestors typically cannot directly > issue SOAP > requests. Consequently, syntax is required for expressing the WS- > Trust [4] > protocol and federation extensions in a browser-only environment > using widely > supported HTTP 1.1 mechanisms (GET, POST, redirects, and cookies). > This work will focus on: > 1. Describing examples of common federation operations that can be > performed by > causing web browsers to transport encoded WS-Trust [4] protocol > messages and > federation extensions described above between service providers. > This includes > describing the browser message patterns that should be used to > perform these > operations. > a. Describing common patterns for performing a Sign-On > operation by using > a web browser requestor to transport WS-Trust [4] RST/RSTR > messages. This > includes describing: > i. How a Resource Provider can "send" a WS-Trust [4] RST > request by > redirecting the web browser to a trusted Identity Provider. > ii. How an Identity Provider can return a WS-Trust [4] > RSTR response > directly to the Resource Provider in a POST body. > iii. How an Identity Provider can return a handle to a WS- > Trust [4] > RSTR response in a GET query string parameter, which the Resource > provider may > use to retrieve the issued token directly from the Identity Provider. > iv. How a Resource Provider can consume the issued token > directly, or > rely upon an intervening Identity Provider to translate it by > causing the web > browser requestor to perform additional redirection and POST > operations. > v. How a home realm discovery service can be used to > determine the > Identity Provider associated with the web browser. > b. Describing common patterns for performing a Sign-Out > operation by using > a web browser requestor to transport federated sign-out messages. > This > includes describing: > i. How a web browser can initiate the process by > selecting a sign-out > URL at either the requestor's Identity Provider or a Resource > Provider. > ii. How the requestor's Identity Provider should keep > track of the > Resource Providers that must be notified. > iii. How the requestor's Identity Provider may use the > web browser to > send sign-out messages to Resource Providers. > iv. The processing that should be performed by an > Identity Provider > or Resource Provider when it receives a sign-out request. > c. Describing common patterns for using Attribute services by > using a web > browser to transport protocol messages described above for using an > Attribute > service. > d. Describing common patterns for using Pseudonym services by > using a web > browser to transport protocol messages described above for using a > Pseudonym > service. > e. Describing how artifacts or cookies can be used to cache > state, > authentication information or issued tokens to prevent requestor > interaction on > every request for security token or a resource. > f. Describing security mechanisms that should be used with > bearer tokens > or reference tokens to prevent attacks. > 2. Defining the syntax for encoding WS-Trust protocol message > elements and > attributes, and federation extensions described above, as > parameters that may > be transported as HTTP 1.1 GET query string parameters or POST body > fields and > parameters. This includes defining the syntax for the set of > required and > optional parameters needed to convey the subset of protocol > semantics that can > be expressed using industry standard, unmodified browser clients. > a. Declaring how parameters should be used with HTTP 1.1 GET > (specified in > query string) and POST (specified in body) methods. > b. Defining parameters for coding attributes that are common > to most WS- > Trust protocol messages and federation extensions described above., > including > the following: > i. The protocol action to be performed. > ii. The URL to which responses should be directed if not pre- > determined by > policy. > iii. A context parameter for using a browser to preserve its state > during HTTP > 302 redirects. > iv. The federation context in which the request is being made. > c. Defining parameters for encoding attributes of WS-Trust RST > messages > and federation extensions described above., including the following: > i. The URI of the requesting realm. > ii. The desired freshness of the principal's authentication. > iii. The realm of the web browser requestor's Identity Provider > which can be > used to facilitate deployment of a centralized home realm discovery > service and > reduce user interaction. > iv. A request parameter conveying a RequestSecurityToken element or > a complete > Security Token Request message as defined in WS-Trust [4]. > v. A URL where the RST can be retrieved when it is not practical or > desirable > for the web browser requestor to transport it. > d. Defining parameters for encoding attributes of WS-Trust [4] > RSTR > messages and federation extensions described above, including the > following: > i. A result parameter to hold the RSTR. > ii. A URL where the RSTR can be retrieved when it is not practical > or desirable > for the web browser requestor to transport it. > e. Defining parameters for encoding federated sign-out messages. > f. Defining parameters that for encoding protocol message > exchanges with > Attribute services. > g. Defining parameters for encoding protocol message exchanges > with > Pseudonym services including encoding of pseudonym requests and > responses > conveyed in SOAP envelopes or via WS-Transfer [10] and WS- > ResourceTransfer [11] > Get operations. > 3. Describing detailed examples of message flows for web browser > requestors > when using HTTP 1.1 mechanisms to deliver the parameter encoded > equivalent of > WS-Trust [4] protocol messages and the federation extensions > described above. > a. Describing mechanisms for a Resource Provider to determine > the Identity > Provider for a particular web browser requestor also referred to as > Home Realm > Discovery. This includes: > i. Describing common mechanisms for determining the home > realm. > ii. Describing an implementation of a Home Realm > Discovery Service > consistent with the protocol encoding for Passive web requestors > described > above > 4. Defining minimum requirements - that is a subset of the web browser > requestor syntax described above - to ensure interoperability of > federated web > single sign-on implementations. This work will focus on: > a. Defining required and optional parameters that an > implementation must > be able to support for encoding attributes of WS-Trust [4] RST/RSTR > messages > and federation extensions described above. > b. Defining the required syntax for returning an issued > token. This > includes describing syntax for either returning the token directly > via the web > browser requestor, or indirectly by returning a handle which the > relying party > must use to retrieve the token from the Security Token Service > c. Describing mechanisms for returning signed security tokens and > unsecured tokens. > d. Defining parameters that an implementation should be able > to support > for encoding attributes of federated sign-out messages. > > Additional Policy Assertions > This work will focus on defining policy assertions enabling > participants in a > federation to advertise support for federation protocols and > features described > above. > 1. Defining an assertion as related to WS-Policy[6] to indicate > that a relying > party will accept a reference token instead of an actual token for > WS-Security > [2,7] protected messages to this endpoint. This includes defining > the syntax > for specifying how the reference token must be formatted. > 2. Defining an assertion as related to WS-Policy[6] to indicate > that token > request or responses for this endpoint use the web browser > requestor protocol > and must be protected using a transport mechanism. This includes > defining a > syntax to specify the following binding properties: > a. The transport mechanism to use. > b. The required token type for authentication, which includes > allowing for > the use of reference tokens. > c. Only signed tokens are accepted. > d. Only bearer tokens are accepted. > e. Use of shared cookies for home realm discovery. This only > includes > definition of an assertion to indicate that shared cookies are > used. The > specific contents of such cookies or the mechanisms for obtaining > them are not > addressed as stated in the Out of Scope section below. > 3. Defining an Authorization assertion as related to WS-Policy[6] > to indicate > support for the authorization mechanisms described above. This > includes > defining a syntax for specifying the following policy requirements: > a. The service requires the use of common claim dialect as > described in > the "Authorization" section above. > b. The service supports the SOAP Fault described in the > "Indicating > Specific Policy/Metadata" section above. > c. The service supports the processing of additional > authorization context > in an RST as described in the "Authorization" section above. > > General Notes on Scope > > The output specifications will uphold the basic principles of other > Web > services specifications of independence and composition and be > composable with > the other specifications in the Web services architecture, such as the > specifications listed in the References section, numbers 1-18, > 24-26. The TC > may also take into consideration the following specifications/works > listed in > the References section, numbers 19-22, 24-27. > If any of the above specifications is outside of a standardization > process at > the time this TC moves to ratify its deliverables, or is not far > enough along > in the standardization process, any normative references to it in > the TC output > will be expressed in an abstract manner, and the incarnation will > be left at > that time as an exercise in interoperability. > > While composition with other specifications is a goal of the TC, it > is also a > goal to leave the specifics of how that composition is achieved > outside the > scope of this TC. > > Each of the protocol elements will use implementation and language > neutral XML > formats defined in XML Schema [23]. > > Out of Scope > > The following is a non-exhaustive list. It is provided only for the > sake of > clarity. If some function, mechanism or feature is not mentioned > here, and it > is not mentioned in the Scope of Work section either, then it will > be deemed to > be out of scope. > > The TC will not define a mapping of the functions and elements > described in the > specifications to any programming language, to any particular > messaging > middleware, nor to specific network transports. > > The following items are specifically out of scope of the work of > the TC: > > 1. Definition and management of trust policy expressions (that is, > statements > about who is trusted to make what claims about an entity); these > are different > from the in-scope "Policy assertions" referred to in the Scope of > Work section > above. > 2. Mechanisms and protocols for establishing federations beyond > those described > in the input document. > 3. Definition of specific authorization context data used in > federation > extensions to WS-Trust [4]. > 4. Definition of specific claim types represented using common > claims dialect > extensions described in the Authorization section above. > 5. Specific contents of shared domain cookies used in home realm > discovery and > mechanisms used to obtain them. > 6. Definition of claim types carried in privacy parameters as > described in the > Privacy section above. > 7. Definition of the form and content of privacy statements. > 8. Token revocation notifications and revocation management (e.g. > via CRLs). > 9. Schemas for specific tokens issued, renewed, cancelled or > validated as part > of the trust process. > 10. The establishment of trust between two or more business parties. > 11. Definition of new key derivation algorithms. > 12. Definition or description of the contents and use of status > messages in > response to sign-out messages. > 13. Definition or description of a specific type of attribute > service or a > specific data organization or repository for implementing an > attribute service > or the protocol for accessing such a service. > 14. Definition or description of the types or contents of attribute > data > elements to be provided by an attribute service. > 15. Definition or description of an interface or protocol for > communicating > with an attribute service. > 16. Definition or description of a specific data organization or > repository for > implementing a pseudonym service. > 17. Definition of additional negotiation and challenge protocol > mechanisms > 18. Developing the roadmaps [21], [22] or other specifications > mentioned in > those roadmaps, beyond the material listed explicitly as within the > scope of > this charter. > > The TC will not attempt to define concepts or renderings for > functions that are > of wider applicability including but not limited to: > - Addressing > - Policy language frameworks and attachment mechanisms > - Routing > - Reliable message exchange > - Transactions and compensation > - Trust > - Secure Conversations > - Metadata Exchange > - Resource Transfer > > Where required these functions are achieved by composition with > other Web > services specifications. > > The TC will not attempt to define functionality duplicating that of > any > normatively referenced specification in the input WS-Federation > Version 1.1 > [1]. If the referenced specification is outside of a > standardization process at > the time this TC moves to ratify its deliverables, or is not far > along enough > in the standardization process, any normative references to it in > the TC output > will be expressed in an abstract manner, and the incarnation will > be left at > that time as an exercise in interoperability. > > d. Deliverables > > The TC has the following set of deliverables: > > * A revised Web Services Federation Version 1.2 specification and > associated Schemas and WSDL. A Committee Specification is > scheduled for > completion within 18 months of the first TC meeting. > > These specifications will reflect refinements, corrections or material > technological improvements with respect to the input documents and in > accordance with this charter. > > Ratification of the above specification as an OASIS standard, > including a brief > period to address any errata will mark the end of the TC's lifecycle. > > e. Anticipated Audience > > The anticipated audience for this work includes: > > * Vendors offering Web services products > * Other specification authors that need federation > capabilities for Web > services such as those described in the WS-Federation [1] > * Software architects and programmers, who design, write or > integrate > applications for Web services > * End users implementing Web services-based solutions that > require > advanced federation mechanisms. > > f. Language > > TC business will be conducted in English. > > g. IPR Policy > > This TC will operate under the "RF (Royalty Free) on RAND Terms" > IPR mode as > defined in the OASIS Intellectual Property Rights (IPR) Policy, > effective 15 > April 2005. > > --- REQUIRED NON-NORMATIVE INFORMATION --- > > a. Related Work > > As the specifications developed by the WSFED TC are part of the Web > services > Architecture, and must work well with other specifications within that > architecture, the following work may be relevant to this WSFED TC: > > Similar Work: > The specifications developed by the WSFED TC address functionality > required for > Web services that is not addressed in other security related > activities. The > WSFED TC will be informed by the following: > > * Internet X.509 Public Key Infrastructure Qualified > Certificates Profile > [28]. > * ITU-T Recommendation X.509 [28] > * The Kerberos Network Authentication Service [29] from IETF. > * Security Requirements for Cryptographic Modules [30], from NIST. > * Security Assertion Markup Language (SAML) [32] from OASIS > * The Liberty Identity Web Services Framework (ID-WSF) [33], [34]. > > The proposers of this TC recognize there are other possible > approaches to > federation and believe that the defined Scope of Work of this TC > addresses > many functional use cases of these parallel efforts. The proposers > of this TC > seek involvement from authors of other such activities and the > contribution of > their expertise and experience, and intend to work in harmony with > them in the > creation of the product of this technical committee. > > Applicable Work: > * OASIS Web Services Security (WSS) TC. The WSFED TC will > ensure that its > specifications compose with the WSS TC specifications. > * OASIS Web Services Secure Exchange (WS-SX) TC. The WSFED TC > will ensure > that its specifications compose with the WS-SX TC specifications. > * W3C WS-Policy Working Group. The WSFED TC will ensure that its > specifications compose with the W3C WS-Policy Working Group > specifications. > > The TC may decide to establish liaisons with other groups as needed. > Responsibilities for such liaison will be defined by the TC at that > time. > > b. Anticipated Contributions > > The current WS-Federation Version 1.1 specification [1] is expected > to be > contributed to this TC by BEA Systems Inc., BMC Software, CA Inc., IBM > Corporation, Layer 7 Technologies, Microsoft Corporation, Novell > Inc., and > VeriSign Inc. > > c. Date and Time of First Meeting > > The first meeting of the WS-SX TC will be a two day face to face > meeting held > in Redmond, WA on Wednesday and Thursday, June 6-7, 2007 from 9:00 > am to 5:30 > pm local time. This meeting will be sponsored by Microsoft > Corporation. > > d. On-Going Meeting Plans & Sponsors > > It is anticipated the WSFED Technical Committee will meet via > teleconference > every week at a time determined by the TC members during the TC's > first > meeting. > > It is anticipated that the WSFED Technical Committee will meet face > to face, > every quarter if needed, at a time and location to be determined by > the TC > members. > > Actual frequency of face to face and teleconference meetings will > be determined > by TC members. > > One of the proposers, as listed below, will sponsor the > teleconferences unless > other TC members offer to donate their own facilities. If no other TC > proposers offer to sponsor teleconference facilities, Microsoft or > IBM will > donate their facilities. If OASIS establishes a phone bridge system > as is being > discussed, the TC will consider use of that bridge system. > > e. Proposers of the TC > > The following eligible individuals are in support of this proposal: > > Don Adams, Tibco, dadams@tibco.com > Steve Anderson, BMC, steve.anderson@bmc.com > Siddharth Bajaj, VeriSign, sbajaj@verisign.com > Abbie Barbir, Nortel, abbieb@nortel.com > Hanane Becha, Nortel, HANANEBE@nortel.com > Jeff Bohren, BMC, jeff.bohren@bmc.com > Toufic Boubez, Layer 7 Technologies, tboubez@layer7tech.com > Lloyd Burch, Novell, lburch@novell.com > Greg Carpenter, Microsoft, gregcarp@microsoft.com > Marco Carugi, Nortel, marco.carugi@nortel.com > David M. Connelly, Open Applications Group, > dconnelly@openapplications.org > Paul Cotton, Microsoft, pcotton@microsoft.com > Glen Daniels, Progress Software, gdaniels@progress.com > Doug Earl, Novell, dearl@novell.com > Alistair Farquharson , SOA, alistair.farquharson@soa.com > Marc Goodner, Microsoft, mgoodner@microsoft.com > Tony Gullotta, SOA, tony.gullotta@soa.com > Phillip Hallam-Baker, VeriSign, pbaker@verisign.com > Patrick Harding, Ping Identity, pharding@pingidentity.com > Mike Kaiser, IBM, mkaiser@us.ibm.com > Chris Kaler, Microsoft, ckaler@microsoft.com > Dana Kaufman, Forum Systems, dkaufman@forumsys.com > Paul Knight, Nortel, paul.knight@nortel.com > Hal Lockhart, BEA Systems, hlockhar@bea.com > Jim Hosmer, Lockheed Martin Corporation, james.b.hosmer@lmco.com > Kelvin Lawrence, IBM, klawrenc@us.ibm.com > Mark Little, Red Hat, mark.little@jboss.com > Michael McIntosh, IBM, mikemci@us.ibm.com > Jonathan Marsh, WSO2, jonathan@wso2.com > K Scott Morrison, Layer 7 Technologies, Inc., > smorrison@layer7tech.com, > Anthony Nadalin, IBM drsecure@us.ibm.com > Eric Newcomer, IONA, Eric.Newcomer@iona.com > Kim Pease, Active Endpoints, kim.pease@active-endpoints.com > Jason Rouault, HP, jason.rouault@hp.com > Don Schmidt, Microsoft, donsch@microsoft.com > Sameer Sharma, Lockheed Martin Corporation, sameer.sharma@lmco.com > Yakov Sverdlov, CA, Yakov.Sverdlov@ca.com > Gene Thurston, AmberPoint, gthurston@amberpoint.com > Greg Whitehead, HP, greg.whitehead@hp.com > Prasad Yendluri, webMethods, prasad.yendluri@webmethods.com > > f. TC Convener > > The TC Convener will be Paul Cotton, Microsoft Corporation, > pcotton@microsoft.com > > References > > [1] WS-Federation Version 1.1 > "Web Services Federation Language" Version 1.1, December 2006 > > MSDN Web Services Security Specifications Index Page: > http://msdn.microsoft.com/webservices/webservices/understanding/ > specs/default.a > spx?pull+AD0-/library/en-us/dnglobspec/html/wssecurspecindex.asp > > IBM Developer Works SOA and Web Services - WS-Federation Language > Page: > http://www.ibm.com/developerworks/webservices/library/specification/ > ws-fed/ > > VeriSign Web Services Security Page: > http://www.verisign.com/research/Security.Research/DEV036564.html > > > [2] WS-Security Version 1.0 > OASIS Standard, "Web Services Security: SOAP Message Security 1.0 > (WS-Security > 2004)", March 2004 > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap- > message-security- > 1.0.pdf > > WS-Security: SAML Token Profile 1.0 > OASIS Standard, "Web Services Security: SAML Token Profile", > December 2004 > > http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf > > WS-Security: REL Token Profile 1.0 > OASIS Standard, "Web Services Security: Rights Expression Language > (REL) Token > Profile", December 2004 > http://docs.oasis-open.org/wss/oasis-wss-rel-token-profile-1.0.pdf > > [3] WS-SecureConversation > OASIS Committee Draft, "WS-SecureConversation 1.3", September 2006 > http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 > > [4] WS-Trust > OASIS Committee Draft, "WS-Trust 1.3", September 2006 > http://docs.oasis-open.org/ws-sx/ws-trust/200512 > > [5] WS-SecurityPolicy > OASIS Committee Draft, "WS-SecurityPolicy 1.3", September 2006 > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512 > > [6] WS-Policy > W3C Member Submission "Web Services Policy 1.2 - Framework", 25 > April 2006. > http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/ > > [7] WS-Security Version 1.1 > OASIS Standard, "OASIS Web Services Security: SOAP Message Security > 1.1 (WS- > Security 2004)", February 2006. > http://www.oasis-open.org/committees/download.php/16790/wss-v1.1- > spec-os- > SOAPMessageSecurity.pdf > > WS-Security: SAML Token Profile 1.0 > OASIS Standard, "Web Services Security: SAML Token Profile 1.1", > December > 2006http://www.oasis-open.org/committees/download.php/16768/wss- > v1.1-spec-os- > SAMLTokenProfile.pdf > > WS-Security: X.509 Certificate Token Profile 1.1 > OASIS Standard, "Web Services Security: X.509 Certificate Token > Profile 1.1", > February 2006 > http://www.oasis-open.org/committees/download.php/16785/wss-v1.1- > spec-os- > x509TokenProfile.pdf > > WS-Security: Kerberos Token Profile 1.1 > OASIS Standard, "Web Services Security: Kerberos Token Profile > 1.1", February > 2006 > http://www.oasis-open.org/committees/download.php/16788/wss-v1.1- > spec-os- > KerberosTokenProfile.pdf > > WS-Security: UsernameToken Profile 1.1 > OASIS Standard, "Web Services Security: Username Token Profile > 1.1", February > 2006http://www.oasis-open.org/committees/download.php/16782/wss- > v1.1-spec-os- > UsernameTokenProfile.pdf > > WS-Security: REL Token Profile 1.1 > OASIS Standard, "Web Services Security: Rights Expression Language > (REL) Token > Profile1.1", February 2006http://www.oasis- > open.org/committees/download.php/16687/oasis-wss-rel-token- > profile-1.1.pdf > > WS- Security: SwAProfile 1.1 > OASIS Standard, "Web Services Security: SOAP Messages with Attachments > (SwA) Profile 1.1", February 2006 > http://www.oasis-open.org/committees/download.php/16672/wss-v1.1- > spec-os- > SwAProfile.pdf > > [8] WS -ReliableMessaging > OASIS Committee Draft "Web Services Reliable Messaging (WS- > ReliableMessaging)" > , August 2006 > http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf > > [9] WS-Addressing > W3C Recommendation, "Web Services Addressing (WS-Addressing)", 9 > May 2006. > http://www.w3.org/TR/2006/REC-ws-addr-core-20060509 > > [10] WS-Transfer > Web Services Transfer (WS-Transfer), 27 September 2006 > http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/ > > [11] WS-ResourceTransfer > W3C Member Submission, "Web Services Resource Transfer (WS- > ResourceTransfer)", > August 2006 > http://schemas.xmlsoap.org/ws/2006/08/resourceTransfer/ > > [12] WS-Metadata Exchange > Web Services Metadata Exchange (WS-MetadataExchange), August 2006 > http://schemas.xmlsoap.org/ws/2004/09/mex/ > > [13] WS-PolicyAttachment > W3C Member Submission "Web Services Policy 1.2 - Attachment", 25 > April 2006 > http://www.w3.org/Submission/WS-PolicyAttachment/ > > [14] WS-Eventing > W3C Member Submission, "Web Services Eventing (WS-Eventing)", 15 > March 2006 > http://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/ > > [15] SOAP 1.1 > W3C Note, "Simple Object Access Protocol (SOAP) 1.1", May 2000 > http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ > > [16] SOAP 1.2 > W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework", > June 2003 > http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ > > [17] WSDL 1.1 > W3C Note, "Web Services Description Language (WSDL) 1.1", March 2001 > http://www.w3.org/TR/2001/NOTE-wsdl-20010315 > > [18] WSDL 2.0 > W3C Candidate Recommendation, " Web Services Description Language > (WSDL) > Version 2.0 Part 1: Core Language", March 2006 > http://www.w3.org/TR/wsdl20/ > > [19] WS-I Basic Profile 1.1 > WS-I Final Material, "Basic Profile Version 1.1", 2006-04-10 > http://www.ws-i.org/Profiles/BasicProfile-1.1.html > > [20] WS-I Basic Security Profile 1.1 > WS-I Final Material, "Basic Security Profile Version 1.1", 2006-04-10 > http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1-2006-10-19.html > > [21] Secure, Reliable, Transacted Web Services: Architecture +ACY- > Composition > http://msdn.microsoft.com/webservices/webservices/understanding/ > advancedwebserv > ices/default.aspx?pull+AD0-/library/en-us/dnwebsrv/html/wsoverview.asp > > http://www-128.ibm.com/developerworks/webservices/library/ws- > securtrans/index.html > > [22] Security in a Web Services World: A Proposed Architecture and > Roadmap > http://msdn.microsoft.com/library/default.asp?url+AD0-/library/en- > us/dnwssecur/html/securitywhitepaper.asp > > http://www-128.ibm.com/developerworks/library/ws-secmap/ > > [23] XML Schema > W3C Recommendation, "XML Schema Part 1: Structures Second Edition", > October > 2004 > http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ > > W3C Recommendation, XML Schema Part 2: Datatypes Second Edition", > October 2004 > http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ > > > [24] WS-Coordination 1.1 > OASIS Committee Specification, "Web Services Coordination (WS- > Coordination) > 1.1", December 2006 > http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.1-spec-cs-01.pdf > > [25] WS-AtomicTransaction 1.1 > OASIS Committee Specification, "Web Services Atomic Transaction (WS- > AtomicTransaction) 1.1", December 2006 > http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec-cs-01.pdf > > [26] WS-BusinessActivity 1.1 > OASIS Committee Specification, "Web Services Business Activity (WS- > BusinessActivity) 1.1", November 2006 > http://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-spec-pr-01.pdf > > [27] XPath 1.0 > W3C Recommendation, "XML Path Language (XPath) Version 1.0", > November 1999 > http://www.w3.org/TR/1999/REC-xpath-19991116 > > [28] ITU-T Recommendation X.509 (2000) http://www.itu.int/ITU- > T/asn1/database/itu-t/x/x509/2000/index.html, > March 2000. > > [29] J. Kohl and C. Neuman, "The Kerberos Network Authentication > Service > 311 (V5)," RFC 1510, September 1993, http://www.ietf.org/rfc/ > rfc1510.txt > > [30] Security Requirements for Cryptographic Modules, May 2001. See > http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf . > > [31] W3C Recommendation, "XML-Signature Syntax and Processing", 12 > February > 2002, http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ > > [32] Security Assertion Markup Language (SAML) > http://www.oasis-open.org/committees/security/ > > [33] Liberty Identity Web Services Framework (ID-WSF) > http://www.projectliberty.org/resources/specifications.php > > [34] Liberty ID-WSF Authentication Service Specification > http://www.projectliberty.org/specs/draft-liberty-idwsf-authn-svc- > v2.0-02.pdf > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]