The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: October 26, 2005
XML and Security

[Document in preparation.] Alphabetic listing of specifications and standards activities related to security for XML and Web Services, representing selections from multiple dozens of security standards.

Contents

Alpha List

Basic Security Profile

The Web Services-Interoperability Organization (WS-I) has published a [draft] WS-I Basic Security Profile 1.0 "based on a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability." The WS-I Basic Security Profile Working Group is developing an interoperability profile dealing with transport security, SOAP messaging security and other Basic-Profile-oriented Web services security considerations. The Working Group is developing and selecting a set of usage scenarios and their component message exchange patterns to guide the profiling work. In addition, the Basic Security Profile Working Group will use the WS-I Security Plan Framework, particularly its collection of usage scenarios and use cases, and the WS-I Work Plan for Web Services Security Interoperability as input to its work... Conformance to the Basic Security Profile 1.0 is defined by adherence to the set of requirements defined for a specific target, within the scope of the Profile. This section explains these terms and describes how conformance is defined and used. Conformance requirements state the criteria for conformance to the Profile. They typically refer to an existing specification and embody refinements, amplifications, interpretations and clarifications to it in order to improve interoperability. All requirements in the Basic Security Profile 1.0 are considered normative, and those in the specifications it references that are in-scope should likewise be considered normative... Conformance targets [e.g., SECURE_ENVELOPE, SECURE_MESSAGE, SENDER, RECEIVER, SECURITY_HEADER, ENCRYPTED_KEY, SIGNATURE, SECURITY_TOKEN] identify what artifacts (e.g., SOAP message, WSDL description, UDDI registry data) or parties (e.g., SOAP processor, end user) requirements apply to. This allows for the definition of conformance in different contexts, to assure unambiguous interpretation of the applicability of requirements, and to allow conformance testing of artifacts (e.g., SOAP messages and WSDL descriptions) and the behavior of various parties to a Web service (e.g., clients and service instances)..."

References:

Canonical XML

Canonical XML was developed by the IETF/W3C XML Signature Working Group, chartered "to develop an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures." Digital signatures provide integrity, signature assurance and non-repudiatability over Web data. Such features are especially important for documents that represent commitments such as contracts, price lists, and manifests. XML Signatures have the potential to provide reliable XML-based signature technology. However, various processors may introduce incidental changes into a document over the course of its processing." Canonical XML Version 1.0 abstract: "Any XML document is part of a set of XML documents that are logically equivalent within an application context, but which vary in physical representation based on syntactic changes permitted by XML 1.0 and Namespaces in XML. This [Canonical XML] specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. Except for limitations regarding a few unusual cases, if two documents have the same canonical form, then the two documents are logically equivalent within the given application context. Note that two documents may have differing canonical forms yet still be equivalent in a given context based on application-specific equivalence rules for which no generalized XML specification could account."

References:

Digital Signature Services

A Digital Signature Service Core Protocols, Elements, and Bindings specification was published by the OASIS Digital Signature Services (DSS) Technical Committee in October 2005. The document defines XML request/response protocols for signing and verifying XML documents and other data. It also defines an XML timestamp format, and an XML signature property for use with these protocols, and transport and security bindings for the protocols. "Web-based Digital Signature Services enable the sharing of digital signature creation, verification and other associated services, avoiding the need to implement the technical, as well as physical and procedural, complexities within user applications." The OASIS DSS TC was chartered "to develop techniques to support the processing of digital signatures. This mandate includes defining an interface for requesting that a web service produce and/or verify a digital signature on a given piece of data and techniques for proving that a signature was created within its key validity period. TC deliverables included: (1) an XML-based protocol for signature and time-stamp creation and verification; (2) bindings for the protocol elements in "(1)" including SOAP and HTTP and TLS security; (3) a set of profiles for the application of the above protocols to specific application areas. The TC's work incorporates the use of existing digital signature standards including: IETF / W3C XML Signature; IETF Cryptographic Message Syntax (RFC 2630); ETSI XML Advanced Electronic Signatures (XAdES — TS 101 733); IETF Time-stamp protocol (RFC 3161). Profiles under consideration (per Charter 2004) included: German Signature Law Signature; European Advanced Electronic Signature (XAdES); Electronic Post Mark; WS-Security; S/MIME and Code-Signing; eNotary; Corporate Seals. As of 2005-10, Committee Drafts were available for the following Profiles of the DSS Core: Time-stamping; Asynchronous operation; Code signing abstract profile; Code signing (J2ME) concrete profile; Entity seal; Electronic Post Mark (EPM); German signature law; Policy wise server; XML Advanced Electronic Signature (XAdES); Signature gateway. The TC was formed in October 2002 and rechartered in November 2004.

References:

EPAL (Enterprise Privacy Authorization Language)

In December 2003, W3C acknowledged receipt of IBM's Enterprise Privacy Authorization Language (EPAL) Version 1.2 as a Member Submission request. The specification includes two parts: a prose description of syntax and semantics, with formal definition of the EPAL syntax presented in an XML Schema. The EPAL technical specification defines a "formal language for writing enterprise privacy policies to govern data handling practices in IT systems according to fine-grained positive and negative authorization rights. It concentrates on the core privacy authorization while abstracting data models and user-authentication from all deployment details such as data model or user-authentication. EPAL is thus an interoperability language for exchanging privacy policy in a structured format between applications or enterprises, supporting the ability to encode an enterprise's privacy-related data-handling policies and practices and providing a language that can be imported and enforced by a privacy-enforcement systems. The goal of EPAL is: (1) to enable organizations to be demonstrably compliant with their stated policies; (2) to reduce overhead and the cost of configuring and enforcing data handling policies; and (3) to leverage existing standards and technologies. Whereas the W3C Platform for Privacy Preferences (P3P) Recommendation defines a global terminology that can be used to describe the privacy promises of an enterprise, EPAL aims at formalizing enterprise-internal privacy policies, which requires a fine-grained vocabulary; it also includes a fine-grained hierarchy of purposes for which an enterprise collects data."

References:

Exclusive XML Canonicalization

The XML Recommendation XML specifies the syntax of a class of objects called XML documents. The Namespaces in XML Recommendation specifies additional syntax and semantics for XML documents. It is normal for XML documents and subdocuments which are equivalent for the purposes of many applications to differ in their physical representation. For example, they may differ in their entity structure, attribute ordering, and character encoding. The goal of this [Exclusive XML Canonicalization] specification is to establish a method for serializing the XPath node-set representation of an XML document or subset such that: (1) The node-set is minimally affected by any XML context which has been omitted; (2) The canonicalization of a node-set representing well-balanced XML [XML-Fragment] will be unaltered by further applications of exclusive canonicalization; (3) It can be determined whether two node-sets are identical except for transformations considered insignificant by this specification under XML and XML Namespaces."

References:

Liberty ID-WSF Security Mechanisms Specification

The Liberty Alliance Project is an undertaking by a group of companies to develop a set of open, technical specifications for web services. The first step, now completed, is the Liberty Identity Federation Framework, a set of specifications enabling single sign-on using federated network identity. The Liberty Identity Federation Framework provides specifications for associating, connecting, and binding multiple accounts for a given Principal at various Liberty Alliance sites within a Circle of Trust. 'Identity Services' is an abstract notion of a web service that acts upon some resource to obtain information about an identity, update information about an identity, or perform some action for the benefit of an identity. Security in the Liberty Framework is layered. Liberty protocols are constructed with extensive security mechanisms. Furthermore they build upon various Internet protocols that themselves have embedded security mechanisms. The Liberty Identity Web Services Framework (ID-WSF) is a set of specifications for creating, using, and updating various aspects of identities. The Liberty ID-WSF Security Mechanisms document "specifies security protocol mechanisms for securing the consumption of identity-based web services. An identity-based web service is a particular type of a web service that acts upon some resource to either retrieve information about an identity, update information about an identity, or to perform some action for the benefit of some identity. The document describes authentication mechanisms which are factored into the authorization decisions enforced by a given identity-based web service. The specified mechanisms provide for authentication, signing and encryption operations. XML-Signature and XML-Encryption are utilized to provide the associated transformations and processing semantics to accommodate the message authentication and protection functionality. OASIS Web Services Security SOAP Message Security compliant header elements communicate the relevant security information, i.e., a SAML V1.1 Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1 or SAML V2.0 assertion, along with the protected message."

References:

SAML (Security Assertion Markup Language)

Version 2.0 of the Security Assertion Markup Language (SAML) has been published as an OASIS Standard, produced by members of the Security Services Technical Committee. SAML is "an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application." The SAML standard "leverages core Web services standards including XML, SOAP, Transport Layer Security (TLS), XML Signature (XMLsig), and XML Encryption (XMLenc). It defines a framework for exchanging security information between online business partners. It allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application." SAML Version 2.0 "enables the secure exchange of authentication, attribute, and authorization information between disparate security domains, making vendor-independent Web single sign-on and secure e-business transactions possible. Version 2.0 adds key functions to create and manage federated networks that combine and appropriately share pre-existing repositories of identity information." A key feature of SAML is its support for federated identity — one that is "both portable and potable, so it can be transported and consumed across autonomous domains or business boundaries. By defining standardized mechanisms for the communication of security and identity information between business partners, SAML makes federated identity, and the crossdomain transactions that it enables, a reality."

References:

Unicode Security Considerations

"The Unicode Standard represents a very significant advance over all previous methods of encoding characters. For the first time, all of the world's characters can be represented in a uniform manner, making it feasible for the vast majority of programs to be globalized: built to handle any language in the world. In many ways, the use of Unicode makes programs much more robust and secure. When systems used a hodge-podge of different charsets for representing characters, there were security and corruption problems that resulted from differences between those charsets, or from the way in which programs converted to and from them. But because Unicode contains such a large number of characters, and because it incorporates the varied writing systems of the world, incorrect usage can expose programs or systems to possible security attacks." A number of visual security issues have arisen in connection with (visual) spoofing, and this threat provides the basis for the UTR #36 technical report from the Unicode Consortium. The new Unicode Security Considerations Technical Report "provides an initial step towards reducing the risk of such problems while preserving the ability to have internationalized domain names for all the modern languages of the world." Security issues identified and addressed in the report include Internationalized Domain Names, Mixed-Script Spoofing, Single-Script Spoofing, Inadequate Rendering Support, Bidirectional Text Spoofing, Syntax Spoofing, and Numeric Spoofs. The Technical Report Unicode Security Considerations "describes some of the security considerations that programmers, system analysts, standards developers, and users should take into account, and provides specific recommendations to reduce the risk of problems.

References:

Web SSO (Web Single Sign-On Metadata Exchange Protocol)

In May 2005 Sun Microsystems and Microsoft Corp announced the publication of two new identity management specifications and plans for additional collaborative effort to support product interoperability. The Web Single Sign-On Metadata Exchange Protocol specification "defines how a service can query an identity provider for metadata that describes the identity-processing protocol suites supported by that provider, to increase the service's ability to communicate successfully and efficiently with the provider." The companion Web Single Sign-On Interoperability Profile "defines an interoperability profile of the web single sign-on metadata exchange protocol that allows using either Liberty Identity Federation or WS-Federation based Identity Providers to interact with a service. It defines how the service determines the protocols supported by the client's identity provider thereby allowing identity processing to occur." According to the public announcement, these new specifications will ultimately enable browser-based web single sign-on between security domains that use Liberty ID-FF and WS-Federation. The two companies welcome developer participation in the further development of the Web SSO specifications; this design work will be managed through the Web services protocol workshop process. Subsequently, the two specifications will be submitted to a standards organization for finalization and ratification as industry standards."

