[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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]