Subscription Response Details regarding Validation about pubsubhubbub

[maksverver]

The hub may answer with a 202 response and later deny the subscription request, since subscription validation may happen asynchronously. If the subscription request succeeds, the subscriber should consider the subscription to be pending until it receives either the verification of intent, or a "denied" callback to indicate that validation failed.

(Note that the subscription is not active until verification of intent has succeeded, regardless of whether the subscription needs to be validated or not.)

[MinusFour]

I see. I understood from the spec that both events (validation and verification of intent) could happen. Because of this:

The subscription MAY be denied by the hub at any point (even if it was previously accepted). The Subscriber SHOULD then consider that the subscription is not possible anymore.

So what you are saying is that while the subscription is in its pending status, it should not expect both events? Verification of Intent will not happen if validation fails? However, the subscriber should expect denial to be possible after verification of intent happens?

If denial still can happen after verification of intent (at any time like the spec says), shouldn't there be an authentication mechanism? Otherwise if the topic of the specific callback URL is made known, other sources (non-hub) could unsubscribe the subscriber. I feel like I'm missing something from the spec but maybe I just misunderstood it.

[maksverver]

Verification of Intent will not happen if validation fails? However, the subscriber should expect denial to be possible after verification of intent happens?

Yes to both, according to my interpretation of the spec.

If denial still can happen after verification of intent (at any time like the spec says), shouldn't there be an authentication mechanism? Otherwise if the topic of the specific callback URL is made known, other sources (non-hub) could unsubscribe the subscriber.

That's a good point. I think you're right: that's a problem which is not addressed by the current spec. By the way, the same issue already exists with verification-of-intent: if the subscriber receives multiple callbacks (perhaps with different lease periods) how does the subscriber know which (if any) came from the hub?

Perhaps the spec should add authentication of callbacks using the shared secret, for both verification of intent and denial of subscription. That means at least callbacks can be done over HTTP, though passing the secret to the hub must be done over HTTPS. Not an unreasonable trade-off.

(Without authentication, one way to secure the protocol is to generate a secret callback URL and use HTTPS for requests in both directions. In that case, there is no need for the shared secret authentication scheme either.)

[MinusFour]

I agree. Right now, it's sort of possible for the subscriber to white list the sources through IP but I fear this sort of verification is too loose and I'm not even sure of it's complete implications. Using the secret for verification of intent and denial could work but then on what should the HMAC be computed? No data is being sent by either isn't? Unlike POST updates where you get a POST payload.

Also, can Hubs subscribe the subscriber again? I was under the impression that verification of intent should only happen once after the subscriber did the subscription request to the hub and afterwards mark the subscription as valid, hence following subscribe GET requests shouldn't have any effect as the subscription is already valid, unless of course subscriber initiated a new subscription request with the hub. Nevertheless, there's still a small time window where an external source (non-hub) could send a subscribe GET request and therefore invalidating the subscription with the hub.