Recommend secret callback as alternative to hub.secret about pubsubhubbub

If the susbcriber has an HTTPS callback, the callback's secret-ness doesn't matter. Also if there is an HTTPs callback, the secret is useless.

The secret was introduced only because it was an elegant mechanism for subscribers who didn't want to use HTTPs.

If we're ok to force everyone to use HTTPS, then, we can get rid of the secret.

Dammit! Wrong Github account... but the previous comment was from me!

[evanp]

"If the susbcriber has an HTTPS callback, the callback's secret-ness doesn't matter."

I don't think that's the case. If the point of a shared secret is to prevent third parties from pushing false data to the callback at distribution time, then using HTTPS is a moot point.

However, you could require client-side certificates, in which case the subscriber can validate that the incoming HTTP POST is coming from someone at the hub organization. But that's really hard with a lot of Web servers, and it's probably setting the bar too high.

If you have HTTPs, then the callback url is protected all the way, so there is no way one could guess it and use it to post false data.
In this context, the callback itself is secret enough that it can be considered a shared secret between the 2 entities.

[evanp]

"If you have HTTPs, then the callback url is protected all the way, so there is no way one could guess it and use it to post false data."

Only if you use a unique callback per hub (I think you should use a unique callback per subscription, but I need to convince myself that that's the case).

If you use the same callback for multiple hubs, then it's not a secret any more.

Even if you're not using a unique callback actually. It's only known by the hub and the subscriber... They would be the only ones to know that it's not unique.