RE: SOAP header for authentication etc

When we addressed this issue in ICE, we decided that we would convey
identity of the sender (and, optionally, receiver) in the protocol, but
leave issues of security and trust to the transport layers, since there
are already good solutions in place there.

It's heavily suggested, but not required, that implementations tie
together the notions of identity between the layers (transport, ICE,
application). For example, if ICE is used over authenticated HTTP with
SSL, it's a good idea to issue a different HTTP username and password, or
even digital certificate, to each person with whom you're communicating.

On Wed, 7 Jun 2000, Mike Dierken wrote:

> s: O
> X-Status: 
> X-Keywords:
> X-UID: 1521
> 
> 
> > Any takers for getting together a list of features that people would like?
> > > 
> > > Are there any standard or convetion for specifying 
> > > authentication etc within <SOAP-ENV:Header>?
> > 
> 
> Is 'authentication information' meant to be used in the context of 'perform
> this operation on the behalf of user-x'? or is it 'perform this operation &
> here is a magic key'? or something different?
> 
> Since SOAP can be carried over multiple transports, and those transports
> have mechanisms for user identification, should there be a concept of
> 'inheriting' user identification information from the transport? The
> underlying transport might not have very secure user-id, but when they do it
> may be nice to use them. Would this be the job of a SOAP dispatcher, to
> extract transport info, transform to a unified format & load into the
> header? Can a SOAP dispatcher touch the message or will it ruin
> digest/checksums/etc.?
> 
> Also, should this discussion be made on the SOAP

Received on Friday, 9 June 2000 12:05:01 UTC