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<https://groups.google.com/d/msg/pubsubhubbub/hfXUeXTlcAg/-zWZdgTUG9EJ> : - 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<http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#hubbestpractices>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
