I'm on the same page as you are. Hubs should care/store the verify_token... Also, I'm actually in favor of stripping the verify_ token from the whole spec as it's useless.
Julien On Mon, Feb 20, 2012 at 3:37 PM, Andy Dennie <[email protected]>wrote: > According to section 6.3 of the spec: > > Before a subscription expires (i.e., before hub.lease_seconds elapses), > Hubs MUST recheck with subscribers to see if a continued subscription is > desired. Hubs do this by sending the subscriber a verification > request<http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#verifysub> > with hub.mode equal to subscribe. This request MUST match the original > verification request sent to the subscriber (but with a new hub.challenge > ). > > > The "MUST match the original" phrasing in the last sentence implies that > this refresh request must include the hub.verify_token value present in the > initial subscription verification request (if one was present). I have a > feeling that this is an unintended implication, since that would require > the hub to store the verify_token value indefinitely, and also would take > away the security that comes from the "one-time-use" aspect of the > verify_token. > > Can anyone confirm my understanding? Thanks. >
