[
Lists Home |
Date Index |
Thread Index
]
> 'Shared state' seems more like a derived requirement from your
> authentication mechanism choice and its implementation.
I'm not sure what you mean by a derived requirement. I don't want
to create my own security mechanism, that's considered real bad
practice. I want to use existing mechanisms. So my requirement
(for our purposes here) is like "I want to do something very much like
SSL" So is shared state therefore derived?
> You need shared state. Shared state that doesn't
> get communicated. Shared state that doesn't
> get communicated over HTTP. And you claim that the
> 'statelessness' of HTTP is a problem.
Sorry, I was too terse. We need to communicate some shared state
so that we can derive common keys. Or we need something like a
running digest of all messages we've exchanged in this "conversation."
> To narrow the conversation,
> I'll go read WS-SecureConversation.
Good. That should do a much better job than I can.
> Are there more detailed
> reasons as to why every client operation
> ends up being a POST?
Because GET doesn't have a message body? Because I need a message
body because I don't know of any way to get a few K (of binary
data; add 4/3 if doing base64) to the server without putting
it in the message body, and because it's *not* idempotent; replays
are something we're trying to avoid.
> Even if every operation is a POST, I believe there would be a
> benefit from leveraging the extensible authentication mechanism
> outlined in RFC 2617. The most obvious one of which is that it can
> be applied to resources who representations aren't just
> 'application/soap+xml', i.e. HTML, images, etc.
I agree it would be a good thing if it could be done. I'm fairly
confident it can't be. I'm sure you're tired of hearing me say
that. Hopefully we're getting closer to an understanding of why.
/r$
--
Rich Salz Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
|
