Macaroons for web push interactions (publish/subscribe over HTTP)

65 views
Skip to first unread message

Jørn Wildt

unread,
Jan 6, 2016, 5:24:38 AM1/6/16
to maca...@googlegroups.com
I am implementing a web push solution where our software will reach out to third party services with a HTTP POST when something interesting happens. Now I want to add some sort of integrity to the POST data such that the receivers can be assured that the POST indeed comes from our service.

For this purpose I am considering using macaroons, but I am a bit unsure about how to do it.

Here is what I intend to try:

1) Web push subscribers register their post back URL with our software and during this process a common shared secret is exchanged. This is a manual process.

2) Each web push data contains a unique event GUID. Our software will take take this GUID and make a (short lived) macaroon from the shared secret like this:

  expires: xxxx
  event-id: <guid>
  
3) Web push data and macaroon is POSTed to the subscriber(s).

4) The reciever of the web push takes the macaroon and verifies it with respect to the actual event GUID, expiration date and shared secret.

Is this is an "acceptable" solution? Did I miss something? Better ideas?

I can think of one alternative where the subscriber creates an initial macaroon and shares that with our software in step 1 instead of sharing a common secret. It could look like this which is a macaroon that is only valid for a certain subscriber:

  subscriber-ID: xxx

Our software then attenuates the macaroon with "expires" and "event-id" yielding something like this:

  subscriber-ID: xxx
  expires: xxxx
  event-id: <guid>

That solution seems more correct as the verifier of the macaroon also is the one that issued the original macaroon: instead of sharing a secret it works by the subscriber issuing a macaroon granting access to itself.

The drawback of the solution is though that step 1 is a manual process and would require some sort of macaroon tool for creating the initial macaroon - that is a bit more complex than simply exchange some random string.

Comments?

Thanks, Jørn
Reply all
Reply to author
Forward
0 new messages