Is it even possible to achieve message level integrity in the context of a RESTful web service exchange?

Francois Lascelles tackles this very question in his latest  Security for enterprise SOA/WOA and cloud computing blog posting.

RESTful Web services and signatures

Well, I guess the simple answer is: Transport a SOAP message then via REST.

REST is an architectural style, not an architecture or framework. It gives you all the tools to build an architecture that fits your needs.

Using and having a common understanding of the representation of the resources being sent is crucial. If you need payload to be signed or encrypted, just do it and make sure the MIME type indicates that so that a client can do the appropriate thing.

I'll save readers the trouble of reading the whole thing if they just want to know the answer.  The answer is yes, it is possible and being done in practice.  A standard approach was created but for some reason the later version of the spec lacks it.

I'll save readers the trouble of reading the whole thing if they just want to know the answer.  The answer is yes, it is possible and being done in practice.  A standard approach was created but for some reason the later version of the spec lacks it.

So what is the best practice here?  On the Resteasy project I mostly have people asking me what to do, rather than people tellling me what they want in regards to message signing and encryption.  I've been recommending multipart/signed and multiple/encrypted.  It seems to me though that signing belongs in a message header (i.e. oauth1 signing) and encryption, IMO, belongs as a content-encoding.

Bill,

Sounds like you prescribe S/MIME for RESTful web services. Is that what you are getting at? I am curious if you know of examples where this is being used? I do agree that signatures belong in a header (transport though, not message level) such as with OAuth (this, the whole point of my post).