Andy, you’re right that there are two different use cases, and that they should probably not be mixed.
About subscription identification: IMHO the specs should strongly encourage users to put an id in their callback URLs. It seems strange to me to rely on the content of the ping to identify the subscription. I think it’d be great to see Pubsubhubbub evolving into something that is not only about feeds. An idea for the next spec version maybe. About impostor hubs: As you said, the verify_token is really efficient for this purpose only if used with https for the “subscriber to hub” request. And if originally it was designed to verify that the subscriber is talking to the same hub, the current spec is less clear about that, it says “to assist the subscriber in identifying which subscription” (6.1). In my opinion, for real protection against impostor hubs, the best would be to use hub.secret + https and then HMAC for the verification request (same as the authenticated ping 7.4). We could then drop the verify_token param that I find confusing. Antoine On Mon, Feb 20, 2012 at 2:33 PM, Andy Dennie <[email protected]> wrote: > I think we're talking about two different things here. Julien and Antoine, > you are talking about using the verify_token as a means for the subscriber > to match up the subscription/unsubscription verification request with the > associated feed on the subscriber side. But there is already a way to > accomplish that, namely by making the callback URL unique on a > per-subscription basis. > > My understanding of the purpose of the verify_token is, to quote Brett > Slatkin: > > > - Used by the subscriber to verify that the hub verifying a > subscription request is the correct hub and not an impostor. > - Used once and thrown away. > - Secret known by both the publisher and subscriber. > - Transmitted from the subscriber to the hub and back again to verify > the subscription. > - Could be stolen by a snooping party > > > [Note: Brett also described it as required, but I'm assuming it was > subsequently made optional]. > > Also, section 8.2 of the spec states: > > The hub.verify_token parameter in subscription requests enables subscribers > to verify the identity and intent of the hub making the verification > request. > > > That is, using https in the subscription request to the hub may secure the > request to the hub, but it doesn't do anything to authenticate the hub to > the subscriber in the verification request. However, by supplying the > verify_token in the payload of the encrypted subscription request, the > subscriber can be confident that whoever first supplies that same value back > in a verification request to the callback URL must be the intended hub, > because nobody else (at that point) could know it. It could be sniffed off > the wire during the verification request, but would be of no value to an > imposter in spoofing subsequent verification requests, since the subscriber > would only consider it to be valid once. > > So, the elegance, or lack thereof, in including the verify_token in the > callback URL depends on whether you consider it to be a feed identifier, or > a hub authenticator for the verification request. I don't look at it as a > feed identifier, since my callback URL already identifies the feed uniquely > (via a query string param). If you accept Brett's definition of its > purpose, then including it in all future requests to the callback URL (not > just the verification request) doesn't seem helpful, and could be confusing, > since its useful lifetime ends after the verification request. > > -Andy > >
