Subscription Response Details regarding Validation

[MinusFour]

I have been reading the spec and the issues around but I just didn't find what I was looking for. If it has already been covered, then I apologize.

Would it be fair to expect a 4xx answer from the hub when subscription validation fails? Or will the hub answer with a 202 answer regardless? The spec does mention that the hub will answer with 4xx in case errors are found but in that case why wouldn't they send the reason within the subscription request instead of using the callback. On the other hand, if hubs do send out a 202 status code and later on might send out a subscription denial notice what options do subscribers have to foresee such event? Feels like the subscriber will mark the subscription as valid once he gets the 202 code and possibly invalidate it if a hub.reason ever gets to the callback url which will trigger both events (subscription and unsubscription).

Either way, if validation (and possibly verification of intent) fails and hubs do respond out with 4xx status codes don't they deserve a specific response status code during subscription?

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