References:

WS-SecureConversation (Web Services Secure Conversation Language)

On October 17, 2005 OASIS announced the charter of a new Web Services Secure Exchange (WS-SX) Technical Committee to continue work on the WS-SecureConversation specification. "Web Services Secure Conversation Language (WS-SecureConversation) is built on top of the WS-Security and WS-Policy models to provide secure communication between services. WS-Security focuses on the message authentication model but not a security context, and thus is subject several forms of security attacks. The WS-SecureConversation specification defines mechanisms for establishing and sharing security contexts, and deriving keys from security contexts, to enable a secure conversation. By using the SOAP extensibility model, modular SOAP-based specifications are designed to be composed with each other to provide a rich messaging environment. As such, WS-SecureConversation by itself does not provide a complete security solution. WS-SecureConversation is a building block that is used in conjunction with other Web service and application-specific protocols (for example, WS-Security) to accommodate a wide variety of security models and technologies."

References:

WS-Security (Web Sevices Security)

In April 2004, OASIS announced the approval of WS-Security 2004 as an OASIS Standard, prepared by members of the Web Services Security (WSS) TC. The specification set included: Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), Web Services Security UsernameToken Profile 1.0, Web Services Security X.509 Certificate Token Profile, and two relevant XML Schemas. WSS "builds upon existing security technologies such as XML Digital Signature, XML Encryption and X.509 Certificates to deliver an industry standard way of securing Web services message exchanges. Providing a framework within which authentication and authorization take place, WSS lets user apply existing security technology and infrastructure in a Web services environment." In July 2005, the OASIS Web Services Security TC approved several WSS Version 1.1 specifications as Public Review Drafts: Message Security v1.1; SAML Token Profile v1.1; x509 Token Profile v1.1; Kerberos Token Profile v1.1; Username Token Profile v1.1; REL Token Profile v1.1; SwA Token Profile v1.1.

References:

WS-SecurityPolicy (Web Services Security Policy Language)

On October 17, 2005 OASIS announced the charter of a new Web Services Secure Exchange (WS-SX) Technical Committee to continue work on the WS-SecurityPolicy specification. The Web Services Security Policy Language (WS-SecurityPolicy) specification indicates the policy assertions which apply to Web Services Security: SOAP Message Security, WS-Trust, and WS-SecureConversation... Web services are a loosely-coupled, language-neutral, platform-independent way of linking applications within organizations, across enterprises, and across the Internet. A key benefit of the emerging Web services architecture is the ability to deliver integrated, interoperable solutions — which makes it critical to ensure the integrity, confidentiality, and overall security of these services. WS-SecurityPolicy defines a set of security policy assertions which apply to Web Services Security: SOAP Message Security, WS-Trust, and WS-SecureConversation. This document takes the approach of defining a base set of assertions that describe how messages are to be secured. Flexibility with respect to token types, cryptographic algorithms, and mechanisms used, including using transport-level security, is part of the design and allows for evolution over time. The intent is to provide enough information for compatibility and interoperability to be determined by Web services participants, along with all information necessary to actually enable a participant to engage in a secure exchange of messages.

References:

WS-Trust (Web Services Trust Language)

On October 17, 2005 OASIS announced the charter of a new Web Services Secure Exchange (WS-SX) Technical Committee to continue work on the WS-Trust specification. "Web Services Trust Language (WS-Trust) uses the secure messaging mechanisms of WS-Security to define additional primitives and extensions for security token exchange to enable the issuance and dissemination of credentials within different trust domains. The Web Services Trust Language (WS-Trust) uses the secure messaging mechanisms of WS-Security to define additional primitives and extensions for the issuance, exchange and validation of security tokens. WS-Trust also enables the issuance and dissemination of credentials within different trust domains. In order to secure a communication between two parties, the two parties must exchange security credentials (either directly or indirectly). However, each party needs to determine if they can 'trust' the asserted credentials of the other party. This specification defines extensions to WS-Security for issuing and exchanging security tokens and ways to establish and access the presence of trust relationships. Using these extensions, applications can engage in secure communication designed to work with the general Web Services framework, including WSDL service descriptions, UDDI businessServices and bindingTemplates, and SOAP messages."

