RE: XML protocol security

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:...
                URI:....
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. 
  
1. 
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 
glance, 
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 
express 
security properties of the message (and those required of its response, if 
any). 
  
2. 
XML messaging will be used in many different environments, with security 
needs ranging from none to requiring authentication, privacy thru 
encryption, 
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 
organization. 
  
3. 
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 
"off-the-shelf" 
security. 
  
4. 
There is a strong consensus around the Role-Based Access Control (RBAC) 
model as providing a scalable framework for enterprise security. This is 
reflected 
in the security architecture for EJBs , academic and industrial research 
(NIST, 
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