Heh. Sadly, we may both need to stand in line. I am sure that Tim's got tenure, and besides, I really want to rename mine to "things i've likely forgotten." Alas, typepad warns against such renamings.
Now, if only you can help me understand REST in the context of security (specifically, confidentiality).
If you use TLS, of course, then you get the confidentiality, but lose the visibility, cacheability, etc, that contribute so well to the scalability. However, if you want confidentiality, then you obviously don't want visibility, and it is likely that you do not want the cacheability either.
An alternative to TLS would be to encrypt the payload, but leave the headers in tact. S/MIME, PGP-MIME, WS-Security. Sounds familiar. An unscruplous attacker may track your requests and infer meaning from the uris that you access, but that could be alleviated via limiting access to a single uri between parties. And you could limit the requests to the good ol' "Do Something" method of choice, POST. If you want to actually target a different uri (and method?), then that would be included in the encrypted content. D'oh. Now we're starting to sound like web services, eprs. I am sure I am missing some key bits. Help, please.
It seems to me that this is a question of interest to enterprises conducting or thinking about conducting confidential business over the internet. It also seems to me that it could call in to question the importance of visibility and cacheability for scalability on the internet, or perhaps more correctly, could call into question just how important or perhaps [im]possible "internet scale" is to business interactions that require confidentiality. Ebay might disagree.
It is likely that I have already forgotten this.
Comments