Matasano is featured in a preview of their Hacking Capitalism talk at Blackhat, which they say will describe various holes in FIX: You’d think electronic financial trading would be extra secure, but not so much: One of the most popular application-lay…

The more I think about it, the more I think REST isn’t message or document based, it’s a form of RPC. REST is RPC that’s restricted to an agreed upon interface of 4 procedures (POST, GET, PUT and DELETE).

Your thoughts?

I agree 100%. In fact, there’s even more to security than you enumerate. It’s a hard problem. This post was really just to point out the fact that Atom allows encryption and signing.

The long and the short of it is that RESTful HTTP has some significant limitations when it comes to security, and we need to start thinking about them now. Sometime soon I’m going to return to this subject and spell out the current issues and possible means of addressing them. Right now, though, my plate’s kinda full.

All these mechanisms are currently supported by WS-Security (which also uses XML-Signature and XML-Encryption). It would make sense to define a simpler profile of WS-Security for securing HTTP messages rather than to reinvent a new format.

What do you think?

I, nor no one else, has ever had a problem with envelopes. Nor is an envelope antithetical to HTTP–even HTML has an envelope. What I said, was that HTTP is not without an envelope–the HTTP headers fulfilling that role. Using another envelope does not sacrifice the power of HTTP, so long as the HTTP headers and standard media types (self-descriptive messages) and the other constraints are are still respected. Which is exactly what Atom and APP does, respect HTTP and allow your infrastructure to keep working. In other words, using an envelope pattern with HTTP works just fine, even when passing credentials or signed and encrypted messages from end to end.

Update: Anne, while the above is correct, after more thought on the subject, I see your point on authentication information in the envelope.  There’s much more thinking needed on this subject, and I’ll write more about it soon.  For now, I’d say this much: Basic+TLS is likely sufficient for 80% of use cases.  For the rest something new will be needed.  Currently, there are any number of alternatives: Amazon and Google, for instance, have custom  (though published) auth schemes.  Then there’s things like WSSE.  However, if the credentials are published in a custom header or in the message body, then at the very least the Authorization header should be set to something so that caches do the right thing.  More later.

The bad news is that we don’t have standards that allow us to support end-to-end security using an HTTP envelope. If you need to pass authentication credentials or you need to sign or encrypt specific content within the message, then you need to use an XML envelope.

So why do you view the Atom envelope as inherently better or more RESTful than a SOAP envelope? If you want to use a pub/sub model, then Atom makes sense. But if you want to use a request/response model, then SOAP makes more sense.

Then there’s the little detail that nobody will really trust any of this until it has been tested by fire when there is real money at stake and real thieves tying to steal it. I’m happy to see that APP provides an extensible framework that can “drag in” bits and pieces of other specs to provide a simple but adequate security model for blog-type data. Obviously WS-* would be overkill for that scenario. On the other hand, do you want *your* bank leaning over the bleeding edge and applying APP to a much more challenging security secenario just because the alternatives are ugly and complicated?

There is a lot of truth in the assertion that WS-* is an “ambiguous and non-interoperable mess”. The question is whether the way forward is to disambiguate through rigorous interop testing, or to start over with something like REST, Atom, and APP. I’m highly skeptical that the result would be much different — these are intrinsically hard problems, and finding a decent tradeoff between preserving the infrastructure that works today and providing a modern interoperable veneer over it just not easy. Doing it via negotiations among fierce competitors doesn’t make it any easier, to say the least. Even if, for the sake of argument, REST/APP was a technically superior approach than WS-* is, it is wildly overoptimistic to assume that the other challenges that have inhibited WS-* interop will not show up in the approach you propose.

In short, the ugly complexities of WS-* reflect hard-won knowledge much more than they are due to incompetent design or pathological politics. Even in some dream world where you have altruistic geniuses without egos designing new RESTful protocols from scratch, the intrinsic complexities of the security domain will intrude, and I’m very skeptical that the result would be notably better.

James Snell points to this developerWorks article by Nick Case which shows how to encrypt and sign Atom entries using Apache Abdera; Pete Lacey correctly notes that this addresses RESTful HTTP’s perceived message-level security shortcoming (and a…