Use of hub.secret to authenticate hub in more circumstances
tonyg opened this issue · comments
hub.secret is available (when supplied in a subscription request) for use in subscription denial notifications and in verification of intent requests. Should it be used to authenticate the message from the hub in these circumstances? It could take the form of an X-Hub-Signature header on these requests just like for authenticated content distribution. The scope of the signature would be the hub.* parameters, presumably.
That works for me. I see no reason to to exclude interactions which are not notifications.
There is one thing that we'd need to clarify: how to provide a signature when the body is empty (as it will be for most GET requests.
Yikes, this sounds like it's heading in the direction of the dreaded OAuth 1.0 parameter signing where query params were sorted in alphabetical order before computing the signature.
Yeah, I don't like that either. BUT, I want to see if HMAC signature of secret + "" is dangerous in any way. Because if it is not, then we're fine. (and we do not need to sigh the headers if we recommend the HTTPs trick discussed previously...)
The HMAC signature of secret + "" will always be the same so someone could change the query string to send forged requests.
So, after discussing at length at the face to face meeting, we recognized that there is no good mechanism for signatures of GET requests. We also recognized that the use of https along with with a capability URL makes the protocol secure because the URL path itself can be considered as a shared secret in this context.
(I'm fine with this, btw -- in general, I favour use of capability URLs over any of the hub.secret stuff anyway :-) )