W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

RE: Progress on Push API

From: <arnaud.braud@orange.com>
Date: Tue, 29 Apr 2014 12:03:46 +0000
To: EDUARDO FULLEA CARRERA <efc@tid.es>, public-webapps <public-webapps@w3.org>
Message-ID: <28549_1398773026_535F9522_28549_11181_1_0AE7120F487393448390B55BE14C3C2406FD4599@PEXCVZYM11.corporate.adroot.infra.ftgroup>
> -----Message d'origine-----
> De : EDUARDO FULLEA CARRERA [mailto:efc@tid.es]

> - App Server - Push Server protocol: Mozilla and Google to kick-off a
> new draft at the IETF to standardize it.

Great, do we know where they plan to do this work ? and when a first draft will be available ?

> - Change references to webapp => service worker where it might be
> unclear that only Service Workers should use interfaces & get events
> etc. other than register (because of the need for permissions UI), all
> interfaces and events to SW only
Doesn't this make push slightly harder to implement on "WebOS type" context ? It also mean we have a strong requirement on the service worker spec which is just starting.

>         - Promise register (optional Object registerOptions); =>
> Promise register ();  registerOptions parameter is dropped, as long as
> Service Workers require secure connection; to prevent MITM (e.g.
> snooping of registration info over non-secure connection from webapp to
> webapp server), Push Registrations should operate only over secure
> connections thus the webapp and Service Workers code should be served
> via HTTPS URI scheme; otherwise registration will be rejected - take
> the text lead from Service Workers spec

This is going to require a lot of clarification I feel, the reason the options were added in the first place was to deal with the non standard underlying push services, for example to provide app authentification details from the browser to the push server (I think this was a requirement on the GCM ? ). I don't see how this modification addresses the issue and I don't see why https is mandatory either. U

Could you provide an updated end to end workflow with who's credentials are used in the exchanges ? 



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
Received on Tuesday, 29 April 2014 12:04:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC