W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2000

RE: XML protocol security

From: Mishra, Prateek <pmishra@netegrity.com>
Date: Fri, 19 May 2000 10:11:16 -0400
Message-ID: <F51E77692CD3D31190F300508B8BFA5E156384@maex02.netegrity.com>
To: "'Yin Leng Husband'" <husband@ozy.dec.com>, "Mishra, Prateek" <pmishra@netegrity.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>, SOAP@DISCUSS.DEVELOP.COM
Cc: "Chippada, Radhika" <rchippada@netegrity.com>
Agreed. In fact it would be a good idea to use a formalism similar to
Trading Partner
Markup Language (from IBM) which essentially defines a declarative notation
for defining security and other properties of methods exposed by an
enterprise. Concentrating on the
security properties for the moment, here is an informal example:
Method Name: getCatalog
Request Document: getCatalog DTD
Transport: HTTPS -- client cert required, 
                Response Document: getCatalogResponse DTD
                Additional Headers Required:...
Transport: SMTP, using S/MIME
                Response Document: 
                URI: ... 
The provider of the getCatalog method would define such a document
and make it available to potential users of the getCatalog method.
- prateek mishra

-----Original Message-----
From: Yin Leng Husband [mailto:husband@ozy.dec.com]
Sent: Wednesday, May 17, 2000 8:09 PM
To: Mishra, Prateek; 'xml-dist-app@w3.org'; SOAP@DISCUSS.DEVELOP.COM
Subject: RE: XML protocol security

If I may add another requirement to the list: 

Security-profiling capability?? 

Though the security-neutral protocol should support 
enough flexibility to incorporate a range of security 
arrangements, there should be some classification or 
systemized way of selecting from the range in order 
to facilitate cross-organization exchanges without 
requiring extensive (if any) security-negotiation phase. 

Yin-Leng Husband  
Compaq Computer Corporation     


-----Original Message----- 
From: xml-dist-app-request@w3.org [ mailto:xml-dist-app-request@w3.org
<mailto:xml-dist-app-request@w3.org> ]On 
Behalf Of Mishra, Prateek 
Sent: Thursday, 18 May 2000 6:19 
To: 'xml-dist-app@w3.org'; SOAP@DISCUSS.DEVELOP.COM 
Cc: Chippada, Radhika 
Subject: Re: XML protocol security 

It would be useful to list some of the requirements for secure XML 
messaging. Here are some thoughts and I invite other contributions. 
The most important aspect seems to be that the protocol 
itself be security neutral but support enough flexibility (using headers 
for example) to incorporate a range of security arrangements. At first 
this seems to be the case for SOAP where there is no hard-wired security 
but there is support for a flexible set of headers which could presumably 
security properties of the message (and those required of its response, if 
XML messaging will be used in many different environments, with security 
needs ranging from none to requiring authentication, privacy thru 
message integrity, non-repudiation, secure acknowledgement, etc.  
The binding between security properties and the SOAP RPC call needs to 
remain fairly loose. The same method call may be exposed with 
varying security properties to different classes of users from within an 
XML messaging can utilize many transports. Historically, some security 
methods have been developed in the context of a transport (SSL, HTTP digest 
authentication, S/MIME). It should be possible to utilize this type of 
There is a strong consensus around the Role-Based Access Control (RBAC) 
model as providing a scalable framework for enterprise security. This is 
in the security architecture for EJBs , academic and industrial research 
Sandhu research) and in commercial systems (Netegrity, enCommerce). 
The ACL approach is not considered scalable in an enterprise context where 
there are many 1000's of users. This needs to be factored in when developing

an access control model for XML messaging. 
- prateek mishra 
Netegrity, Inc. 
Waltham, MA 
disclaimer: these are my personal opinions, not my employers. 
Received on Friday, 19 May 2000 10:00:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:27 UTC