Let my try responding one point at a time, it makes for easier reading, I think.
> verify_token won't prevent any DoS attack. If someone sniffed the callback url (with or without the verify token), nothing will prevent someone from doing a DoS attack. ' Nothing will prevent the attack itself, but the attack can be recognized as fraudulent, and the requests quickly rejected without acting upon them, by virtue of the verify_token no longer being valid (since it was previously discarded by the subscriber). >if he gets verification on that callback, it knows it comes from the hub, because the hub only knows about this url at this point. Right, but after that point, the callback url has been exposed, and since it's not a used-once-and-discarded secret, it doesn't help thwart subsequent illegitimate verification requests. > You are right that the url is not encrypted in the verification request, but again, that is the same with the verify token. Right, but the verify token can be discarded so that it can never be successfully used again; the URL can't. >The only "difference" would be for later reconfirmations of intent, which, with the callback could be "spoofed". If someone found the callback url, they could reconfirm with the susbcriber that he still wants the data. That doesn't seem so bad, and for the cases where it is (a subscriber may want any 3rd party to know that it's getting content from a specific hub), then, the use of HTTPS on the callback url just solves that. [I assume you meant "a subscriber may NOT want"...] I'm a little confused; the use of HTTPS on the callback doesn't authenticate the hub to the subscriber, it authenticates the subscriber to the hub. Unless you're talking about using client certificates (i.e. the hub provides a client certificate to the subscriber on the verification request) ? > Another option would be for subscribers to refuse 2nd confirmation and resubscribe with a different callback when in doubt. Hmm, that's an idea, let me think this through... - Subscriber's subscription request to hub includes callback="http://www.myapp.com/subscriber?sub_id=12345"; - Hub's verification request to callback URL is accepted by subscriber, who records the acceptance in some way - DoS attacker sends verification requests to callback URL, subscriber rejects them because they're not the first one. So far, so good. - Subscriber sends unsubscription request to the hub, supplying the original callback URL - ... OK here's a problem, I think... at this point the subscriber can't distinguish between a legitimate unsub verification request from the hub, and an illegitimate one from an imposter, because we're past the point where only the hub knows the callback URL. At this point in the conversation, I feel like I should pause and say that I'm not trying to be a pain in the a** (although it probably seems like it). This has been a good conversation and I appreciate the interaction. I just want to make sure that before something is removed from the spec, the use case that it addressed is either addressed another way, or agreed to be not important to address. I infer from the conversation so far, that your motivation for removing verify_token was related to the use case of leveraging it as a subscription identifier, and I agree that for that use case, it's not needed, since a callback URL that's unique to the subscription is sufficient to accomplish that. The original use case that Brett described seems to still be relevant, however. > Now, IIRC , at the time when the verify_token was added to the spec, nobody really thought about using a different callback url for each subscription (the idea came from Jeff Lindsay's feedback). In that context, yes, having a verify token made sense, because it allowed the subscriber to know what was being confirmed. I'll take your word regarding the history, since I just arrived on the scene recently. I can see how, prior to the idea of having distinct callback URLs, some people could/would have used the verify_token for that purpose (after all, the spec itself suggests this in 6.1, but later contradicts itself in 8.2). I agree that it makes sense to document more clearly that it is not needed for that purpose. -Andy
