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

RE: XML protocol security

From: Adi Oltean <aoltean@Exchange.Microsoft.com>
Date: Thu, 18 May 2000 11:52:25 -0700
Message-ID: <19398D273324D3118A2B0008C7E9A56909C91FE8@SIT.platinum.corp.microsoft.com>
To: <xml-dist-app@w3.org>
> The "SOAP object reference" concept is a declared non-goal of the
> current SOAP spec. Therefore capabilities cannot fit naturally in SOAP
> design. 

[Constantine] I think that they will be quite easy to add.

[adi] In my personal opinion the problem is not how easy/hard is to add
these feature but how do you solve scalability problems that occur.
Dealing with object references will limit the scalability of a Web-based
component server. Such a server must scale beyond millions of clients
per day - and many of these clients may either become unreachable in
time as a consequence of bad network conditions or these clients can die
unexpectedly. Since each client may create potentially several objects
the net result is that you have a huge amount of objects that must be
garbage collected. And distributed garbage collection mechanisms is a
difficult problem at Internet level. Not to mention that you must keep
in-memory state at the server side for the entire life of the object...
(which is not needed for lightweight stateless objects that seems to fit
very well in SOAP model). The picture looks even worse in capability
world since a single object can have many different capabilities - as
opposed to a single type of reference - and each capability must be
GC-ed independently.

> That's because since a capability is nothing more than a
> (marshalled) object reference that has associated a set of access
rights
> which were marshalled together with the reference (because even after
> marshalling you must maintain the rule that you cannot perform an
action
> to a capability unless you have the proper access right to do it).

[Constantine] AFAIK Rights are not usually marshaled with reference in
implementations 
I have seen. Pointer representation was generated with secure random
number generator and some sort of proxy object lived on server. 

Implementation like you described was done in e-speak 2.2 
(www.e-speak.net). But I do not like it.

[Adi] Agree, but that's an implementation detail. From the client point
of view both models should look the same (almost).

> (check
> http://www4.cs.fau.de/~riechman/papers/abstract-smo-nspw-97.shtml for
> example)
[Constantine] The paper cannot be downloaded (dead link) so I have not
read it.
[adi] Ok - check
http://www4.cs.fau.de/~riechman/papers/nspw-97-meta-sec.ps instead.

Thanks, Adi
Received on Thursday, 18 May 2000 15:00:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:56 GMT