W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2003

Re: Standards Descriptions

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Wed, 1 Oct 2003 08:50:40 -0400
To: "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>
Cc: www-ws-arch@w3.org, www-ws-arch-request@w3.org
Message-ID: <OFFD11F452.77B77636-ON85256DB2.0043A60F-85256DB2.00468AEB@us.ibm.com>

Some comments below. In general, I think that you should explicitly cite 
the standards
body (if any) for each developing standard.

Missing from this list is WSRP which was recently adopted as an OASIS 

Also missing are ebMS, ebCPPA and more recently ebBPSS all at OASIS.



In the category of WS-TX and C and WS-CAF, there is also BTP

And finally (for this email anyway) WSDM, also at OASIS and co-chaired by 
our own Heather


Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 09/30/2003 06:00:30 PM:

> SOAP - Basic messaging spec for Web services. SOAP 1.1 has been very
> widely implemented and is part of the WS-I Basic Profile Version 1.0. 
SOAP 1.2
> is being developed in the W3C and is in the latter stages of the 
> process. It does not seem likely that SOAP 1.2 will be particularly 
> controversial and major vendors will probably implement it quickly 
> once it becomes a recommendation.

SOAP1.2 *is* a W3C REC as of this past June.

> WSDL - Basic Web services description spec. WSDL 1.1 has been very 
> widely implemented and is part of the WS-I Basic Profile Version 1.0. 
WSDL 1.2
> is being developed in the W3C and is in a "middle" stage of the 
> process. There does not seem to be any particular competition to 
> WSDL 1.2 in other standards organizations and major vendors will 
> probably implement it quickly once it becomes a recommendation 
> (which will take a while).

Actually, I would put DAML-S in roughly the same category as WSDL
but in the SWS camp.

> UDDI (Universal Description, Discovery, and Integration)- Web 
> services registry. Version 2 adopted 4/2003 has been implemented by 
> a number of vendors. Version 3, under development, includes new 
> features like federation, which should allow communication between 
> locally customized servers. Implementation of UDDI on the internet 
> has stalled but there is widespread interest in using UDDI in 
> corporate intranets.

UDDI v3 is being developed at OASIS. I would add this factoid to the

> ebXML Registry Services - - ebeXML registry, provides function along
> lines similar to UDDI. Version 2 adopted 12/2001. See also the ebXML
> Registry Information Model 

Also at OASIS.


> WS-Security – Construct secure SOAP message exchanges, including 
> provision for multiple security tokens for authorization and 
> authentication, multiple trust domains, multiple encryption 
> technologies and end-to-end message-level security (not just 
> transport-level security). Out of scope: multiple message exchanges,
> key exchange, establishing and maintaining trust. WS-Security 
> defines two core capabilities: 1- how to use XML-Signature and XML-
> Encryption with SOAP messaging. It specifies how to pass signatures 
> and key information in a SOAP header. 2- how to pass security tokens
> with a SOAP message. WS-Security supports a variety of security 
> tokens (each defined by its own binding specification), such as 
> userid/password, X.509 certificates, Kerberos tickets, and SAML 
> tokens. The WS-Security TC is just starting in OASIS, but major 
> vendors (MS, IBM) have already implemented the submitted spec. 

Actually, the OASIS TC just adopted a Committee Spec status for the
core spec and two of the profiles (user password and x509 certs) and is
in the middle of the public review period prior to submission to OASIS
membership for consideration as an OASIS Standard. Also, WS-I is 
its Basic Security Profile 1.0 using WSS and the first two profiles as 
its foundation.

> SAML – Security Assertion Markup Language. Exchanging authorization 
> and authentication information. Version 1.0 finalized 11/2002. SAML 
> defines three core capabilities: 1- how to represent security tokens
> in XML. These tokens are called assertions, and SAML defines three 
> types of assertions -- authentication, authorization, and 
> attributes. (attributes provide qualifying information that 
> constrain the other assertions -- such as spending limits or timing 
> constraints). An assertion is made by some type of trust authority. 
> 2- a process model for obtaining security tokens from a trust 
> authority. This includes a set of protocols for accessing a trust 
> authority. SAML defines two types of trust authorities: Policy 
> Decision Points (PDPs) and Policy Enforcement Points (PEPs). SAML 
> has defined bindings for multiple protocols, including SOAP/WSDL. 3-
> a set of protocol bindings for conveying SAML tokens. SAML 1.1 
> defines how to pass SAML tokens for browser applications. It does 
> not define bindings for how to pass SAML tokens in SOAP messages -- 
> that is left to WS-Security. It appears that this spec may be 
> getting some real traction in terms of practical implementations. 
> See, for example, this auto industry implementation. 

SAMLv1.1 was recently adopted as an OASIS Standard (02-sept-2003)

Received on Wednesday, 1 October 2003 08:50:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:09 UTC