Web-Based Push Notifications
charter-ietf-webpush-01

[Ballot comment]
I reserved my position on this while I watched the discussion that Stephen had about Security. I was surprised that this did not reach a conclusion that he was tolerably able to live with. That is a shame. So I support his Block.

[Ballot comment]
Can I just say how much I love short, clear charters?

Not enough to write them myself, apparently, but a lot. And this one's quite accessible.

I agree with Pete's comments, including the part where if you think the working group should explicitly choose an HTTP-based solution, that's OK with me.

[Ballot comment]
In the third paragraph, it seems like instead of "The work may describe a protocol", you want "The work will describe a protocol". Am I misunderstanding something?

I am still concerned that not chartering this work to use an HTTP-based protocol is inviting unproductive discussions when the WG gets started. I do note that Paul Hoffman raised the identical concern in his review of the charter. This is, IMO, just inviting a standard APP rathole. That said, if you really want to leave the choice of base protocol up to a consensus discussion in the WG, I'm not going stand in the way.

[Ballot comment]
I think this is a fine thing to be working on and have no objection to sending this charter for external review.

Building on what Stephen says, I would like the WG to explicitly consider the privacy aspects of consolidating push events since that redirects the 1:1 relationship between pusher and pushee to allow the consolidating service to be aware of the relationships and services that exist.

[Ballot comment]
Somewhat oddly, I thought I knew what

  The work may include an exemplar
  protocol for devices registering with push services.

meant, until Pete said he couldn't understand it. I look forward to seeing an explanation about that, but it's unlikely that would change my ballot position.

[Ballot comment]

I've no objection to this going for external review.

I am concerned however about the security goals here and
would like to be clear about those before this is chartered.
(If they remain unclear then I figure that'd be worth a BLOCK,
but I'm fine if this is sorted before, during or after external
review so long as it is sorted.) Apologies if some of the
deployed proprietary schemes already address all of this,
I'm not that familiar with 'em.

I think there are 3 security things I'd like to be clear about:

First, I think it needs to be possible for pushed data to be
encrypted and authenticated at all times. I'm not sure if all
pushed data MUST or SHOULD be so protected but that
seems like something the WG would need to discuss. And
there are issues related to authorization (by the device
owner) here too. Given that that might not be so easy I
think it'd need to be explicit in the charter or am I missing
something?

Second, I think that there's a need for some analysis about
any differences in security between pushed and other data
for specific applications. (The security needs to be
commensurate I figure or else we're doing the user a
disservice telling them about application security properties.)
I'm not sure how that'd be reflected in the charter but I'd
like to chat about it. For example, my phone gives me a
push/sync option for email and I don't know if that provides
the same or different security compared to IMAP. I think
the same issues arise here.

Third, the charter says "This protocol will include the ability
to push the same message to multiple devices (broadcast)."
I have no clue how that can be done with the same security
features as a secured individual push. Can you explain a
bit? Arm-waving is fine, but I'd like to know that the broadcast
requirement is not going to mean that in practice all pushed
data ends as cleartext. Note: I am not asking if a secured
broadcast is needed here, I'm asking if the highly likely
desire for an insecure broadcast will result in insecure
everything.

[Ballot comment]
(For the IESG only: I still don't know if we have completely given up on 2418, section 2.2:

      The first
      paragraph must give a brief summary of the problem area, basis,
      goal(s) and approach(es) planned for the working group.

Can we perhaps ask the secretariat if it makes a difference to any formal thing?)

Seems fine. Strictly editorial/clarification stuff, and one question at the bottom.

Paragraph 3:

  This working group will develop a protocol...

Though the name of the WG should suffice, to save some heartache/heartburn, you probably want to say instead:

  This working group will develop an HTTP-based protocol…

or something like that.

  ...that applications can use to request
  the delivery of application data to a device using a consolidated push
  notification service.

I think you can strike the second "application". What other sort of data could there be?

  This protocol will include the ability to push the same
  message to multiple devices (broadcast).

Suggest:

s/message/notification
s/devices (broadcast)/subscribed applications

I know what you meant, but I think using the word "broadcast" could lead to silly discussions.

  The work may include an exemplar
  protocol for devices registering with push services.

I can't quite figure out what that sentence means. Help please?