References:

XACML (Extensible Access Control Markup Language)

"XACML is used to represent and evaluate access control policies. The motivation behind XACML is to express the well-established ideas in the field of access- control policy (e.g., rules, policies, policy sets, subjects, decision requests, authorization decisions,) using an extension language of XML. According to the Core specification, "there is a pressing need for a common language for expressing security policy. If implemented throughout an enterprise, a common policy language allows the enterprise to manage the enforcement of all the elements of its security policy in all the components of its information systems. Managing security policy may include some or all of the following steps: writing, reviewing, testing, approving, issuing, combining, analyzing, modifying, withdrawing, retrieving and enforcing policy." The XACML specification thus "enables the use of arbitrary attributes in policies, role-based access control, security labels, time/date-based policies, indexable policies, 'deny' policies, and dynamic policies — all without requiring changes to the applications that use XACML. Adoption of XACML across vendor and product platforms should provide the opportunity for organizations to perform access and access policy audits directly across such systems." XACML Version 2.0 can be of particular interest to those deploying SAML, looking for a practical way to implement RBAC or protecting hierarchical resources, such as portions of XML documents. The principal features of XACML are documented in the core Extensible Access Control Markup Language (XACML) Version 2.0 specification, supported by the Core Policy Schema and Core Context Schema. This document provides the model descriptions for data-flow, XACML context (canonical representation of a decision request and an authorization decision), and policy language (rule, policy, policy set).

References:

XAdES (XML Advanced Electronic Signatures)

XAdES "extends the IETF/W3CXML-Signature Syntax and Processing specification into the domain of non-repudiation by defining XML formats for advanced electronic signatures that remain valid over long periods and are compliant with the European 'Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures' (Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures, also denoted as 'the Directive' or the 'European Directive' in the rest of the present document) and incorporate additional useful information in common uses cases. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (repudiates) the validity of the signature. An advanced electronic signature aligned with the present document can, in consequence, be used for arbitration in case of a dispute between the signer and verifier, which may occur at some later time, even years later.

References:

XCBF (XML Common Biometric Format)

XCBF Version 1.1 was approved as an OASIS Standard in August 2003. The XML Common Biometric Format specification deals with biometrics in the sense of "automated methods of recognizing a person based on physiological (retina, hand geometry, DNA) or behavioral characteristics; they are used to recognize the identity of an individual, or to verify a claimed identity." The OASIS Committee Specification defines "a common set of secure XML encodings for the patron formats specified in CBEFF, the Common Biometric Exchange File Format (NISTIR 6529). These XML encodings are based on the ASN.1 schema defined in ANSI X9.84 Biometric Information Management and Security. For security purposes, they make use of the Canonical XML Encoding Rules (CXER) for ASN.1 defined in ITU-T Rec. X.693, and rely on the security and processing requirements specified in the X9.96 XML Cryptographic Message Syntax (XCMS) and X9.73 Cryptographic Message Syntax (CMS) standards." Section 7 provides the XCBF Schema in the form of ASN.1 modules (X9-84-Biometrics Module, X9-84-CMS Module, X9-84-Identifiers Module). Examples for readers and implementors are supplied in Section 8 of the specification with the goal of promoting secure, interoperable biometric applications and systems... The standard defines cryptographic messages represented in XML markup for the secure collection, distribution, and processing, of biometric information. These messages provide the means of achieving data integrity, authentication of origin, and privacy of biometric data in XML based systems and applications. Mechanisms and techniques are described for the secure transmission, storage, and integrity and privacy protection of biometric data.

