Webpush (IETF 91 - Honolulu, USA) -- Tuesday 11 November 2014 1520-1720

Action Items

• Someone:
   Write up a proposal for push ack?
• Martin:
  1. Add some example for data passed between the app and the app server (passing channel/subscription url)
  2. Eventually add some text / guidance on what subscription message will contain
  3. Subscription validity etc need to be clarified
• Ali:
  Keep on working on the draft.

Detail Minutes

• Status and Agenda Bashing -- 10 min (Chairs)

Chairs ask how many people understand what the WG does on a 0-10 level indicating using both hands. A few people indicated they fully understand showing 10 fingers. Chairs indicate a desire that everyone can be at 7-10 by end of meeting.

• Overview & History (Dan Druta) -- 15 min
Dan presents some background and use cases, along with some high level expectations and history.
call for questions
Shijun: Given that push services exist on existing devices, where do we need improvements from a carrier perspective?
Dan: Even consolidated push services may have issues that can be improved with resource usage. But goal of wg should be to standardize message type, security consideration
martin: Interest from operators who want to go beyond what is being defined here. For short term want to establish a baseline. Will talk about role of proprietary solutions in his talk.
Giri: Any thought on server sent events (SSE) compatibility?
Martin: rather not discuss whether this is a replacement for SSE. Doesn't want to unload on SSE (wouldn't be healthy)
Dan: Should allow developers to develop solutions that don't fork to proprietary protocols.
• Generic Event Delivery Using HTTP Push (Martin Thomson)
draft:http://tools.ietf.org/html/draft-thomson-webpush-http2-01
Shijun [comment about what makes up the server]
Martin: Wants to keep that abstract for now.
Joe (from floor): [on assertion that interface from app to app server does not need standardization] Agree, but might be worth talking about what sort of data gets sent.
Martin: Not considering ack of pushed message for now. App could send to app server over whatever the application channel is. Some push services use in band ack to save resources by using same connection, etc. Feedback is not many people use this feature.
Shijun: Windows uses this.
Martin: Looks forward to proposal.
Joe from floor: See how this works in http2, does anyone care about http1.x? Hope not due to complexity in spec or crickets
Issue: Is it okay to tie this to HTTP2?
Mark: can do this in websock, bare tcp, etc now, why tie to http2?
Martin: This works, had to come up with something.
Mark: Closest in http1 is to pull list of atoms, poll list, etc.
Richard (as AD) : Proceed with HTTP2 to get work done, see if http1.x requirement comes up.
Mark: Relying on a particular version is not cool. HTTP is hop by hop, version may change across hops.
Chair: Would you mind if we made progress down on this path, then look at things.
MN: Okay as long as we accept feedback down the road
Shijun: Same comment. Some devices may not be able to handle a restriction on http version.

Chair Guidance: Continue on current path, get more concrete, then have a foodfight.

