Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1193C12D574 for ; Wed, 19 Apr 2017 13:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZyXbPbF2yOb for ; Wed, 19 Apr 2017 13:44:17 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9AD12E6A3 for ; Wed, 19 Apr 2017 13:44:16 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id t144so18787647lff.1 for ; Wed, 19 Apr 2017 13:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=B6MPBGMIg4di2su4/S0627DZUXdFQHCx392vrsznaeA=; b=Voeb5/G22iDgqNY/Zp2YXCmUqsTLR7EEDvRdSiDd78v2TRNU+k1MsJI8iEkqynTWGQ FuVNLF+25EvLYJITXh6o9Znby2LGC6KVcdpCkIqlMWO+/iInBBzhNR2ou4kgFU/BCFb+ 5t3AL1oYwh87FZ0zZ0giwNTL6jMurRI2E9q7w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=B6MPBGMIg4di2su4/S0627DZUXdFQHCx392vrsznaeA=; b=nX/WthgVnAxk1LZe5AxGeizZv/af9TpVvh9nPsuiTvGSGzrF1KLMC1GAWda+vEZd7r swxMuuzuFX/h6LNWySASDJ31/BKOxdVJzybFxC66RcXCBX0irvEEebyCDLSrIwfqDGRx 97O6s7RrAtDVxe6pPaG2tK0Eqgr9BwqF549/fxTUtsJJvt1u4Yq2p093H8ZecwWBckRE aAcOXxUcIuQs0iDyaN9SrLpSkyjpaEa1dZk36ElJ6qoCZ8kJLJPwF9RLcVaiOIpnoRq8 3lJjlCvFCjOW4u6I5NSr6ydXCwavdx21qhn8olrGKi9kFpWzQmD78K0OFNdfZs/0bTEb 9eeQ== X-Gm-Message-State: AN3rC/4BrHoOJDhf81J0a+pSwh8+wKXIRXVf6geoABZ9zrntcXZSTUuw FB8lpJvNuTkROexmCwjLJxEKvDVIaRjWJY0RNA== X-Received: by 10.46.0.70 with SMTP id 67mr1617053lja.113.1492634654244; Wed, 19 Apr 2017 13:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.84.79 with HTTP; Wed, 19 Apr 2017 13:44:13 -0700 (PDT) Reply-To: jrconlin@mozilla.com From: JR Conlin Date: Wed, 19 Apr 2017 13:44:13 -0700 Message-ID: To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a1142b53658a999054d8b165e Archived-At: Subject: [Webpush] User Agents should return a list of supported encryption content types X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:44:19 -0000 --001a1142b53658a999054d8b165e Content-Type: text/plain; charset=UTF-8 Recently, a bug filed against a webpush subscription library highlighted a shortcoming. https://github.com/web-push-libs/web-push-php/issues/48#issuecomment-295416292 Currently, there are two in production encryption content types, "aesgcm" and "aes128gcm". The "voice of authority" about what types of accepted content types is the UA. The sorts of allowed encryption is not communicated to the subscription update provider. I would like to propose that the returned PublishSubscription object < https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription> "options" object be modified to include a "contenttypes" list of allowed ECE content types. (e.g. ['aesgcm', 'aes128gcm']) This method would also allow future content types to be relayed. If no "contenttypes" field is present, then the provider must assume "aesgcm" encoding, to allow for older UAs. This field would also help indicate "updated" UAs which can take advantage of the newer draft specifications. My apologies if this is the wrong group. WebPush and ECE span several and this is a case where they overlap. I will happily repost to the appropriate group. --001a1142b53658a999054d8b165e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Recently, a bug filed against a webpush subscription library highlighted a= shortcoming.

https://github.com/web-push-libs/w= eb-push-php/issues/48#issuecomment-295416292

Currently, there are two in production encryption content types, "aesgcm" a= nd=20 "aes128gcm". The "voice of authority" about what types = of accepted=20 content types is the UA. The sorts of allowed encryption is not=20 communicated to the subscription update provider.

I would like to propose that the returned PublishSubscription object=20 <https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription> "options" object be modified to include a "contenttypes&quo= t; list of=20 allowed ECE content types. (e.g. ['aesgcm', 'aes128gcm']) T= his method=20 would also allow future content types to be relayed. If no=20 "contenttypes" field is present, then the provider must assume &q= uot;aesgcm"=20 encoding, to allow for older UAs.

This field would also h= elp indicate "updated" UAs which can take advantage of the newer = draft specifications.

My apologies if this is the wrong group. WebPush and ECE span seve= ral and this is a case where they overlap. I will happily repost to the app= ropriate group.
--001a1142b53658a999054d8b165e--