[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What Does SOAP/WS Do that A REST System Can't?

• To: Joe Gregorio <joe.gregorio@g...>
• Subject: Re: What Does SOAP/WS Do that A REST System Can't?
• From: Rich Salz <rsalz@d...>
• Date: Wed, 13 Apr 2005 22:54:26 -0400 (EDT)
• Cc: "xml-dev@l..." <xml-dev@l...>
• In-reply-to: <3f1451f50504131322584d1611@m...>

>  The claims you are making are rather strange.

Sorry.  What seems strange.  It might be more effective for me to
explain myself better, than to try to go into further explanation.

> Thanks for the analysis of both these methods, but you missed the point.
> I brought them up to demostrate that HTTP auth is extensible.

Yes, you're right, I missed the point.  (Wasn't the first time,
won't be the last. :)

As I understand it, HTTP auth is somewhat extensible.  A client
can make a request, and the server can respond with a challenge.
The client uses that challenge to authenticate itself, re-issue
the request, and verify the server's identity.

How can the client get the server's identity before sending any
"real" data?  A well-known URI or a new method? How can the server
challenge the client to prove it's identity without requiring state
on the server?

I believe the very statelessness of HTTP and REST makes it
impossible.  (Yeah, I know, it's not really without state, it's just
that all the state is in the representations sent back and forth.
Not good enough -- you need *shared state* that doesn't get
communicated.  Go see the SSL/TLS or WS-SecureConversation specs.)

Also, by the rules, all data the client sends should be POST not
GET since they're not idempotent.  The minute all your data transfers
are POST, most of the HTTP/REST benefits vanish.

> If the current
> schemes don't meet your requirements why aren't you working within
> the HTTP framework to define an authentication mechanism that *does*
> meet your needs.

Not to be flip, but why should I?  I'd say the onus is on the
HTTP/REST community to prove me wrong.  They may not care to do so,
or be competent to do so, and that's fine -- they're certainly
under no obligation to oblige me.  But on the other hand, they
can't bitch until they knock down my arguments. :)

The challenge is pretty simple to explain, actually.  Design a
REST implementation of SSL.

        /r$

-- 
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html

• Follow-Ups:
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Dave Pawson <davep@d...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Mark Baker <distobj@a...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Joe Gregorio <joe.gregorio@g...>

• References:
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Joe Gregorio <joe.gregorio@g...>

• Prev by Date: Re: United States Patent: 6,880,125
• Next by Date: Re: What Does SOAP/WS Do that A REST System Can't?
• Previous by thread: Re: What Does SOAP/WS Do that A REST System Can't?
• Next by thread: Re: What Does SOAP/WS Do that A REST System Can't?
• Index(es):
  • Date
  • Thread