Antonio Tapiador and Victor Sanchez of the Universidad Politecnica de Madrid presented a paper at FSW2011 on their experience with implementing the OStatus HTTP Stack for their own social network technology called "Social Streams."

"Social network federation with Social Stream and Social2social" first describes their advanced social model with people bearing roles in social spheres of each person and a trust degree simply described as how close a person is to you, the extremes being friend vs. acquaintance. Sounds very familiar to PSYC's context and trust concepts and the channel hierarchy as a way to model them together.

It goes on to address "Social2social security issues." For your convenience here are the relevant points from the paper:

1. "Forgery of feeds and spam feeds are possible due to the fact that anyone can request to publish any feed. When we request to publish or update a topic we provide the URL address for the topic and the hub will take it as a legit topic no matter what. For this very same reason is hard to identify if the author is the one pushing the feed and no way at all to determine if the author is willing to share the feed and in that case, with whom."
2. "Regarding attacks to the hub infrastructure, there are some messages (pinging after publishing for instance) that don't even require an ACK back so it will be quite simple to perform a potentially devastating DoS or DDoS attack by publishing random updates for fake topic addresses."
3. "The subscriber side is not completely safe either, even with the verify secret field (that again is not encrypted or protected in any way) an attacker should be able to force an unwilling subscriber to read, or at the very least receive tons of spam feeds."
4. "Furthermore an important missing feature for our scenarios in social2social are the support of multiple feeds for a single user. Right now if an activity needs to appear in several feeds we have to order the ping of everyone of them in different threads or make them wait in some kind of outbound queue. TCP pipelining is also possible to improve this exchange but can also became inefficient in a node with a huge number of feeds."¹.
5. "Last but not least we encounter no way to deal with private feeds or semi-private feeds in a secure way. There is no way to establish permissions or visibility restrictions for our feeds. In fact with the discovery proposed by the current draft of Ostatus feeds need to be open for the subscriber to get the hub URL that will manage the content distribution from now on."
6. "There is also another consideration about HTTPS and is that even if we use the protocol as a security measure the "middleman", the hub, need to be trusted with a lot of information. A new issue arise; if we want a flexible and fast growing environment ensuring new hubs will be an almost impossible job."
7. "There is also some issues about identity of publishers and subscribers that can be solved with Oauth or Oauth2 but this would not solve the fact that feeds and messaging between entities are still plain text that could be "sniffed"."

Overall they come to conclusion that they should better switch to the XMPP approach, but they also make a special proposal concerning encryption. Since HTTP is unencrypted, there is a huge potential for abuse there. Here's what they think of HTTP over TLS aka HTTPS:

"The main security protocol for pubsubhubbub is HTTPS for connections between the hubs and the others actors of the protocol. HTTPS has been proved fairly secure but the implementation nuances of this protocol require a trustworthy signing authority, so being able to start providing secure HTTPS services is neither fast nor easy. In our opinion forcing the newcomers to have properly signed HTTPS certificates may hurt the growing of the new federated environment. Even big players such as a Twitter or Facebook had delayed the implementation of HTTPS, so we do not expect the new players to implement it before hand."

So they present a solution they call the "Spartan Hub." It is a per-context end-to-end encryption similar to how DSNP has it. PSYC has planned for "multicast cryptography" which actually uses a symmetric encryption scheme instead. Achieves the same goal, but with a little less overhead. This kind of encryption can be deployed well over HTTP, HTTPS, PSYC and F2F protocols in form of binary data, but it would not be very efficient over XMPP as it would all have to be base64-encoded.