subscription messages
Issue: any guidance on content, authn, etc?
Ted:So, at minimum you want de-register primitive along with a registration primitive.
Martin: Not now. Will probably have some later.
Push messages
Shijun: Is http2 required for the push from app server to push service?
Martin: Just a simple http PUT request. Not version specific.
Uwe?: Are we considering long polling for the push?
Martin: Yes. But this is better in HTTP2.
Uwe: any impact on keepalive timing? Need to control this for mobile.
Martin: Getting keepalive duration correct is challenging. Push services have solved this in various ways.
Dan: How do we deal with multiple UAs.
Martin: We hope we can use the platform's push service and avoid multiple UAs.
Dan: There are other ways that delivery can be done that might be more efficient. This is a good start, but may need to look at others.
Martin: Want to use optimizations when they apply, but may have narrow applicability. As proposed is for a general baseline.
Ted Hardy: Poker Star example. If each UA has a unique subscription, you may have to send a separate push for UA. Might not all be from same service. (e.g. over-21 apps might use a gambling service, rather than apple.)
Martin: Yes. Has submitted proposal to offload list of things, not talking about that today.
Chairs: Don't bog down for now, discuss it separately
Dan: How can you optimize delivery across independent subscriptions?
Martin: Maybe you can't. Need to keep privacy property.
Roger Marshall: Have we considered how to let the device learn and reveal if the subscription is still alive?
Martin: Further down the deck. Skullduggery involved. Open issue on how we allow service side deletion of subscriptions.
Securing web push through Skullduggery
Giri: [couldn't catch question due to cross talk] clarification questions on keypair
Martin: Key pair generated by service. App service never sees private key. Encrypt with public key. User agent manages storage of key. Public part available for export. Browser persists private key material.
Shijun: This assumes no trust between UA and push service
Martin: No reliance on trust
ekr: (pretending to be joe) Someone has to go to trouble to do e2e crypto. Push subscription lives in browswer. Generates keypair, stores private key and metadata. Hands public key to api, which hands it to the application server. App server encrypts. Push server not involved.
Giri: question about push authorization
Martin: push authorization carried in URL (pawn ticket)
The Bike Shed

W3C likely to delegate protection container to IETF.

Dan: Opportunity to separate envelope from content, get in business of doing encryption right. Avoid the push service visibility into content.
Martin: That is the intent, but not looking to create new security object model.
M&M: JOSE is almost finished. Understand there are size constraints. Can be small if careful. Alternative is [seeborg?] if we want to have a new serializer.
ekr: Nothing post JOSE is credible.
Joe from floor: Let UA say what it expects.
Authentication of app server
Richard: First two options look like pawn tickets
martin: each app may have it's own mechanism. Doesn't scale. recommendation to offer a baseline of capability URIs, but allow other methods of authentication/authorization
Dan: Not as easy. Legal considerations require contractual relationships. UA is an application in itself.
Martin: One way out would be to attribute all messages generated on the API to the user agent.
M&M: Capability URI is a good starting part. Will eventually need all sorts of protections.
Martin: Part of the purpose of a push service is to shield devices
Ted: May not be able to handwave the app to app server connection. For example, must pass some sort of time to live to app server. Need error message to say app server won't talk to that push server. May need to offer guidance on minimum set of things that must be passed to app server.
ekr: Why do we need to standardize how an app server tells the app it doesn't like a push service.
Ted: May just need to offer guidance, if not standardize. For example, might have multiple push services. [discussion on whether this is possible, may be possible in future]
Martin: Interesting discussion to have at W3C
Open Issues
Dan: As user, frustration at lack of message surpression, getting notices across multiple devices even after having read it on one.

Chairs: Who plans to implement:

*** Light smattering of hands.

Chair: Anyone willing to submit text

*** several hands.

Chair: Should not be Martin show next time.
• MPEG DASH Requirements for a webpush Protocol (Ali Begen)
draft:https://tools.ietf.org/html/draft-begen-webpush-dash-reqs-00
seeking guidance from working group.
martin: Push is really for these always available, but seldom connected devices. SAND seems to be about devices that are active participants. Other protocols may be more appropriate than webpush, unless there are devices in the highly available but not online state.
Mary: I agree with Martin's point about not using for media.
Giri: For FDH Would you take buffer states into account?
Ali: Push bases streaming would require some changes on the client.
Joe from floor (no hats): Suggest to follow the work as it becomes more concrete. If small, concrete additions come up that would help this use case and not damage core use cases, bring them up then.
??? : Has colleagues working on FDH experiment, might be useful to present experiments to HTTP wg.
• AoB and Open Discussion -- Any remaining time and energy

Chairs: If people have other use cases (even beyond core), please bring up on list.

Chair: Need to see more engagement on list about Martin's draft.

Michael Thornburg: Addressing use case for push of media itself. Should be optimized for low latency. Buffering shouldn't be a problem because media would be in real time.