Subject: [Webpush] Publishing events to multiple subscribers

From: Phil Hunt <[email-masked]>
Date: Thu, 23 Jul 2015 18:26:12 +0200

As a follow up to my comment on in the WG meeting today. I wanted to let the group know that the SCIM WG is considering an event notification proposal that sends events to subscribers interested in knowing about events that have occured within a SCIM service. The subscribers may be individual mobile apps, or they may be partner SCIM service providers in another administrative domain.

You can find the initial proposal here:
https://tools.ietf.org/html/draft-hunt-scim-notify-00. 

This draft specifies some concepts that are not yet part of WebPush and indeed includes web push as a possible message delivery protocol (and probably should not be).

I see a lot affinity and similarities that show a good design overlap with what we have been thinking and the current WebPush proposal. I like the overlap between the SCIM notify draft and the current WebPush work. As such, I would like to consider re-working the SCIM Notify draft to be WebPush centric if possible.

While not in the current scope, I do want to be able to allow multiple subscribers to receive events to the same “subscription”.  Similar to the WebPUSH architecture, we have a publication server that offloads the job of message delivery from the application server and takes care of delivery to subscribers. SCIM Notify has both 1-1 to cases (e.g. to mobile apps) and 1:Many cases, where multiple cloud providers may wish to know about changes that are occurring in a domain.

While one-to-many might not be in scope, I would like to at least make sure this is possible for a future “extension” draft.  This would allow the SCIM notify draft to be simplified and focus instead on SCIM event definitions rather than having to define delivery.

Note: The SCIM WG has not yet adopted this work. At this stage, it is just a proposal some members are working on. We’ve slowed down while the WebPUSH work has been progressing.  Now seems like a good time to revisit the proposal.

Thanks,

Phil

@independentid
www.independentid.com
[email-masked]

---

From: JR Conlin <[email-masked]>
Date: Thu, 23 Jul 2015 11:46:22 -0700

Hi Phil,

I'm sure others will be far smarter about this, but I'll note that one
of the big reasons we passed on broadcast was mostly around the deep
complexity of secure key exchange for multiple hosts. Because of privacy
reasons, WebPush doesn't want intermediaries to be able to read user
data. There's a bit of hand waving even in WebPush, but fundamentally,
the creator of the data (the App Server) and the receiver of the data
(the App) have both agreed to a key exchange outside of WebPush. This
key is (ideally) unique between creator and recipient and never travels
across WebPush.

This makes matters a tad complicated when you've got multiple
recipients, since the data being sent needs to be re-encrypted for each.
Now, add in the problem that your specification also uses encryption and
data sizes can get fairly out-of-hand.

Granted, there's little preventing a single App Server from using the
same encryption for all App recipients (aside from the tears of the
OpSec team), much like picking a point on the curve where O=P=Q. Of
course, this means that the content of the message is a target of
attack, and we'll hope that they didn't use the same O=P=Q key selection
method.

Going back to inadvertent privacy concerns, there's also the potential
for social graph disclosure with any broadcast method. For things like
server alerts or surf reports, probably not a big deal. For things like
political marches or whistle-blower efforts, a bit more of a concern.

Hopefully, this won't discourage you from your goal, I simply wanted you
to know some of our previous discussion.

On 7/23/2015 9:26 AM, Phil Hunt wrote:
> As a follow up to my comment on in the WG meeting today. I wanted to
> let the group know that the SCIM WG is considering an event
> notification proposal that sends events to subscribers interested in
> knowing about events that have occured within a SCIM service. The
> subscribers may be individual mobile apps, or they may be partner SCIM
> service providers in another administrative domain.
>
> This draft specifies some concepts that are not yet part of WebPush
> and indeed includes web push as a possible message delivery protocol
> (and probably should not be).
>
> I see a lot affinity and similarities that show a good design overlap
> with what we have been thinking and the current WebPush proposal. I
> like the overlap between the SCIM notify draft and the current WebPush
> work. As such, I would like to consider re-working the SCIM Notify
> draft to be WebPush centric if possible.
>
> While not in the current scope, I do want to be able to allow multiple
> subscribers to receive events to the same “subscription”.  Similar to
> the WebPUSH architecture, we have a publication server that offloads
> the job of message delivery from the application server and takes care
> of delivery to subscribers. SCIM Notify has both 1-1 to cases (e.g. to
> mobile apps) and 1:Many cases, where multiple cloud providers may wish
> to know about changes that are occurring in a domain.
>
> While one-to-many might not be in scope, I would like to at least make
> sure this is possible for a future “extension” draft.  This would
> allow the SCIM notify draft to be simplified and focus instead on SCIM
> event definitions rather than having to define delivery.
>
> Note: The SCIM WG has not yet adopted this work. At this stage, it is
> just a proposal some members are working on. We’ve slowed down while
> the WebPUSH work has been progressing.  Now seems like a good time to
> revisit the proposal.
>
> Thanks,
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush