Hi,

> From: Ben Tilly [mailto:ben_tilly / hotmail.com]
> Sent: Monday, December 11, 2000 10:05 PM

> Well I don't like SOAP, so I suggest doing the least you
> can while claiming you support it, then wait to find out
> if people really want more. :-)

Sure.  I'll do so.

> > > I think that Bruce Schneier is absolutely correct that by
> > > building an internet prototol with no security model which
> > > is hard to filter, SOAP will be responsible for a new host
> > > of security holes.
> > >
> > >   http://www.counterpane.com/crypto-gram-0006.html#SOAP
> >
> >Agreed.  DCOM over HTTP is required but not adopted much.
> >SOAP and XML-RPC is to be the next candidate but we do
> >care security vulnerabilities as he said.  Transport
> >seurity SSL might help for some purpose.  Messaging
> >security XML-Signature might help for another purpose.
> 
> Security here means two different things.  One issue is
> proper authentication, the other is privacy of data.  My
> inclination is to worry about getting authentication right
> and then letting people who care about encrypted data do
> that with ssl, ssh, or some other tunnelling mechanism.

Ohter issues except authentication and privacy of
data I konw is:
  - integrity
  - non-repudiation
  - blind signature
  - ...

SOAP itself provides no security.  I approve SOAP in
point of this simplicity.  Developers using SOAP shall
consider appropriate security policy and integrate
appropriate techniques.  And same applies to any other
RPC system.

> It isn't hard to emulate the structure of an ACL system
> with a capability system.  Have an initial login that is
> mediated through an ACL.  Have it return an object
> through which all further access is mediated.  That
> object carries user information.  However it may then
> return objects which themselves authenticate directly.
> 
> For instance you log into a database and get back a
> database handle.  Then you send a query through the
> handle, the database checks user permission, runs the
> query and then returns another handle through which you
> get results.  Then you ask the query handle many times
> for results.
> 
> The system administrator sees an ACL system.  But the
> majority of access is not authenticated that way.
> Most of the traffic, if compromised, would give you
> only limited access to transient parts of the system.

Thanks again.

For dRuby users: DRbObject in DRb seems to be able to
support above capability system I think.  Any idea?

Besides this, ACL implementation in DRb now does not
support full POSIX ACL.  In fact, only supports
accessing control by host ip-addr like "deny from all
and allow from 192.168.1.*" and only supports accessing
control per DRbServer...

// NaHi