Andy, The only way to "secure" communication upon subscription is to use https on the hub. By doing so, the subscriber can very well check that it's talking to the right hub, and none can then intercept that. Using (or not) verify_token doesn't change anything.
verify_token does not have any "security" role here and won't prevent any attack whatsoever. It's only purpose is/was to help subscriber match a subscription faster with a given feed, should they receive 2 verification of intent concurrently. Now, this can very well be done with the callback and I would argue that this is actually more elegant than using an extra param. An easy way to make that change backward compatible is just to specify that any additional POST param sent along the subscription should be used in the GET verification of intent. Julien On Mon, Feb 20, 2012 at 4:06 PM, Andy Dennie <[email protected]>wrote: > I tried to reply to this a while back, but my comment didn't go through, > so I'm trying again. My understanding of the verify_token is that it > allows the subscriber to confirm that the subscription verification > request is coming from the hub to which the subscription request was sent, > and not an imposter. Assuming the subscription request is sent to the hub > using HTTPS, the value of the verify_token is hidden from wire snoopers. > Therefore, its presence in the verification request to the callback proves > that the sender of that request is the same hub to which the subscription > request was sent. The value of the verify_token could be sniffed off the > verification request, but since it is a one-time-use value, it could not be > used again by an imposter. > > I do see that putting an equivalent value into the callback URL via a > query parameter would have the same mechanics of being encrypted in an > HTTPS subscription request and being visible in a subscription verification > request, and it still could be treated in a one-time-use way by the > subscriber (i.e. discard the value after the first verification, so that a > subsequent verification request from an imposter would be rejected) . But > somewhat inelegantly, it would need to be supplied on all future callback > requests (i.e. content distribution), instead of just the subscription > verification request, even though it would be no longer of value. >
