Hi, We are working on PSHB support here at MySpace. We have decided that authenticating the caller is a key requirement for various legal reasons, allowing us to hold clients to a terms of service agreement, as well as allowing us to easily shut down malicious subscribers. Obviously MySpace users' data is subject to a number of privacy rules, which depend on who the subscriber is, among other factors. It's also just useful for a number of other reasons, such as usage tracking.
The method of authentication we are planning to use is OAuth, since it's an open standard, and one we already use across the rest of our APIs. Since MySpace is acting both as a hub and a publisher, communication between the hub and and a set of publishers is not a problem we need to solve. The implementation I have in mind, is a standard OAuth request, where all parameters (including hub.* ones of course) are signed per OAuth. There are 5 ways in which I see this impacting the PSHB spec: 1. The hub.verify parameter is set to "OAuth" 2. The hub.verify_token parameter is redundant in this context, and is ignored, if present 3. Verification of the intent of the subscriber is redundant, and is not done 4. Automatic subscription refresh requests are signed using OAuth, all PSHB specific parameters remain unchanged. 5. Outgoing updates to the subscriber are signed using OAuth, and the X-Hub-Signature header is omitted. In this case I wonder if it's necessary to identify the signature method to the subscriber so that he knows not to look for the X-Hub-Signature header and instead look for OAuth parameters. Perhaps adding a hub.verify parameter with the outgoing updates is something that could be changed as well. This parameter may also need to be added to the automatic refresh request. We are forging forward with our implementation, and are quite close to being ready to release this functionality. The only major roadblock at this point is simply spec compliance. I'm very hopeful we can get some general agreement over the correct way to do this very soon. Any and all thoughts very welcome. Nikita [[email protected]]
