verify_token in subscription refresh request?

[Andy Dennie]

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 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.

[Julien Genestoux]

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

[Andy Dennie]

Actually, I don't think hubs should store the verify_token beyond the subscription verification request -- as I understand things, it's only purpose is to "authenticate" the hub sending the verification request, and is of no further use after that (the hub.secret value serves that purpose for content distribution requests).  In fact, in my code, I purge the verify_token value after validating it in my processing of the subscription verification request, so that it can't be used again by an imposter hub that has sniffed its value.  

But then again, I'm kind of new to this stuff, so I could be interpreting things incorrectly.

Please see my related comment in the "removal of verify_token" topic.

-Andy

[Julien Genestoux]

Oooops, I meant "Hubs should NOT care/store the verify_token..." . 

Sorry about that!

And again, it's purpose is certainly not to authenticate anything... as that wouldn't be secure. 

The only way authenticate the hub from the subscriber perspective is to use https when talking with the hub.

Thanks

[Julien Genestoux]

Don't expect the hub to send any automatic (re)subscriprion request by default.

but if it does, yes, it should include a verify token.

Thanks,

On Fri, Feb 15, 2013 at 8:53 PM, Poluxus <lafeuill...@gmail.com> wrote:

So if a hub is sending an "Automatic Subscription Refreshing request", it's doesn't come with a verify_token?
Just to be sure

--
 
---
You received this message because you are subscribed to the Google Groups "Pubsubhubbub" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pubsubhubbub...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Poluxus]

I will change my PuSH implementation to work with release time
Thanks