References:

XKMS (XML Key Management Specification)

The XML Key Management Specification (XKMS 2.0) "specifies protocols for distributing and registering public keys, suitable for use in conjunction with the standard for XML Signatures defined by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) and companion standard for XML encryption. The XML Key Management Specification (XKMS) comprises two parts: the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS). These protocols do not require any particular underlying public key infrastructure (such as X.509) but are designed to be compatible with such infrastructures... The XML Key Information Service Specification is a protocol to support the delegation by an application to a service of the processing of key information associated with an XML signature, XML encryption, or other usage of the XML Signature <ds:KeyInfo> element. The XML Key Registration Service Specification is a protocol to support the registration of a key pair by a key pair holder, with the intent that the key pair subsequently be usable in conjunction with the XML Key Information Service Specification or a Public Key Infrastructure (PKI) such as X.509 and PKIX (Internet X.509 Public Key Infrastructure Certificate and CRL Profile)..."

References:

XML [Digital] Signature

The XML-Signature Syntax and Processing specification was developed and published jointly by IETF and W3C in the XML Signature Working Group, chartered to "develop an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures.' The Recommendation/RFC document "specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, this specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. This specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information. The XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements."

References:

XML Encryption

"XML Encryption is a method whereby XML content can be transformed such that it is discernable only to the intended recipients, and opaque to all others. There are many applications for such a specification given the increasing importance of XML on the Internet and Web including the protection of payment and transaction information. The proposed work will obviously address how to encrypt an XML documents including elements. The XML Encryption Syntax and Processing Recommendation was produced by members of the W3C XML Encryption Working Group, chartered "to develop a process for encrypting/decrypting digital content (including XML documents and portions thereof) and an XML syntax used to represent the (1) encrypted content and (2) information that enables an intended recipient to decrypt it. The XML Encryption Recommendation "specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption EncryptedData element which contains (via one of its children's content) or identifies (via a URI reference) the cipher data. When encrypting an XML element or element content the EncryptedData element replaces the element or content (respectively) in the encrypted version of the XML document. When encrypting arbitrary data (including entire XML documents), the EncryptedData element may become the root of a new XML document or become a child element in an application-chosen XML document. This specification implements features outlined in the XML Encryption Requirements document, which "lists the design principles, scope, and requirements for XML Encryption. It includes requirements as they relate to the encryption syntax, data model, format, cryptographic processing, and external requirements and coordination."

References:

General: Articles, Papers, News

  • "WS-Stardate 2005.10" By Tim Bray. Ongoing. 2005-10-23. "How's the WS-* field strength, Mr. Spock?" ... "Steady at 783; sub-optimal, but manageable." ... "My intuition tells me something's wrong." ... "All right, I'll run a deep scan, but..." ..."Captain! I'm getting a weird reading from three specs in the Security sector; it looks like..." ... "Checking, Captain; those WS-warbirds are SecureConversation, Trust, and SecurityPolicy. They've been there for years, but somehow they're different... aaaah. They're deploying an OASIS-TC standardization field!" ... "But that's a friendly tactic, Spock."... "No, Captain, they're modulating the field with a locked-down charter device; the TC has to just approve them the way they are." ... "That's fiendish!" ... "And extremely illogical, Captain."...

  • [April 7, 2002] "Security in a Web Services World: A Proposed Architecture and Roadmap." A Joint White Paper from IBM Corporation and Microsoft Corporation. Version 1.0. April 7, 2002. Also available from IBM. "This document describes a proposed strategy for addressing security within a Web service environment. It defines a comprehensive Web service security model that supports, integrates and unifies several popular security models, mechanisms, and technologies (including both symmetric and public key technologies) in a way that enables a variety of systems to securely interoperate in a platform- and language-neutral manner. It also describes a set of specifications and scenarios that show how these specifications might be used together."
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/security.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org