From nobody Mon Jun 1 12:40:23 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B691B3262 for ; Mon, 1 Jun 2015 12:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 xAkOGNLzjnqe for ; Mon, 1 Jun 2015 12:40:16 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 D9F4D1B3285 for ; Mon, 1 Jun 2015 12:39:51 -0700 (PDT) Received: by ykfl8 with SMTP id l8so46820675ykf.1 for ; Mon, 01 Jun 2015 12:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=WuXFS8EGrBTc6JydxffLWQQTx89XIWBN/DYvl2UzeFU=; b=X9p0rDXBiBTxkI0CMDwonx5Es1aFwrDYeBM2k8fEd4myW0RveehYbIkinnSWabY6TX YhPNsEt2Q6jqo8sQxmixAYJj9X5RECL98OFsOaD5Aq8ZJ09PdhTMGytUSf1km5B69iyw ur+BIeOhZo8ijtPHdnaS/ETmrp13uAI+NkC7Qfx/D44TxUu9vpkcs5D1eL5KyZdnsKlv fUds+v6a+x6ikmYhNJKesdF7SmEmCDIkZuNz2RQaqVII1pjUiqJ1h2uZSjj8uw2jkM+i 6u5HLrx7IcAfnq8iqfvphakl68wxhBPMoov7pe5uJrAXVknAOE2pHpVOuQjlZpDtuU6g nuBg== MIME-Version: 1.0 X-Received: by 10.170.139.132 with SMTP id g126mr19431787ykc.98.1433187591219; Mon, 01 Jun 2015 12:39:51 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 1 Jun 2015 12:39:51 -0700 (PDT) Date: Mon, 1 Jun 2015 12:39:51 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 01 Jun 2015 19:40:22 -0000 On 30 May 2015 at 14:48, Costin Manolache wrote: > Some metadata is needed for operating the service. > > Authenticating the sender doesn't need to expose more than absolutely > needed. Let's talk about what properties we are looking to provide here. Are we simply looking for a way for a server to track individual senders? Building up a reputation associated with a particular sender is important in detecting abnormal patterns of requests. An asymmetric key pair certainly accomplishes that goal. But so does a cookie, at a much lower cost. From nobody Mon Jun 1 18:09:17 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4641A87A0 for ; Mon, 1 Jun 2015 18:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 CbouCXB6Qv9x for ; Mon, 1 Jun 2015 18:09:14 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 B0BEC1A8797 for ; Mon, 1 Jun 2015 18:09:14 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so122051548ieb.0 for ; Mon, 01 Jun 2015 18:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ijqU5MwYorX9oxZc1H3CYUuTA89/+MvExxSaaxzd9g=; b=G0Vpq5iCgWYs4kJ4rJujXrfXIoz4kcxc5NfA5+m/uMAt1AVBIO+CqMz6ncSJEsLGBE ITbvqtHkm68VoMy3usBrQWML0+Z7Qput+TdfvRHS6MTfcaGAEWVS83hbafgfn5SFavvz ybr/u2Y0CxapoBbE9TG238gtKaGERT+uYfT2h1fcWvTCOK8DWy6HsA1iB7XLLbYIcGvQ +1SAhlqNmwBqVk83tK9fMZVk38hDjSIOE4WYQgbm4P5zbhU86KGt/bKdmbA9/8bBZUZh 6FRPC4wwJ26KsSufFVOMQI71263JtgkG/tl7Iw7cIeVmKvoRflvxihkRRBsM2jfoed2h Xb9w== MIME-Version: 1.0 X-Received: by 10.50.47.50 with SMTP id a18mr9920139ign.46.1433207354116; Mon, 01 Jun 2015 18:09:14 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Mon, 1 Jun 2015 18:09:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jun 2015 18:09:14 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=089e013cbc263b533705177e9758 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 02 Jun 2015 01:09:16 -0000 --089e013cbc263b533705177e9758 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 1, 2015 at 12:39 PM, Martin Thomson wrote: > On 30 May 2015 at 14:48, Costin Manolache wrote: > > Some metadata is needed for operating the service. > > > > Authenticating the sender doesn't need to expose more than absolutely > > needed. > > Let's talk about what properties we are looking to provide here. > - a stable identity for each sender - a secure way to authenticate the sender ( otherwise anyone can impersonate a sender ). - some way to contact the sender - it can be the domain name/origin ( and use Whois info to contact ), or an email. If it is valid - the sender may be contacted in case of problems that can be fixed, it happens quite often we detect some bugs and usually they get fixed in hours/days when we contact the sender. If it is not valid or missing - the only recourse is to block the sender, and we may allow only low QPS. Nice to have: - a way to associate or register the same identity with multiple push providers > > Are we simply looking for a way for a server to track individual > senders? Building up a reputation associated with a particular sender > is important in detecting abnormal patterns of requests. > > An asymmetric key pair certainly accomplishes that goal. But so does > a cookie, at a much lower cost. > As long as the push service gets an "Authorization:" header that it can use to verify the sender - it doesn't matter if you call it a 'cookie' or token. What matters is how does the sender gets this cookie, and how does the push service uses the cookie. The reason I'm proposing a key pair is simple: we already define this for app. In order to send a message, you need a 'subscription URL' and the public key generated by the UA. So each 'receiving' side has a key pair. I don't see generating another key pair for the sending side as a major problem. Servers need to generate one for https and than go trough a much harder process to get a cert for https, which is required by webpush. Having a single key pair - and registering it with different push providers - seems cleaner than getting a different Oauth (or cookie) from each server. I'm ok with a token/cookie too - but the process to register with the push provider needs to be specified. Costin --089e013cbc263b533705177e9758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 1, 2015 at 12:39 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 30 Ma= y 2015 at 14:48, Costin Manolache <c= ostin@gmail.com> wrote:
> Some metadata is needed for operating the service.
>
> Authenticating the sender doesn't need to expose more than absolut= ely
> needed.

Let's talk about what properties we are looking to provide here.


- a stable identity for each s= ender=C2=A0
- a secure way to authenticate the sender ( otherwise= anyone can impersonate a sender ).=C2=A0
- some way to contact t= he sender - it can be the domain name/origin ( and use Whois info to contac= t ), or
an email. If it is valid - the sender may be contacted in= case of problems that can be fixed, it happens
quite often we de= tect some bugs and usually they get fixed in hours/days when we contact the= sender.
If it is not valid =C2=A0or missing - the only recourse = is to block the sender, and we may allow only low QPS.

=
Nice to have:
- a way to associate or register the same iden= tity with multiple push providers

=C2=A0

Are we simply looking for a way for a server to track individual
senders?=C2=A0 Building up a reputation associated with a particular sender=
is important in detecting abnormal patterns of requests.

An asymmetric key pair certainly accomplishes that goal.=C2=A0 But so does<= br> a cookie, at a much lower cost.

As long as the push service gets an "Authorization:"= ; header that it can use to=C2=A0
verify th= e sender - it doesn't matter if you call it a 'cookie' or token= .=C2=A0
What matters is how does the sender= gets this cookie, and how does the push
se= rvice uses the cookie.=C2=A0

The reason I'm proposing a key pair is simple: w= e already define this for app.
In order to = send a message, you need a 'subscription URL' and the public key ge= nerated by the UA.
So each 'receiving&#= 39; side has a key pair.=C2=A0

I don't see generating another key pair for th= e sending side as a major problem. Servers need to generate one for https
and than go trough a much harder process to = get a cert for https, which is required by webpush.

Having a single key pair - an= d registering it with different push providers - seems cleaner than getting= =C2=A0
a different Oauth (or cookie) from e= ach server.=C2=A0

I'm ok with a token/cookie too - but the process to registe= r with the push provider needs to be specified.

Costin






--089e013cbc263b533705177e9758-- From nobody Mon Jun 1 18:45:16 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802511A8829 for ; Mon, 1 Jun 2015 18:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 l2CTa2bOGahb for ; Mon, 1 Jun 2015 18:45:11 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 DD1991A8827 for ; Mon, 1 Jun 2015 18:45:10 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so75530991igb.0 for ; Mon, 01 Jun 2015 18:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n//3QsMvtMOH0q21j1d8OkuvRpeMuXsyrA5K9aun4dA=; b=mYpnTw90vczOo6YCBgbwVhWb7U/W5MK7zdAQF0wwLIjpRyxolTPyxd0NpUTDreBTC9 U5LjqvBrf/jo8E3y2dTWEJQlEcunZNQ0yU9F2xPiPyPblj23zdlwQmR9OUkyAhmdOs20 oGdGDGEfhhSg899Gm0ImEJSUbbPC//sfjB2VzOzpoieLwIrHRNcKcmXZJKh7MHt3LdvT UVPy1AP6MQMa/84f6mAZnChKIy9B/q3KjvAN51GKwxWYDYr6H5n/5qsDpmMy97qMmOqN 4xh7dNTZyIi/KDjAymibZJplTANDjGfHIYyku2edVwswJT/veeEhQyaaJv38IN/8s6bK iP4g== MIME-Version: 1.0 X-Received: by 10.42.93.17 with SMTP id v17mr8617057icm.42.1433209510337; Mon, 01 Jun 2015 18:45:10 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Mon, 1 Jun 2015 18:45:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jun 2015 18:45:10 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=90e6ba614ce6c0a9e905177f17a0 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 02 Jun 2015 01:45:14 -0000 --90e6ba614ce6c0a9e905177f17a0 Content-Type: text/plain; charset=UTF-8 I should also mention that GCM (and other providers) may provide additional features - for example 'upstream' or 'device to device' - when the app running in the UA may send a message to its server using the existing webpush TCP connection. The benefit is lower latency - the app can obviously contact the server by making a http connection, but that involves TCP and TLS roundtrips. The case of device to device is even more interesting. Assuming other providers may have those features, and there is a chance future versions of webpush will add some of them - it would be good if both sides are symmetrical - in particular for end-to-end encryption purpose, which is the trickiest part of webpush. In this model either end has a key pair, and uses the same process to register with the push provider, and can use the public key as an identifier across multiple push services. For example, server S talking to to it's app. It is possible that instances of app will run on different devices and UA, using different services - for example app A1 using UA1 and WP1, and A2 using UA2 and WP2. It is also possible that same UA may use different webpush providers. S will generate a key pair, and use it to 'subscribe' to WP1 and WP2, including some contact info - like the domain name or email. UA1 and UA2 will generate key pairs for A1 and A2, and 'subscribe' to WP1 and WP2. This can be optional - if a webpush providers doen't need to worry about misbehaving apps it can just not include the public key and information about the apps. In case of GCM, a UA running on android will need to provide some way to identify the app (like origin)- or use the UA's own package name, but in the second case any misbehaving app may result in blocking the entire UA. If there is a problem ( bug ) - the webpush provider can use the domain to locate some contact the app developer. In case of abuse - it may completely block that particular app. >From app developer perspective - everything has a key pair, and they may use same libraries to end-to-end encrypt messages between any endpoints ( S to A1, A1 to S or A1 to A2 ). It may even be possible for A1 to change push providers - getting a different subscription, but using same key pair. Costin On Mon, Jun 1, 2015 at 6:09 PM, Costin Manolache wrote: > > > On Mon, Jun 1, 2015 at 12:39 PM, Martin Thomson > wrote: > >> On 30 May 2015 at 14:48, Costin Manolache wrote: >> > Some metadata is needed for operating the service. >> > >> > Authenticating the sender doesn't need to expose more than absolutely >> > needed. >> >> Let's talk about what properties we are looking to provide here. >> > > > - a stable identity for each sender > - a secure way to authenticate the sender ( otherwise anyone can > impersonate a sender ). > - some way to contact the sender - it can be the domain name/origin ( and > use Whois info to contact ), or > an email. If it is valid - the sender may be contacted in case of problems > that can be fixed, it happens > quite often we detect some bugs and usually they get fixed in hours/days > when we contact the sender. > If it is not valid or missing - the only recourse is to block the sender, > and we may allow only low QPS. > > Nice to have: > - a way to associate or register the same identity with multiple push > providers > > > >> >> Are we simply looking for a way for a server to track individual >> senders? Building up a reputation associated with a particular sender >> is important in detecting abnormal patterns of requests. >> >> An asymmetric key pair certainly accomplishes that goal. But so does >> a cookie, at a much lower cost. >> > > As long as the push service gets an "Authorization:" header that it can > use to > verify the sender - it doesn't matter if you call it a 'cookie' or token. > What matters is how does the sender gets this cookie, and how does the push > service uses the cookie. > > The reason I'm proposing a key pair is simple: we already define this for > app. > In order to send a message, you need a 'subscription URL' and the public > key generated by the UA. > So each 'receiving' side has a key pair. > > I don't see generating another key pair for the sending side as a major > problem. Servers need to generate one for https > and than go trough a much harder process to get a cert for https, which is > required by webpush. > > Having a single key pair - and registering it with different push > providers - seems cleaner than getting > a different Oauth (or cookie) from each server. > > I'm ok with a token/cookie too - but the process to register with the push > provider needs to be specified. > > Costin > > > > > > > --90e6ba614ce6c0a9e905177f17a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I should also mention that GCM (and other providers) may p= rovide additional features -=C2=A0
for example 'upstream' or &#= 39;device to device' - when the app running in the UA may send a messag= e
to its server using the existing webpush TCP connection. Th= e benefit is lower latency - the app
can obviously contact the se= rver by making a http connection, but that involves TCP and TLS roundtrips.= =C2=A0
The case of device to device is even more interesting.=C2= =A0

Assuming other providers may have those featur= es, and there is a chance future versions of webpush will
add som= e of them - it would be good if both sides are symmetrical - in particular = for end-to-end
encryption purpose, which is the trickiest part of= webpush.=C2=A0

In this model either end has a key= pair, and uses the same process to register with the push provider,
<= div>and can use the public key as an identifier across multiple push servic= es.

For example, server S talking to to it's a= pp. It is possible that instances of=C2=A0
app will run on differ= ent devices and UA, using different services - for example app A1
using UA1 and WP1, and A2 using UA2 and WP2. It is also possible that
same UA may use different webpush providers.=C2=A0

S will generate a key pair, and use it to 'subscribe' to WP1= and WP2, including some contact info -=C2=A0
like the domain nam= e or email.

UA1 and UA2 will generate key pairs fo= r A1 and A2, and 'subscribe' to WP1 and WP2.=C2=A0

This can be optional - if a webpush providers doen't need to w= orry about misbehaving apps it
can just not include the public ke= y and information about the apps. In case of GCM, a UA
running on= android will need to provide some way to identify the app (like origin)- o= r use the UA's own
package name, but in the second case any m= isbehaving app may result in blocking the entire
UA.=C2=A0
<= div>
If there is a problem ( bug ) - the webpush provider can= use the domain to locate some contact=C2=A0
the app developer. I= n case of abuse - it may completely block that particular app.=C2=A0
<= div>
From app developer perspective - everything has a key pa= ir, and they may use same libraries
to end-to-end encrypt message= s between any endpoints ( S to A1, A1 to S or A1 to A2 ). It may
= even be possible for A1 to change push providers - getting a different subs= cription, but using same
key pair.=C2=A0

Costin

On Mon, Jun 1, 2015 at 6:09 PM, Costin Manolache <costin@gmail.com>= ; wrote:


On M= on, Jun 1, 2015 at 12:39 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 30 May 2015= at 14:48, Costin Manolache <costin@gmail.com> wrote:
> Some metadata is needed for operating the service.
>
> Authenticating the sender doesn't need to expose more than absolut= ely
> needed.

Let's talk about what properties we are looking to provide here.


- a stable identity for= each sender=C2=A0
- a secure way to authenticate the sender ( ot= herwise anyone can impersonate a sender ).=C2=A0
- some way to co= ntact the sender - it can be the domain name/origin ( and use Whois info to= contact ), or
an email. If it is valid - the sender may be conta= cted in case of problems that can be fixed, it happens
quite ofte= n we detect some bugs and usually they get fixed in hours/days when we cont= act the sender.
If it is not valid =C2=A0or missing - the only re= course is to block the sender, and we may allow only low QPS.
Nice to have:
- a way to associate or register the sa= me identity with multiple push providers

=C2=A0

Are we simply looking for a way for a server to track individual
senders?=C2=A0 Building up a reputation associated with a particular sender=
is important in detecting abnormal patterns of requests.

An asymmetric key pair certainly accomplishes that goal.=C2=A0 But so does<= br> a cookie, at a much lower cost.

As long as the push service gets an "Authorizatio= n:" header that it can use to=C2=A0
ve= rify the sender - it doesn't matter if you call it a 'cookie' o= r token.=C2=A0
What matters is how does the= sender gets this cookie, and how does the push
service uses the cookie.=C2=A0

The reason I'm proposing a key pair is si= mple: we already define this for app.
In or= der to send a message, you need a 'subscription URL' and the public= key generated by the UA.
So each 'rece= iving' side has a key pair.=C2=A0

<= /div>
I don't see generating another key pair= for the sending side as a major problem. Servers need to generate one for = https
and than go trough a much harder proc= ess to get a cert for https, which is required by webpush.

Having a single key p= air - and registering it with different push providers - seems cleaner than= getting=C2=A0
a different Oauth (or cookie= ) from each server.=C2=A0

I'm ok with a token/cookie too - but the process to= register with the push provider needs to be specified.

Costin







--90e6ba614ce6c0a9e905177f17a0-- From nobody Wed Jun 3 10:34:15 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D621ACDC9 for ; Wed, 3 Jun 2015 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 mRKzwM28mCZE for ; Wed, 3 Jun 2015 10:34:10 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (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 7874D1A8A55 for ; Wed, 3 Jun 2015 10:34:07 -0700 (PDT) Received: by qcej9 with SMTP id j9so7206524qce.1 for ; Wed, 03 Jun 2015 10:34:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type; bh=qjgRtOAz6EIzoAJAHJs2s86jkjKqk9/LJWjL/kwOOio=; b=beBqvW4krm/2D4etE35/GXY+Fonerf7INAIlfySrfuNC2F6d2I7E0zIxDxRJDa7OK4 7+sNQ3Btd4+rFGkA1cl46b3CYuaN4QvcebS4yATpEXnGbEoEyfwDoUuX1Tdiq2kFBQ4W DEzwZVOyCTgJ/3nZqjm8VYolrsc84lvhhQKg5yYw7SH1Sh0NIFGVXH3N6AFnU1M9J3OK v0/pHtc06eiK6sdKCdY93sbgHIqid2Gbi0x0bgrrTRNwBgMB6aDjjUsAFHA6oVNFAnPb Sn+HnwALZ7R4bRHD84Xu45wvnUWwKq2Q/9eM/a3wWdzigdjj8rIEB3KOjqRZfwTXP4uF rm8A== X-Gm-Message-State: ALoCoQls7BqMr9BDGxb/rtgKVeVfaUrkxxiVZF+eH3bR4DRmFgNo4WAjleECXUloOOEMpxZq5T0C X-Received: by 10.55.17.21 with SMTP id b21mr60803571qkh.27.1433352846427; Wed, 03 Jun 2015 10:34:06 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:20d9:102c:5541:9278? ([2620:101:80fc:224:20d9:102c:5541:9278]) by mx.google.com with ESMTPSA id 102sm743473qgn.37.2015.06.03.10.34.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2015 10:34:05 -0700 (PDT) From: JR Conlin X-Google-Original-From: JR Conlin To: webpush@ietf.org References: X-Enigmail-Draft-Status: N1110 Organization: mozilla Message-ID: <556F3A8F.5090009@mozilla.com> Date: Wed, 3 Jun 2015 10:34:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Thunderbird/40.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020406080609070104060806" Archived-At: Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2015 17:34:14 -0000 This is a multi-part message in MIME format. --------------020406080609070104060806 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 6/1/2015 6:09 PM, Costin Manolache wrote: > > > On Mon, Jun 1, 2015 at 12:39 PM, Martin Thomson > > wrote: > > On 30 May 2015 at 14:48, Costin Manolache > wrote: > > Some metadata is needed for operating the service. > > > > Authenticating the sender doesn't need to expose more than > absolutely > > needed. > > Let's talk about what properties we are looking to provide here. > > > > - a stable identity for each sender > - a secure way to authenticate the sender ( otherwise anyone can > impersonate a sender ). I'll note that this may be a bit difficult. As the current SourceForge ruckus is showing, trusted parties may not always remain trusted. It would be very nice to ensure that messages delivered to a user from an app server, and not from whatever system may be holding the credentials of the app server when talking to a bridge. For instance, If Costin wants to send a message to Martin via my service, that I cannot use Costin's credentials to try and send Martin ads for my new fish based cologne service. (Feel free to add as many other possible fishy scented parties as you like between Costin and Martin when it comes to bridges, because they absolutely complicate things.) > - some way to contact the sender - it can be the domain name/origin ( > and use Whois info to contact ), or > an email. If it is valid - the sender may be contacted in case of > problems that can be fixed, it happens > quite often we detect some bugs and usually they get fixed in > hours/days when we contact the sender. > If it is not valid or missing - the only recourse is to block the > sender, and we may allow only low QPS. > > Nice to have: > - a way to associate or register the same identity with multiple push > providers > > > > > Are we simply looking for a way for a server to track individual > senders? Building up a reputation associated with a particular sender > is important in detecting abnormal patterns of requests. > > An asymmetric key pair certainly accomplishes that goal. But so does > a cookie, at a much lower cost. > > > As long as the push service gets an "Authorization:" header that it > can use to > verify the sender - it doesn't matter if you call it a 'cookie' or token. > What matters is how does the sender gets this cookie, and how does the > push > service uses the cookie. > > The reason I'm proposing a key pair is simple: we already define this > for app. > In order to send a message, you need a 'subscription URL' and the > public key generated by the UA. > So each 'receiving' side has a key pair. > > I don't see generating another key pair for the sending side as a > major problem. Servers need to generate one for https > and than go trough a much harder process to get a cert for https, > which is required by webpush. > > Having a single key pair - and registering it with different push > providers - seems cleaner than getting > a different Oauth (or cookie) from each server. > > I'm ok with a token/cookie too - but the process to register with the > push provider needs to be specified. > > Costin > > > > > > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush --------------020406080609070104060806 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 6/1/2015 6:09 PM, Costin Manolache wrote:


On Mon, Jun 1, 2015 at 12:39 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 30 May 2015 at 14:48, Costin Manolache <costin@gmail.com> wrote:
> Some metadata is needed for operating the service.
>
> Authenticating the sender doesn't need to expose more than absolutely
> needed.

Let's talk about what properties we are looking to provide here.


- a stable identity for each sender 
- a secure way to authenticate the sender ( otherwise anyone can impersonate a sender ).
I'll note that this may be a bit difficult. As the current SourceForge ruckus is showing, trusted parties may not always remain trusted. It would be very nice to ensure that messages delivered to a user from an app server, and not from whatever system may be holding the credentials of the app server when talking to a bridge.

For instance, If Costin wants to send a message to Martin via my service, that I cannot use Costin's credentials to try and send Martin ads for my new fish based cologne service. (Feel free to add as many other possible fishy scented parties as you like between Costin and Martin when it comes to bridges, because they absolutely complicate things.)

- some way to contact the sender - it can be the domain name/origin ( and use Whois info to contact ), or
an email. If it is valid - the sender may be contacted in case of problems that can be fixed, it happens
quite often we detect some bugs and usually they get fixed in hours/days when we contact the sender.
If it is not valid  or missing - the only recourse is to block the sender, and we may allow only low QPS.

Nice to have:
- a way to associate or register the same identity with multiple push providers

 

Are we simply looking for a way for a server to track individual
senders?  Building up a reputation associated with a particular sender
is important in detecting abnormal patterns of requests.

An asymmetric key pair certainly accomplishes that goal.  But so does
a cookie, at a much lower cost.

As long as the push service gets an "Authorization:" header that it can use to 
verify the sender - it doesn't matter if you call it a 'cookie' or token. 
What matters is how does the sender gets this cookie, and how does the push
service uses the cookie. 

The reason I'm proposing a key pair is simple: we already define this for app.
In order to send a message, you need a 'subscription URL' and the public key generated by the UA.
So each 'receiving' side has a key pair. 

I don't see generating another key pair for the sending side as a major problem. Servers need to generate one for https
and than go trough a much harder process to get a cert for https, which is required by webpush.

Having a single key pair - and registering it with different push providers - seems cleaner than getting 
a different Oauth (or cookie) from each server. 

I'm ok with a token/cookie too - but the process to register with the push provider needs to be specified.

Costin








_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush

--------------020406080609070104060806-- From nobody Wed Jun 3 19:37:51 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7CA1B2AE3 for ; Wed, 3 Jun 2015 19:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 GhNrtU5Ptl3w for ; Wed, 3 Jun 2015 19:37:46 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 541651A896E for ; Wed, 3 Jun 2015 19:37:46 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so5696362igb.0 for ; Wed, 03 Jun 2015 19:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dCoDeJ8SKsUsMP5ngBLu6Kby1MpZ84B2PjrOcUHwdk=; b=Lsvpp7IszsI4715FD6WKOtcjs7Rm3oZ3HCodfkgfA2Tq5p1iuFkk73u0pFgNjiX3N/ Jz/Qhie7/kAygNxE9Rbs160I/QOZaXVJp142uIPzX+szqoi2nWmtdM9dpJh1nc4xi3iC loeLirM56/YcPkx01lz41XCrE0uIpKZLJ7jDcjJ96GEE6Lb+zY6iPd78ttq2JRH0R8aC IRI9FUWTJKuKc/uJxE3LhdLDoT2i7DVDE6ACCFi89CwCKq/gEHpXVwL3sxELD17BxEZI KMBILo40d2PrfVSv+gfL84eVhN8jod2b1MOTHsd6X6VYBsFasP937sKKz0bIRL7576VH gnPg== MIME-Version: 1.0 X-Received: by 10.50.118.42 with SMTP id kj10mr6507616igb.1.1433385465675; Wed, 03 Jun 2015 19:37:45 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Wed, 3 Jun 2015 19:37:45 -0700 (PDT) In-Reply-To: <556F3A8F.5090009@mozilla.com> References: <556F3A8F.5090009@mozilla.com> Date: Wed, 3 Jun 2015 19:37:45 -0700 Message-ID: From: Costin Manolache To: JR Conlin Content-Type: multipart/alternative; boundary=089e013d0d468233e80517a80f92 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Jun 2015 02:37:49 -0000 --089e013d0d468233e80517a80f92 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 10:34 AM, JR Conlin wrote: > On 6/1/2015 6:09 PM, Costin Manolache wrote: > > > > On Mon, Jun 1, 2015 at 12:39 PM, Martin Thomson < > martin.thomson@gmail.com> wrote: > >> On 30 May 2015 at 14:48, Costin Manolache < >> costin@gmail.com> wrote: >> > Some metadata is needed for operating the service. >> > >> > Authenticating the sender doesn't need to expose more than absolutely >> > needed. >> >> Let's talk about what properties we are looking to provide here. >> > > > - a stable identity for each sender > - a secure way to authenticate the sender ( otherwise anyone can > impersonate a sender ). > > I'll note that this may be a bit difficult. As the current SourceForge > ruckus is showing, trusted parties may not always remain trusted. It would > be very nice to ensure that messages delivered to a user from an app > server, and not from whatever system may be holding the credentials of the > app server when talking to a bridge. > > > For instance, If Costin wants to send a message to Martin via my service, > that I cannot use Costin's credentials to try and send Martin ads for my > new fish based cologne service. (Feel free to add as many other possible > fishy scented parties as you like between Costin and Martin when it comes > to bridges, because they absolutely complicate things.) > Intermediaries do complicate things - and obviously it is best if the sender of a message is using directly the webpush service. We're not trying to solve multi-party authentication - all we need is to know that the message originated from a specific sender. In email this is done by sender adding a signature header to the message, and receiver checking it with the public key from DNS ( or something similar, I haven't looked at recent changes ). XMPP has a different scheme, but also insures that when the final user receives the message, the 'from' can be trusted. I am ok with using an auth scheme where the payload is signed by the sender key ( it already has to be encrypted using the public key of the receiver - adding signing is not too much extra burden ). But the end goal is for both final webpush service and for the recipient to know for sure who originated the message. If your webpush subscription is leaked and gets in the hand of a spammer - it should be possible to block it. Same if the service gets compromised. I personally thing that a simpler scheme, using just regular JWT tokens ( with few hours expiry ) would be enough and we don't need to sign the payload. GCM uses apikeys - similar with a cookie, but can be changed/rotated by sender when they need to, and seems to work well enough. The problem is that it requires the sender to get keys(cookies) from each webpush service they may use. What I'm proposing instead is to rely on a single key pair for sender, and than just generate tokens and register the public key with any webpush server that may be used. This avoids the custom sign-up to each webpush service. Costin > > - some way to contact the sender - it can be the domain name/origin ( > and use Whois info to contact ), or > an email. If it is valid - the sender may be contacted in case of problems > that can be fixed, it happens > quite often we detect some bugs and usually they get fixed in hours/days > when we contact the sender. > If it is not valid or missing - the only recourse is to block the sender, > and we may allow only low QPS. > > Nice to have: > - a way to associate or register the same identity with multiple push > providers > > > >> >> Are we simply looking for a way for a server to track individual >> senders? Building up a reputation associated with a particular sender >> is important in detecting abnormal patterns of requests. >> >> An asymmetric key pair certainly accomplishes that goal. But so does >> a cookie, at a much lower cost. >> > > As long as the push service gets an "Authorization:" header that it can > use to > verify the sender - it doesn't matter if you call it a 'cookie' or token. > What matters is how does the sender gets this cookie, and how does the push > service uses the cookie. > > The reason I'm proposing a key pair is simple: we already define this > for app. > In order to send a message, you need a 'subscription URL' and the public > key generated by the UA. > So each 'receiving' side has a key pair. > > I don't see generating another key pair for the sending side as a major > problem. Servers need to generate one for https > and than go trough a much harder process to get a cert for https, which is > required by webpush. > > Having a single key pair - and registering it with different push > providers - seems cleaner than getting > a different Oauth (or cookie) from each server. > > I'm ok with a token/cookie too - but the process to register with the > push provider needs to be specified. > > Costin > > > > > > > > > _______________________________________________ > Webpush mailing listWebpush@ietf.orghttps://www.ietf.org/mailman/listinfo/webpush > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --089e013d0d468233e80517a80f92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 3, 2015 at 10:34 AM, JR Conlin <jconlin@mozilla.com&= gt; wrote:
=20 =20 =20
On 6/1/2015 6:09 PM, Costin Manolache wrote:


On Mon, Jun 1, 2015 at 12:39 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 30 May 2015 at 14:48, Costin Manolache <costin@gmail.com> wrote:
> Some metadata is needed for operating the service.
>
> Authenticating the sender doesn't need to expose mor= e than absolutely
> needed.

Let's talk about what properties we are looking to provid= e here.


- a stable identity for each sender=C2=A0
- a secure way to authenticate the sender ( otherwise anyone can impersonate a sender ).
I'll note that this may be a bit difficult. As the current SourceForge ruckus is showing, trusted parties may not always remain trusted. It would be very nice to ensure that messages delivered to a user from an app server, and not from whatever system may be holding the credentials of the app server when talking to a bridge.=C2= =A0


For instance, If Costin wants to send a message to Martin via my service, that I cannot use Costin's credentials to try and send Martin ads for my new fish based cologne service. (Feel free to add as many other possible fishy scented parties as you like between Costin and Martin when it comes to bridges, because they absolutely complicate things.)

Intermedi= aries do complicate things - and obviously it is best if the sender of a me= ssage is using directly the webpush service.=C2=A0

We're not trying to solve multi-party authentication - all we need is = to know that the message originated from a specific sender.
In em= ail this is done by sender adding a signature header to the message, and re= ceiver checking it with the public key from DNS (=C2=A0
or someth= ing similar, I haven't looked at recent changes ). XMPP has a different= scheme, but also insures that when the final
user receives the m= essage, the 'from' can be trusted.

I am ok= with using an auth scheme where the payload is signed by the sender key ( = it already has to be encrypted using the=C2=A0
public key of the = receiver - adding signing is not too much extra burden ).

But the end goal is for both final webpush service and for the reci= pient to know for sure who originated the message.=C2=A0
If your = webpush subscription is leaked and gets in the hand of a spammer - it shoul= d be possible to block it.=C2=A0
Same if the service gets comprom= ised.

I personally thing that a simpler scheme, us= ing just regular JWT tokens ( with few hours expiry ) would be enough and w= e don't need=C2=A0
to sign the payload. GCM uses apikeys - si= milar with a cookie, but can be changed/rotated by sender when they need to= , and=C2=A0
seems to work well enough. The problem is that it req= uires the sender to get keys(cookies) from each webpush service they may=C2= =A0
use. What I'm proposing instead is to rely on a single ke= y pair for sender, and than just generate tokens and register the public ke= y
with any webpush server that may be used. This avoids the custo= m sign-up to each webpush service.=C2=A0



Costin
=C2=A0

- some way to contact the sender - it can be the domain name/origin ( and use Whois info to contact ), or
an email. If it is valid - the sender may be contacted in case of problems that can be fixed, it happens
quite often we detect some bugs and usually they get fixed in hours/days when we contact the sender.
If it is not valid =C2=A0or missing - the only recourse is to block the sender, and we may allow only low QPS.

Nice to have:
- a way to associate or register the same identity with multiple push providers

=C2=A0

Are we simply looking for a way for a server to track individual
senders?=C2=A0 Building up a reputation associated with a particular sender
is important in detecting abnormal patterns of requests.

An asymmetric key pair certainly accomplishes that goal.=C2= =A0 But so does
a cookie, at a much lower cost.

As long as the push service gets an "Authorization:" header that it can use to=C2=A0
verify the sender - it doesn't matte= r if you call it a 'cookie' or token.=C2=A0
What matters is how does the sender gets this cookie, and how does the push
service uses the cookie.=C2=A0

The reason I'm proposing a key pair = is simple: we already define this for app.
In order to send a message, you need a 'subscription URL' and the public key generated by the UA= .
So each 'receiving' side has a k= ey pair.=C2=A0

I don't see generating another key p= air for the sending side as a major problem. Servers need to generate one for https
and than go trough a much harder process to get a cert for https, which is required by webpush.

Having a single key pair - and registering it with different push providers - seems cleaner than getting=C2=A0
a different Oauth (or cookie) from each server.=C2=A0

I'm ok with a token/cookie too - but the process to register with the push provider needs to be specified.

Costin








_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--089e013d0d468233e80517a80f92-- From nobody Wed Jun 3 22:07:05 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8785F1B344E for ; Wed, 3 Jun 2015 22:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 UvfhBQPpWFPX for ; Wed, 3 Jun 2015 22:07:02 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 136801B30E9 for ; Wed, 3 Jun 2015 22:07:02 -0700 (PDT) Received: by ykfl8 with SMTP id l8so10647858ykf.1 for ; Wed, 03 Jun 2015 22:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UUIaFkn9yb1ShZJB+KGTjFmvXYAJWPdv1CHFly90fxc=; b=vF/kPqg5Ssg6aI9wNn5eJkEPi9Oe6z+KW/lqwT8L35JOieliHWIBmiat1QN0F1QQRO K3+KiQQFUF45x8xOMxcKZGT+3LGrXjVgbNA8sWsm9a3Se4PMD5gyUGqBpxCB4rB9PT2y SG8qhv/25IECGECg7hiOp2hHN+K2tUlyNBduc97vHhviPIdCDLwL0a8br5KqrZ8js3Vb q6DCVy7Vq9yt2wkKOHWfXV+TpIv1o7WFQ9T5mQO81BPiI0m57PFc6HimbvdN/jR+8gWI sI9c/1DI0y5q20FYBuYejo/CfG7cDwXkm59JQFwKKKrt4xBXnmubtdJoii7wAQeVwy1j yG5Q== MIME-Version: 1.0 X-Received: by 10.236.20.230 with SMTP id p66mr38754554yhp.181.1433394421403; Wed, 03 Jun 2015 22:07:01 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 3 Jun 2015 22:07:01 -0700 (PDT) In-Reply-To: References: <556F3A8F.5090009@mozilla.com> Date: Wed, 3 Jun 2015 22:07:01 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Jun 2015 05:07:03 -0000 On 3 June 2015 at 19:37, Costin Manolache wrote: > We're not trying to solve multi-party authentication - all we need is to > know that the message originated from a specific sender. I'm fairly sure that you don't want this, but I'd like to restate that I'm not looking to invent a global authentication system. > But the end goal is for both final webpush service and for the recipient to > know for sure who originated the message. I don't think that "for sure" is necessary here. And I think that we have to balance the confidentiality needs of the sender as well. What you are proposing doesn't do that, which is good. > I personally thing that a simpler scheme, using just regular JWT tokens ( > with few hours expiry ) would be enough and we don't need > to sign the payload. GCM uses apikeys - similar with a cookie, but can be > changed/rotated by sender when they need to, and > seems to work well enough. The problem is that it requires the sender to get > keys(cookies) from each webpush service they may > use. I think that different details per origin is a positive property. What you are describing, if it were a browser that was doing the sending, would be called a supercookie. That allows correlation of sender behaviour across different origins. Sure, this would all be under the control of a sender, and you might argue that senders have a lesser need for this sort of privacy and you might even be right. But lesser isn't the same as none and I'd like to avoid situations where we specify encouragement to do things that potentially undermine privacy in this fashion. I'd like to hold this design to the same sorts of standards we hold the rest of the web to. Or better yet, our aspirational goals for the web. Particularly when it comes to privacy. I have no fundamental objection to having a sender volunteer extra information, like a support email address, but that needs to be at their discretion. I keep coming back to a simple cookie. I'd also be OK with the push service sending back a full-blown web page with a registration form to newcomers where additional information might be volunteered. Though maybe that should be limited to those senders that include HTML in their Accept header fields. > What I'm proposing instead is to rely on a single key pair for sender, > and than just generate tokens and register the public key > with any webpush server that may be used. This avoids the custom sign-up to > each webpush service. I certainly agree with the general idea, but cutting this down to something that might deploy is my main concern. JWT is nice, but it's more complex than I think we need. (Also, if we use cookies, there's this nice anti-cookie-stealing technology being developed in the tokbind WG. If we use cookies, we would need to generate good guidance about scope, because cookies are a bit of a mess.) From nobody Thu Jun 4 11:57:53 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3671A888F for ; Thu, 4 Jun 2015 11:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 3c5kFA-KHg8L for ; Thu, 4 Jun 2015 11:57:49 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 E00C11A6EF1 for ; Thu, 4 Jun 2015 11:57:48 -0700 (PDT) Received: by igbzc4 with SMTP id zc4so16006724igb.0 for ; Thu, 04 Jun 2015 11:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ochga/nWGQYbfoPWTb5/TcKspQwPCH/TVjj4U0UAi7I=; b=JqWzjUoEOkH/qLVJmfhpvrW4rqi5KevNFbD8o7+LN8OUUkqysVSOLkM67veqssYSEN AiWzJLC9CCSEDpITw6VLdA8UFhU5sMYVK3g9R2GCT7lwxxEZeRHwEhaKTG4PBdTepRUo X+IlqYgQmWqHW1rLl7A26l/s9EjU1gSulPQ2lpdQSA0W//7TJCwO4jYu1rOcZGuHFb9p SXzI/ebrkFKUoUIzcdigwRqXwoNcmz+7pK4wHqxNb83KxQYVlFPkEx7x2nToDSNh4EQ7 IPO09q5aqiC5mIEB6qMuhf7x2MLh6isUE7EyDPD7nURVT9ajZXFJkc5ZIeg/6Jtb06ku I9qw== MIME-Version: 1.0 X-Received: by 10.107.30.10 with SMTP id e10mr50039408ioe.72.1433444268209; Thu, 04 Jun 2015 11:57:48 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Thu, 4 Jun 2015 11:57:48 -0700 (PDT) In-Reply-To: References: <556F3A8F.5090009@mozilla.com> Date: Thu, 4 Jun 2015 11:57:48 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140f33c697dcb0517b5c0a6 Archived-At: Cc: JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Jun 2015 18:57:52 -0000 --001a1140f33c697dcb0517b5c0a6 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 10:07 PM, Martin Thomson wrote: > On 3 June 2015 at 19:37, Costin Manolache wrote: > > We're not trying to solve multi-party authentication - all we need is to > > know that the message originated from a specific sender. > > I'm fairly sure that you don't want this, but I'd like to restate that > I'm not looking to invent a global authentication system. > Nobody is looking to invent authentication systems - just use or adapt what is already well known, and learn/reuse from other messaging systems. > > > But the end goal is for both final webpush service and for the recipient > to > > know for sure who originated the message. > > I don't think that "for sure" is necessary here. And I think that we > have to balance the confidentiality needs of the sender as well. What > you are proposing doesn't do that, which is good. > We may need to break things down: - a receiver should know for sure who sent the message, and there is zero confidentiality expectation here - if someone sends you a message, you should know who sent it and be sure that it is verified. ( at least in the case of UA that use webpush services that use sender authentication ). - each webpush service can decide what policies it needs. There are still 'open relay' SMTP servers, but it is also common for SMTP servers to reject messages where the source can't be verified. Pretty much all I'm discussing should be considered in perspective of SMTP experience, which IMHO has many things in common with webpush. > > I personally thing that a simpler scheme, using just regular JWT tokens ( > > with few hours expiry ) would be enough and we don't need > > to sign the payload. GCM uses apikeys - similar with a cookie, but can be > > changed/rotated by sender when they need to, and > > seems to work well enough. The problem is that it requires the sender to > get > > keys(cookies) from each webpush service they may > > use. > > I think that different details per origin is a positive property. > What you are describing, if it were a browser that was doing the > sending, would be called a supercookie. That allows correlation of > sender behaviour across different origins. > > Sure, this would all be under the control of a sender, and you might > argue that senders have a lesser need for this sort of privacy and you > might even be right. > > But lesser isn't the same as none and I'd like to avoid situations > where we specify encouragement to do things that potentially undermine > privacy in this fashion. > > I'd like to hold this design to the same sorts of standards we hold > the rest of the web to. Or better yet, our aspirational goals for the > web. Particularly when it comes to privacy. > Going back to your comment about inventing things :-), I don't think we should focus on inventing a new privacy model. The web is starting to insist on verifying the domain name of the origin ( i.e. who sends data to your app ) - the same should be true on webpush. > > I have no fundamental objection to having a sender volunteer extra > information, like a support email address, but that needs to be at > their discretion. > Just like it is at the discretion of a webpush service to accept or not to forward messages, or what policy to apply. As is the case in SMTP. We may allow messages from un-identifiable senders, but at low QPS and with additional restrictions. > > I keep coming back to a simple cookie. I'd also be OK with the push > service sending back a full-blown web page with a registration form to > newcomers where additional information might be volunteered. Though > maybe that should be limited to those senders that include HTML in > their Accept header fields. > I'm not sure what you mean by 'cookie' in this context - but as I mentioned we have used a token without major problems. However the registration form doesn't scale - and it is considered painful. Why would it be a problem to standardize the fields and registration - we can use the same kind of info that is typically present in a HTTPS certificate, or JWT token, or whois record. It would be ok for webpush providers to include additional URL for extra signup if needed, but for the common case it will be better to automate the process. There is also the option to adapt what SMTP or XMPP are doing - and identify the sender using the domain name, but I think it's too complicated. > > > What I'm proposing instead is to rely on a single key pair for sender, > > and than just generate tokens and register the public key > > with any webpush server that may be used. This avoids the custom sign-up > to > > each webpush service. > > I certainly agree with the general idea, but cutting this down to > something that might deploy is my main concern. JWT is nice, but it's > more complex than I think we need. > How about: - first time you talk with a webpush ( identified by the domain in the capability subscription URL ), you need to grab an opaque string ( cookie/token), and use it in subsequent requests - to grab the opaque string, you need to call the subscribe URL, and include a set of optional information. - the initial request will use the private key of the sender to sign the request - and the public key of the sender will be included. If you go with HTML form - it will still eventually need to result in some way to prevent a sender impersonating another one. I suspect any webpush service that uses sender authentication will want to provide the authenticated identity of the sender to the UA and client app - so whatever identifier is seen by the client must be trusted. I'm proposing the public key of the sender because there are many ways to verify it without manual work. If you use a form - than it gets into verifying domain or email ownership, and can get as hard as getting a https cert. > > (Also, if we use cookies, there's this nice anti-cookie-stealing > technology being developed in the tokbind WG. If we use cookies, we > would need to generate good guidance about scope, because cookies are > a bit of a mess.) > If you have any more detailed description on what cookie means in this context - please include it, I see it as an opaque string with some rules about origin - but the rules are only enforced in the context of a browser AFAIK. Costin --001a1140f33c697dcb0517b5c0a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 3, 2015 at 10:07 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 3 June 2015 at 19:37, Costin Manolache <costin@gmail.com> wrote:
> We're not trying to solve multi-party authentication - all we need= is to
> know that the message originated from a specific sender.

I'm fairly sure that you don't want this, but I'd like t= o restate that
I'm not looking to invent a global authentication system.

Nobody is looking to invent authentication systems -= just use or adapt what is already
well known, and learn/reuse fr= om other messaging systems.


=C2=A0<= /div>

> But the end goal is for both final webpush service and for the recipie= nt to
> know for sure who originated the message.

I don't think that "for sure" is necessary here.=C2=A0= And I think that we
have to balance the confidentiality needs of the sender as well.=C2=A0 What=
you are proposing doesn't do that, which is good.
=

We may need to break things down:
<= br>
- a receiver should know for sure who sent the message, and t= here is zero confidentiality=C2=A0
expectation here - if someone = sends you a message, you should know who sent it
and be sure that= it is verified. ( at least in the case of UA that use webpush services tha= t=C2=A0
use sender authentication ).

- e= ach webpush service can decide what policies it needs. There are still '= ;open relay' SMTP
servers, but it is also common for SMTP ser= vers to reject messages where the source can't be
verified.= =C2=A0

Pretty much all I'm discussing should b= e considered in perspective of SMTP experience, which=C2=A0
IMHO = has many things in common with webpush.=C2=A0


=

> I personally thing that a simpler scheme, using just regular JWT token= s (
> with few hours expiry ) would be enough and we don't need
> to sign the payload. GCM uses apikeys - similar with a cookie, but can= be
> changed/rotated by sender when they need to, and
> seems to work well enough. The problem is that it requires the sender = to get
> keys(cookies) from each webpush service they may
> use.

I think that different details per origin is a positive property. What you are describing, if it were a browser that was doing the
sending, would be called a supercookie.=C2=A0 That allows correlation of sender behaviour across different origins.

Sure, this would all be under the control of a sender, and you might
argue that senders have a lesser need for this sort of privacy and you
might even be right.

But lesser isn't the same as none and I'd like to avoid situations<= br> where we specify encouragement to do things that potentially undermine
privacy in this fashion.

I'd like to hold this design to the same sorts of standards we hold
the rest of the web to.=C2=A0 Or better yet, our aspirational goals for the=
web.=C2=A0 Particularly when it comes to privacy.

=
Going back to your comment about inventing things :-), I don'= ;t think we should focus on
inventing a new privacy model.
<= div>
The web is starting to insist on verifying the domain na= me of the origin ( i.e. who sends data to
your app ) - the same s= hould be true on webpush.=C2=A0

=C2=A0

I have no fundamental objection to having a sender volunteer extra
information, like a support email address, but that needs to be at
their discretion.

Just like it is at th= e discretion of a webpush service to accept or not to forward messages, or= =C2=A0
what policy to apply. As is the case in SMTP.=C2=A0
<= div>
We may allow messages from un-identifiable senders, but = at =C2=A0low QPS and with additional
restrictions.=C2=A0

=C2=A0

I keep coming back to a simple cookie.=C2=A0 I'd also be OK with the pu= sh
service sending back a full-blown web page with a registration form to
newcomers where additional information might be volunteered.=C2=A0 Though maybe that should be limited to those senders that include HTML in
their Accept header fields.


<= div>I'm not sure what you mean by 'cookie' in this context - bu= t as I mentioned we have used a token
without major problems.=C2= =A0

However the registration form doesn't scal= e - and it is considered painful.=C2=A0

Why would = it be a problem to standardize the fields and registration - we can use the= same=C2=A0
kind of info that is =C2=A0typically present in a HTT= PS certificate, or JWT token, or whois record.=C2=A0

It would be ok for webpush providers to include additional URL for extra= signup if needed, but=C2=A0
for the common case it will be bette= r to automate the process.

There is also the optio= n to adapt what SMTP or XMPP are doing - and identify the sender
= using the domain name, but I think it's too complicated.
=C2= =A0

> What I'm proposing instead is to rely on a single key pair for sen= der,
> and than just generate tokens and register the public key
> with any webpush server that may be used. This avoids the custom sign-= up to
> each webpush service.

I certainly agree with the general idea, but cutting this down to something that might deploy is my main concern.=C2=A0 JWT is nice, but it&#= 39;s
more complex than I think we need.

How = about:=C2=A0
- first time you talk with a webpush ( identified by= the domain in the capability subscription URL ), you need
to gra= b an opaque string ( cookie/token), and use it in subsequent requests
=
- to grab the opaque string, you need to call the subscribe URL, and i= nclude a set of optional=C2=A0
information.
- the initi= al request will use the private key of the sender to sign the request - and= the public key of the=C2=A0
sender will be included.=C2=A0
=

If you go with HTML form - it will still eventually nee= d to result in some way to prevent a sender impersonating
another= one.=C2=A0

I suspect any webpush service that use= s sender authentication will want to provide the authenticated
id= entity of the sender to the UA and client app - so whatever identifier is s= een by the client must be=C2=A0
trusted. I'm proposing the pu= blic key of the sender because there are many ways to verify it without=C2= =A0
manual work. If you use a form - than it gets into verifying = domain or email ownership, and can get as hard=C2=A0
as getting a= https cert.=C2=A0

=C2=A0

(Also, if we use cookies, there's this nice anti-cookie-stealing
technology being developed in the tokbind WG.=C2=A0 If we use cookies, we would need to generate good guidance about scope, because cookies are
a bit of a mess.)

If you have any mor= e detailed description on what cookie means in this context - please includ= e it, I see it=C2=A0
as an opaque string wi= th some rules about origin - but the rules are only enforced in the context= of a browser
AFAIK.

Costin
--001a1140f33c697dcb0517b5c0a6-- From nobody Sun Jun 7 09:09:18 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE251A92E3 for ; Sun, 7 Jun 2015 09:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZhYBI-KfOJzF for ; Sun, 7 Jun 2015 09:09:14 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 91A271A92DE for ; Sun, 7 Jun 2015 09:09:13 -0700 (PDT) Received: by wigg3 with SMTP id g3so28818021wig.1 for ; Sun, 07 Jun 2015 09:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=31q0T1ZKt9npuf4UeDvvtG9okUB4nNFLud8Q6w2ked4=; b=k6N4+DvP6EEiiMbA9P1+LrrgGxwIbI8z7O2SbT8HJn4ERWXkNgm9LwChXsUrXakGMc 2wwL+shWWDNY1t+zgFmIBIkpItPyNorftJ8RAGytHR6qAfxm/OEmjGRrmT17fIgwUgZI 9nB/eUGnAB7zf+h1EAI+PSozl5gI+IRJtuBWzOkvyiBDQcV+PnMPFbfvL887P4P+kT4U sUEQPjO2kFJEY/gaoK9sPBUCuBF/sI7AJrYbu/a9RJF6tnYRsy7iubkTzyogHhY26Ibd OUcrlCnBLdld8wk2Zw5R+3krYtgtNZC1z2T5dTuv6c8wBNr08ZcK4D2XsVfWD/OEIKE+ fgjQ== X-Received: by 10.194.161.138 with SMTP id xs10mr17581133wjb.37.1433693352285; Sun, 07 Jun 2015 09:09:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.17.170 with HTTP; Sun, 7 Jun 2015 09:08:51 -0700 (PDT) In-Reply-To: References: <556F3A8F.5090009@mozilla.com> From: Paul Em Date: Sun, 7 Jun 2015 18:08:51 +0200 Message-ID: To: Costin Manolache Content-Type: multipart/alternative; boundary=089e013d0f38fae41d0517efbea4 Archived-At: Cc: Martin Thomson , JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Jun 2015 16:09:17 -0000 --089e013d0f38fae41d0517efbea4 Content-Type: text/plain; charset=UTF-8 So if we are not inventing some global system, then we cannot have a common generic authentication. Correct me if I am wrong, but I can't think of a system where you have a token, no manual work and no global system. I would also leave the possibility open for the push server to reject pushes after a certain quota (or even at first one?) and include a link to authenticate in the error description. You would have to register and get a token you can include in the requests for this endpoint. 2015-06-04 20:57 GMT+02:00 Costin Manolache : > > > On Wed, Jun 3, 2015 at 10:07 PM, Martin Thomson > wrote: > >> On 3 June 2015 at 19:37, Costin Manolache wrote: >> > We're not trying to solve multi-party authentication - all we need is to >> > know that the message originated from a specific sender. >> >> I'm fairly sure that you don't want this, but I'd like to restate that >> I'm not looking to invent a global authentication system. >> > > Nobody is looking to invent authentication systems - just use or adapt > what is already > well known, and learn/reuse from other messaging systems. > > > > >> >> > But the end goal is for both final webpush service and for the >> recipient to >> > know for sure who originated the message. >> >> I don't think that "for sure" is necessary here. And I think that we >> have to balance the confidentiality needs of the sender as well. What >> you are proposing doesn't do that, which is good. >> > > > We may need to break things down: > > - a receiver should know for sure who sent the message, and there is zero > confidentiality > expectation here - if someone sends you a message, you should know who > sent it > and be sure that it is verified. ( at least in the case of UA that use > webpush services that > use sender authentication ). > > - each webpush service can decide what policies it needs. There are still > 'open relay' SMTP > servers, but it is also common for SMTP servers to reject messages where > the source can't be > verified. > > Pretty much all I'm discussing should be considered in perspective of SMTP > experience, which > IMHO has many things in common with webpush. > > > >> > I personally thing that a simpler scheme, using just regular JWT tokens >> ( >> > with few hours expiry ) would be enough and we don't need >> > to sign the payload. GCM uses apikeys - similar with a cookie, but can >> be >> > changed/rotated by sender when they need to, and >> > seems to work well enough. The problem is that it requires the sender >> to get >> > keys(cookies) from each webpush service they may >> > use. >> >> I think that different details per origin is a positive property. >> What you are describing, if it were a browser that was doing the >> sending, would be called a supercookie. That allows correlation of >> sender behaviour across different origins. >> >> Sure, this would all be under the control of a sender, and you might >> argue that senders have a lesser need for this sort of privacy and you >> might even be right. >> >> But lesser isn't the same as none and I'd like to avoid situations >> where we specify encouragement to do things that potentially undermine >> privacy in this fashion. >> >> I'd like to hold this design to the same sorts of standards we hold >> the rest of the web to. Or better yet, our aspirational goals for the >> web. Particularly when it comes to privacy. >> > > Going back to your comment about inventing things :-), I don't think we > should focus on > inventing a new privacy model. > > The web is starting to insist on verifying the domain name of the origin ( > i.e. who sends data to > your app ) - the same should be true on webpush. > > > >> >> I have no fundamental objection to having a sender volunteer extra >> information, like a support email address, but that needs to be at >> their discretion. >> > > Just like it is at the discretion of a webpush service to accept or not to > forward messages, or > what policy to apply. As is the case in SMTP. > > We may allow messages from un-identifiable senders, but at low QPS and > with additional > restrictions. > > > >> >> I keep coming back to a simple cookie. I'd also be OK with the push >> service sending back a full-blown web page with a registration form to >> newcomers where additional information might be volunteered. Though >> maybe that should be limited to those senders that include HTML in >> their Accept header fields. >> > > > I'm not sure what you mean by 'cookie' in this context - but as I > mentioned we have used a token > without major problems. > > However the registration form doesn't scale - and it is considered > painful. > > Why would it be a problem to standardize the fields and registration - we > can use the same > kind of info that is typically present in a HTTPS certificate, or JWT > token, or whois record. > > It would be ok for webpush providers to include additional URL for extra > signup if needed, but > for the common case it will be better to automate the process. > > There is also the option to adapt what SMTP or XMPP are doing - and > identify the sender > using the domain name, but I think it's too complicated. > > >> >> > What I'm proposing instead is to rely on a single key pair for sender, >> > and than just generate tokens and register the public key >> > with any webpush server that may be used. This avoids the custom >> sign-up to >> > each webpush service. >> >> I certainly agree with the general idea, but cutting this down to >> something that might deploy is my main concern. JWT is nice, but it's >> more complex than I think we need. >> > > How about: > - first time you talk with a webpush ( identified by the domain in the > capability subscription URL ), you need > to grab an opaque string ( cookie/token), and use it in subsequent requests > - to grab the opaque string, you need to call the subscribe URL, and > include a set of optional > information. > - the initial request will use the private key of the sender to sign the > request - and the public key of the > sender will be included. > > If you go with HTML form - it will still eventually need to result in some > way to prevent a sender impersonating > another one. > > I suspect any webpush service that uses sender authentication will want to > provide the authenticated > identity of the sender to the UA and client app - so whatever identifier > is seen by the client must be > trusted. I'm proposing the public key of the sender because there are many > ways to verify it without > manual work. If you use a form - than it gets into verifying domain or > email ownership, and can get as hard > as getting a https cert. > > > >> >> (Also, if we use cookies, there's this nice anti-cookie-stealing >> technology being developed in the tokbind WG. If we use cookies, we >> would need to generate good guidance about scope, because cookies are >> a bit of a mess.) >> > > If you have any more detailed description on what cookie means in this > context - please include it, I see it > as an opaque string with some rules about origin - but the rules are only > enforced in the context of a browser > AFAIK. > > Costin > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --089e013d0f38fae41d0517efbea4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So if we are not inventing some global system, then w= e cannot have a common generic authentication.=C2=A0
Cor= rect me if I am wrong, but I can't think of a system where you have a t= oken, no manual work and no global system.

I= would also leave the possibility open for the push server to reject pushes= after a certain quota (or even at first one?) and include a link to authen= ticate in the error description. You would have to register and get a token= you can include in the requests for this endpoint.


2015-06-04 20:57= GMT+02:00 Costin Manolache <costin@gmail.com>:


On Wed, Jun 3, 2015 at 10:07 PM, Martin Thomson= <martin.thomson@gmail.com> wrote:
On 3 June 2015 at 19:37, Costin Manolache <costin@gmail.com> wrote:
> We're not trying to solve multi-party authentication - all we need= is to
> know that the message originated from a specific sender.

I'm fairly sure that you don't want this, but I'd like t= o restate that
I'm not looking to invent a global authentication system.

Nobody is looking to invent authentication sy= stems - just use or adapt what is already
well known, and learn/r= euse from other messaging systems.

=C2=A0
=
=C2=A0

> But the end goal is for both final webpush service and for the recipie= nt to
> know for sure who originated the message.

I don't think that "for sure" is necessary here.=C2=A0= And I think that we
have to balance the confidentiality needs of the sender as well.=C2=A0 What=
you are proposing doesn't do that, which is good.
=

We may need to break things down:

- a receiver should know for sure who sent the message= , and there is zero confidentiality=C2=A0
expectation here - if s= omeone sends you a message, you should know who sent it
and be su= re that it is verified. ( at least in the case of UA that use webpush servi= ces that=C2=A0
use sender authentication ).

<= div>- each webpush service can decide what policies it needs. There are sti= ll 'open relay' SMTP
servers, but it is also common for S= MTP servers to reject messages where the source can't be
veri= fied.=C2=A0

Pretty much all I'm discussing sho= uld be considered in perspective of SMTP experience, which=C2=A0
= IMHO has many things in common with webpush.=C2=A0



> I personally thing that a simpler scheme, using just regular JWT token= s (
> with few hours expiry ) would be enough and we don't need
> to sign the payload. GCM uses apikeys - similar with a cookie, but can= be
> changed/rotated by sender when they need to, and
> seems to work well enough. The problem is that it requires the sender = to get
> keys(cookies) from each webpush service they may
> use.

I think that different details per origin is a positive property. What you are describing, if it were a browser that was doing the
sending, would be called a supercookie.=C2=A0 That allows correlation of sender behaviour across different origins.

Sure, this would all be under the control of a sender, and you might
argue that senders have a lesser need for this sort of privacy and you
might even be right.

But lesser isn't the same as none and I'd like to avoid situations<= br> where we specify encouragement to do things that potentially undermine
privacy in this fashion.

I'd like to hold this design to the same sorts of standards we hold
the rest of the web to.=C2=A0 Or better yet, our aspirational goals for the=
web.=C2=A0 Particularly when it comes to privacy.

=
Going back to your comment about inventing things :-), I = don't think we should focus on
inventing a new privacy model.=

The web is starting to insist on verifying the do= main name of the origin ( i.e. who sends data to
your app ) - the= same should be true on webpush.=C2=A0

=C2=A0

I have no fundamental objection to having a sender volunteer extra
information, like a support email address, but that needs to be at
their discretion.

Just like it i= s at the discretion of a webpush service to accept or not to forward messag= es, or=C2=A0
what policy to apply. As is the case in SMTP.=C2=A0<= /div>

We may allow messages from un-identifiable senders= , but at =C2=A0low QPS and with additional
restrictions.=C2=A0

=C2=A0

I keep coming back to a simple cookie.=C2=A0 I'd also be OK with the pu= sh
service sending back a full-blown web page with a registration form to
newcomers where additional information might be volunteered.=C2=A0 Though maybe that should be limited to those senders that include HTML in
their Accept header fields.


<= /span>
I'm not sure what you mean by 'cookie' in this conte= xt - but as I mentioned we have used a token
without major proble= ms.=C2=A0

However the registration form doesn'= t scale - and it is considered painful.=C2=A0

Why = would it be a problem to standardize the fields and registration - we can u= se the same=C2=A0
kind of info that is =C2=A0typically present in= a HTTPS certificate, or JWT token, or whois record.=C2=A0

It would be ok for webpush providers to include additional URL for= extra signup if needed, but=C2=A0
for the common case it will be= better to automate the process.

There is also the= option to adapt what SMTP or XMPP are doing - and identify the sender
using the domain name, but I think it's too complicated.
=C2=A0

> What I'm proposing instead is to rely on a single key pair for sen= der,
> and than just generate tokens and register the public key
> with any webpush server that may be used. This avoids the custom sign-= up to
> each webpush service.

I certainly agree with the general idea, but cutting this down to something that might deploy is my main concern.=C2=A0 JWT is nice, but it&#= 39;s
more complex than I think we need.

How about:=C2=A0
- first time you talk with a webpush ( identi= fied by the domain in the capability subscription URL ), you need
to grab an opaque string ( cookie/token), and use it in subsequent request= s
- to grab the opaque string, you need to call the subscribe URL= , and include a set of optional=C2=A0
information.
- th= e initial request will use the private key of the sender to sign the reques= t - and the public key of the=C2=A0
sender will be included.=C2= =A0

If you go with HTML form - it will still event= ually need to result in some way to prevent a sender impersonating
another one.=C2=A0

I suspect any webpush service= that uses sender authentication will want to provide the authenticated
identity of the sender to the UA and client app - so whatever identi= fier is seen by the client must be=C2=A0
trusted. I'm proposi= ng the public key of the sender because there are many ways to verify it wi= thout=C2=A0
manual work. If you use a form - than it gets into ve= rifying domain or email ownership, and can get as hard=C2=A0
as g= etting a https cert.=C2=A0

=C2=A0=

(Also, if we use cookies, there's this nice anti-cookie-stealing
technology being developed in the tokbind WG.=C2=A0 If we use cookies, we would need to generate good guidance about scope, because cookies are
a bit of a mess.)

If you have = any more detailed description on what cookie means in this context - please= include it, I see it=C2=A0
as an opaque st= ring with some rules about origin - but the rules are only enforced in the = context of a browser
AFAIK.

Costin

_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--089e013d0f38fae41d0517efbea4-- From nobody Sun Jun 7 13:44:44 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ACF1ACDFD for ; Sun, 7 Jun 2015 13:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 zRDFjnVaSFF0 for ; Sun, 7 Jun 2015 13:44:38 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (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 0D90B1ACDE7 for ; Sun, 7 Jun 2015 13:44:38 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so51297382ieb.1 for ; Sun, 07 Jun 2015 13:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Bgip67lElbZ4a+ab8TgtbBiqrHAwDrLSf/rBlx5ktI=; b=p4BRq4pX4oNyV13NhtC7dQoBWZC5QtY8Ycbcr21p5FmQCoeglykShwyUAqJr2xn3bV 0mvT0dKl62pP5HL+iO+7FWBSAi2BUPsZXeVfBiByl7uhA6lo6n+Q/tMBq151GXuivF5x w2EYgitGZlHbeKqulIO2ypFt7jy+H/Ctd0i8a2LeGU8V6JnVfhucllxhg32+7Pyyj+3m XfQLKKtBQdO7cbe5uugMCKtXFkI7PqsHjnZ9PE6ULfTsgSzc9RAejIk2kM8mZJbusdLq vxlx5YH+SZ5FaZQIR8vCK6Kl3D+5kJsg6rEm2HJr1EILYEe3APTIdk0CbF0zlvoP+uOg r/gA== MIME-Version: 1.0 X-Received: by 10.107.30.10 with SMTP id e10mr16697517ioe.72.1433709877476; Sun, 07 Jun 2015 13:44:37 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Sun, 7 Jun 2015 13:44:37 -0700 (PDT) In-Reply-To: References: <556F3A8F.5090009@mozilla.com> Date: Sun, 7 Jun 2015 13:44:37 -0700 Message-ID: From: Costin Manolache To: Paul Em Content-Type: multipart/alternative; boundary=001a1140f33cf546350517f397b0 Archived-At: Cc: Martin Thomson , JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Jun 2015 20:44:41 -0000 --001a1140f33cf546350517f397b0 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 7, 2015 at 9:08 AM, Paul Em wrote: > So if we are not inventing some global system, then we cannot have a > common generic authentication. > Not inventing a global authentication system - maybe adapting existing ones a bit :-) But we are defining a 'subscribe' or registration protocol - one is required for apps and UAs to register with the push service. I'm just suggesting to extend it a bit, and use it symmetrically for all entities - i.e. including senders. We also require use of asymmetric keys for receivers - we can use them on the senders as well, for the purpose of signing/identification. > Correct me if I am wrong, but I can't think of a system where you have a > token, no manual work and no global system. > I'm trying to avoid manual work, where each sender has to register (fill forms) for each push provider. The system is global in the sense that a sender can work with any push service that requires sender authentication and is free or has some free quota. There are few systems that allow registration of public keys with key servers - as well as systems that use private keys for authentication. Or as result of registration we can return regular tokens/cookies. The main point of my proposal is to use the public key of the sender as 'identifier' that is verified at each send ( using either the private key or some tokens/cookies returned after verifying the private key ). Any other alternative I know would require some manual work to prove that the identity is the same to different push providers. For example - domain name / origin would require either some certificate ( I hope nobody wants to go there ), or other proof of ownership, plus some forms to fill manually, since this is hard to automate. > > I would also leave the possibility open for the push server to reject > pushes after a certain quota (or even at first one?) and include a link to > authenticate in the error description. You would have to register and get a > token you can include in the requests for this endpoint. > Agreed - result of subscribe should include an optional link. But I think we should add this for both registering senders and registering UAs. The current draft assumes that the UA can just register automatically, with no extra user intervention. Costin > > > > 2015-06-04 20:57 GMT+02:00 Costin Manolache : > >> >> >> On Wed, Jun 3, 2015 at 10:07 PM, Martin Thomson > > wrote: >> >>> On 3 June 2015 at 19:37, Costin Manolache wrote: >>> > We're not trying to solve multi-party authentication - all we need is >>> to >>> > know that the message originated from a specific sender. >>> >>> I'm fairly sure that you don't want this, but I'd like to restate that >>> I'm not looking to invent a global authentication system. >>> >> >> Nobody is looking to invent authentication systems - just use or adapt >> what is already >> well known, and learn/reuse from other messaging systems. >> >> >> > >> >>> >>> > But the end goal is for both final webpush service and for the >>> recipient to >>> > know for sure who originated the message. >>> >>> I don't think that "for sure" is necessary here. And I think that we >>> have to balance the confidentiality needs of the sender as well. What >>> you are proposing doesn't do that, which is good. >>> >> >> >> We may need to break things down: >> >> - a receiver should know for sure who sent the message, and there is zero >> confidentiality >> expectation here - if someone sends you a message, you should know who >> sent it >> and be sure that it is verified. ( at least in the case of UA that use >> webpush services that >> use sender authentication ). >> >> - each webpush service can decide what policies it needs. There are still >> 'open relay' SMTP >> servers, but it is also common for SMTP servers to reject messages where >> the source can't be >> verified. >> >> Pretty much all I'm discussing should be considered in perspective of >> SMTP experience, which >> IMHO has many things in common with webpush. >> >> >> >>> > I personally thing that a simpler scheme, using just regular JWT >>> tokens ( >>> > with few hours expiry ) would be enough and we don't need >>> > to sign the payload. GCM uses apikeys - similar with a cookie, but can >>> be >>> > changed/rotated by sender when they need to, and >>> > seems to work well enough. The problem is that it requires the sender >>> to get >>> > keys(cookies) from each webpush service they may >>> > use. >>> >>> I think that different details per origin is a positive property. >>> What you are describing, if it were a browser that was doing the >>> sending, would be called a supercookie. That allows correlation of >>> sender behaviour across different origins. >>> >>> Sure, this would all be under the control of a sender, and you might >>> argue that senders have a lesser need for this sort of privacy and you >>> might even be right. >>> >>> But lesser isn't the same as none and I'd like to avoid situations >>> where we specify encouragement to do things that potentially undermine >>> privacy in this fashion. >>> >>> I'd like to hold this design to the same sorts of standards we hold >>> the rest of the web to. Or better yet, our aspirational goals for the >>> web. Particularly when it comes to privacy. >>> >> >> Going back to your comment about inventing things :-), I don't think we >> should focus on >> inventing a new privacy model. >> >> The web is starting to insist on verifying the domain name of the origin >> ( i.e. who sends data to >> your app ) - the same should be true on webpush. >> >> >> >>> >>> I have no fundamental objection to having a sender volunteer extra >>> information, like a support email address, but that needs to be at >>> their discretion. >>> >> >> Just like it is at the discretion of a webpush service to accept or not >> to forward messages, or >> what policy to apply. As is the case in SMTP. >> >> We may allow messages from un-identifiable senders, but at low QPS and >> with additional >> restrictions. >> >> >> >>> >>> I keep coming back to a simple cookie. I'd also be OK with the push >>> service sending back a full-blown web page with a registration form to >>> newcomers where additional information might be volunteered. Though >>> maybe that should be limited to those senders that include HTML in >>> their Accept header fields. >>> >> >> >> I'm not sure what you mean by 'cookie' in this context - but as I >> mentioned we have used a token >> without major problems. >> >> However the registration form doesn't scale - and it is considered >> painful. >> >> Why would it be a problem to standardize the fields and registration - we >> can use the same >> kind of info that is typically present in a HTTPS certificate, or JWT >> token, or whois record. >> >> It would be ok for webpush providers to include additional URL for extra >> signup if needed, but >> for the common case it will be better to automate the process. >> >> There is also the option to adapt what SMTP or XMPP are doing - and >> identify the sender >> using the domain name, but I think it's too complicated. >> >> >>> >>> > What I'm proposing instead is to rely on a single key pair for sender, >>> > and than just generate tokens and register the public key >>> > with any webpush server that may be used. This avoids the custom >>> sign-up to >>> > each webpush service. >>> >>> I certainly agree with the general idea, but cutting this down to >>> something that might deploy is my main concern. JWT is nice, but it's >>> more complex than I think we need. >>> >> >> How about: >> - first time you talk with a webpush ( identified by the domain in the >> capability subscription URL ), you need >> to grab an opaque string ( cookie/token), and use it in subsequent >> requests >> - to grab the opaque string, you need to call the subscribe URL, and >> include a set of optional >> information. >> - the initial request will use the private key of the sender to sign the >> request - and the public key of the >> sender will be included. >> >> If you go with HTML form - it will still eventually need to result in >> some way to prevent a sender impersonating >> another one. >> >> I suspect any webpush service that uses sender authentication will want >> to provide the authenticated >> identity of the sender to the UA and client app - so whatever identifier >> is seen by the client must be >> trusted. I'm proposing the public key of the sender because there are >> many ways to verify it without >> manual work. If you use a form - than it gets into verifying domain or >> email ownership, and can get as hard >> as getting a https cert. >> >> >> >>> >>> (Also, if we use cookies, there's this nice anti-cookie-stealing >>> technology being developed in the tokbind WG. If we use cookies, we >>> would need to generate good guidance about scope, because cookies are >>> a bit of a mess.) >>> >> >> If you have any more detailed description on what cookie means in this >> context - please include it, I see it >> as an opaque string with some rules about origin - but the rules are only >> enforced in the context of a browser >> AFAIK. >> >> Costin >> >> _______________________________________________ >> Webpush mailing list >> Webpush@ietf.org >> https://www.ietf.org/mailman/listinfo/webpush >> >> > --001a1140f33cf546350517f397b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Jun 7, 2015 at 9:08 AM, Paul Em <paul3m@gmail.com> wr= ote:
So if we are n= ot inventing some global system, then we cannot have a common generic authe= ntication.=C2=A0

Not invent= ing a global authentication system - maybe adapting existing ones a bit :-)=

But we are defining a 'subscribe' or regi= stration protocol - one is required for apps and UAs to register with the p= ush=C2=A0
service. I'm just suggesting to extend it a bit, an= d use it symmetrically for all entities - i.e. including senders.

We also require use of asymmetric keys for receivers - we c= an use them on the senders as well, for the purpose=C2=A0
of sign= ing/identification.

=C2=A0
Correct me if I am wron= g, but I can't think of a system where you have a token, no manual work= and no global system.

I&= #39;m trying to avoid manual work, where each sender has to register (fill = forms) for each push provider.

The system is globa= l in the sense that a sender can work with any push service that requires s= ender authentication
and is free or has some free quota.=C2=A0

There are few systems that allow registration of pub= lic keys with key servers - as well as systems that use private keys=C2=A0<= /div>
for authentication. Or as result of registration we can return re= gular tokens/cookies.

The main point of my proposa= l is to use the public key of the sender as 'identifier' that is ve= rified at each send ( using
either the private key or some tokens= /cookies returned after verifying the private key ).=C2=A0

Any other alternative I know would require some manual work to pro= ve that the identity is the same to different=C2=A0
push provider= s. For example - domain name / origin would require either some certificate= ( I hope nobody wants to=C2=A0
go there ), or other proof of own= ership, plus some forms to fill manually, since this is hard to automate.= =C2=A0
=C2=A0

I would also leave the possibility open for the push = server to reject pushes after a certain quota (or even at first one?) and i= nclude a link to authenticate in the error description. You would have to r= egister and get a token you can include in the requests for this endpoint.<= /div>

Agreed - result of subscribe sh= ould include an optional link. But I think we should add this for both regi= stering senders and=C2=A0
registering UAs. The current draft assu= mes that the UA can just register automatically, with no extra user interve= ntion.

Costin

=C2=A0



2= 015-06-04 20:57 GMT+02:00 Costin Manolache <costin@gmail.com>= :


<= div class=3D"gmail_quote">On Wed, Jun 3, 2015 at 10:07 PM, Martin Tho= mson <martin.thomson@gmail.com> wrote:
On 3 June 2015 at 19:37, Costin Manolache <costin@gmail.com> wrote:
> We're not trying to solve multi-party authentication - all we need= is to
> know that the message originated from a specific sender.

I'm fairly sure that you don't want this, but I'd like t= o restate that
I'm not looking to invent a global authentication system.

Nobody is looking to invent authentication sy= stems - just use or adapt what is already
well known, and learn/r= euse from other messaging systems.

=C2=A0
=
=C2=A0

> But the end goal is for both final webpush service and for the recipie= nt to
> know for sure who originated the message.

I don't think that "for sure" is necessary here.=C2=A0= And I think that we
have to balance the confidentiality needs of the sender as well.=C2=A0 What=
you are proposing doesn't do that, which is good.
=

We may need to break things down:

- a receiver should know for sure who sent the message= , and there is zero confidentiality=C2=A0
expectation here - if s= omeone sends you a message, you should know who sent it
and be su= re that it is verified. ( at least in the case of UA that use webpush servi= ces that=C2=A0
use sender authentication ).

<= div>- each webpush service can decide what policies it needs. There are sti= ll 'open relay' SMTP
servers, but it is also common for S= MTP servers to reject messages where the source can't be
veri= fied.=C2=A0

Pretty much all I'm discussing sho= uld be considered in perspective of SMTP experience, which=C2=A0
= IMHO has many things in common with webpush.=C2=A0



> I personally thing that a simpler scheme, using just regular JWT token= s (
> with few hours expiry ) would be enough and we don't need
> to sign the payload. GCM uses apikeys - similar with a cookie, but can= be
> changed/rotated by sender when they need to, and
> seems to work well enough. The problem is that it requires the sender = to get
> keys(cookies) from each webpush service they may
> use.

I think that different details per origin is a positive property. What you are describing, if it were a browser that was doing the
sending, would be called a supercookie.=C2=A0 That allows correlation of sender behaviour across different origins.

Sure, this would all be under the control of a sender, and you might
argue that senders have a lesser need for this sort of privacy and you
might even be right.

But lesser isn't the same as none and I'd like to avoid situations<= br> where we specify encouragement to do things that potentially undermine
privacy in this fashion.

I'd like to hold this design to the same sorts of standards we hold
the rest of the web to.=C2=A0 Or better yet, our aspirational goals for the=
web.=C2=A0 Particularly when it comes to privacy.

=
Going back to your comment about inventing things :-), I = don't think we should focus on
inventing a new privacy model.=

The web is starting to insist on verifying the do= main name of the origin ( i.e. who sends data to
your app ) - the= same should be true on webpush.=C2=A0

=C2= =A0

I have no fundamental objection to having a sender volunteer extra
information, like a support email address, but that needs to be at
their discretion.

Just like it i= s at the discretion of a webpush service to accept or not to forward messag= es, or=C2=A0
what policy to apply. As is the case in SMTP.=C2=A0<= /div>

We may allow messages from un-identifiable senders= , but at =C2=A0low QPS and with additional
restrictions.=C2=A0

=C2=A0

I keep coming back to a simple cookie.=C2=A0 I'd also be OK with the pu= sh
service sending back a full-blown web page with a registration form to
newcomers where additional information might be volunteered.=C2=A0 Though maybe that should be limited to those senders that include HTML in
their Accept header fields.


<= /span>
I'm not sure what you mean by 'cookie' in this conte= xt - but as I mentioned we have used a token
without major proble= ms.=C2=A0

However the registration form doesn'= t scale - and it is considered painful.=C2=A0

Why = would it be a problem to standardize the fields and registration - we can u= se the same=C2=A0
kind of info that is =C2=A0typically present in= a HTTPS certificate, or JWT token, or whois record.=C2=A0

It would be ok for webpush providers to include additional URL for= extra signup if needed, but=C2=A0
for the common case it will be= better to automate the process.

There is also the= option to adapt what SMTP or XMPP are doing - and identify the sender
using the domain name, but I think it's too complicated.
=C2=A0

> What I'm proposing instead is to rely on a single key pair for sen= der,
> and than just generate tokens and register the public key
> with any webpush server that may be used. This avoids the custom sign-= up to
> each webpush service.

I certainly agree with the general idea, but cutting this down to something that might deploy is my main concern.=C2=A0 JWT is nice, but it&#= 39;s
more complex than I think we need.

How about:=C2=A0
- first time you talk with a webpush ( identi= fied by the domain in the capability subscription URL ), you need
to grab an opaque string ( cookie/token), and use it in subsequent request= s
- to grab the opaque string, you need to call the subscribe URL= , and include a set of optional=C2=A0
information.
- th= e initial request will use the private key of the sender to sign the reques= t - and the public key of the=C2=A0
sender will be included.=C2= =A0

If you go with HTML form - it will still event= ually need to result in some way to prevent a sender impersonating
another one.=C2=A0

I suspect any webpush service= that uses sender authentication will want to provide the authenticated
identity of the sender to the UA and client app - so whatever identi= fier is seen by the client must be=C2=A0
trusted. I'm proposi= ng the public key of the sender because there are many ways to verify it wi= thout=C2=A0
manual work. If you use a form - than it gets into ve= rifying domain or email ownership, and can get as hard=C2=A0
as g= etting a https cert.=C2=A0

=C2=A0

(Also, if we use cookies, there's this nice anti-cookie-stealing
technology being developed in the tokbind WG.=C2=A0 If we use cookies, we would need to generate good guidance about scope, because cookies are
a bit of a mess.)

If you have = any more detailed description on what cookie means in this context - please= include it, I see it=C2=A0
as an opaque st= ring with some rules about origin - but the rules are only enforced in the = context of a browser
AFAIK.

Costin

__________________________________________= _____
Webpush mailing list
Webpush@ietf.org<= br> https://www.ietf.org/mailman/listinfo/webpush



--001a1140f33cf546350517f397b0-- From nobody Mon Jun 8 11:56:57 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6504E1B31BF for ; Mon, 8 Jun 2015 11:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 nUKGByqd0FeT for ; Mon, 8 Jun 2015 11:56:54 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (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 BF0E11B31B5 for ; Mon, 8 Jun 2015 11:56:54 -0700 (PDT) Received: by yked142 with SMTP id d142so56402513yke.3 for ; Mon, 08 Jun 2015 11:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4G9jc6GZVlfATFy7wqF5d/c8Pvjyjk01CWmXnpKhm6M=; b=Z0cOLkGb6ESdWc+nruKXeSt2RZuNfBk5kE9bYxBky6F8LMJAI3SUfZKMXM9YWdKqJ9 hTvNBxhmVyY3ZIznaFCBsoq8VrMsFKCP+DnNSB5Waa5zto91ojwfVhdVEEWrzzi3IR/5 2EkdI9PCOBuaHFXaPtcKBpc99HHqCUPa/kKsS0WnNC0I+ZRrynuGGIbULACgG8EjFyYU ij9eOlOR24G8wvqD4jeN7waHoF29TT7kou/GFc71tiU8IyfOcYZGPEth6eKUdSu+S1ra jwtVtfv8r74ikpz156qG2Q8EHvDdwQ7WT6E42g3sdJdm8f/+BpLMSx9E15T3FDSyDX12 qAbw== MIME-Version: 1.0 X-Received: by 10.129.97.213 with SMTP id v204mr17828284ywb.56.1433789814190; Mon, 08 Jun 2015 11:56:54 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 8 Jun 2015 11:56:54 -0700 (PDT) In-Reply-To: References: <556F3A8F.5090009@mozilla.com> Date: Mon, 8 Jun 2015 11:56:54 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 08 Jun 2015 18:56:56 -0000 Trimming aggressively. Let me know if I missed something. On 4 June 2015 at 11:57, Costin Manolache wrote: > - a receiver should know for sure who sent the message, and there is zero > confidentiality > expectation here - if someone sends you a message, you should know who sent > it > and be sure that it is verified. ( at least in the case of UA that use > webpush services that > use sender authentication ). This is a guarantee that the web does not provide, because it has negative privacy consequences. So I guess I'm challenging your assertion about confidentiality. Think about it this way: If I send you a message, I might want my identity to remain hidden from the service that you use. That way I am at least partially insulated to some extent from the choices that you have made. This is not the same as your email server authenticating your MTA, it's more correctly analogous to Google being able to authenticate every email sent to a gmail account. As I understand it, authentication is an important part of anti-spam, but not the only criterion. > We may allow messages from un-identifiable senders, but at low QPS and with > additional restrictions. As I would expect :) > It would be ok for webpush providers to include additional URL for extra > signup if needed, but > for the common case it will be better to automate the process. I have no fundamental objection to automating the provision of extra information, but automation requires standardizing and I'm leery of doing more standardizing than necessary, at least initially. I'd rather remove as much as possible from the critical path. > How about: > - first time you talk with a webpush ( identified by the domain in the > capability subscription URL ), you need > to grab an opaque string ( cookie/token), and use it in subsequent requests > - to grab the opaque string, you need to call the subscribe URL, and include > a set of optional > information. > - the initial request will use the private key of the sender to sign the > request - and the public key of the > sender will be included. I was thinking that you sent a push, received a cookie in return and a link to a registration resource, or - if you like - links to automated and/or manual forms. You could replay the cookie to receive whatever benefits might be accrued to that cookie, either by establishing a reputation as a good actor over time, or by providing extra information. > I suspect any webpush service that uses sender authentication will want to > provide the authenticated > identity of the sender to the UA and client app It would be better for the sender to authenticate themselves with the application/UA directly. > If you have any more detailed description on what cookie means in this > context - RFC 6265. From nobody Mon Jun 8 13:07:48 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966B51B323A for ; Mon, 8 Jun 2015 13:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6b00_JTVM0pG for ; Mon, 8 Jun 2015 13:07:44 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 09CB81A878E for ; Mon, 8 Jun 2015 13:07:33 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so70463397igb.1 for ; Mon, 08 Jun 2015 13:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uj/+KQ2scGNseD6anWAne2sia1Fqz//BHvmG0fiypBg=; b=w3+k4WPi7cgpdhFfFg75p2/u/tEZ4IRou6Cln42det4CCZc450mi5QSSHh8FG06Lp+ Yi0pQOHIo57w2Xt7PkFSLGGj31kc5JJhdVbkKllciApw2BVlyjsJhjh/UR+cvk7EFC6V EsUI5xniE/U2S4C2iOrdXhTiveRLqmkaS7x179fkysZhShtiRsJjy0ajHtBExl3WlA64 x6MuDiccyyPkhj+P7RwvR10uuA4oM9fig5H/jMUh4WvE/SBIeQyoYWeDekFbMDX01vJN jSfO+iKPG7vvI1G/dVXvjwyeuENfNll6RSgFatphUwcKfcWjedDoUCAysSHKjVz0TIip JG8A== MIME-Version: 1.0 X-Received: by 10.50.79.202 with SMTP id l10mr15756387igx.7.1433794052515; Mon, 08 Jun 2015 13:07:32 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Mon, 8 Jun 2015 13:07:32 -0700 (PDT) In-Reply-To: References: <556F3A8F.5090009@mozilla.com> Date: Mon, 8 Jun 2015 13:07:32 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0122aaee2e6d8805180731ea Archived-At: Cc: JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 08 Jun 2015 20:07:47 -0000 --089e0122aaee2e6d8805180731ea Content-Type: text/plain; charset=UTF-8 On Mon, Jun 8, 2015 at 11:56 AM, Martin Thomson wrote: > Trimming aggressively. Let me know if I missed something. > > On 4 June 2015 at 11:57, Costin Manolache wrote: > > - a receiver should know for sure who sent the message, and there is zero > > confidentiality > > expectation here - if someone sends you a message, you should know who > sent > > it > > and be sure that it is verified. ( at least in the case of UA that use > > webpush services that > > use sender authentication ). > > This is a guarantee that the web does not provide, because it has > negative privacy consequences. So I guess I'm challenging your > assertion about confidentiality. > Not sure what you mean - https on the web 1. doesn't provide any confidentiality on the origin ( at least if SNI is used - domain is visible to transport provider and anyone in between). 2. requires that UA will verify the origin of the content it shows to the user. And the current internet does provide this kind of verification in a lot of messaging cases. The reason I keep mentioning SMTP is that it's the only one I know where the origin of the content can be easily forged ( with well-known consequence ), I don't have other good examples. The choice to get content only from verified sources is present on the web as well: some services only support https for example ( which does verify the origin ). In my view webpush originated content is as important as site-originated content in the page, having parts of the page from unverified sources (mixed content) is not ideal. > Think about it this way: If I send you a message, I might want my > identity to remain hidden from the service that you use. That way I > am at least partially insulated to some extent from the choices that > you have made. > As I mentioned - accepting untrusted content is a choice, as it is in SMTP. > This is not the same as your email server authenticating your MTA, > it's more correctly analogous to Google being able to authenticate > every email sent to a gmail account. As I understand it, > authentication is an important part of anti-spam, but not the only > criterion. > Yes, because SMTP was designed like current webpush :-) - without consideration for verifying the identity of the sender of a message, instead assuming that the 'capability URL' that allows sending ( email address in case of SMTP ) will be kept confidential and only provided to trusted senders. > > > We may allow messages from un-identifiable senders, but at low QPS and > with > > additional restrictions. > > As I would expect :) > > > It would be ok for webpush providers to include additional URL for extra > > signup if needed, but > > for the common case it will be better to automate the process. > > I have no fundamental objection to automating the provision of extra > information, but automation requires standardizing and I'm leery of > doing more standardizing than necessary, at least initially. I'd > rather remove as much as possible from the critical path. > > We may do this in a separate document - the only alternative is developers having to manually register to each push provider that requires verification. If it turns out that only very few push services have this requirement - it may not be a huge problem, and maybe the automated registration can be just a way to improve developer experience for those providers. > > How about: > > - first time you talk with a webpush ( identified by the domain in the > > capability subscription URL ), you need > > to grab an opaque string ( cookie/token), and use it in subsequent > requests > > - to grab the opaque string, you need to call the subscribe URL, and > include > > a set of optional > > information. > > - the initial request will use the private key of the sender to sign the > > request - and the public key of the > > sender will be included. > > I was thinking that you sent a push, received a cookie in return and a > link to a registration resource, or - if you like - links to automated > and/or manual forms. You could replay the cookie to receive whatever > benefits might be accrued to that cookie, either by establishing a > reputation as a good actor over time, or by providing extra > information. > But the UA and app on the client will still have no way to know who sent the message. Just that the sender has some good reputation - like it's done now in SMTP ( based on IP / etc ). Using a key pair - and the equivalent of a CSR - would allow the webpush provider to identify the public key of the sender to the UA and app, and that would work consistently for an app - regardless of which webpush provider is used. Of course - if a webpush provider choses 'open relay / anonymous sender' - there would be no 'from' field provided. > > > I suspect any webpush service that uses sender authentication will want > to > > provide the authenticated > > identity of the sender to the UA and client app > > It would be better for the sender to authenticate themselves with the > application/UA directly. > That may be possible - for example by signing the content - but still doesn't address the issue of webpush providers managing their network, and adds more complexity on the send side. What would be the benefit of using different ways to authenticate the sender - one to client app, a different one to webpush provider ? > > > If you have any more detailed description on what cookie means in this > > context - > > RFC 6265. > AFAIK this is for a UA like browsers, not for distributed senders (100s of machines in different zones making API requests on behalf of a sender). Typically Authorization is used for that, I'm not aware of many server side APIs using regular cookies for auth. Costin --089e0122aaee2e6d8805180731ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 8, 2015 at 11:56 AM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
Trimming= aggressively.=C2=A0 Let me know if I missed something.

On 4 June 2015 at 11:57, Costin Manolache <costin@gmail.com> wrote:
> - a receiver should know for sure who sent the message, and there is z= ero
> confidentiality
> expectation here - if someone sends you a message, you should know who= sent
> it
> and be sure that it is verified. ( at least in the case of UA that use=
> webpush services that
> use sender authentication ).

This is a guarantee that the web does not provide, because it has negative privacy consequences.=C2=A0 So I guess I'm challenging your assertion about confidentiality.

Not su= re what you mean - https on the web
1. doesn't provide any co= nfidentiality on the origin ( at least if SNI is used - domain is visible t= o=C2=A0
transport provider and anyone in between).
2. r= equires that UA will verify the origin of the content it shows to the user.=

And the current internet does provide this kind o= f verification in a lot of messaging cases.
The reason I keep men= tioning SMTP is that it's the only one I know where the origin of=C2=A0=
the content can be easily forged ( with well-known consequence )= , I don't have
other good examples.

= The choice to get content only from verified sources is present on the web = as well: some services=C2=A0
only support https =C2=A0for example= ( which does verify the origin ).=C2=A0

In my vie= w webpush originated content is as important as site-originated content in = the page, having
parts of the page from unverified sources (mixed= content) is not ideal.=C2=A0


Think about it this way: If I send you a message, I might want my
identity to remain hidden from the service that you use.=C2=A0 That way I am at least partially insulated to some extent from the choices that
you have made.
=C2=A0

As = I mentioned - accepting untrusted content is a choice, as it is in SMTP. = =C2=A0


=C2=A0
This is not the same as your email server authenticating your MTA,
it's more correctly analogous to Google being able to authenticate
every email sent to a gmail account.=C2=A0 As I understand it,
authentication is an important part of anti-spam, but not the only
criterion.

Yes, because SMTP was design= ed like current webpush :-) - without consideration
for verifying= the identity of the sender of a message, instead assuming that the=C2=A0
'capability URL' that allows sending ( email address in ca= se of SMTP ) will be=C2=A0
kept confidential and only provided to= trusted senders.=C2=A0
=C2=A0

> We may allow messages from un-identifiable senders, but at=C2=A0 low Q= PS and with
> additional restrictions.

As I would expect :)

> It would be ok for webpush providers to include additional URL for ext= ra
> signup if needed, but
> for the common case it will be better to automate the process.

I have no fundamental objection to automating the provision of extra=
information, but automation requires standardizing and I'm leery of
doing more standardizing than necessary, at least initially.=C2=A0 I'd<= br> rather remove as much as possible from the critical path.


We may do this= in a separate document - the only alternative is developers having=C2=A0
to manually register to each push provider that requires verificat= ion.=C2=A0

If it turns out that only very few push= services have this requirement - it may not be a huge problem, and=C2=A0
maybe the automated registration can be just a way to improve deve= loper experience
for those providers.

= =C2=A0
> How about:
> - first time you talk with a webpush ( identified by the domain in the=
> capability subscription URL ), you need
> to grab an opaque string ( cookie/token), and use it in subsequent req= uests
> - to grab the opaque string, you need to call the subscribe URL, and i= nclude
> a set of optional
> information.
> - the initial request will use the private key of the sender to sign t= he
> request - and the public key of the
> sender will be included.

I was thinking that you sent a push, received a cookie in return and= a
link to a registration resource, or - if you like - links to automated
and/or manual forms.=C2=A0 You could replay the cookie to receive whatever<= br> benefits might be accrued to that cookie, either by establishing a
reputation as a good actor over time, or by providing extra
information.

But the UA and app on the = client will still have no way to know who sent the message.

<= /div>
Just that the sender has some good reputation - like it's don= e now in SMTP ( based on=C2=A0
IP / etc ).=C2=A0

Using a key pair - and the equivalent of a CSR - would allow the w= ebpush provider=C2=A0
to identify the public key of the sender to= the UA and app, and that would work consistently
for an app - re= gardless of which webpush provider is used.
Of course - if a webp= ush provider choses 'open relay / anonymous sender' - there would b= e=C2=A0
no 'from' field provided.
=C2=A0
<= div>=C2=A0

> I suspect any webpush service that uses sender authentication will wan= t to
> provide the authenticated
> identity of the sender to the UA and client app

It would be better for the sender to authenticate themselves with th= e
application/UA directly.


That may be possible - for example by signing the content - but still does= n't=C2=A0
address the issue of webpush providers managing the= ir network, and adds=C2=A0
more complexity on the send side.

What would be the benefit of using different ways to a= uthenticate the sender - one=C2=A0
to client app, a different one= to webpush provider ?=C2=A0

=C2=A0

> If you have any more detailed description on what cookie means in this=
> context -

RFC 6265.

AFAIK this is for a= UA like browsers, not for distributed senders (100s of machines in differe= nt=C2=A0
zones making API requests on behal= f of a sender). Typically Authorization is used for that, I'm not=C2=A0=
aware of many server side APIs using regul= ar cookies for auth.

Costin=C2=A0
--089e0122aaee2e6d8805180731ea-- From nobody Mon Jun 8 13:21:35 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658531B3301 for ; Mon, 8 Jun 2015 13:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 44uWSJNX1EV4 for ; Mon, 8 Jun 2015 13:21:33 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (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 E892A1B32FA for ; Mon, 8 Jun 2015 13:21:32 -0700 (PDT) Received: by yhak3 with SMTP id k3so40512254yha.2 for ; Mon, 08 Jun 2015 13:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=11+QfZYV3tb/a5pmZuLIquCPjsfMV0/9G3Dk4dn90oU=; b=v/kbB0jN0OJu0T3Z5Qym4QkvOv1TkdwMX/OxnPtgkDJnLcy1vyLIkIOJxJNC0FBdcQ 4Srsj0PUSP9ZvUs95cG1BWl+SoQVdCVgGTbitdnmuax0CnafumPE2gY24fwdf/qrtQLo nM7HZgbodpH5TXcrVTqsJM0aTXa7kvO55k04ny/uKdeBc8jPirr/V4NxBML7Dubq3Qnt ZRd5dQzZyssC9xsfO7Zx0ovzpoR9siX7cKTftYPPNJH9L1QTstpomyWi3MwoZbFm8wsa H/pQiEDV1MzmzYpDwHIfS5V+Gsg8msabEOBNHKSiqcrnr78d+kxiafSxzErDQJhraFhc q7FA== MIME-Version: 1.0 X-Received: by 10.170.131.201 with SMTP id x192mr20824985ykb.118.1433794892277; Mon, 08 Jun 2015 13:21:32 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 8 Jun 2015 13:21:32 -0700 (PDT) In-Reply-To: References: <556F3A8F.5090009@mozilla.com> Date: Mon, 8 Jun 2015 13:21:32 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 08 Jun 2015 20:21:34 -0000 On 8 June 2015 at 13:07, Costin Manolache wrote: > Not sure what you mean - https on the web > 1. doesn't provide any confidentiality on the origin ( at least if SNI is > used - domain is visible to > transport provider and anyone in between). > 2. requires that UA will verify the origin of the content it shows to the > user. You are talking about authenticating servers. I was thinking about clients. Thinking of the sender/application server as a client of the push service, that is. > In my view webpush originated content is as important as site-originated > content in the page, having > parts of the page from unverified sources (mixed content) is not ideal. The current model treats it no differently to data that comes across a WebRTC data channel. That might be a mistake, and I'm certainly happy to talk about better authentication. I had hoped to add that at a later stage. Either way, I wouldn't want the push service having access to origin information without the origin choosing to add that information. > But the UA and app on the client will still have no way to know who sent the > message. That's a separate - and separable - problem. > What would be the benefit of using different ways to authenticate the sender > - one > to client app, a different one to webpush provider ? Privacy for one. >> RFC 6265. > > AFAIK this is for a UA like browsers, not for distributed senders (100s of > machines in different > zones making API requests on behalf of a sender). Typically Authorization is > used for that, I'm not > aware of many server side APIs using regular cookies for auth. A shared cookie jar isn't unheard of. Though people do like to invent new authentication schemes. From nobody Mon Jun 8 23:10:43 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046301AD1D5 for ; Mon, 8 Jun 2015 23:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 38E4xkGwThOv for ; Mon, 8 Jun 2015 23:10:39 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 970F21AD357 for ; Mon, 8 Jun 2015 23:09:11 -0700 (PDT) Received: by igblz2 with SMTP id lz2so4553448igb.1 for ; Mon, 08 Jun 2015 23:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0rgE2wgQO3EDk6K4oQJdfDNDZFp5T4aodwajpOwwm5g=; b=jRaNyKvi7aUpmjI0m6ZIOYmBJ+hrsePFkFu4lLUGKIe5FClbM7bOY9BtydbCvZM3oG MEonvvQKQDIiGnFb+uVzn7Y06RyL+vbAM+U30eLi4urm61LGWPJJVIko/3L35WDKMPT2 2xPOdmJnQYBOw5HOU00wjIaD9vfNkSqAC5dl1iv9KDK3WNzmwgajBrNgMaYs8WJbIKEg bJUu3MxGwpW/0Jj3rCAtH07VCRbBjaD4fyJNG2lp22Lfy5cVWUaCZto06bgxxOeL7hhL PXJTQEYL/xwLjGSQdVz6a0igeqG9SvC0DbnFFkf9YBX2cEOO3tPy42RFOWOaoNuXPWHn XvJg== MIME-Version: 1.0 X-Received: by 10.107.9.66 with SMTP id j63mr25393370ioi.37.1433830151050; Mon, 08 Jun 2015 23:09:11 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Mon, 8 Jun 2015 23:09:10 -0700 (PDT) In-Reply-To: References: <556F3A8F.5090009@mozilla.com> Date: Mon, 8 Jun 2015 23:09:10 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113f934ed27e7505180f980c Archived-At: Cc: JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 09 Jun 2015 06:10:41 -0000 --001a113f934ed27e7505180f980c Content-Type: text/plain; charset=UTF-8 On Mon, Jun 8, 2015 at 1:21 PM, Martin Thomson wrote: > On 8 June 2015 at 13:07, Costin Manolache wrote: > > Not sure what you mean - https on the web > > 1. doesn't provide any confidentiality on the origin ( at least if SNI is > > used - domain is visible to > > transport provider and anyone in between). > > 2. requires that UA will verify the origin of the content it shows to the > > user. > > You are talking about authenticating servers. I was thinking about > clients. Thinking of the sender/application server as a client of the > push service, that is. > I'm talking about the 'application server' - typically the same with the https origin, where apps running in the UA send their subscription. I wouldn't call it 'client'. > > In my view webpush originated content is as important as site-originated > > content in the page, having > > parts of the page from unverified sources (mixed content) is not ideal. > > The current model treats it no differently to data that comes across a > WebRTC data channel. That might be a mistake, and I'm certainly happy > to talk about better authentication. I had hoped to add that at a > later stage. > I'm not very familiar with WebRTC - does it now include any part where you would get rings or messages from unidentified sources ? > > Either way, I wouldn't want the push service having access to origin > information without the origin choosing to add that information. > I don't think it is feasible to run a service where servers generating 1000s of QPS of messages are unidentifiable to the network operator. > > > But the UA and app on the client will still have no way to know who sent > the > > message. > > That's a separate - and separable - problem. > > > What would be the benefit of using different ways to authenticate the > sender > > - one > > to client app, a different one to webpush provider ? > > Privacy for one. > I think inventing a mechanism that provides privacy for servers is very hard - a webpush service can still use the IP address (which typically is registered for large senders). Many protocols require contact information for the server operator ( domain registration, certificates ). > > >> RFC 6265. > > > > AFAIK this is for a UA like browsers, not for distributed senders (100s > of > > machines in different > > zones making API requests on behalf of a sender). Typically > Authorization is > > used for that, I'm not > > aware of many server side APIs using regular cookies for auth. > > A shared cookie jar isn't unheard of. Though people do like to invent > new authentication schemes. > Actually - I never heard of any shared cookie jar that would operate well in a distributed server environment. How would Set-Cookie be implemented if you have senders in different continents, with high latency between them ? RFC 6265 defines 'distributed state management' - it is not actually defining authentication or identity schemes. HTTP defines "Authorization" header for authentication, but I would agree people like to invent new authentication schemes. Costin --001a113f934ed27e7505180f980c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 8, 2015 at 1:21 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 8 June 2015 at 13:07, Costin Manolache <costin@gmail.com> wrote:
> Not sure what you mean - https on the web
> 1. doesn't provide any confidentiality on the origin ( at least if= SNI is
> used - domain is visible to
> transport provider and anyone in between).
> 2. requires that UA will verify the origin of the content it shows to = the
> user.

You are talking about authenticating servers.=C2=A0 I was thinking a= bout
clients.=C2=A0 Thinking of the sender/application server as a client of the=
push service, that is.

I'm talking = about the 'application server' - typically the same with the=C2=A0<= /div>
https origin, where apps running in the UA send their subscriptio= n.
I wouldn't call it 'client'.



> In my view webpush originated content is as important as site-originat= ed
> content in the page, having
> parts of the page from unverified sources (mixed content) is not ideal= .

The current model treats it no differently to data that comes across= a
WebRTC data channel.=C2=A0 That might be a mistake, and I'm certainly h= appy
to talk about better authentication.=C2=A0 I had hoped to add that at a
later stage.


I'm not= very familiar with WebRTC - does it now include any part where you
would get rings or messages from unidentified sources ?=C2=A0
=
=C2=A0

Either way, I wouldn't want the push service having access to origin information without the origin choosing to add that information.

I don't think it is feasible to run a service= where servers generating 1000s of QPS=C2=A0
of messages are unid= entifiable to the network operator.

=C2=A0

> But the UA and app on the client will still have no way to know who se= nt the
> message.

That's a separate - and separable - problem.


> What would be the benefit of using different ways to authenticate the = sender
> - one
> to client app, a different one to webpush provider ?

Privacy for one.

I think inventi= ng a mechanism that provides privacy for servers is very hard - a webpush= =C2=A0
service can still use the IP address (which typically is r= egistered for large senders).=C2=A0
Many protocols require contac= t information for the server operator ( domain registration,=C2=A0
certificates ).=C2=A0

=C2=A0

>> RFC 6265.
>
> AFAIK this is for a UA like browsers, not for distributed senders (100= s of
> machines in different
> zones making API requests on behalf of a sender). Typically Authorizat= ion is
> used for that, I'm not
> aware of many server side APIs using regular cookies for auth.

A shared cookie jar isn't unheard of.=C2=A0 Though people do lik= e to invent
new authentication schemes.

Actually - I never = heard of any shared cookie jar that would operate well in a distributed
server environment. How would Set-Cookie be im= plemented if you have senders
in different = continents, with high latency between them ?=C2=A0

RFC 6265 defines 'distribu= ted state management' - it is not actually defining authentication or= =C2=A0
identity schemes. HTTP defines "= ;Authorization" header for authentication, but I would agree=C2=A0
people like to invent new authentication schem= es.

Co= stin
--001a113f934ed27e7505180f980c-- From nobody Tue Jun 9 10:18:54 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7091AC3A6 for ; Tue, 9 Jun 2015 10:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Wc4aAtk8_2d7 for ; Tue, 9 Jun 2015 10:18:51 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (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 7C6961A886F for ; Tue, 9 Jun 2015 10:18:51 -0700 (PDT) Received: by yhid80 with SMTP id d80so10105696yhi.1 for ; Tue, 09 Jun 2015 10:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DZG+qHnVRffBQXMfPFeyk38OLd6KL2Xm8paXrJHuBFc=; b=hzd+TVSqQXtXJBialC7j122Dcf30RkWUuXqwwrOqMgqREMiW8DIKIyHPzbr98dM4Mp PaKqsZg/e+CJoz7ygpXlYKe2a2OmtMULADgMN+Ytn0uGiLxio4/nclVHo0e+4oYnVetV /FuZY5atA0X+8+BddFlcfxM1mGOrK8m+oLlKYJ111AV+rARXAZejFhBBs+mXk6bfYJHE PRDOqSDXICiHob9RS+wd63BjmhfpN1AQmPFjT3hhMkfYY4CiA4xVvp2b/SnPj6zCZKoW cj46xQun65DqiBXj1S79rk8CrEEocmDvdzUKjZsFBxrI/Zu/II6dwy6UhRmnzt8ZH4RT QGKw== MIME-Version: 1.0 X-Received: by 10.129.39.205 with SMTP id n196mr23815102ywn.55.1433870330845; Tue, 09 Jun 2015 10:18:50 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 9 Jun 2015 10:18:50 -0700 (PDT) In-Reply-To: References: <556F3A8F.5090009@mozilla.com> Date: Tue, 9 Jun 2015 10:18:50 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 09 Jun 2015 17:18:53 -0000 On 8 June 2015 at 23:09, Costin Manolache wrote: > I'm talking about the 'application server' - typically the same with the > https origin, where apps running in the UA send their subscription. > I wouldn't call it 'client'. I too was talking about the application server. And it is absolutely a client in this context. > I'm not very familiar with WebRTC - does it now include any part where you > would get rings or messages from unidentified sources ? Yes. Unless you are able to use the extra authentication piece (which only Firefox currently implements). >> Either way, I wouldn't want the push service having access to origin >> information without the origin choosing to add that information. > > > I don't think it is feasible to run a service where servers generating 1000s > of QPS > of messages are unidentifiable to the network operator. Make no mistake, I have no illusions about that sort of case needing authentication. And at higher numbers, exceptions have to be made. I was expecting that to be exceptional though. > I think inventing a mechanism that provides privacy for servers is very hard I always imagined that pushes could come from anywhere, not just the machine that serves the front-end for a site. The opposite in fact, I would expect that pushes will come from elsewhere, like the back-end that is reacting to the event as it happens. If pushes are originating from (for example) somewhere in Amazon's cloud, that's going to give the server pretty good anonymity. At least without asking Amazon to trace the IP, anyway. > Actually - I never heard of any shared cookie jar that would operate well in > a distributed > server environment. How would Set-Cookie be implemented if you have senders > in different continents, with high latency between them ? Like any other piece of shared state. I wouldn't imagine that it would be any harder than sharing a key, or any other common authentication information. From nobody Tue Jun 9 11:43:48 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BF91A87C7 for ; Tue, 9 Jun 2015 11:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 mdK2xnLCs0_5 for ; Tue, 9 Jun 2015 11:43:44 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 CC23B1A011B for ; Tue, 9 Jun 2015 11:43:43 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so19090615igb.1 for ; Tue, 09 Jun 2015 11:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kYs97G4qjVVqgx4oT8K2gPQLVK7Nss0n04LDitjE1/I=; b=GA9x1mavJrFkTSZ3CZQl0wGIUzJmuPVcY3umJ73r1a92neuXwvDUDnhgwWofuFsybH Zt4yx19UUGVdVe+vMpNfcoGZnNQaBUUZ3tLmdpJHcdtP5TUqTYfSgv0Ert+ZlaK371CT OtDw8vTdG7ioNI4diwJNlFmsFs6+mPI2YpNtMHd6cek1ZQZpNWoWT4Q+BMbwlPTnWZJN AavQF0Gy9QHBmOhVXQYpUWOXD5jYM8V0WT+TOm2chH6YPWkO/FZr1Oir2RYCCd7XGkBD wiPx0Zvs4Hr4xXYpwJTM97Yi7fu4iWe/1xy5J+Gdb/jTM2kMBizs4cWmf7jBkpWcXVFO YjOg== MIME-Version: 1.0 X-Received: by 10.107.3.210 with SMTP id e79mr29106238ioi.50.1433875416102; Tue, 09 Jun 2015 11:43:36 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Tue, 9 Jun 2015 11:43:35 -0700 (PDT) In-Reply-To: References: <556F3A8F.5090009@mozilla.com> Date: Tue, 9 Jun 2015 11:43:35 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113f8ef0d4668105181a22fb Archived-At: Cc: JR Conlin , "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 09 Jun 2015 18:43:46 -0000 --001a113f8ef0d4668105181a22fb Content-Type: text/plain; charset=UTF-8 On Tue, Jun 9, 2015 at 10:18 AM, Martin Thomson wrote: > On 8 June 2015 at 23:09, Costin Manolache wrote: > > I'm talking about the 'application server' - typically the same with the > > https origin, where apps running in the UA send their subscription. > > I wouldn't call it 'client'. > > I too was talking about the application server. And it is absolutely > a client in this context. > Then let's avoid using 'client' and 'server'. How about 'origin' or "machine operated by application developer' (the app server can be operated by another organization - but it is the decision of the app developer on where he will send/share the capability URL) To be clear: if the message is sent by a user - in case of 'device to device' for example, which webpush doesn't cover - I wouldn't expect any identifiable information about the user. We'll still need to identify the sender ( so a response can be sent for example ) - and we still need this to be verified, to avoid abuse. This is a separate issue, no point talking too much about it. While both regular users and web site developer initiate client http connections to webpush service - there are still some differences between a company/organization and an end user. > > I'm not very familiar with WebRTC - does it now include any part where > you > > would get rings or messages from unidentified sources ? > > Yes. Unless you are able to use the extra authentication piece (which > only Firefox currently implements). > I'll read about it - do you have any pointers ? I see they have a section on identity - and it doesn't seem to require that UA/apps accepts un-identified messages. I can't find any definition of a new signaling mechanism - which would be the equivalent of webpush, what I found still references SIP or XMPP - which both identity and check the sender. > >> Either way, I wouldn't want the push service having access to origin > >> information without the origin choosing to add that information. > > > > > > I don't think it is feasible to run a service where servers generating > 1000s > > of QPS > > of messages are unidentifiable to the network operator. > > Make no mistake, I have no illusions about that sort of case needing > authentication. And at higher numbers, exceptions have to be made. I > was expecting that to be exceptional though. > I don't know what other webpush operators will do - my strong requirement is to have a verifiable identity for the sender - can be a random number. I would also like to see a definition of optional contact elements (email or domain) - but I think we may accept at least low QPS without contact info. Current GCM requires an dev account which requires an email - so far in the cases we had to contact the developers we didn't run into problems finding them. For very high numbers it's probably less important - there are more channels of communication with large developers, and they're more likely to contact the webpush service first. Which reminds me that we should also define some link to a webpush contact info. > > I think inventing a mechanism that provides privacy for servers is very > hard > > I always imagined that pushes could come from anywhere, not just the > machine that serves the front-end for a site. The opposite in fact, I > would expect that pushes will come from elsewhere, like the back-end > that is reacting to the event as it happens. If pushes are originating > from (for example) somewhere in Amazon's cloud, that's going to give > the server pretty good anonymity. At least without asking Amazon to > trace the IP, anyway. > See above - pushes could come from any machine operated or delegated by the organization controlling the 'origin', not only the frontend. Requests 'coming from anywhere' are the root problem I'm trying to solve :-), if the capability URL gets out of machines operated by the developer, like it happens to email addresses. > > > Actually - I never heard of any shared cookie jar that would operate > well in > > a distributed > > server environment. How would Set-Cookie be implemented if you have > senders > > in different continents, with high latency between them ? > > Like any other piece of shared state. I wouldn't imagine that it > would be any harder than sharing a key, or any other common > authentication information. > In many authentication schemes each machine ( or region ) can get or generate it's own tokens - without requiring consistency or synchronization with other regions. And since you mentioned we don't want to invent new authentication - cookies are not typically an authentication mechanism ( they are just used to track sessions that are used by various auth schemes ). Costin --001a113f8ef0d4668105181a22fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 9, 2015 at 10:18 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 8 June 2015 at 23:09, Costin Manolache <costin@gmail.com> wrote:
> I'm talking about the 'application server' - typically the= same with the
> https origin, where apps running in the UA send their subscription. > I wouldn't call it 'client'.

I too was talking about the application server.=C2=A0 And it is abso= lutely
a client in this context.

Then let'= s avoid using 'client' and 'server'.=C2=A0

How about 'origin' or "machine operated by applicatio= n developer' (the app server can be operated by=C2=A0
another= organization - but it is the decision of the app developer on where he wil= l send/share the capability
URL)=C2=A0

T= o be clear: if the message is sent by a user - in case of 'device to de= vice' for example, which webpush
doesn't cover - I wouldn= 't expect any identifiable information about the user. We'll still = need to=C2=A0
identify the sender ( so a response can be sent for= example ) - and we still need this to be verified, to avoid=C2=A0
abuse. This is a separate issue, no point talking too much about it.=C2= =A0

While both regular users and web site develope= r initiate client http connections to webpush service -=C2=A0
the= re are still some differences between a company/organization and an end use= r.=C2=A0


> I'm not very familiar with WebRTC - does it now include any part w= here you
> would get rings or messages from unidentified sources ?

Yes.=C2=A0 Unless you are able to use the extra authentication piece= (which
only Firefox currently implements).

I&#= 39;ll read about it - do you have any pointers ? I see they have a section = on identity - and it=C2=A0
doesn't seem to require that UA/ap= ps accepts un-identified messages.=C2=A0

I can'= ;t find any definition of a new signaling mechanism - which would be the eq= uivalent of=C2=A0
webpush, what I found still references SIP or X= MPP - which both identity and check the sender.


>> Either way, I wouldn't want the push service having access to = origin
>> information without the origin choosing to add that information. >
>
> I don't think it is feasible to run a service where servers genera= ting 1000s
> of QPS
> of messages are unidentifiable to the network operator.

Make no mistake, I have no illusions about that sort of case needing=
authentication.=C2=A0 And at higher numbers, exceptions have to be made.=C2= =A0 I
was expecting that to be exceptional though.

I don't know what other webpush operators will do - my strong req= uirement=C2=A0
is to have a verifiable identity for the sender - = can be a random number.=C2=A0
I would also like to see a definiti= on of optional contact elements (email or domain)
- but I think w= e may accept at least low QPS without contact info.=C2=A0
Current= GCM requires an dev account which requires an email - so far in the cases= =C2=A0
we had to contact the developers we didn't run into pr= oblems finding them.=C2=A0

For very high numbers i= t's probably less important - there are more
channels of comm= unication with large developers, and they're more likely=C2=A0
to contact the webpush service first. Which reminds me that we should als= o=C2=A0
define some link to a webpush contact info.


> I think inventing a mechanism that provides privacy for servers is ver= y hard

I always imagined that pushes could come from anywhere, not just the=
machine that serves the front-end for a site. The opposite in fact, I
would expect that pushes will come from elsewhere, like the back-end
that is reacting to the event as it happens. If pushes are originating
from (for example) somewhere in Amazon's cloud, that's going to giv= e
the server pretty good anonymity. At least without asking Amazon to
trace the IP, anyway.

See above - pushe= s could come from any machine operated or delegated=C2=A0
by the = organization controlling the 'origin', not only the frontend.=C2=A0=

Requests 'coming from anywhere' are the r= oot problem I'm trying to solve :-),=C2=A0
if the capability = URL gets out of machines operated by the developer, like it
happe= ns to email addresses.

=C2=A0

> Actually - I never heard of any shared cookie jar that would operate w= ell in
> a distributed
> server environment. How would Set-Cookie be implemented if you have se= nders
> in different continents, with high latency between them ?

Like any other piece of shared state.=C2=A0 I wouldn't imagine t= hat it
would be any harder than sharing a key, or any other common
authentication information.

In many authenticat= ion schemes each machine ( or region ) can get or generate it's own
tokens - without requiring consistency or sync= hronization with other regions.=C2=A0
And s= ince you mentioned we don't want to invent new authentication - cookies= are not=C2=A0
typically an authentication = mechanism ( they are just used to track sessions that are used by
various auth schemes ).

Costin
--001a113f8ef0d4668105181a22fb-- From nobody Wed Jun 10 12:25:17 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A73E1A8827 for ; Wed, 10 Jun 2015 12:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=no 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 RDcO60FHwhx0 for ; Wed, 10 Jun 2015 12:25:13 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (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 95C861A87C7 for ; Wed, 10 Jun 2015 12:25:12 -0700 (PDT) Received: by wibut5 with SMTP id ut5so57829546wib.1 for ; Wed, 10 Jun 2015 12:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=UG8044O5Evp03kifitnrjBMDhMvJT6Wn6XPp/9d9cCo=; b=hEigGc/3+eY8mgDs4XKvd2u727MtTYFw30fDsNqRR6UwHgHFaD+VyDr04El1nSIV2o 3TTWhRx6YPrjO+E9VMYVHiW2a/bAVlDGn6MbUgYTfWr+GxQeaM8SyHu2F23xWimPbjit R4GwVqY2MCLH8v+J/ORbtILtf+ZWMnOU17hhKKunLLCZgVKrK07rWUEMJhazuiru3AYf /NIWkxLYbahjdiPshMmpyR7L9XS0+54c03ARvBI8Oq2Zczh2JeZmsAMS1nU0emwts9uj qi//aPUC0G03Ykc5Ryp5BRAsYtFTDS4gwkFyV/J/gxQ8HfowRIfoV5Te+OLGUTdSjrb9 ffug== X-Received: by 10.180.77.193 with SMTP id u1mr21708137wiw.50.1433964311218; Wed, 10 Jun 2015 12:25:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.17.170 with HTTP; Wed, 10 Jun 2015 12:24:50 -0700 (PDT) From: Paul Em Date: Wed, 10 Jun 2015 21:24:50 +0200 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=f46d043d6759640d2605182ed55b Archived-At: Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 19:25:15 -0000 --f46d043d6759640d2605182ed55b Content-Type: text/plain; charset=UTF-8 Now that I read more about SMTP techniques I also think we could use parts of this approach, but in a slightly different way. By checking SPF records SMTP checks if the sender is allowed to send messages. We could do the same, but instead of using DNS records all allowed senders could be specified in, for example, the manifest.json, similar to CORS. The push service can, but does not have to, check if the sender is valid and use the ip or hostname of the sender as unique sender. Of course this would only work if the sender uses https and has a valid signed cert to ensure the right sender. With this approach a compromised server would not have to fear that someone else can use the compromised urls to spam. I am not sure if and how this would work with the example of amazon cloud though. Further comments below. 2015-06-09 20:43 GMT+02:00 Costin Manolache : > On Tue, Jun 9, 2015 at 10:18 AM, Martin Thomson > wrote: > >> On 8 June 2015 at 23:09, Costin Manolache wrote: >> > I'm talking about the 'application server' - typically the same with the >> > https origin, where apps running in the UA send their subscription. >> > I wouldn't call it 'client'. >> >> I too was talking about the application server. And it is absolutely >> a client in this context. >> > > Then let's avoid using 'client' and 'server'. > > How about 'origin' or "machine operated by application developer' (the app > server can be operated by > another organization - but it is the decision of the app developer on > where he will send/share the capability > URL) > > To be clear: if the message is sent by a user - in case of 'device to > device' for example, which webpush > doesn't cover - I wouldn't expect any identifiable information about the > user. We'll still need to > identify the sender ( so a response can be sent for example ) - and we > still need this to be verified, to avoid > abuse. This is a separate issue, no point talking too much about it. > > While both regular users and web site developer initiate client http > connections to webpush service - > there are still some differences between a company/organization and an end > user. > > >> > I'm not very familiar with WebRTC - does it now include any part where >> you >> > would get rings or messages from unidentified sources ? >> >> Yes. Unless you are able to use the extra authentication piece (which >> only Firefox currently implements). >> > > I'll read about it - do you have any pointers ? I see they have a section > on identity - and it > doesn't seem to require that UA/apps accepts un-identified messages. > > I can't find any definition of a new signaling mechanism - which would be > the equivalent of > webpush, what I found still references SIP or XMPP - which both identity > and check the sender. > > >> >> Either way, I wouldn't want the push service having access to origin >> >> information without the origin choosing to add that information. >> > >> > >> > I don't think it is feasible to run a service where servers generating >> 1000s >> > of QPS >> > of messages are unidentifiable to the network operator. >> >> Make no mistake, I have no illusions about that sort of case needing >> authentication. And at higher numbers, exceptions have to be made. I >> was expecting that to be exceptional though. >> > > I don't know what other webpush operators will do - my strong requirement > is to have a verifiable identity for the sender - can be a random number. > I would also like to see a definition of optional contact elements (email > or domain) > - but I think we may accept at least low QPS without contact info. > Current GCM requires an dev account which requires an email - so far in > the cases > we had to contact the developers we didn't run into problems finding them. > > For very high numbers it's probably less important - there are more > channels of communication with large developers, and they're more likely > to contact the webpush service first. Which reminds me that we should also > define some link to a webpush contact info. > > > >> > I think inventing a mechanism that provides privacy for servers is very >> hard >> >> I always imagined that pushes could come from anywhere, not just the >> machine that serves the front-end for a site. The opposite in fact, I >> would expect that pushes will come from elsewhere, like the back-end >> that is reacting to the event as it happens. If pushes are originating >> from (for example) somewhere in Amazon's cloud, that's going to give >> the server pretty good anonymity. At least without asking Amazon to >> trace the IP, anyway. >> > > See above - pushes could come from any machine operated or delegated > by the organization controlling the 'origin', not only the frontend. > > Requests 'coming from anywhere' are the root problem I'm trying to solve > :-), > if the capability URL gets out of machines operated by the developer, like > it > happens to email addresses. > > The approach I described above would solve the problem of having requests 'coming from anywhere', but of course the origin would be given away to the push service. Martin wrote before that he wouldn't want the push service having access to origin information. I don't fully understand the problem here - doesn't the push service see the origin regardless if I want it or not? What do I miss here? And if not, how would this be a problem? > > >> >> > Actually - I never heard of any shared cookie jar that would operate >> well in >> > a distributed >> > server environment. How would Set-Cookie be implemented if you have >> senders >> > in different continents, with high latency between them ? >> >> Like any other piece of shared state. I wouldn't imagine that it >> would be any harder than sharing a key, or any other common >> authentication information. >> > > In many authentication schemes each machine ( or region ) can get or > generate it's own > tokens - without requiring consistency or synchronization with other > regions. > And since you mentioned we don't want to invent new authentication - > cookies are not > typically an authentication mechanism ( they are just used to track > sessions that are used by > various auth schemes ). > > Costin > > Paul --f46d043d6759640d2605182ed55b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Now that I read more about SMTP techniques I also thi= nk we could use parts of this approach, but in a slightly different way.=C2= =A0
By checking SPF records SMTP checks if the sender is allowed = to send messages.=C2=A0
We could do the same, but instead of usin= g DNS records all allowed senders could be specified in, for example, the m= anifest.json, similar to CORS.
The push service can, but does not= have to, check if the sender is valid and use the ip or hostname of the se= nder as=C2=A0
unique sender.

Of cour= se this would only work if the sender uses https and has a valid signed cer= t to ensure the right sender.
With this approach a compromised se= rver would not have to fear that someone else can use the compromised urls = to spam.

I am not sure if and how this would work = with the example of amazon cloud though.

Further c= omments below.


2015-06-09 20:43 GMT+02:00 Costin Manolache <costin@gmail.com>= ;:
On Tue, Jun 9, 201= 5 at 10:18 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 8 June 2015 at 23:09,= Costin Manolache <costin@gmail.com> wrote:
> I'm talking about the 'application server' - typically the= same with the
> https origin, where apps running in the UA send their subscription. > I wouldn't call it 'client'.

I too was talking about the application server.=C2=A0 And it is abso= lutely
a client in this context.

Then l= et's avoid using 'client' and 'server'.=C2=A0

How about 'origin' or "machine operated by app= lication developer' (the app server can be operated by=C2=A0
= another organization - but it is the decision of the app developer on where= he will send/share the capability
URL)=C2=A0

To be clear: if the message is sent by a user - in case of 'devic= e to device' for example, which webpush
doesn't cover - I= wouldn't expect any identifiable information about the user. We'll= still need to=C2=A0
identify the sender ( so a response can be s= ent for example ) - and we still need this to be verified, to avoid=C2=A0
abuse. This is a separate issue, no point talking too much about i= t.=C2=A0

While both regular users and web site dev= eloper initiate client http connections to webpush service -=C2=A0
there are still some differences between a company/organization and an en= d user.=C2=A0


> I'm not very familiar with WebRTC - does it now include any part w= here you
> would get rings or messages from unidentified sources ?

Yes.=C2=A0 Unless you are able to use the extra authentication piece= (which
only Firefox currently implements).

<= div>I'll read about it - do you have any pointers ? I see they have a s= ection on identity - and it=C2=A0
doesn't seem to require tha= t UA/apps accepts un-identified messages.=C2=A0

I = can't find any definition of a new signaling mechanism - which would be= the equivalent of=C2=A0
webpush, what I found still references S= IP or XMPP - which both identity and check the sender.


>> Either way, I wouldn't want the push service having access to = origin
>> information without the origin choosing to add that information. >
>
> I don't think it is feasible to run a service where servers genera= ting 1000s
> of QPS
> of messages are unidentifiable to the network operator.

Make no mistake, I have no illusions about that sort of case needing=
authentication.=C2=A0 And at higher numbers, exceptions have to be made.=C2= =A0 I
was expecting that to be exceptional though.

I don't know what other webpush operators will do - my str= ong requirement=C2=A0
is to have a verifiable identity for the se= nder - can be a random number.=C2=A0
I would also like to see a d= efinition of optional contact elements (email or domain)
- but I = think we may accept at least low QPS without contact info.=C2=A0
= Current GCM requires an dev account which requires an email - so far in the= cases=C2=A0
we had to contact the developers we didn't run i= nto problems finding them.=C2=A0

For very high num= bers it's probably less important - there are more
channels o= f communication with large developers, and they're more likely=C2=A0
to contact the webpush service first. Which reminds me that we shou= ld also=C2=A0
define some link to a webpush contact info.



> I think inventing a mechanism that provides privacy for servers is ver= y hard

I always imagined that pushes could come from anywhere, not just the=
machine that serves the front-end for a site. The opposite in fact, I
would expect that pushes will come from elsewhere, like the back-end
that is reacting to the event as it happens. If pushes are originating
from (for example) somewhere in Amazon's cloud, that's going to giv= e
the server pretty good anonymity. At least without asking Amazon to
trace the IP, anyway.

See above = - pushes could come from any machine operated or delegated=C2=A0
= by the organization controlling the 'origin', not only the frontend= .=C2=A0

Requests 'coming from anywhere' ar= e the root problem I'm trying to solve :-),=C2=A0
if the capa= bility URL gets out of machines operated by the developer, like it
happens to email addresses.

<= /div>

The approach I described = above would solve the problem of having requests 'coming from anywhere&= #39;,
but of course the origin would be given away to the push se= rvice.=C2=A0
Martin wrote before that he wouldn't want the pu= sh service having access to origin information.
I don't fully= understand the problem here - doesn't the push service see the origin= =C2=A0
regardless if I want it or not? What do I miss here? And i= f not, how would this be a problem?

=C2=A0
=C2=A0

> Actually - I never heard of any shared cookie jar that would operate w= ell in
> a distributed
> server environment. How would Set-Cookie be implemented if you have se= nders
> in different continents, with high latency between them ?

Like any other piece of shared state.=C2=A0 I wouldn't imagine t= hat it
would be any harder than sharing a key, or any other common
authentication information.

In many auth= entication schemes each machine ( or region ) can get or generate it's = own
tokens - without requiring consistency = or synchronization with other regions.=C2=A0
And since you mentioned we don't want to invent new authentication - = cookies are not=C2=A0
typically an authenti= cation mechanism ( they are just used to track sessions that are used by
various auth schemes ).

Costin


Paul=C2=A0

--f46d043d6759640d2605182ed55b-- From nobody Wed Jun 10 12:51:21 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268211A88C5 for ; Wed, 10 Jun 2015 12:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=no 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 t6IzJUbUyWfl for ; Wed, 10 Jun 2015 12:51:19 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 34CC51A8913 for ; Wed, 10 Jun 2015 12:51:18 -0700 (PDT) Received: by ykfl8 with SMTP id l8so28139298ykf.1 for ; Wed, 10 Jun 2015 12:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uwj1fybRe90qz0U9iVkmAZwtoSEJLhwqwPab4jcWDFc=; b=Wd+XTZk505lmW/1zkpWcRaQo/zejQg9b0uIb18qCBBIIGuWsLLJzrWCodHM+V9ODzv sQ99sFw26bvMswbUBLv7vLJXcxjpU69AECXJ7+flBkylyjPwSgS1KdpGS9j1vVmZzDRc muV7kfq1jNo67v+MnXQzoJGnJxI3uaYGaQiGD2wi3NxUPYCTsJKP4/y023CQcOpFJHYj yK0aHZqCwjSLNw3q2sqzmVDYJiwnTvI+PKz1tKeggYSAj7svfzTNFSCaxk/xGrLcMH2O AYvD86yiwJEwcXAAQr4L2mEWNPMJ4T9+94NGTkaz9iEm8UDLgXa4NqQv9SAlO8/4Ce1R 8dcA== MIME-Version: 1.0 X-Received: by 10.129.39.205 with SMTP id n196mr6391165ywn.55.1433965877588; Wed, 10 Jun 2015 12:51:17 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 10 Jun 2015 12:51:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jun 2015 12:51:17 -0700 Message-ID: From: Martin Thomson To: Paul Em Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 19:51:20 -0000 On 10 June 2015 at 12:24, Paul Em wrote: > Now that I read more about SMTP techniques I also think we could use parts > of this approach, but in a slightly different way. > By checking SPF records SMTP checks if the sender is allowed to send > messages. > We could do the same, but instead of using DNS records all allowed senders > could be specified in, for example, the manifest.json, similar to CORS. > The push service can, but does not have to, check if the sender is valid and > use the ip or hostname of the sender as > unique sender. It might make a little sense to uplevel the discussion here. Recall that we're actually in a situation where an application is talking to itself. The analogues with SMTP aren't all applicable in this context if you consider that the destination address is essentially secret. > The approach I described above would solve the problem of having requests > 'coming from anywhere', > but of course the origin would be given away to the push service. > Martin wrote before that he wouldn't want the push service having access to > origin information. > I don't fully understand the problem here - doesn't the push service see the > origin > regardless if I want it or not? What do I miss here? And if not, how would > this be a problem? The push service doesn't need to know the origin. It might *want* to know the origin for all the reasons Costin has articulated, and it might make sense to provide the origin in some cases for those reasons. But fundamentally the push endpoint is all the information it needs to deliver the message to the right place. That doesn't mean we can't add extra capabilities. But I'd prefer to at least reach the point where we have something that minimally works first. From nobody Wed Jun 10 13:31:31 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032021AC408 for ; Wed, 10 Jun 2015 13:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=no 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 KjEmuVS1Eggr for ; Wed, 10 Jun 2015 13:31:26 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (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 AB55F1AC3F7 for ; Wed, 10 Jun 2015 13:31:21 -0700 (PDT) Received: by wibut5 with SMTP id ut5so58920276wib.1 for ; Wed, 10 Jun 2015 13:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dwBMaG+etjUE0DfW6HM3jN5RaWcvD6dwEYizJ1qVMsM=; b=GgyLqUWnejgnYLZ//Cpg1sOB5+I8wRRG6TOuCDdP6t2VNUrWXrT1QU87rDOsBUrEki Z9FSgI0hp2+ddPywkQWyjUjttBJ7R2Tz8cB909X9pm2xgGJkPiDIxMLIi7n11QHLPLdw mDLeVtylNkED65iu84nVvuxqYEeaeJVUf2d9hsLQJTjKsrqytbmaJ+8j1TU9AA52bEyh iiA4jECRuqO7xUOLZgnpslMzwhWNsa9vpwPlNVc08Zxh683eV04uqjE6LSw/Eomd9ziZ X7bVWxkX1AY9iIn3kwUNF4bfZrGm9HNTMTNFwdZrXETPPlxaM43kX/BcfG/74i7iPENp dPmQ== X-Received: by 10.194.143.4 with SMTP id sa4mr9695974wjb.22.1433968279489; Wed, 10 Jun 2015 13:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.17.170 with HTTP; Wed, 10 Jun 2015 13:30:59 -0700 (PDT) In-Reply-To: References: From: Paul Em Date: Wed, 10 Jun 2015 22:30:59 +0200 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0112c4f8eb13bf05182fc104 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 20:31:28 -0000 --089e0112c4f8eb13bf05182fc104 Content-Type: text/plain; charset=UTF-8 2015-06-10 21:51 GMT+02:00 Martin Thomson : > On 10 June 2015 at 12:24, Paul Em wrote: > > Now that I read more about SMTP techniques I also think we could use > parts > > of this approach, but in a slightly different way. > > By checking SPF records SMTP checks if the sender is allowed to send > > messages. > > We could do the same, but instead of using DNS records all allowed > senders > > could be specified in, for example, the manifest.json, similar to CORS. > > The push service can, but does not have to, check if the sender is valid > and > > use the ip or hostname of the sender as > > unique sender. > > It might make a little sense to uplevel the discussion here. Recall > that we're actually in a situation where an application is talking to > itself. > > The analogues with SMTP aren't all applicable in this context if you > consider that the destination address is essentially secret. > Apologies if I am completely wrong here and i will try to explain it a bit better, otherwise I will stop writting nonesense, i promise ;-) Yes the app is talking with itself in the end, but when putting the information about valid senders in the manfiest this information can be sent to the push service when subscribing and stored there. So the push service knows all allowed senders for a registration and can check this if needed. The destination address (you mean the endpoint, right?) can be "secret", but you still talk to same one from view of UA and from the "machine operated by application developer'. > > > The approach I described above would solve the problem of having requests > > 'coming from anywhere', > > but of course the origin would be given away to the push service. > > Martin wrote before that he wouldn't want the push service having access > to > > origin information. > > I don't fully understand the problem here - doesn't the push service see > the > > origin > > regardless if I want it or not? What do I miss here? And if not, how > would > > this be a problem? > > The push service doesn't need to know the origin. It might *want* to > know the origin for all the reasons Costin has articulated, and it > might make sense to provide the origin in some cases for those > reasons. But fundamentally the push endpoint is all the information > it needs to deliver the message to the right place. > > That doesn't mean we can't add extra capabilities. But I'd prefer to > at least reach the point where we have something that minimally works > first. > --089e0112c4f8eb13bf05182fc104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2015-06-10 21:51 GMT+02:00 Martin Thomson <martin.thomson@gmail= .com>:
On 10 June 2015 at 12:24, Pa= ul Em <paul3m@gmai= l.com> wrote:
> Now that I read more about SMTP techniques I also think we could use p= arts
> of this approach, but in a slightly different way.
> By checking SPF records SMTP checks if the sender is allowed to send > messages.
> We could do the same, but instead of using DNS records all allowed sen= ders
> could be specified in, for example, the manifest.json, similar to CORS= .
> The push service can, but does not have to, check if the sender is val= id and
> use the ip or hostname of the sender as
> unique sender.

It might make a little sense to uplevel the discussion here.=C2=A0 R= ecall
that we're actually in a situation where an application is talking to itself.

The analogues with SMTP aren't all applicable in this context if you consider that the destination address is essentially secret.

Apologies if I am completely wrong here and i will tr= y to explain it a bit better, otherwise=C2=A0
I will stop writtin= g nonesense, i promise ;-)

Yes the app is talking = with itself in the end, but when putting the information about valid sender= s
in the manfiest this information can be sent to the push servic= e when subscribing and stored there.
So the push service knows al= l allowed senders for a registration and can check this if=C2=A0
= needed.=C2=A0

The destination address (you mean th= e endpoint, right?) can be "secret", but you still talk
to same one from view of UA and from the=C2=A0"machine operated by application developer'.

=C2=A0

> The approach I described above would solve the problem of having reque= sts
> 'coming from anywhere',
> but of course the origin would be given away to the push service.
> Martin wrote before that he wouldn't want the push service having = access to
> origin information.
> I don't fully understand the problem here - doesn't the push s= ervice see the
> origin
> regardless if I want it or not? What do I miss here? And if not, how w= ould
> this be a problem?

The push service doesn't need to know the origin.=C2=A0 It might= *want* to
know the origin for all the reasons Costin has articulated, and it
might make sense to provide the origin in some cases for those
reasons.=C2=A0 But fundamentally the push endpoint is all the information it needs to deliver the message to the right place.

That doesn't mean we can't add extra capabilities.=C2=A0 But I'= d prefer to
at least reach the point where we have something that minimally works
first.

--089e0112c4f8eb13bf05182fc104-- From nobody Wed Jun 10 13:51:12 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1719D1ACE61 for ; Wed, 10 Jun 2015 13:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 eWrG9CSve89c for ; Wed, 10 Jun 2015 13:51:09 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (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 B9B141ACD61 for ; Wed, 10 Jun 2015 13:51:09 -0700 (PDT) Received: by yhan67 with SMTP id n67so25696362yha.3 for ; Wed, 10 Jun 2015 13:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jfuYxdiM5dhtoM0YNmJBV75+vST3xCGFBtFuSknih4g=; b=JlXlFlDz3bwSu8Xc58M3nhejTY1e9DFGF2NfHFT91EXTjqVy75IG8O9hfCw5n+n5aw nIYuzvK6+hw/TWYQfco3NNUd4pWzpvWYIKUqSJOaJik8XcxzAufSlRMTzBfhDE/T6vtw 1uNxihiW/Z89MoGyYiBamudJQo3TmtRCFaMDbc686mUdNjNgDbzM5uX3nq3YXdnQv0Tz KNctzyhjtyJ0GUMrlUpJ4tGOBByBHbw1PybxYMvYGUE6WZL3JvDDjINFHICebD8t5pwR MxJ7kN79R2NZ6LttRBtHcEtjrfyQYr7lzLoZC1Ia8xwXVgUQUk6Ub0ngLNvKOK2Nl3Ay Nr2Q== MIME-Version: 1.0 X-Received: by 10.170.90.5 with SMTP id h5mr6805802yka.26.1433969469119; Wed, 10 Jun 2015 13:51:09 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 10 Jun 2015 13:51:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jun 2015 13:51:09 -0700 Message-ID: From: Martin Thomson To: Paul Em Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Authenticating senders X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2015 20:51:11 -0000 On 10 June 2015 at 13:30, Paul Em wrote: > Apologies if I am completely wrong here and i will try to explain it a bit > better, otherwise > I will stop writting nonesense, i promise ;-) I'm not reading nonsense, but you can rely on me telling you if I do. > Yes the app is talking with itself in the end, but when putting the > information about valid senders > in the manfiest this information can be sent to the push service when > subscribing and stored there. > So the push service knows all allowed senders for a registration and can > check this if > needed. I'd rather not rely on manifests for this. If we need this, we can put it in the API. We would also need to have the browser tell the push service about these constraints at the same time. Any reluctance there on my behalf is reluctance to do all that work. Not because specifying it is hard, but because it raises the bar for implementations. > The destination address (you mean the endpoint, right?) can be "secret", but > you still talk > to same one from view of UA and from the "machine operated by application > developer'. Only the "mobad" sends to the endpoint. From nobody Thu Jun 11 01:39:15 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318E51A8837 for ; Thu, 11 Jun 2015 01:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1n4qxR0Kx0JN for ; Thu, 11 Jun 2015 01:39:11 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 DF7361A064C for ; Thu, 11 Jun 2015 01:39:10 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so50600329igb.0 for ; Thu, 11 Jun 2015 01:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=qNJ9eCJkXPMw+DC+3xpcz3pJRMgqlBQo7A1I0Euwx4M=; b=AJeEuFuhsnwmtnjDkIv7waNw8N4VLeRcOsVAwsN+NLfxbiWjbTgQ1CyujQ0UhXEXIP 94SJvdAwHjN6j4SQ8e7/JknJKZKUUF/eEtzuQu4lsOhsFaxlXEguL/ardNIsn28EaOuV VvFSU0hkTp+b02hWAbxhqI4HVieOB7PUvTL9mcSIN/eKKyXFLHvss3Q7eh/D9SH1yVTf ckRprmZrs4VGtxXV6kmsG5zC8ymdJzoEnR72zX41vW8iPQz94tVJaXJZoK/47zPquuMn +2OaQznv8V/hqiMjM8i9VQUJm/B/SeavdRPJP8uA198fPvbvkfBtsoovvXvlgTVMdMZl tN7g== X-Received: by 10.42.178.7 with SMTP id bk7mr9413788icb.79.1434011950296; Thu, 11 Jun 2015 01:39:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.112.131 with HTTP; Thu, 11 Jun 2015 01:38:29 -0700 (PDT) From: Idel Pivnitskiy Date: Thu, 11 Jun 2015 11:38:29 +0300 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e8f52e6b4e9051839ec34 Archived-At: Cc: AeroGear Developer Mailing List Subject: [Webpush] Question about next version of draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 11 Jun 2015 08:39:13 -0000 --90e6ba6e8f52e6b4e9051839ec34 Content-Type: text/plain; charset=UTF-8 Hello Martin, Elio and Brian, Thanks for the great work on WebPush protocol! I'm a student of NRNU MEPhI and this year I take part in GSoC [1] with AeroGear team [2]. I'm working on experimental project, which is called "Aerogear WebPush Server" [3]. I'm watching for updates of WebPush protocol and discussions in this mailing list and I will update our project to support the latest version. I want to know about your current plans, when do you plan to release a new draft? Maybe you know an approximate month? Best regards, Idel Pivnitskiy [1] https://www.google-melange.com/gsoc/homepage/google/gsoc2015 [2] https://aerogear.org/ [3] https://github.com/aerogear/aerogear-webpush-server -- E-mail: Idel.Pivnitskiy@gmail.com Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy --90e6ba6e8f52e6b4e9051839ec34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Martin, Elio and Brian,

Thanks fo= r the great work on WebPush protocol!

I'm= a student of NRNU MEPhI and this year I take part in GSoC [1] with AeroGea= r team [2]. I'm working on experimental project, which is called "= Aerogear WebPush Server" [3].
I'm watching for updates o= f WebPush protocol and discussions in this mailing list and I will update o= ur project to support the latest version.
I want to know about yo= ur current plans, when do you plan to release a new draft? Maybe you know a= n approximate month?
--90e6ba6e8f52e6b4e9051839ec34-- From nobody Sat Jun 13 02:49:36 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7E11B2F9F for ; Sat, 13 Jun 2015 02:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 6ulDX6qYJktx for ; Sat, 13 Jun 2015 02:49:33 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 E4FDA1B2F9E for ; Sat, 13 Jun 2015 02:49:27 -0700 (PDT) Received: by igbzc4 with SMTP id zc4so25823566igb.0 for ; Sat, 13 Jun 2015 02:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bTj4Iv+2ujCQbESELXmVVnnkpx4Ii0m3leWzWZKD3PM=; b=OqWfvZQW8Y/QOAPTnI+Pr0i5NToXlUKlgChgT+N4wG+jFRN/4wbMlBgioNxh/Z+RhL PRLxWl5PKn315IDAfD2YBPr4OSDb9VFv3Q+T6QtzmULkSTyGblJxN25tJAYYliK8xX3C gUqdfNw/AekVzW7m0mEkaT3W1PC6B9DTMD0VliM7wYxtUX4jo8Uoc+qQMIvGW2aDHK0W H96JxPOJksibP70oovmN8bQDyoj+7wDoVPsYHI37xkSfZn/PZh/tSBHMyE7LcgqN3Sf+ gzmW7BmnuAIit5bNmHoduuXvbvpCCjDc8CsorupcVv3nI7aV5Y/6JoePz9s5/tCGQ4vb UZUw== X-Received: by 10.42.178.7 with SMTP id bk7mr20624937icb.79.1434188967404; Sat, 13 Jun 2015 02:49:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.112.131 with HTTP; Sat, 13 Jun 2015 02:48:47 -0700 (PDT) In-Reply-To: References: From: Idel Pivnitskiy Date: Sat, 13 Jun 2015 12:48:47 +0300 Message-ID: To: AeroGear Developer Mailing List Content-Type: multipart/alternative; boundary=90e6ba6e8f52f16c6d05186323d9 Archived-At: Cc: webpush@ietf.org Subject: Re: [Webpush] [aerogear-dev] Question about next version of draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 13 Jun 2015 09:49:35 -0000 --90e6ba6e8f52f16c6d05186323d9 Content-Type: text/plain; charset=UTF-8 Hi Matthias, Good news about WebPush support in FF! Yes, but after releasing this draft, there was some discussions in the WebPush mailing list and new opened PRs on github. So, I want to know only about plans to release the next draft. Thanks, Idel Pivnitskiy -- E-mail: Idel.Pivnitskiy@gmail.com Twitter: @idelpivnitskiy GitHub: @idelpivnitskiy 2015-06-12 17:41 GMT+03:00 Matthias Wessendorf : > Idel, > > on the Mozilla #push channel, I got pointed to this newer draft: > https://unicorn-wg.github.io/webpush-protocol/ > > On that channel kitcambridge told me that the nightly FF is doing webpush, > instead of simplepush, when setting 'dom.push.serverURL, to an HTTPs > endpoint, following the above mentioned draft. > > -Matthias > > > On Thu, Jun 11, 2015 at 10:38 AM, Idel Pivnitskiy < > idel.pivnitskiy@gmail.com> wrote: > >> Hello Martin, Elio and Brian, >> >> Thanks for the great work on WebPush protocol! >> >> I'm a student of NRNU MEPhI and this year I take part in GSoC [1] with >> AeroGear team [2]. I'm working on experimental project, which is called >> "Aerogear WebPush Server" [3]. >> I'm watching for updates of WebPush protocol and discussions in this >> mailing list and I will update our project to support the latest version. >> I want to know about your current plans, when do you plan to release a >> new draft? Maybe you know an approximate month? >> >> Best regards, >> Idel Pivnitskiy >> >> [1] https://www.google-melange.com/gsoc/homepage/google/gsoc2015 >> [2] https://aerogear.org/ >> [3] https://github.com/aerogear/aerogear-webpush-server >> -- >> E-mail: Idel.Pivnitskiy@gmail.com >> Twitter: @idelpivnitskiy >> GitHub: @idelpivnitskiy >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > --90e6ba6e8f52f16c6d05186323d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Matthias,

Good news about WebPu= sh support in FF!

Yes, but after releasing this dr= aft, there was some discussions in the WebPush mailing list and new opened = PRs on github. So, I want to know only about plans to release the next draf= t.

Thanks,
Idel Pivnitskiy
--=C2=A0

2015-06-12 17:41 GMT+03:00 Matthias Wessendorf <matzew@apach= e.org>:
Idel,

on the Mozilla #push channel, I got pointed to this newer draft:
On that channel kitcambridge told me that the nightly FF i= s doing webpush, instead of simplepush, when setting 'dom.push.serverUR= L, to an HTTPs endpoint, following the above mentioned draft.
-Matthias

=
On Thu, Jun 11, 2015 at 10:38 AM, = Idel Pivnitskiy <idel.pivnitskiy@gmail.com> wrote:
Hello Martin, Eli= o and Brian,

Thanks for the great work on WebPush protoc= ol!

I'm a student of NRNU MEPhI and this = year I take part in GSoC [1] with AeroGear team [2]. I'm working on exp= erimental project, which is called "Aerogear WebPush Server" [3].=
I'm watching for updates of WebPush protocol and discussions= in this mailing list and I will update our project to support the latest v= ersion.
I want to know about your current plans, when do you plan= to release a new draft? Maybe you know an approximate month?

Best regards,
Idel Pivnitskiy

[1]=C2=A0https://www.google-melange.com/gsoc/homepage/goo= gle/gsoc2015
--=C2=A0

_______________________________________________
aerogear-dev mailing list
aerogear-= dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aeroge= ar-dev



--

_______________________________________________
aerogear-dev mailing list
aerogear-= dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aeroge= ar-dev



--90e6ba6e8f52f16c6d05186323d9-- From nobody Sun Jun 14 22:01:22 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE89E1B31B9 for ; Sun, 14 Jun 2015 22:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 u8SFk52dUb3v for ; Sun, 14 Jun 2015 22:01:17 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5651B31B8 for ; Sun, 14 Jun 2015 22:00:59 -0700 (PDT) Received: from [71.204.141.163] (port=44072 helo=[192.168.1.7]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Z4MVz-0003uK-Sq; Mon, 15 Jun 2015 00:00:56 -0500 From: Shida Schubert Content-Type: multipart/alternative; boundary="Apple-Mail=_097A1B41-3C2B-48BF-82C2-69900246C744" Date: Sun, 14 Jun 2015 22:00:52 -0700 Message-Id: <0067651F-8C90-44DC-BC27-FF6F4D53F654@ntt-at.com> To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 71.204.141.163 X-Exim-ID: 1Z4MVz-0003uK-Sq X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [71.204.141.163]:44072 X-Source-Auth: shida@agnada.com X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: webpush-chairs@tools.ietf.org Subject: [Webpush] Adopting thomson-webpush-protocol-00 as WG item X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 15 Jun 2015 05:01:20 -0000 --Apple-Mail=_097A1B41-3C2B-48BF-82C2-69900246C744 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (as WG cochair) We have a draft for the core push protocol: https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt = As mentioned at the last IETF, the call for adopting the merged draft as = the WG item was to be brought to the list as the two drafts presented at = the last IETF were merged. The draft referenced above is such draft, so = I am here to call the adoption of this draft as WG item. Please respond by June 29th as to whether the text is acceptable to = adopt and work on as WG draft, or not.=20 Regards Shida= --Apple-Mail=_097A1B41-3C2B-48BF-82C2-69900246C744 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii (as WG cochair)

We have a draft = for the core push protocol:

https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt=

As mentioned at the last IETF, the = call for adopting the merged draft as the WG item was to be brought to = the list as the two drafts presented at the last IETF were merged. The = draft referenced above is such draft, so I am here to call the adoption = of  this draft as WG item.

Please respond by June 29th as to whether the = text is acceptable to adopt and work on as WG draft, or not. 

Regards

Shida
= --Apple-Mail=_097A1B41-3C2B-48BF-82C2-69900246C744-- From nobody Mon Jun 15 11:35:27 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9ED1A1AE8 for ; Mon, 15 Jun 2015 11:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 gbvW2TDZqFTc for ; Mon, 15 Jun 2015 11:35:25 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (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 D6C971A1B1C for ; Mon, 15 Jun 2015 11:35:12 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so68476163ieb.1 for ; Mon, 15 Jun 2015 11:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PMskaIA23yi2hUlC0T+WOB30nczmXlVlAbZW5d5VcNo=; b=O7nsQDDh3/HC6vL6o1CyGKWX1I1Sz2DiThfaU1SyUbuE9YM6+7MioNjIM6XwhZdk8b fZo7IlSFEbIetZCdjD2rGevMDJjLb7T+xyXyRNtw2xP9Ydn0rZJD/P/co4r2jUXuiVyD Xf9N1waYfacxcmzhPA/WBfLUAspskB6VqPuH7I7+k7nMG6pyckoqfjhyQG/fPXzdxict +Zc3+rS4ZQ7DxRZpSJxJ8HR/fP6p2ih3XLESxSSe0SqdAZz4kfv9utmE8o3RKBw7tjUi /6exCSpgfHopajQjP9ILE/rsEWRr8XXxLLEl33HNMKDXk4J7Wi0hU1rLARgsfiXhO325 P+2Q== MIME-Version: 1.0 X-Received: by 10.50.50.98 with SMTP id b2mr22335208igo.42.1434393312290; Mon, 15 Jun 2015 11:35:12 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Mon, 15 Jun 2015 11:35:12 -0700 (PDT) Date: Mon, 15 Jun 2015 11:35:12 -0700 Message-ID: From: Costin Manolache To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=089e0122e764d8eefe051892b712 Archived-At: Subject: [Webpush] Single subscription for multiple apps. X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 15 Jun 2015 18:35:26 -0000 --089e0122e764d8eefe051892b712 Content-Type: text/plain; charset=UTF-8 Hi, We discussed in the past the problem with returning a different 'subscription resource' for each subscription, and than having the UA issue a separate GET on each one. I think the conclusion was that: 1. A push service can return the same subscription URL for all apps on a UA, and the UA will than make a single GET - and retrieve messages for each app. 2. Push services may use other more efficient protocols for communication between UA and webpush service. For 1, I don't see any way for the UA to know how to dispatch to each app. This could be resolved with 2 changes: - adding the push resource ( ex /s/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx ) to the push promise in section 6.3. In this case, the webpush service can return a unique subscription resource for all apps running in the UA. - in subscribe, include a new header containing the subscription resource associated with the UA. A UA will get an initial subscription (associated with the UA as a whole ), and this will be referenced in all subscription requests for apps running in the UA. Without those changes - I don't think it'll be possible ( or at least not easy ) to have a scalable and efficient implementation. Please let me know if I missed something - it is not critical for GCM ( since 2 is likely to be used as an alternative). I'll open a separate thread for receipts - which have a similar problem. Costin --089e0122e764d8eefe051892b712 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We discussed in the past the proble= m with returning a different 'subscription resource' for each subsc= ription, and than having the UA issue a separate GET on each one.=C2=A0

I think the conclusion was that:

=
1. A push service can return the same subscription URL for all apps on= a UA, and=C2=A0
the UA will than make a single GET - and retriev= e messages for each app.=C2=A0

2. Push services may use other more effi= cient protocols for communication between UA and webpush service.

For 1, I don't see any way for the UA to k= now how to dispatch to each app.=C2=A0

This could = be resolved with 2 changes:=C2=A0
- adding the push resource ( ex= =C2=A0/s/LBhhw0OohO-W= l4Oi971UGsB7sdQGUibx ) to the push promise in section 6.3. In this c= ase, the webpush service can return a unique subscription resource for all = apps running in the UA.

- in subscribe, incl= ude a new header containing the subscription resource associated with the U= A.=C2=A0
A UA will get an initial subscription (associated with t= he UA as a whole ), and this will be referenced in all subscription request= s for apps running in the UA.=C2=A0

Without those = changes - I don't think it'll be possible ( or at least not easy ) = to have a scalable and efficient implementation. Please let me know if I mi= ssed something - it is not critical for GCM ( since 2 is likely to be used = as an alternative). I'll open a separate thread for receipts - which ha= ve a similar problem.=C2=A0

Costin

<= /div>

=




--089e0122e764d8eefe051892b712-- From nobody Mon Jun 15 12:05:27 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4B01A86F4 for ; Mon, 15 Jun 2015 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001] autolearn=no 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 0d96wJjv3aFJ for ; Mon, 15 Jun 2015 12:05:24 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 9716B1A8707 for ; Mon, 15 Jun 2015 12:05:15 -0700 (PDT) Received: by igbzc4 with SMTP id zc4so62015859igb.0 for ; Mon, 15 Jun 2015 12:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FMzj7xRIeqM176PhunRjypIx0ekuTkVvF7LzY9B+beg=; b=kQWB/hlNNXTvWAbWg424E+V9kJC+M9lppeG0UyzasEBA876ZxG/x0JB8T4ZqbhsVHd DcDlpofrHaT2Urr62x7egPELauARw0hNiujwXACxgaUkiHKhT2QqQYsORyfS9aALlZAx /8oD3puDZf9iov9z8lfnGN22Xmm9otf3wcjkgI0X8tY5lee8U4Dvl4NDzlWvtvu+LlyR ao4U4Dl/M3VKLpAQROT+xBWJ8OjznBqMFhskxY4wzUiD41QiXU8K5/34kEdVo5FKG2Ds d15JwDpR+dtwQ20LXaRS6Wgi5Ru6yTaqiFwPC6aVUa8qJ/aoKZTEytkCsfTFK0jdeM9h Qicg== MIME-Version: 1.0 X-Received: by 10.107.9.66 with SMTP id j63mr37616936ioi.37.1434395115095; Mon, 15 Jun 2015 12:05:15 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Mon, 15 Jun 2015 12:05:15 -0700 (PDT) Date: Mon, 15 Jun 2015 12:05:15 -0700 Message-ID: From: Costin Manolache To: "webpush@ietf.org" Content-Type: multipart/alternative; boundary=001a113f934e4d8d3d0518932398 Archived-At: Subject: [Webpush] Delivery receipt question X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 15 Jun 2015 19:05:25 -0000 --001a113f934e4d8d3d0518932398 Content-Type: text/plain; charset=UTF-8 As result to subscribe, the webpush service is required to return a link with rel=urn:ietf:params:push:receipt (section 3) In section 4, the URL returned is exchanged for another URL - and the text is a bit confusing on "application may reuse the same receipt resource". Also not clear how the push service would return the same "receipt subscribe URI to user agents". There are 2 problems, the smallest is that for each subscription it requires an extra HTTP request to exchange 2 URLs - it would be more efficient for the push service to directly return the "receipt subscription resource", and save 1/2 QPS on the subscription service. This may seem small - but there are additional savings on reducing the consistency requirements if nosql storage is used. In most cases the subscribe from UA and the "subscribe to receipts" happen in different zones, and in short time. The bigger issue is that it's not clear how it would be possible to implement this in an efficient way - I can see how it can be done if the app would issue a GET for each subscription, but that's practically impossible ( some apps run close to 1B subscriptions ). The only way to have working receipts is to have the app get a single resource where it'll get receipts for all the subscriptions. This is currently impossible since the webpush service doesn't have any information to associate subscriptions to an app sender. My proposal is to define that if "sender authentication" is required by a webpush service, the sender ID should be included in the /subscribe request, and the webpush service should return a unique receipt subscribe URI for each sender ID. Alternatively, the subscribe should include the 'origin' of the app, and an unique receipt resource would be created for each app. This will be harder to implement - the webpush service will need to authenticate the request for receiving receipts, and only send the receipts for messages sent by the same sender. I'm not aware of any scalable solution for the webpush providers that will not require sender authentication - there is simply not enough information to know that 2 push:receipt URLs correspond to same app or sender ( or maybe I'm missing something obvious ? ). Costin --001a113f934e4d8d3d0518932398 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As result to subscribe, the webpush service is requir= ed to return a link with rel=3Durn:ietf:params:push:receipt (section 3)

In section 4, the URL returned is exchanged for another URL - and t= he text is a bit confusing on "application may reuse the same receipt = resource".=C2=A0 Also not clear how the push service would return the = same "receipt su= bscribe URI to user agents".

There are 2 problems, t= he smallest is that for each subscription it requires an extra HTTP request= to exchange 2 URLs - it would be more efficient for the push service to di= rectly return the "receipt subscription resource", and save 1/2 Q= PS on the subscription service. This may seem small - but there are additio= nal savings on reducing the consistency requirements if nosql storage is us= ed. In most cases the subscribe from UA and the "subscribe to receipts= " happen in different zones, and in short time.=C2=A0

The bigger issue is that it's not clear how it would be possib= le to implement this in an efficient way - I can see how it can be done if = the app would issue a GET for each subscription, but that's practically= impossible ( some apps run close to 1B subscriptions ).

The only way to have working receipts is to have the app get a singl= e resource where it'll get receipts for all the subscriptions. This is = currently impossible since the webpush service doesn't have any informa= tion to associate subscriptions to an app sender.=C2=A0

My proposal is to define that if "sender authentication" is= required by a webpush service, the sender ID should be included in the /su= bscribe request, and the webpush service should return a unique receipt sub= scribe URI for each sender ID.

Alternatively, the = subscribe should include the 'origin' of the app, and an unique=C2= =A0
receipt resource would be created for each app. This will be = harder to implement -=C2=A0
the webpush service will need to auth= enticate the request for receiving receipts, and only send the receipts for= messages sent by the same sender.

I'm not awa= re of any scalable solution for the webpush providers that will not require= sender authentication - there is simply not enough information to know tha= t 2 push:receipt URLs correspond to same app or sender ( or maybe I'm m= issing something obvious ? ).

Costin
--001a113f934e4d8d3d0518932398-- From nobody Mon Jun 15 12:48:35 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCD91A8873 for ; Mon, 15 Jun 2015 12:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 aWOldWWAWn0c for ; Mon, 15 Jun 2015 12:48:32 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (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 88A711A885F for ; Mon, 15 Jun 2015 12:48:32 -0700 (PDT) Received: by yhid80 with SMTP id d80so50409519yhi.1 for ; Mon, 15 Jun 2015 12:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qUn3IPCC+/ajI+WHXiOUYdOSDXVhDrkE6t3trr7YHFM=; b=eRKYhtBCsP78BPfb1oEg2vpnn0TxIJ+v/oUoZ7cH5ejlGNLlyaPsyuQVeL4c/WVlXg HCtwjSvE/UCNCYltIC1h0uhU39pg1MnrZRxO4n6eQH8CV3xpW9EyflpSRV2zYAe5UkGK Q/s58bWquKJ01qosKWVQOmWT2xeIwyCgjv9BgaGv7jHGJun6ge0OF4+N5lXAxgAiF4uv /vdi/qdk8GnEu1BPQymNxixJ8QY0Fyw4Z0HkhjsHIAemwyOmk7c5qHlOkMWqc0jiyFS7 qSeAyvFDqd1Q9TEkrKeoVA+kmXQmhC49UIY6dixAD9s0aFQQinsbEsPy3hMpnIg602Xl gtqA== MIME-Version: 1.0 X-Received: by 10.13.251.199 with SMTP id l190mr37008202ywf.148.1434397711967; Mon, 15 Jun 2015 12:48:31 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 15 Jun 2015 12:48:31 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 12:48:31 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Single subscription for multiple apps. X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 15 Jun 2015 19:48:34 -0000 On 15 June 2015 at 11:35, Costin Manolache wrote: > 1. A push service can return the same subscription URL for all apps on a UA, > and > the UA will than make a single GET - and retrieve messages for each app. This isn't right. We need to have a different subscription URL for each application for privacy reasons alone. The dispatch problem is easier to solve if each application has its own subscription. From nobody Mon Jun 15 14:02:09 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0A01ACE50 for ; Mon, 15 Jun 2015 14:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1IRi4dgMK6YR for ; Mon, 15 Jun 2015 14:02:05 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (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 1D4041A88FE for ; Mon, 15 Jun 2015 14:02:05 -0700 (PDT) Received: by iesa3 with SMTP id a3so404223ies.2 for ; Mon, 15 Jun 2015 14:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8EbAXS2AoKL4ZRjJsm0eruX8/9gQIJ9NQn6caDzVRhY=; b=1EE6fuvRMrmddoZqErZ0UVKmYDYoyEsUk9EGYV5sh3tnMtOOWpsgbJfP9HEq2hF2vr 0JfQzHWjS6ZCTd1y4X93+XAgIWbwJbpyYfvhUn/HayUFIuvbJB3Ys5CBDHIycpy8n7UV OfPN3xMXdLpeAUG7pf+BCNb3VViaunqeoVl3iuPK5yq8sYbbOhiAfD8kAN9nY/39uxrw w4oTBLwwqZmueIHMhKJzWahZlXavBxnC5XZV/S/drBlDejwaMb0SV4dcNeIfpM+FboOS rfoPx3zBBN8i5XaKtsizpL+Yqdl/Y0y/MHpVGUON/wJ3zx5arzH7u6HG9819Y8AQGeZl GKEQ== MIME-Version: 1.0 X-Received: by 10.107.3.210 with SMTP id e79mr37410498ioi.50.1434402124651; Mon, 15 Jun 2015 14:02:04 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Mon, 15 Jun 2015 14:02:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 14:02:04 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113f8ef01b075f051894c5aa Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Single subscription for multiple apps. X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 15 Jun 2015 21:02:07 -0000 --001a113f8ef01b075f051894c5aa Content-Type: text/plain; charset=UTF-8 On Mon, Jun 15, 2015 at 12:48 PM, Martin Thomson wrote: > On 15 June 2015 at 11:35, Costin Manolache wrote: > > 1. A push service can return the same subscription URL for all apps on a > UA, > > and > > the UA will than make a single GET - and retrieve messages for each app. > > > This isn't right. We need to have a different subscription URL for > each application for privacy reasons alone. > The push resource needs to be different for privacy reasons - the one sent to app servers. The subscription resource is used by UA to talk with webpush service and request delivery - there is no extra privacy you can gain ( unless you use different TCP connections for each subscription - which is beyond unscalable ). The webpush service obviously can associate all subscriptions from a UA based on connection. > > The dispatch problem is easier to solve if each application has its > own subscription. > At significant cost - transferred bytes, time to connect - and more important it greatly increases the storage costs on the webpush service. Grouping all apps in a UA (device) allows a single transaction to check stored messages for all of them. With different subscriptions you would need one transaction for each subscription. Assuming only 10 apps per UA - in one case you need one HTTP GET and 1 DB lookup, in the second you need 10 HTTP GETs and 10 DB lookups. And this is going to happen many times, as the UA may get disconnected - even if the UA doesn't receive any message. Costin --001a113f8ef01b075f051894c5aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 15, 2015 at 12:48 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
On 15 June 2015 at 11:35, Costin Manolache <costin@gmail.com> wrote:
> 1. A push service can return the same subscription URL for all apps on= a UA,
> and
> the UA will than make a single GET - and retrieve messages for each ap= p.


This isn't right. We need to have a different subscription URL f= or
each application for privacy reasons alone.

=
The push resource needs to be different for privacy reasons - the one= =C2=A0
sent to app servers.

The subscrip= tion resource is used by UA to talk with webpush service and request=C2=A0<= /div>
delivery - there is no extra privacy you can gain ( unless you us= e different TCP connections for=C2=A0
each subscription - which i= s beyond unscalable ). The webpush service obviously
can associat= e all subscriptions from a UA based on connection.=C2=A0

=C2=A0

The dispatch problem is easier to solve if each application has its
own subscription.

At significant cost= - transferred bytes, time to connect - and more important it greatly=C2=A0=
increases the storage costs on the webpush= service. Grouping all apps in a UA (device) allows=C2=A0
a single transaction to check stored messages for all of t= hem. With different subscriptions you=C2=A0
would need one transaction for each subscription.

Assuming only 10 apps per UA -= in one case you need one HTTP GET and 1 DB lookup, in the second
you need 10 HTTP GETs and 10 DB lookups. And this is= going to happen many times, as=C2=A0
the U= A may get disconnected - even if the UA doesn't receive any message.=C2= =A0

Co= stin

--001a113f8ef01b075f051894c5aa-- From nobody Mon Jun 15 14:08:37 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FC41B2A16 for ; Mon, 15 Jun 2015 14:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 75Qw5SYCJ5S6 for ; Mon, 15 Jun 2015 14:08:34 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (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 C12041B2A0B for ; Mon, 15 Jun 2015 14:08:34 -0700 (PDT) Received: by yhpn97 with SMTP id n97so51750981yhp.0 for ; Mon, 15 Jun 2015 14:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ngjyh6oJ+VuKVLfoegKYMYbFiMBGEvVKGEoa5OrR+qU=; b=KwTh7Y6viXEfOyMAFehDoiuszoOhQp02LCcIH6aegbijiBezOiA/QhYHxanWQhc4ir 6yEPtMNtTNUOQ2gUflbDihRTDKoDlwmThA2BqLZ83ZgZ/rzEA2usN+kG5BWfcusmu1f/ epGcSnwzh7eacvlGCd5gARSJRz4+Q+H0G4K83ldZQJ20SFd/vokg7lxF5D0wAQr5iVaF 3RiZNOavVhCio3L9Nbu8ZIrD00xsMrmEykbYP49rF2tFn+8em21GLxe5mIjfQeT9WsD3 +xHC06Sh0RxicfPSZuxM+AXLBgDaWArMNPjRtJ1/gyfEfgckMqIiJss/vm40kX+nSESu VEOQ== MIME-Version: 1.0 X-Received: by 10.13.247.3 with SMTP id h3mr37471256ywf.154.1434402514146; Mon, 15 Jun 2015 14:08:34 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 15 Jun 2015 14:08:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 14:08:34 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Delivery receipt question X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 15 Jun 2015 21:08:36 -0000 On 15 June 2015 at 12:05, Costin Manolache wrote: > As result to subscribe, the webpush service is required to return a link > with rel=urn:ietf:params:push:receipt (section 3) > > In section 4, the URL returned is exchanged for another URL - and the text > is a bit confusing on "application may reuse the same receipt resource". > Also not clear how the push service would return the same "receipt subscribe > URI to user agents". I think that I can see how this might be confusing, but I might need your help so that we can make it clearer in the document. Maybe if we can take it in reverse. Each application server needs to have a unique URI that it subscribes to for receipts. Or, at best, a very small number of URIs, maybe one for each push service that it has talked to. 1B would be ludicrous, I agree. The way that the application server gets those URIs is by registering/subscribing. But it doesn't know, a priori, where to do that. So the UA provides it with the identity of a resource that can be used to register. Currently, the application server registration results in a "receipt subscription" resource being provided. The text in question notes that the way that an application server learns about whether this is a new push service, or one that it already knows about is by performing a comparison between the URIs handed to clients. Perhaps putting a different way would help. From nobody Mon Jun 15 14:14:52 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DD41B2A66 for ; Mon, 15 Jun 2015 14:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 TUR0laxlBEsO for ; Mon, 15 Jun 2015 14:14:50 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 275561B2A63 for ; Mon, 15 Jun 2015 14:14:50 -0700 (PDT) Received: by igbiq7 with SMTP id iq7so28456374igb.1 for ; Mon, 15 Jun 2015 14:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EXCkP6QYomCtdEgJUHOqoxAPjBBlFLZFaFx075OUJxE=; b=kRjiilO5dx0iKjf+8jA33Dc3nGpLT95yuqhYoZlR/jb40+MfPPTPTt81lQt1ZHtKjd nm3uDFelN6DYdhK60fz/t7WIv/J3uzPdFtM0ySeqCDG0cSXmE77VKhYfcQ5jPfC2qm57 wvryijHWGlnFGkQC8T/2qw68Y+Kml3riXwfS8+JVCNAELOOZtUxCAxMH4j0qVdrPlQAZ 304LcJYQFk3NXmZBhusnHVZeEfZVaR2U3Vvi/lzQXtoaIIVfQRDeEqiPvzZOJFR2Jn9s +BuncnV25HnnaarRD8xeF3xyL12Pclf8f/IafIO8LWzPdkBjfTPQ8Hab6oCenNPU37BU pNLQ== MIME-Version: 1.0 X-Received: by 10.43.74.131 with SMTP id yw3mr23175615icb.97.1434402889592; Mon, 15 Jun 2015 14:14:49 -0700 (PDT) Received: by 10.64.5.37 with HTTP; Mon, 15 Jun 2015 14:14:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 14:14:49 -0700 Message-ID: From: Martin Thomson To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Single subscription for multiple apps. X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 15 Jun 2015 21:14:51 -0000 On 15 June 2015 at 14:02, Costin Manolache wrote: >> The dispatch problem is easier to solve if each application has its >> own subscription. > > > At significant cost - transferred bytes, time to connect - and more > important it greatly > increases the storage costs on the webpush service. Grouping all apps in a > UA (device) allows > a single transaction to check stored messages for all of them. With > different subscriptions you > would need one transaction for each subscription. I see where you are at now. This is the old cardinality question: one subscription or many? When we asked the question in Dallas, it seemed like we had one person really strongly arguing for multiple independent subscriptions (Elio) and a couple of lukewarm responses (yourself included). The original design I had used a single request from a UA to pull down information about multiple subscriptions. We changed that after some discussion, based on the previous. It also turns out that the whole acknowledgment design is cleaner as a result of the change. Is the overhead significant enough to warrant a change? I would have thought that you could cheat on at the DB lookups and avoid some of the overhead. From nobody Mon Jun 15 14:27:10 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03E61A00D4 for ; Mon, 15 Jun 2015 14:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001] autolearn=no 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 JmQ4hLb_LXH6 for ; Mon, 15 Jun 2015 14:27:07 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 06AAA1A00BF for ; Mon, 15 Jun 2015 14:27:07 -0700 (PDT) Received: by igbiq7 with SMTP id iq7so28674788igb.1 for ; Mon, 15 Jun 2015 14:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BuyTjvHkRG9W7/K5SOs5GBAsos5qO24TMIGCi+aHCqs=; b=ruiN0Y8S+LtmLg8CAdl5hsMtd4nggCz0JJIvf9+sLAiSsbuXuEhHJo4s+ZWBOClmtI UDRtRgQPXaTkGSCuGuIuzuNQlPE5BTmZr+0JOyKMDd2t6nasqQ09xACU29rj2M5IsdFK Yrx1EIBQQav4IK6gyRjt26CRo4zOvNuMaNXAlRzk6gvpdyKZiChfu47Dmti0Y+JlgDco PVL0ACjwIpulAGe34uMRwacVjrXV0hTQMNgjUtr15Ss1ub/znLbAf5WuGmRBJZQL/jMi Ay3nfGRefH02sDhMsQm0yJcG4NgrucujimOVNlENiKFSifEvNaXU6GcQIbxwtefAzELC 8UuQ== MIME-Version: 1.0 X-Received: by 10.50.79.202 with SMTP id l10mr23737900igx.7.1434403626553; Mon, 15 Jun 2015 14:27:06 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Mon, 15 Jun 2015 14:27:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 14:27:06 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0122aaeea01a830518951ef3 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Delivery receipt question X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 15 Jun 2015 21:27:08 -0000 --089e0122aaeea01a830518951ef3 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 15, 2015 at 2:08 PM, Martin Thomson wrote: > On 15 June 2015 at 12:05, Costin Manolache wrote: > > As result to subscribe, the webpush service is required to return a link > > with rel=urn:ietf:params:push:receipt (section 3) > > > > In section 4, the URL returned is exchanged for another URL - and the > text > > is a bit confusing on "application may reuse the same receipt resource". > > Also not clear how the push service would return the same "receipt > subscribe > > URI to user agents". > > I think that I can see how this might be confusing, but I might need > your help so that we can make it clearer in the document. > > Maybe if we can take it in reverse. > > Each application server needs to have a unique URI that it subscribes > to for receipts. Or, at best, a very small number of URIs, maybe one > for each push service that it has talked to. 1B would be ludicrous, I > agree. > > The way that the application server gets those URIs is by > registering/subscribing. But it doesn't know, a priori, where to do > that. So the UA provides it with the identity of a resource that can > be used to register. Currently, the application server registration > results in a "receipt subscription" resource being provided. > > The text in question notes that the way that an application server > learns about whether this is a new push service, or one that it > already knows about is by performing a comparison between the URIs > handed to clients. Perhaps putting a different way would help. > Yes, this is similar with what I was proposing - the application server needs one URI per webpush service, and the way to get it is via a one-time subscription of the 'app server' with the webpush service. In this case I don't think we need the complexity of a separate urn:ietf:params:push:receipt - the /subscribe URI would work as well for app servers as it does for UA. But I'm ok with having a separate URI or returning it as push:receipt link. The main question remains: even if you have one URI per app server, how do we associate each message or app subscription to the URI of the app server. For authenticated sender - it can be done by matching the authenticated ID on the message send and on receipt request. I don't know any good way for un-authenticated sender. Costin --089e0122aaeea01a830518951ef3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 15, 2015 at 2:08 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 15= June 2015 at 12:05, Costin Manolache <costin@gmail.com> wrote:
> As result to subscribe, the webpush service is required to return a li= nk
> with rel=3Durn:ietf:params:push:receipt (section 3)
>
> In section 4, the URL returned is exchanged for another URL - and the = text
> is a bit confusing on "application may reuse the same receipt res= ource".
> Also not clear how the push service would return the same "receip= t subscribe
> URI to user agents".

I think that I can see how this might be confusing, but I might need=
your help so that we can make it clearer in the document.

Maybe if we can take it in reverse.

Each application server needs to have a unique URI that it subscribes
to for receipts.=C2=A0 Or, at best, a very small number of URIs, maybe one<= br> for each push service that it has talked to.=C2=A0 1B would be ludicrous, I=
agree.

The way that the application server gets those URIs is by
registering/subscribing.=C2=A0 But it doesn't know, a priori, where to = do
that.=C2=A0 So the UA provides it with the identity of a resource that can<= br> be used to register.=C2=A0 Currently, the application server registration results in a "receipt subscription" resource being provided.

The text in question notes that the way that an application server
learns about whether this is a new push service, or one that it
already knows about is by performing a comparison between the URIs
handed to clients.=C2=A0 Perhaps putting a different way would help.


Yes, this is similar with what= I was proposing - the application server needs
one URI per webpu= sh service, and the way to get it is via a one-time
subscription = of the 'app server' with the webpush service.=C2=A0

<= /div>
In this case I don't think we need the complexity of a separa= te=C2=A0
ur= n:ietf:params:push:receipt - the /subscribe URI would work as well <= /div>
for app ser= vers as it does for UA. But I'm ok with having a separate
<= div>URI or returning = it as push:receipt link.

The main question remains: even if you have on= e URI per app server,
how do we associate each message or app sub= scription to the URI
of the app server. For authenticated sender = - it can be done by matching
the authenticated ID on the message = send and on receipt request.=C2=A0
I don't know any good way = for un-authenticated sender.

Costin
--089e0122aaeea01a830518951ef3-- From nobody Mon Jun 15 14:34:46 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4211B2ABB for ; Mon, 15 Jun 2015 14:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ki-CjhK5Djff for ; Mon, 15 Jun 2015 14:34:40 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 63C8A1B2AB9 for ; Mon, 15 Jun 2015 14:34:38 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so1062518igb.0 for ; Mon, 15 Jun 2015 14:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kRK/yUdu60x4evUSr326nyUUoBcWMJFea09fEmw9K7Y=; b=rr6THIRoMtXOdUi1P5edzYJ7JBh7rsvykHIfKisvKWVZVPCi31fO8fzIofTEGysk04 2MORwX1HwTOFjYCu6Tlt/jFDF+oqHCkqOdzeIAsS2EjMIBpJ0FOpqrEY5KGkoQlo2164 Qv8j3xojs9rh257D2NnSDgkmTrMHR3ZKXsgYNSu4iWR69AUJ0M8mhvTh5p0Q+vTX5yAU BFZGDDXcnQJqv5L+uXEEJzhRIfSvJDn9XK3rDyTZKYn2MxaoCHyQDn8BU22SiVV86Wvg HiEHE038ww7fZqbOCCtcP7N4usPRsDuBEAHzS1EGrNfakpthnn9z3YLe4xZb7DhdVc9V 271Q== MIME-Version: 1.0 X-Received: by 10.42.93.17 with SMTP id v17mr33608844icm.42.1434404077779; Mon, 15 Jun 2015 14:34:37 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Mon, 15 Jun 2015 14:34:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 14:34:37 -0700 Message-ID: From: Costin Manolache To: Martin Thomson Content-Type: multipart/alternative; boundary=90e6ba614ce68542710518953919 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Single subscription for multiple apps. X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 15 Jun 2015 21:34:45 -0000 --90e6ba614ce68542710518953919 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 15, 2015 at 2:14 PM, Martin Thomson wrote: > On 15 June 2015 at 14:02, Costin Manolache wrote: > >> The dispatch problem is easier to solve if each application has its > >> own subscription. > > > > > > At significant cost - transferred bytes, time to connect - and more > > important it greatly > > increases the storage costs on the webpush service. Grouping all apps in > a > > UA (device) allows > > a single transaction to check stored messages for all of them. With > > different subscriptions you > > would need one transaction for each subscription. > > I see where you are at now. This is the old cardinality question: one > subscription or many? > > When we asked the question in Dallas, it seemed like we had one person > really strongly arguing for multiple independent subscriptions (Elio) > and a couple of lukewarm responses (yourself included). > My response was lukewarm in part because GCM is not affected (we're very likely to continue to use our binary protocol for efficiency - this part of the protocol is pretty orthogonal to the rest, only affects UA to webpush communication ), and I don't mind if the standard provides both options - in cases where a UA will have only 1-2 subscriptions it may be simpler, and maybe other provides have better databases or more resources. > The original design I had used a single request from a UA to pull down > information about multiple subscriptions. We changed that after some > discussion, based on the previous. It also turns out that the whole > acknowledgment design is cleaner as a result of the change. > > Is the overhead significant enough to warrant a change? I would have > thought that you could cheat on at the DB lookups and avoid some of > the overhead. > It is possible to avoid DB lookups only if there is a way to link the various app subscriptions with the UA. And the network cost can be saved only if UA can make a single GET request instead of 10 (or more). On mobile it matters - this is not one time, but repeated each time phone disconnects. Costin --90e6ba614ce68542710518953919 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 15, 2015 at 2:14 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 15 June 2015 at 14:02, Costin Manolache <costin@gmail.com> wrote:
>> The dispatch problem is easier to solve if each application has it= s
>> own subscription.
>
>
> At significant cost - transferred bytes, time to connect - and more > important it greatly
> increases the storage costs on the webpush service. Grouping all apps = in a
> UA (device) allows
> a single transaction to check stored messages for all of them. With > different subscriptions you
> would need one transaction for each subscription.

I see where you are at now.=C2=A0 This is the old cardinality questi= on: one
subscription or many?

When we asked the question in Dallas, it seemed like we had one person
really strongly arguing for multiple independent subscriptions (Elio)
and a couple of lukewarm responses (yourself included).

My response was lukewarm in part because GCM is not affect= ed (we're very likely
to continue to use our binary protocol = for efficiency - this part of the protocol is=C2=A0
pretty orthog= onal to the rest, only affects UA to webpush communication ),
=C2= =A0and I don't mind if the standard provides both options - in cases wh= ere a UA
will have only 1-2 subscriptions it may be simpler, and = maybe other provides
have better databases or more resources.


The original design I had used a single request from a UA to pull down
information about multiple subscriptions.=C2=A0 We changed that after some<= br> discussion, based on the previous.=C2=A0 It also turns out that the whole acknowledgment design is cleaner as a result of the change.

Is the overhead significant enough to warrant a change?=C2=A0 I would have<= br> thought that you could cheat on at the DB lookups and avoid some of
the overhead.

It is possible to a= void DB lookups only if there is a way to link the various=C2=A0
app subscriptions with the UA.

And the network cost can be = saved only if UA can make a single GET request=C2=A0
instead of 10 (or more). On mobile it matters - this is not one t= ime, but repeated
each time phone disconnec= ts.

Co= stin
--90e6ba614ce68542710518953919-- From nobody Thu Jun 18 02:09:21 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF83D1B30A2 for ; Thu, 18 Jun 2015 02:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.927 X-Spam-Level: ** X-Spam-Status: No, score=2.927 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 UDCAE1VNnpca for ; Thu, 18 Jun 2015 02:09:18 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6BE1B30A0 for ; Thu, 18 Jun 2015 02:09:17 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t5I99HKD001077 for ; Thu, 18 Jun 2015 03:09:17 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 18 Jun 2015 03:09:17 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Thu, 18 Jun 2015 03:09:16 -0600 From: Darshak Thakore To: "webpush@ietf.org" Thread-Topic: some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AQHQqaZzsT4CoedwPEu3u/5QrncIMQ== Date: Thu, 18 Jun 2015 09:09:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_D1A7E6DC5098dthakorecablelabscom_" MIME-Version: 1.0 Archived-At: Subject: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 18 Jun 2015 09:09:20 -0000 --_000_D1A7E6DC5098dthakorecablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, At the Dallas meeting, I had volunteered to review the draft and provide so= me feedback and comments. I=92m a little behind on that but here=92s the fi= rst installment I tried to capture the example end to end webpush flow (just to make sure I= understand it correctly) in the following diagram: https://raw.githubusercontent.com/darshakthakore/ietf-work/master/webpush/r= eview/webpush-flow.png There were a couple of places where I didn=92t quite get the intent of the = spec (they are marked in red in the diagram above and referenced below) Section 4 =96 The first sentence in the last paragraph =93A push service SHOULD provide the same receipt subscribe URI to user age= nts=94. I=92m trying to understand what this means. If we are referring to the "htt= ps://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN" URI in the exampl= e in Section 4, how exactly does the push service provide this URI to the u= ser-agent. Is the intent to say that it should provide the same URI to a gi= ven application server? (I=92ve marked this with the red arrow in the diagr= am) Section 5 - In the example, Is the post operation to the right URL? Is that= just an editorial oversight or is that the intended URL? Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 Section 5.1 - Would be useful to give an example of where/when the Push-Rec= eipt header is sent and what the value looks like. I'm guessing the example value should be "https://push.example.net/r/3ZtI4Y= VNBnUUZhuoChl6omUvG4ZM9mpN" but it would help to just explicitly show it. Also, as I understand it, if the application server does not want a push me= ssage receipt, it would not do anything that is specified in Section 4 and = so will also not send the Push-Receipt header. Is that correct? If so, does the Push Server still need to send back a 201 Created (with the= Location header populated) or should it send back a 200 OK instead. To take an example of a push message for a call notification, the AS is exp= ecting the notification to be delivered immediately and its going to get an= inherent acknowledgement by the mere fact that the actual app was woken up= to receive the call. If stuff in Section 4 and Section 6.2 does not happen, can the interaction = between the UA and the PS be simplified (the PS can itself delete the push = message resource) Section 6 - Sentence in second last paragraph =96 "In response to this request, the push service SHOULD return link reference= s to the push and receipt subscribe resources, plus expiration information" Are these the original URL's generated by the PS (i.e. /p/JzLQ3raZJfFBR0aqv= OMsLrt54w4rJUsV and /receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ) or are thes= e the corresponding uri's generated in response to the application server's= messages (i.e. r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN and /d/qDIYHNcfAIPP_5ITv= URr-d6BGtYnTRnk). Also I'm assuming here that the "expiration information" = refers to the expiration info of the push messages (i.e their TTL), correct= ? Push message prioritization - Would it make sense to use the Prefer header = instead of the TTL header. This would allow carrying prioritization info fo= r messages (the prioritization is only relative to the application server's= own set of messages) to be carried in the Prefer header (e.g. Prefer: prio= rity=3D5, wait=3D10). Also the wait 0 can be used to indicate the equivalen= t of TTL 0 or we can even define a new preference token. Darshak --_000_D1A7E6DC5098dthakorecablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5A87C3D53A696944A0D5322636693E33@cablelabs.com> Content-Transfer-Encoding: quoted-printable
Hi all,
At the Dallas meeting, I had volunteered to review the draft and provi= de some feedback and comments. I=92m a little behind on that but here=92s t= he first installment

I tried to capture the example end to end webpush flow (just to make s= ure I understand it correctly) in the following diagram: 


There were a couple of places where I didn=92t quite get the intent of= the spec (they are marked in red in the diagram above and referenced below= )

Section 4 =96 The first sentence in the last paragraph
=93A push service SHOULD provide the same receipt subscribe URI to use= r agents=94.
I=92m trying to understand what this means. If we are referring to the=  "https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN&quo= t; URI in the example in Section 4, how exactly does the push service provi= de this URI to the user-agent. Is the intent to say that it should provide the same URI to a given application server? (I=92ve= marked this with the red arrow in the diagram)

Section 5 - In the example, Is the post operation to the right URL? Is= that just an editorial oversight or is that the intended URL?
Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1
Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1&= nbsp;

Section 5.1 - Would be useful to give an example of where/when the Pus= h-Receipt header is sent and what the value looks like.
I'm guessing the example value should be "https://push.example.ne= t/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN" but it would help to just explic= itly show it. 
Also, as I understand it, if the application server does not want a pu= sh message receipt, it would not do anything that is specified in Section 4= and so will also not send the Push-Receipt header. Is that correct?
If so, does the Push Server still need to send back a 201 Created (wit= h the Location header populated) or should it send back a 200 OK instead.
To take an example of a push message for a call notification, the AS i= s expecting the notification to be delivered immediately and its going to g= et an inherent acknowledgement by the mere fact that the actual app was wok= en up to receive the call. 
If stuff in Section 4 and Section 6.2 does not happen, can the interac= tion between the UA and the PS be simplified (the PS can itself delete the = push message resource)

Section 6 - Sentence in second last paragraph =96  
"In response to this request, the push service SHOULD return link= references to the push and receipt subscribe resources, plus expiration in= formation" 
Are these the original URL's generated by the PS (i.e. /p/JzLQ3raZJfFB= R0aqvOMsLrt54w4rJUsV and /receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ) or are= these the corresponding uri's generated in response to the application ser= ver's messages (i.e. r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN and /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk). Also I'm assuming here that the = "expiration information" refers to the expiration info of the pus= h messages (i.e their TTL), correct?

Push message prioritization - Would it make sense to use the Prefer he= ader instead of the TTL header. This would allow carrying prioritization in= fo for messages (the prioritization is only relative to the application ser= ver's own set of messages) to be carried in the Prefer header (e.g. Prefer: priority=3D5, wait=3D10). Also = the wait 0 can be used to indicate the equivalent of TTL 0 or we can even d= efine a new preference token.


Darshak









--_000_D1A7E6DC5098dthakorecablelabscom_-- From nobody Thu Jun 18 22:04:39 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B221A1A7D for ; Thu, 18 Jun 2015 22:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 NGQKaNFP9Ydw for ; Thu, 18 Jun 2015 22:04:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7931A1A82 for ; Thu, 18 Jun 2015 22:04:35 -0700 (PDT) Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) with Microsoft SMTP Server (TLS) id 15.1.190.14; Fri, 19 Jun 2015 05:04:19 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0190.013; Fri, 19 Jun 2015 05:04:19 +0000 From: "Brian Raymor (MS OPEN TECH)" To: Darshak Thakore , "webpush@ietf.org" Thread-Topic: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCqHj9VdIsjhqcjQPeKa7MgtolfFw== Date: Fri, 19 Jun 2015 05:04:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cablelabs.com; dkim=none (message not signed) header.d=none; x-originating-ip: [73.42.172.77] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 3:HuTrMd//oOBk6VX2ZHZNnxnDsx3wejagmaDGAgfGfY1YRfIT7HuJd8qFCH1JRFR0z0pAeuCgN7jtWpqpCI/8P8teKHn4IvgUZpAiiEvE5KTUznpkbatL06w7PUJnFbpSt7eROwI9rNCJ05rRAgbw7w==; 10:tPGXYmTck1MUAVr41sRns3CP93b8Nx/6VUE5zsL/SX+19WuEP76LftFT8cvu4aTnZkCe9iXKxwc/lhlcXN2TODyjLA25CSEc23wVPmNSHYo=; 6:mxg7+kKGxd60ywbcw8kK2RrQxmC+M4sugNhaGtkOUIsTpSNHlh87phXiU93Kl8JP x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001)(42139001); SRVR:BY2PR0301MB0647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 0612E553B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(575784001)(2900100001)(87936001)(33656002)(102836002)(2656002)(15975445007)(74316001)(76576001)(92566002)(19580395003)(99286002)(19580405001)(5003600100002)(46102003)(50986999)(77096005)(86612001)(5002640100001)(5001960100002)(107886002)(5001920100001)(54356999)(230783001)(86362001)(5001770100001)(189998001)(62966003)(77156002)(2501003)(66066001)(122556002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2015 05:04:19.2670 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 19 Jun 2015 05:04:38 -0000 Thanks for the review feedback, Darshak. I will respond to each section in = separate messages. On Thursday, Jun 18, 2015, Darshak Thakore wrote: > Section 4 - The first sentence in the last paragraph > "A push service SHOULD provide the same receipt subscribe URI to user age= nts". > I'm trying to understand what this means. If we are referring to the=A0"h= ttps://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN" URI in > the example in Section 4, how exactly does the push service provide this = URI to the user-agent.=20 Let me review the "how" first. In addition to the URI for the push resource (urn:ietf:params:push), the pu= sh service also returns the URI for the receipt subscribe resource (urn:ietf:params:push:receipt) to the User Agent during the subscr= iption process.=20 (https://tools.ietf.org/html/draft-thomson-webpush-protocol-00#section-3) The push server MUST provide a URI for a receipt subscribe resource in a link relation of type "urn:ietf:params:push:receipt". In the examples, the receipt subscribe resource uses the https://push.examp= le.net/receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ URI. The User Agent then forwards both the URI(s) its application server: An application-specific method is used to distribute the push and receipt subscribe URIs to the application server. The application server can then use the receipt subscribe URI to create a r= eceipt subscription (https://tools.ietf.org/html/draft-thomson-webpush-protocol-00#section-4) t= o receive receipts from the push server (https://tools.ietf.org/html/draft-thomson-webpush-pro= tocol-00#section-6.2). In the examples, the receipt subscription resource is https://push.example.= net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN which is the URI you're referencing above. > Is the intent to say that it should provide the same URI > to a given application server? (I've marked this with the red arrow in th= e diagram) Recently, Martin developed this section further to provide more context: https://github.com/unicorn-wg/webpush-protocol/commit/68c4c599314f9f4ca91= 6831468ea7323605e6bcb Does this offer more clarity and answer your question? There were also earlier conversations on the rationale for the SHOULD state= ment: https://github.com/unicorn-wg/webpush-protocol/commit/9fb7296585c7d69d1b84d= f837e1cf16c297ccb20#commitcomment-10675623 From nobody Thu Jun 18 22:32:43 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE9A1A1B3E for ; Thu, 18 Jun 2015 22:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 FIej8TLm5QJc for ; Thu, 18 Jun 2015 22:32:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4366D1A0122 for ; Thu, 18 Jun 2015 22:32:41 -0700 (PDT) Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0645.namprd03.prod.outlook.com (10.160.63.13) with Microsoft SMTP Server (TLS) id 15.1.190.14; Fri, 19 Jun 2015 05:32:39 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0190.013; Fri, 19 Jun 2015 05:32:39 +0000 From: "Brian Raymor (MS OPEN TECH)" To: Darshak Thakore , "webpush@ietf.org" Thread-Topic: RE: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCqTLVlBEGCotjlTVOAavWYB9q3mQ== Date: Fri, 19 Jun 2015 05:32:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cablelabs.com; dkim=none (message not signed) header.d=none; x-originating-ip: [73.42.172.77] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0645; 3:Ehh8uN1B+G7x7Mscmj4wRfeTdnK0c7MH4J0+qlixtNb6fIM1O8G5URvoLa6aWr933QSJr3y/6o0Y7w4WcF7L+Dt2XXty9R3JLXx1iKsWcAzEKZaXKFmz26X9+4YOICb5IQ7uv2xqPOYE/W6l2r1EAw==; 10:EFb60Vbwlu3jSgIxVrKb1SqsqvAmkCn1o5P/c/zXgPaw2YWenzOogKlYEjGO9+agU5204iFK5nwe46O4+TLjFwk2bABZzD5m17aCb6iQR8A=; 6:pKwdLlgcpDjZdtVScRFUnzkfjEoXqmqkEzwgFecYBRvgjGbMF5lbDFlThusu9x0p x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR0301MB0645; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0645; x-forefront-prvs: 0612E553B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(46102003)(2900100001)(15975445007)(50986999)(77096005)(5002640100001)(74316001)(54356999)(102836002)(230783001)(92566002)(87936001)(2656002)(5001770100001)(66066001)(77156002)(62966003)(5003600100002)(40100003)(122556002)(2501003)(107886002)(19580405001)(19580395003)(575784001)(76576001)(86362001)(5001960100002)(33656002)(189998001)(99286002)(86612001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0645; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2015 05:32:38.9289 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0645 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 19 Jun 2015 05:32:43 -0000 On Thursday, Jun 18, 2015, Darshak Thakore wrote: > Section 5 - In the example, Is the post operation to the right URL? Is th= at just an editorial oversight or is that the intended URL? > Current example: POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 > Probably should be: POST /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1 Nice catch. The current example is incorrect. It should match the urn:ietf:= params:push link relation returned in the Subscription response - /p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV= - and distributed to the application server. This was probably introduced when we made the changes for the "Subscription= split" http://www.ietf.org/mail-archive/web/webpush/current/msg00130.html From nobody Fri Jun 19 16:14:32 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF721A8A0C for ; Fri, 19 Jun 2015 16:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.533 X-Spam-Level: * X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, TRACKER_ID=1.306, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 Z85nKOYQ5kbY for ; Fri, 19 Jun 2015 16:14:30 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC8D1A8980 for ; Fri, 19 Jun 2015 16:14:30 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t5JNEPEc030175; Fri, 19 Jun 2015 17:14:29 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 19 Jun 2015 17:14:25 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Fri, 19 Jun 2015 17:14:22 -0600 From: Darshak Thakore To: Costin Manolache , Martin Thomson Thread-Topic: [Webpush] Delivery receipt question Thread-Index: AQHQp549nUksC4qf4EeXFbKd7XcY2Z2udDkAgAAFLgCABgK7AA== Date: Fri, 19 Jun 2015 23:14:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_D1A9FBD453ABdthakorecablelabscom_" MIME-Version: 1.0 Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Delivery receipt question X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 19 Jun 2015 23:14:31 -0000 --_000_D1A9FBD453ABdthakorecablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 6/15/15, 3:27 PM, "Costin Manolache" > wrote: The main question remains: even if you have one URI per app server, how do we associate each message or app subscription to the URI of the app server. For authenticated sender - it can be done by matching the authenticated ID on the message send and on receipt request. I don't know any good way for un-authenticated sender. Costin Isn=92t the Push-Receipt header supposed to associate each message with the= receipt subscription URI of the sender (application server) ? As I understand it, each push message request is supposed to look as follow= s =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97 POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 Host: push.example.net Content-Type: text/plain;charset=3Dutf8 Content-Length: 36 TTL: 5 Push-Receipt: https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97 That=92s my understanding but it would be good if someone else can confirm = it :-) Darshak --_000_D1A9FBD453ABdthakorecablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <24A6175DD34EAB4B994B64AA060813BE@cablelabs.com> Content-Transfer-Encoding: quoted-printable

On 6/15/15, 3:27 PM, "Costin Manolache" <costin@gmail.com> wrote:


The main = question remains: even if you have one URI per app server,
how do we= associate each message or app subscription to the URI
of the ap= p server. For authenticated sender - it can be done by matching
the authe= nticated ID on the message send and on receipt request. =
I don't k= now any good way for un-authenticated sender.

Costin

Isn=92t the Push-Receipt header supposed to associate each message wit= h the receipt subscription URI of the sender (application server) ?

As I understand it, each push message request is supposed to look as f= ollows

=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97
POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1
Host: push.example.net
Content-Type: text/plain;charset=3Dutf8
Content-Length: 36
TTL: 5
Push-Receipt: https://= push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN

iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97

That=92s my understanding but it would be good if someone else can con= firm it :-)

Darshak



--_000_D1A9FBD453ABdthakorecablelabscom_-- From nobody Fri Jun 19 16:16:01 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4A31A9056 for ; Fri, 19 Jun 2015 16:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 H6nmoutepzol for ; Fri, 19 Jun 2015 16:15:58 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id A8AD51A8FD6 for ; Fri, 19 Jun 2015 16:15:58 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t5JNFwkj030327; Fri, 19 Jun 2015 17:15:58 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 19 Jun 2015 17:15:57 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Fri, 19 Jun 2015 17:15:54 -0600 From: Darshak Thakore To: "Brian Raymor (MS OPEN TECH)" , "webpush@ietf.org" Thread-Topic: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCqHj9VdIsjhqcjQPeKa7MgtolfFwAx6ZGA Date: Fri, 19 Jun 2015 23:15:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <3147EC55CB60D247A32A9EB4C9CB60B1@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 19 Jun 2015 23:16:00 -0000 Hi Brian, Thanks for the explanation. I also managed to catch up on the other email exchanges and that clarifies it. The added suggested wording from Martin also helps. Darshak On 6/18/15, 11:04 PM, "Brian Raymor (MS OPEN TECH)" wrote: >Thanks for the review feedback, Darshak. I will respond to each section >in separate messages. > >On Thursday, Jun 18, 2015, Darshak Thakore >wrote: > >> Section 4 - The first sentence in the last paragraph >> "A push service SHOULD provide the same receipt subscribe URI to user >>agents". >> I'm trying to understand what this means. If we are referring to the >>"https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN" URI in >> the example in Section 4, how exactly does the push service provide >>this URI to the user-agent. > >Let me review the "how" first. > >In addition to the URI for the push resource (urn:ietf:params:push), the >push service also returns the URI for the receipt subscribe >resource (urn:ietf:params:push:receipt) to the User Agent during the >subscription process. >(https://tools.ietf.org/html/draft-thomson-webpush-protocol-00#section-3) > > The push server MUST provide a URI for a receipt subscribe resource > in a link relation of type "urn:ietf:params:push:receipt". > >In the examples, the receipt subscribe resource uses the >https://push.example.net/receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ URI. > >The User Agent then forwards both the URI(s) its application server: > > An application-specific method is used to distribute the push and > receipt subscribe URIs to the application server. > >The application server can then use the receipt subscribe URI to create a >receipt subscription >(https://tools.ietf.org/html/draft-thomson-webpush-protocol-00#section-4) >to receive receipts >from the push server >(https://tools.ietf.org/html/draft-thomson-webpush-protocol-00#section-6.2 >). > >In the examples, the receipt subscription resource is >https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN which is >the URI you're referencing above. > >> Is the intent to say that it should provide the same URI >> to a given application server? (I've marked this with the red arrow in >>the diagram) > >Recently, Martin developed this section further to provide more context: > =20 >https://github.com/unicorn-wg/webpush-protocol/commit/68c4c599314f9f4ca916 >831468ea7323605e6bcb > >Does this offer more clarity and answer your question? > >There were also earlier conversations on the rationale for the SHOULD >statement: > >https://github.com/unicorn-wg/webpush-protocol/commit/9fb7296585c7d69d1b84 >df837e1cf16c297ccb20#commitcomment-10675623 > > From nobody Fri Jun 19 17:21:02 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6841B2B33 for ; Fri, 19 Jun 2015 17:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZaETuAVNYEot for ; Fri, 19 Jun 2015 17:20:59 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 3220B1ACE53 for ; Fri, 19 Jun 2015 17:20:59 -0700 (PDT) Received: by ykfr66 with SMTP id r66so101768953ykf.0 for ; Fri, 19 Jun 2015 17:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hpLojq4SBmXL0L7NcaMHtR5JQD40sJiukfGI2f669PM=; b=f/U9AgCYYlYStp8sEIr4W1oEow/x+xRtHq4oWHgqN/59uxmc+atp+fzyKan7Eiuz79 WkHN0WMKn+sDm9Uk4uWS5vxL7E/81o02xm3ECc72V08l7toNUOapelXewHjj1qU+jaXh fdtxi8jyL4Gu0OwJ3Rv3wQOxWd1BEnAqUtokcpcdTN8yCgDZIg6myBsaoGsCVUTkQc8M IAB9i1KgMZkuc+U5W1Scb7lb85vNaxliGdP3TdE7Okgl4mGVTjMBwtJqp3oMuRdBfPRm u8RNgeLFM/jnvdXT/JPnwsJ7zEdriNHcwe8o1TQC088ogoJ0ExajvKYHDdii8w/TH2sQ jvBA== MIME-Version: 1.0 X-Received: by 10.129.36.14 with SMTP id k14mr22337433ywk.64.1434759658681; Fri, 19 Jun 2015 17:20:58 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 19 Jun 2015 17:20:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jun 2015 17:20:58 -0700 Message-ID: From: Martin Thomson To: Darshak Thakore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Costin Manolache , "webpush@ietf.org" Subject: Re: [Webpush] Delivery receipt question X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 20 Jun 2015 00:21:01 -0000 On 19 June 2015 at 16:14, Darshak Thakore wrote: > Isn=E2=80=99t the Push-Receipt header supposed to associate each message = with the > receipt subscription URI of the sender (application server) ? Yes, that header field can serve to correlate pushes from the same application server. From nobody Fri Jun 19 18:05:13 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8621B2C0D for ; Fri, 19 Jun 2015 18:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zKW3x5saGTRD for ; Fri, 19 Jun 2015 18:05:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEC21B2C0C for ; Fri, 19 Jun 2015 18:05:08 -0700 (PDT) Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0648.namprd03.prod.outlook.com (10.160.63.140) with Microsoft SMTP Server (TLS) id 15.1.190.14; Sat, 20 Jun 2015 01:04:48 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0190.013; Sat, 20 Jun 2015 01:04:48 +0000 From: "Brian Raymor (MS OPEN TECH)" To: Darshak Thakore , "webpush@ietf.org" Thread-Topic: RE: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCq6jHpnLbVz2p+SL+kq2BR/a0kPg== Date: Sat, 20 Jun 2015 01:04:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cablelabs.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2601:600:8080:1972:8021:8c8e:4b3d:7f14] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0648; 3:dRT0trq6e+ozkLzfDOiIfHYmTtVybHvyLpfI80esbbyeu1oepR5ZIqe4UDLiRoznK5ySS03lK0iLXY/4g6y5eR3ugUpzFpE+4HC2auhD56raxeUuj0vWTKoZ+G26zJSHKl/B4SywHNuOBfkVpvvbDQ==; 10:gCANWLMoryr6L9+ly5s6rWYImFvtKqVa0RhuPQyS72YHHOouQDnhQuf+NYF5VstwAQxU0FNp75wA3PQvjJ5y50pWFyaNIiPPPVx7Mpl2t30=; 6:p6oI5iYxfXq1Dyw7AWro2zila8teh73WElfcrT24aRK2nREZI5Sy8mfB6NGTuKC/ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR0301MB0648; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0648; x-forefront-prvs: 0613912E23 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(5003600100002)(74316001)(2900100001)(189998001)(87936001)(15975445007)(102836002)(86362001)(107886002)(46102003)(5001960100002)(122556002)(62966003)(33656002)(551934003)(92566002)(19580395003)(19580405001)(40100003)(77156002)(77096005)(5001770100001)(2656002)(99286002)(54356999)(2501003)(50986999)(76576001)(5002640100001)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0648; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2015 01:04:48.0652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0648 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 20 Jun 2015 01:05:11 -0000 On Thursday, Jun 18, 2015, Darshak Thakore wrote: > Section 5.1 - Would be useful to give an example of where/when the Push-R= eceipt header is sent and what the value looks like. > I'm guessing the example value should be=20 > "https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN" but it woul= d help to just explicitly show it. Note that I'm opening issues in our github repo to track responses to your = feedback. We could include the Push-Receipt header field in the earlier Section 5 exa= mple and then explain its use in Section 5.1. To be consistent with the oth= er examples, its value would be the example URI returned in Section 4: https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN > Also, as I understand it, if the application server does not want a=20 > push message receipt, it would not do anything that is specified in Secti= on 4 and so will also not send the Push-Receipt header. Is that correct? That is correct. > If so, does the Push Server still need to send back a 201 Created (with t= he Location header populated) or should it send back a 200 OK instead. I'm uncertain which operation or section is being referenced. Can you clari= fy? > To take an example of a push message for a call notification, the AS=20 > is expecting the notification to be delivered immediately and its going t= o get an inherent acknowledgement > by the mere fact that the actual app was woken up to receive the call. There's no guarantee that the message would be delivered immediately due to= intermittent connectivity. How does the application server know that the app has woken up and received= the call? > If stuff in Section 4 and Section 6.2 does not happen, can the=20 > interaction between the UA and the PS be simplified (the PS can itself=20 > delete the push message resource) This is a great question. It demonstrates that we need to clarify the relat= ionship between Acknowledgements and Receipts and their related scenarios. As outlined in https://tools.ietf.org/html/draft-thomson-webpush-protocol-0= 0#section-6.1, the intent for Acknowledgements: To ensure that a push message is properly delivered to the user agent at least once, the user agent MUST acknowledge receipt of the message by performing a HTTP DELETE on the push message resource. What's missing in this description is the requirement for the user agent to= receive AND process the message before acknowledging receipt. The device may have been interrup= ted after receiving=20 the message with resulting loss of state. Push Message Receipts can be configured when the Application Server also wa= nts to track the status.=20 There was more background on the motivation for the feature in the Introduction of https://tools.ietf.org/id/draft-damaggio-webpush-http2-00.t= xt : A push server that does not support reliable delivery over intermittent network connections or failing applications on devices, forces the device to acknowledge receipt directly to the application server, incurring additional power drain in order to establish (usually secure) connections to the individual application servers. While reliability is not required for messages that expire in few seconds (e.g. an incoming call) or collapsible ones (e.g. the current number of unread emails), it is more important when messages contain information that is longer lasting, e.g. a command to update a configuration value, or the acknowledgement of a financial transaction or workflow step. In particular, in the case of power- constrained devices, it is preferable to transmit the actual information in the "pushed" message reliably, instead of forcing them to reconnect periodically to get the current state. From nobody Fri Jun 19 23:50:27 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1341B2D57 for ; Fri, 19 Jun 2015 23:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no 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 AX9eI2FF7fK3 for ; Fri, 19 Jun 2015 23:50:20 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 2708E1B2D56 for ; Fri, 19 Jun 2015 23:50:20 -0700 (PDT) Received: by igbqq3 with SMTP id qq3so30992002igb.0 for ; Fri, 19 Jun 2015 23:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=epUPKhdhZFLduUnDUFyx5sB4iHeMkStearxctI+sqm0=; b=KxLrO1CNt6hjYPs/3ZvEGA/xeAxi9XhKvoq1eLHBNSuNFexY7w0aMiNNq0eamgJkjV 1TQCAW101vizZdCYBdefwUlDZlOQXMRqQZfXmMUj5R3dqh7ilGHHy7tAlseUsTYlu5xm 0O4IjiTlzt3P89qFlyyfm9sUDPaUXw1u0BIQ6OwAKgi2bvjM16aanphoCdus01/ozrkQ GHTOoCLwmCySIylG6OWL4RLHN5iYLznrt72Zdw1X3FYwRviyqsYS3AVU7+egtscc/Tng zIwTJbldSZzySFJyv5oADARH3uB4V3pYh6MTDjZh3QqkNmsG39BJls0Rg3rgNx+IqB2W UK9g== MIME-Version: 1.0 X-Received: by 10.107.30.10 with SMTP id e10mr27303526ioe.72.1434783019623; Fri, 19 Jun 2015 23:50:19 -0700 (PDT) Received: by 10.36.9.207 with HTTP; Fri, 19 Jun 2015 23:50:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jun 2015 23:50:19 -0700 Message-ID: From: Costin Manolache To: Darshak Thakore Content-Type: multipart/alternative; boundary=001a1140f33c36ec4a0518ed7479 Archived-At: Cc: Martin Thomson , "webpush@ietf.org" Subject: Re: [Webpush] Delivery receipt question X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 20 Jun 2015 06:50:22 -0000 --001a1140f33c36ec4a0518ed7479 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 19, 2015 at 4:14 PM, Darshak Thakore wrote: > > On 6/15/15, 3:27 PM, "Costin Manolache" wrote: > > > The main question remains: even if you have one URI per app server, > how do we associate each message or app subscription to the URI > of the app server. For authenticated sender - it can be done by matching > the authenticated ID on the message send and on receipt request. > I don't know any good way for un-authenticated sender. > > Costin > > > Isn=E2=80=99t the Push-Receipt header supposed to associate each message= with > the receipt subscription URI of the sender (application server) ? > > As I understand it, each push message request is supposed to look as > follows > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1 > Host: push.example.net > Content-Type: text/plain;charset=3Dutf8 > Content-Length: 36 > TTL: 5 > Push-Receipt: https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN > > iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > That=E2=80=99s my understanding but it would be good if someone else can= confirm > it :-) > Again - this is very similar with what I am proposing - the important thing missing is that in the current draft, there is no such thing as " receipt subscription URI of the sender (application server)". Only apps in UA subscribe - and the Push-Receipt returned is unique per app - since there is no way for anyone to determine that 2 app instances actually want to talk with the same app server. The sender is not identified, and it doesn't subscribe in the current spec. My proposal is to define that senders also subscribe - and get back some identifier ( subscription URL can act as an identifier ). In GCM - subscribe takes the sender ID as a parameter in subscribe, and sending has the sender ID in the authorization header, so it's clear where delivery receipts should be sent. Costin > > Darshak > > > > --001a1140f33c36ec4a0518ed7479 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 19, 2015 at 4:14 PM, Darshak Thakore <= d.thakore@cabl= elabs.com> wrote:

On 6/15/15, 3:27 PM, "Costin Manolache" <costin@gmail.com> wrote:


The main = question remains: even if you have one URI per app server,
how do we= associate each message or app subscription to the URI
of the ap= p server. For authenticated sender - it can be done by matching
the authe= nticated ID on the message send and on receipt request.=C2=A0=
I don'= ;t know any good way for un-authenticated sender.

Costin

Isn=E2=80=99t the Push-Receipt header supposed to associate eac= h message with the receipt subscription URI of the sender (application serv= er) ?

As I understand it, each push message request is supposed to look as f= ollows

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1
Content-Type: text/plain;charset=3Dutf8
Content-Length: 36
TTL: 5

iChYuI3jMzt3ir20P8r_jgRR-dSuN182x7iB
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

That=E2=80=99s my understanding but it would be good if someone else c= an confirm it :-)

Again - this = is very similar with what I am proposing - the important thing missing is t= hat in the current draft, there is no=C2=A0
such thing as "<= span style=3D"color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14p= x">=C2=A0receipt subscription URI of the sender (application ser= ver)". Only apps in UA subscribe - and=C2=A0
the = Push-Receipt returned is unique per app - since there is no way for anyone = to determine that 2 app instances
actually want to tal= k with the same app server.

= The sender is not identified, and it doesn't subscribe in the current s= pec. My proposal is to define that senders
also subscr= ibe - and get back some identifier ( subscription URL can act as an identif= ier ).

In GCM - subscribe takes the sender = ID as a parameter in subscribe, and sending has the sender ID in the author= ization
header, so it's clear where delivery receipts should = be sent.=C2=A0

Costin
=C2=A0

Darshak




--001a1140f33c36ec4a0518ed7479-- From nobody Mon Jun 22 01:16:13 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAFA1ACDE3 for ; Mon, 22 Jun 2015 01:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.391 X-Spam-Level: ** X-Spam-Status: No, score=2.391 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, SPF_HELO_PASS=-0.001] autolearn=no 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 Qf4nzn_MKRGh for ; Mon, 22 Jun 2015 01:16:09 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BBC1ACDEA for ; Mon, 22 Jun 2015 01:16:09 -0700 (PDT) Received: from [76.102.219.160] (port=44930 helo=[192.168.1.4]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Z6wtk-0005Qc-Ty for webpush@ietf.org; Mon, 22 Jun 2015 03:16:08 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2329D18B-EA76-4748-BC4C-7ADC4A135646@ntt-at.com> Date: Sun, 21 Jun 2015 21:26:06 -0700 To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 76.102.219.160 X-Exim-ID: 1Z6wtk-0005Qc-Ty X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [76.102.219.160]:44930 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Subject: [Webpush] Preliminary session slot X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 22 Jun 2015 08:16:12 -0000 All; Below is our meeting slot at Prague based on the preliminary agenda (not = finalized).=20 Jul 23rd 17:40-19:10=20 Thanks!=20 Shida= From nobody Mon Jun 22 11:47:37 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F901A1B8C for ; Mon, 22 Jun 2015 11:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 j9GPDJi9LNoa for ; Mon, 22 Jun 2015 11:47:34 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0299F1A1B8B for ; Mon, 22 Jun 2015 11:47:33 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t5MIlUe2026467; Mon, 22 Jun 2015 12:47:33 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 22 Jun 2015 12:47:29 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Mon, 22 Jun 2015 12:47:28 -0600 From: Darshak Thakore To: "Brian Raymor (MS OPEN TECH)" , "webpush@ietf.org" Thread-Topic: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCq6jHpdIsjhqcjQPeKa7MgtolfFwCMbHOA Date: Mon, 22 Jun 2015 18:47:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9EA46F94FFB5C442A64EB346480DB412@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 22 Jun 2015 18:47:35 -0000 Comments inline. On 6/19/15, 7:04 PM, "Brian Raymor (MS OPEN TECH)" wrote: >On Thursday, Jun 18, 2015, Darshak Thakore >wrote: > >> Section 5.1 - Would be useful to give an example of where/when the >>Push-Receipt header is sent and what the value looks like. >> I'm guessing the example value should be >> "https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN" but it >>would help to just explicitly show it. > >Note that I'm opening issues in our github repo to track responses to >your feedback. DT> Thanks, I did see the issues in the github repo and have it on my watch list. > >We could include the Push-Receipt header field in the earlier Section 5 >example and then explain its use in Section 5.1. To be consistent with >the other examples, its value would be the example URI returned in >Section 4: > > https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN DT> Yes that would be helpful to the readers. > >> Also, as I understand it, if the application server does not want a >> push message receipt, it would not do anything that is specified in >>Section 4 and so will also not send the Push-Receipt header. Is that >>correct? > >That is correct. > >> If so, does the Push Server still need to send back a 201 Created (with >>the Location header populated) or should it send back a 200 OK instead. > >I'm uncertain which operation or section is being referenced. Can you >clarify? DT> I=B9m referring to the exchange in Section 5 (POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1). In response to this post, the PS sends back a 201 Created with the URI of the push message resource (Location: https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk). The only reason for this URI to be provided to the application server is so that it can get a receipt for it later (with the synthesized GET request and the 410 GONE response code). However, if the application server doesn=B9t what receipts of messages, then the PS can send back a 200 OK instead of the 201 with Location. In this case, the PS can also immediately clear out the state of the push message resource as soon as its delivered to the UA and does not need to maintain it till the application server asks for the receipt. > >> To take an example of a push message for a call notification, the AS >> is expecting the notification to be delivered immediately and its going >>to get an inherent acknowledgement >> by the mere fact that the actual app was woken up to receive the call. > >There's no guarantee that the message would be delivered immediately due >to intermittent connectivity. >How does the application server know that the app has woken up and >received the call? DT> In this particular example, the application server doesn=B9t necessaril= y care if the user didn=B9t pick up a call because they wanted to or because the notification didn=B9t reach the app (for whatever reason). It would automatically know that there was no response since the app didn=B9t actually establish the call session and that=B9s enough for the application server to do whatever it needs to do (direct the other end-point to voicemail and/or send an actual confirmable notification to the app that there was a missed call etc). This is just one example, there are other IoT cases where the application server itself might be a constrained device and all its doing is sending some reading every so often (like a thermometer) and if one of the readings is missed, it wouldn=B9t matter so the application server doesn=B9t necessarily need to care for notification receipts. Darshak From nobody Wed Jun 24 15:11:42 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB8E1B2BFE for ; Wed, 24 Jun 2015 15:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ZwwR-VLCoYzA for ; Wed, 24 Jun 2015 15:11:39 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2131B2E5F for ; Wed, 24 Jun 2015 15:11:38 -0700 (PDT) Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) with Microsoft SMTP Server (TLS) id 15.1.201.16; Wed, 24 Jun 2015 22:11:36 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0201.000; Wed, 24 Jun 2015 22:11:36 +0000 From: "Brian Raymor (MS OPEN TECH)" To: Darshak Thakore , "webpush@ietf.org" Thread-Topic: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCuyBzIB8NkQU1gQlOKJUM9qgWYOA== Date: Wed, 24 Jun 2015 22:11:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cablelabs.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ed43::3] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:+a6EVW0UEnWAe8VYPF8Aj8FYSplST/3EB6fsSMveaNjSFlbpCJOReFgl0FWP7ttiCa/+n4VS8Z/KJ6vsLaZd4hzep0jBz52IdpMVE5WGD//L+f+GDW7uq5wjkqbnPIja2yE8nLbdIbauLC3oZbr92Q==; 24:Y452kB/1bobb6hh6RIWdmMwugdFkLA7twpgERXQsu5ZuI33krsUA4RO2OuHGLizH9VYx70Cnq0LTzhAXAPspx+QXbnkSb7CDvJJxetXXe9Y=; 20:+b0VUUmaG8KaqssLfVSrft1H7jwoWoy7tiVydqSn7J5iLoz7Y2m9FLtjhHkhVs1I+uF7Ah9dA45eQCxgznkmKg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001)(42139001); SRVR:BY2PR0301MB0647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(60444003)(24454002)(40100003)(77156002)(189998001)(5002640100001)(122556002)(62966003)(5003600100002)(92566002)(2501003)(76576001)(99286002)(230783001)(46102003)(74316001)(33656002)(19580405001)(19580395003)(86612001)(54356999)(50986999)(5001960100002)(107886002)(5001770100001)(15975445007)(102836002)(77096005)(87936001)(575784001)(2900100001)(86362001)(2656002)(3826002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2015 22:11:36.6432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2015 22:11:41 -0000 On Thursday, Jun 18, 2015, Darshak Thakore wrote: > Section 6 - Sentence in second last paragraph - =20 > "In response to this request, the push service SHOULD return link referen= ces to the push and receipt subscribe resources, plus expiration informatio= n"=20 > Are these the original URL's generated by the PS (i.e. /p/JzLQ3raZJfFBR0a= qvOMsLrt54w4rJUsV and /receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ)=20 > or are these the corresponding uri's generated in response to the applica= tion server's messages (i.e. r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN and > /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk).=20 The link references are the urn:ietf:params:push and urn:ietf:params:push:r= eceipt returned in the Subscription response. > Also I'm assuming here that the "expiration information" refers to the ex= piration info of the push messages=20 > (i.e their TTL), correct? I agree that "expiration information" is ambiguous in this context. The ref= erence is to subscription expirations.=20 For the moment, Martin has added a small clarification: https://github.com/unicorn-wg/webpush-protocol/commit/181b620837aa39276b0= a23b1a02d66f5f145cd0c This is another case that could be clarified with an example. From nobody Wed Jun 24 15:40:43 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8F1B2EF9 for ; Wed, 24 Jun 2015 15:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 HthT9XrRDbcu for ; Wed, 24 Jun 2015 15:40:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697B31B2EF0 for ; Wed, 24 Jun 2015 15:40:40 -0700 (PDT) Received: from BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) by BY2PR0301MB0647.namprd03.prod.outlook.com (10.160.63.14) with Microsoft SMTP Server (TLS) id 15.1.201.16; Wed, 24 Jun 2015 22:40:38 +0000 Received: from BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) by BY2PR0301MB0647.namprd03.prod.outlook.com ([10.160.63.14]) with mapi id 15.01.0201.000; Wed, 24 Jun 2015 22:40:38 +0000 From: "Brian Raymor (MS OPEN TECH)" To: Darshak Thakore , "webpush@ietf.org" Thread-Topic: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCuzhtd2DbwvJ3ARAGhLtss1tRQQA== Date: Wed, 24 Jun 2015 22:40:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cablelabs.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ed43::3] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0647; 5:YNOKjf2tBH+EvB919OQqKVupO9GrrcsYwgDokdj5bW0m40eK2Hyj4aZJb+GwM2G8GjajT8Zb+F8ZEutgvFZkO8lHr6BTp+ATSPKmNkwGVgnXzUb067h54Fd2eKJ3Qkl/zgB8SJVs3fk8sL75Oo0Arw==; 24:RuwodMNPqFQTXXMdzvd3G7vU0TekmISp8r9LWOsTbBI1XpOmQuwKweSeZcTMK207KnDscXM2yqaXvVFsIj/kTQBYvJegIKp6eswdqqWDGhg=; 20:Jb/RPBwUhGgQTVw54rv+uod4wkLkOp+NgVUVJR7ww/iwdPd4tJGbuPuVgPp4nWyVRXeQKY4Df69liR42K3cWeg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR0301MB0647; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0647; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(77156002)(5002640100001)(189998001)(122556002)(40100003)(62966003)(5003600100002)(92566002)(2501003)(76576001)(99286002)(230783001)(46102003)(74316001)(33656002)(19580405001)(19580395003)(86612001)(54356999)(50986999)(5001960100002)(107886002)(5001770100001)(15975445007)(102836002)(77096005)(87936001)(575784001)(86362001)(2656002)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0647; H:BY2PR0301MB0647.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2015 22:40:38.4015 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0647 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2015 22:40:42 -0000 On Thursday, Jun 18, 2015, Darshak Thakore wrote: > Push message prioritization - Would it make sense to use the Prefer heade= r instead of the TTL header. This would allow carrying prioritization info = for=20 > messages (the prioritization is only relative to the application server's= own set of messages) to be carried in the Prefer header (e.g. Prefer: prio= rity=3D5, wait=3D10). > Also the wait 0 can be used to indicate the equivalent of TTL 0 or we can= even define a new preference token. Dan Druta raised the question of priorities earlier on the mailing list. Th= e thread starts: https://mailarchive.ietf.org/arch/msg/webpush/7ltW-kU9katoRX6J0hlv-QAFplM There's also a related issue open on our github: https://github.com/unicorn-wg/webpush-protocol/issues/28 which references - https://tools.ietf.org/html/draft-thomson-http-nice-02 -= as an option to explore. It would be helpful to first clarify use cases and requirements as Dan conc= luded in the earlier thread? From nobody Wed Jun 24 16:13:16 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8AB1B2FA1 for ; Wed, 24 Jun 2015 16:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 cO8E750ACvJJ for ; Wed, 24 Jun 2015 16:13:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C26C1B2F56 for ; Wed, 24 Jun 2015 16:13:12 -0700 (PDT) Received: from BN1PR0301MB0626.namprd03.prod.outlook.com (10.160.171.11) by BN1PR0301MB0641.namprd03.prod.outlook.com (10.160.171.14) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 24 Jun 2015 23:13:10 +0000 Received: from BN1PR0301MB0626.namprd03.prod.outlook.com ([10.160.171.11]) by BN1PR0301MB0626.namprd03.prod.outlook.com ([10.160.171.11]) with mapi id 15.01.0195.005; Wed, 24 Jun 2015 23:13:10 +0000 From: Elio Damaggio To: Darshak Thakore , "Brian Raymor (MS OPEN TECH)" , "webpush@ietf.org" Thread-Topic: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCq6jHpdIsjhqcjQPeKa7MgtolfFwCMbHOAAG0bOWA= Date: Wed, 24 Jun 2015 23:13:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cablelabs.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::6] x-microsoft-exchange-diagnostics: 1; BN1PR0301MB0641; 5:WQPsrgDXHmfub6x+7JmdAlFRabx9A546P57kfUEenIxIN65inxIhdq6d4J4OsUTv//6yHKZAR0oN8dZfVZuDEjx/3u5lKBtEAV+l3cHPVrjpyug+1yMtNCpwXuEtvnRoQh42HxzKRQG8s/yieccrhg==; 24:Y7tmcYmIDm4/tTjKJYrdOOXNsrFbErEwysClEY77rbhEQ04ZXEOyrGfj/XAPI1tCzrmxBfGMrEbQKNggQacAT9bUwwPrGk83Es0PGWLme6M=; 20:9bRGmr6dRJHfgPXEgqmLab5BI4lpgKG8Vi9lR6sprS57IHhGcGRL89V40dDtv05XEatosmYbSRDTLjfgQYFF/A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR0301MB0641; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BN1PR0301MB0641; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0641; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(164054003)(26614003)(377454003)(51704005)(479174004)(5003600100002)(74316001)(1511001)(40100003)(87936001)(2656002)(33656002)(561944003)(62966003)(189998001)(77156002)(77096005)(575784001)(86362001)(102836002)(19580405001)(15975445007)(86612001)(2900100001)(5001960100002)(2421001)(19580395003)(107886002)(5002640100001)(5001920100001)(2950100001)(5001770100001)(46102003)(76576001)(50986999)(122556002)(54356999)(76176999)(2501003)(92566002)(230783001)(2561002)(99286002)(3826002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0641; H:BN1PR0301MB0626.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2015 23:13:10.3471 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0641 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2015 23:13:14 -0000 Hi Darshak, Comments inline. -----Original Message----- From: Webpush [mailto:webpush-bounces@ietf.org] On Behalf Of Darshak Thakor= e Sent: Monday, June 22, 2015 11:47 AM To: Brian Raymor (MS OPEN TECH); webpush@ietf.org Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webp= ush-protocol-00 Comments inline. On 6/19/15, 7:04 PM, "Brian Raymor (MS OPEN TECH)" wrote: >On Thursday, Jun 18, 2015, Darshak Thakore >wrote: > >> Section 5.1 - Would be useful to give an example of where/when the=20 >>Push-Receipt header is sent and what the value looks like. >> I'm guessing the example value should be =20 >>"https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN" but it=20 >>would help to just explicitly show it. > >Note that I'm opening issues in our github repo to track responses to=20 >your feedback. DT> Thanks, I did see the issues in the github repo and have it on my watch list. > >We could include the Push-Receipt header field in the earlier Section 5=20 >example and then explain its use in Section 5.1. To be consistent with=20 >the other examples, its value would be the example URI returned in=20 >Section 4: > > https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN DT> Yes that would be helpful to the readers. > >> Also, as I understand it, if the application server does not want a =20 >>push message receipt, it would not do anything that is specified in=20 >>Section 4 and so will also not send the Push-Receipt header. Is that=20 >>correct? > >That is correct. > >> If so, does the Push Server still need to send back a 201 Created=20 >>(with the Location header populated) or should it send back a 200 OK inst= ead. > >I'm uncertain which operation or section is being referenced. Can you=20 >clarify? DT> I=B9m referring to the exchange in Section 5 (POST /p/LBhhw0OohO-Wl4Oi971UGsB7sdQGUibx HTTP/1.1). In response to this post, th= e PS sends back a 201 Created with the URI of the push message resource (Location: https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk). The only reason for this URI to be provided to the application server is so= that it can get a receipt for it later (with the synthesized GET request a= nd the 410 GONE response code). However, if the application server doesn=B9= t what receipts of messages, then the PS can send back a 200 OK instead of = the 201 with Location. In this case, the PS can also immediately clear out = the state of the push message resource as soon as its delivered to the UA a= nd does not need to maintain it till the application server asks for the re= ceipt. Elio> The PS will not have to maintain any information regarding the state = of a notification. The reason is that the PS (as per proposal) does not sup= port a GET https://push.example.net/d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk call= to receive the receipts. The receipts are delivered as PUSH_PROMISEs to th= e AS only if the AS wants to (as detailed in Section 6.2). > >> To take an example of a push message for a call notification, the AS =20 >>is expecting the notification to be delivered immediately and its=20 >>going to get an inherent acknowledgement by the mere fact that the=20 >>actual app was woken up to receive the call. > >There's no guarantee that the message would be delivered immediately=20 >due to intermittent connectivity. >How does the application server know that the app has woken up and=20 >received the call? DT> In this particular example, the application server doesn=B9t=20 DT> necessarily care if the user didn=B9t pick up a call because they wanted to or because = the notification didn=B9t reach the app (for whatever reason). It would aut= omatically know that there was no response since the app didn=B9t actually = establish the call session and that=B9s enough for the application server t= o do whatever it needs to do (direct the other end-point to voicemail and/o= r send an actual confirmable notification to the app that there was a misse= d call etc). This is just one example, there are other IoT cases where the = application server itself might be a constrained device and all its doing i= s sending some reading every so often (like a thermometer) and if one of the readings is missed, it wouldn=B9t matter so = the application server doesn=B9t necessarily need to care for notification = receipts. Elio> I agree that there might be cases where an explicit ack is not requir= ed. Adding a flag to an incoming notification is a possible solution to avo= id sending the ack from the device for each notification. At this time we d= o not know the impact this will have on power consumption (having just rece= ived a notification the antenna is already in high gain) or the percentage = of notifications that will be affected. Darshak _______________________________________________ Webpush mailing list Webpush@ietf.org https://www.ietf.org/mailman/listinfo/webpush From nobody Tue Jun 30 10:16:55 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086F51B29B7 for ; Tue, 30 Jun 2015 10:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001] autolearn=ham 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 XIKdIcB3WMH2 for ; Tue, 30 Jun 2015 10:16:52 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9FB81AD374 for ; Tue, 30 Jun 2015 10:16:51 -0700 (PDT) Received: from [50.174.96.154] (port=36077 helo=[192.168.1.12]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Z9z9N-0002Fj-8S; Tue, 30 Jun 2015 12:16:49 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 30 Jun 2015 10:16:45 -0700 Message-Id: To: webpush@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 50.174.96.154 X-Exim-ID: 1Z9z9N-0002Fj-8S X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.12]) [50.174.96.154]:36077 X-Source-Auth: shida@agnada.com X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: webpush-chairs@tools.ietf.org Subject: [Webpush] WEBPUSH WG Meeting in Prague X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 30 Jun 2015 17:16:54 -0000 All, We have a 1.5 hour slot in Prague on Thursday night from 17:40 - 19:10. Please send any requests for agenda slots to the chair as soon as possible. As a reminder, the Internet Draft cutoff date is July 6th. Regards, Shida (as co-chair) From nobody Tue Jun 30 10:25:45 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135DA1A90FD for ; Tue, 30 Jun 2015 10:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 51xeQWdvltjz for ; Tue, 30 Jun 2015 10:25:41 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15DD81A90A6 for ; Tue, 30 Jun 2015 10:25:41 -0700 (PDT) Received: from [50.174.96.154] (port=48206 helo=[192.168.1.12]) by gator4135.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Z9zHw-0005BT-CC; Tue, 30 Jun 2015 12:25:40 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_FC675CC9-C18D-4634-AB4D-C502A5AACFA4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Shida Schubert In-Reply-To: <0067651F-8C90-44DC-BC27-FF6F4D53F654@ntt-at.com> Date: Tue, 30 Jun 2015 10:25:38 -0700 Message-Id: <2FC167C1-58A0-48B8-97C7-3C477D6AA92B@ntt-at.com> References: <0067651F-8C90-44DC-BC27-FF6F4D53F654@ntt-at.com> To: webpush@ietf.org X-Mailer: Apple Mail (2.2098) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 50.174.96.154 X-Exim-ID: 1Z9zHw-0005BT-CC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.12]) [50.174.96.154]:48206 X-Source-Auth: shida@agnada.com X-Email-Count: 4 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: Cc: webpush-chairs@tools.ietf.org Subject: Re: [Webpush] Adopting thomson-webpush-protocol-00 as WG item X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 30 Jun 2015 17:25:43 -0000 --Apple-Mail=_FC675CC9-C18D-4634-AB4D-C502A5AACFA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All,=20 I polled the list for adopting the draft in subject 2 weeks ago but saw = no feedback. I am trying to figure out what to make out of that. Seeing the discussion regarding the draft on the list, I am assuming = people do care.=20 Do people see reasons why the draft should not be adopted as a starting = point for working on the only milestone for the WG? If so I would = appreciate it if you can share what you want to see in the draft before = the draft is adopted as a WG item.=20 Thanks!=20 Shida (as co-chair) =20 > On Jun 14, 2015, at 10:00 PM, Shida Schubert wrote: >=20 > (as WG cochair) >=20 > We have a draft for the core push protocol: >=20 > https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt = >=20 > As mentioned at the last IETF, the call for adopting the merged draft = as the WG item was to be brought to the list as the two drafts presented = at the last IETF were merged. The draft referenced above is such draft, = so I am here to call the adoption of this draft as WG item. >=20 > Please respond by June 29th as to whether the text is acceptable to = adopt and work on as WG draft, or not.=20 >=20 > Regards >=20 > Shida --Apple-Mail=_FC675CC9-C18D-4634-AB4D-C502A5AACFA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All, 

I polled the list for adopting the = draft in subject 2 weeks ago but saw no feedback. I am trying to figure = out what to make out of that.

Seeing the discussion regarding the = draft on the list, I am assuming people do care. 

Do people see reasons = why the draft should not be adopted as a starting point for working on = the only milestone for the WG? If so I would appreciate it if you can = share what you want to see in the draft before the draft is adopted as a = WG item. 

Thanks! 
 Shida (as = co-chair)
 

On Jun 14, 2015, at 10:00 PM, = Shida Schubert <shida@ntt-at.com> wrote:

(as WG = cochair)

We have a draft for the core push = protocol:

https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt=

As mentioned at the last IETF, the = call for adopting the merged draft as the WG item was to be brought to = the list as the two drafts presented at the last IETF were merged. The = draft referenced above is such draft, so I am here to call the adoption = of  this draft as WG item.

Please respond by June 29th as to whether the = text is acceptable to adopt and work on as WG draft, or not. 

Regards

Shida

= --Apple-Mail=_FC675CC9-C18D-4634-AB4D-C502A5AACFA4-- From nobody Tue Jun 30 10:51:01 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F4F1B29CE for ; Tue, 30 Jun 2015 10:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 GdaAETnv4OGg for ; Tue, 30 Jun 2015 10:50:58 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 5A37F1ACD02 for ; Tue, 30 Jun 2015 10:50:58 -0700 (PDT) Received: by igblr2 with SMTP id lr2so17910955igb.0 for ; Tue, 30 Jun 2015 10:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0YnN/AALVkeUyYziXGj8UNqT9nibXGvbTcYGsGJpaRA=; b=gUCKK9JjDmHozYcvTTHokSbXLkRjY0vqYu3Tqxs3lKQo59s1t7HU0PZF5UiZzIgQJp NME3HI42v9An+K9p4LeZOsF/COwXtU1A8S1Zr/q4cQRxUVONtjOMYGhjEKeD/Rkvq5pv 4hA9XgpvvpMWaxf2GoQclLuO1+tEP2ZryUtVAtwzJBIeOFI/CthvcAzJ6dU7Aksau5Ic GL20NvBrjE8r7BQT9qsBK/wx9KpONDJwJxxOpzQDPZnzLmQQL7oajhn+TJcTNRTbl4pv 4XQ8CRPzGxIc+VOJre/s+NE9k8wW9Le6jfMJg9gJqLmWmk+Au0dzr9Qm/aHTPHxs2sAd mv8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0YnN/AALVkeUyYziXGj8UNqT9nibXGvbTcYGsGJpaRA=; b=cPMaFa4vQY1EP9f/LOL+O0hnI6xRql2hvdJEOKmj2fDrQqhO9OB4ie+yJFK+Y7nmns nyHMDksTPk+m7ntuEpd5Ke0HAduScmk+Og9Wl+G3jV1OMwcytCSuv2T24BxwQK7/SupG WJuYo8DYmG4+xPDvV5P83RX1FakqDxHneU7pA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=0YnN/AALVkeUyYziXGj8UNqT9nibXGvbTcYGsGJpaRA=; b=j25LHKUx9b0qfAo9ookzGWnzOQaQMCb37JAV3wf67SKNN6zV5/cIB93pAyjeJ8uM6o kzt6fpXr3LkOkezwvrjBfo9NKXjHGuxptzpXTQ9p98ACt+Jc45O+WTVPbq93hwTHvYEP HsWBpV7BnL8Aoq7jo2GSVcBeYQ0hewDSXS8O+WTDgEhKR/Kpl9w99dN4Umkqjd9LRPuD L6OXH8U5A1YtzRnjPT3vemp0zoOULyQ7VXTuVKftVzp/hr6KgUMC8Rt9LT4ZzJjIA7B3 JeCJURDBQREbxa+6l/xEEWIoByGu9zoS6Jr+P1ev53PuMBDpXQE6p8GT2i6CoS3991uK cHPw== X-Gm-Message-State: ALoCoQkVKEz5WTdxlEOLq+tgvA9t1nyjcdrYtlpU2x8qaVgaSZgS+WP9BBCc2gzGQ8CU31Rz6lEG X-Received: by 10.107.161.6 with SMTP id k6mr32420645ioe.41.1435686657567; Tue, 30 Jun 2015 10:50:57 -0700 (PDT) MIME-Version: 1.0 Sender: miguelg@google.com Received: by 10.64.77.73 with HTTP; Tue, 30 Jun 2015 10:50:37 -0700 (PDT) In-Reply-To: <2FC167C1-58A0-48B8-97C7-3C477D6AA92B@ntt-at.com> References: <0067651F-8C90-44DC-BC27-FF6F4D53F654@ntt-at.com> <2FC167C1-58A0-48B8-97C7-3C477D6AA92B@ntt-at.com> From: Miguel Garcia Date: Tue, 30 Jun 2015 18:50:37 +0100 X-Google-Sender-Auth: x79QPAHxtUzV3OMJWPii-_SPHy0 Message-ID: To: Shida Schubert Content-Type: multipart/alternative; boundary=001a1141bd963be4a80519bfd91c Archived-At: Cc: webpush@ietf.org, webpush-chairs@tools.ietf.org Subject: Re: [Webpush] Adopting thomson-webpush-protocol-00 as WG item X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 30 Jun 2015 17:51:00 -0000 --001a1141bd963be4a80519bfd91c Content-Type: text/plain; charset=UTF-8 We (Google) never replied to the first call (our apologies for that) due to some key members of the team being on vacation. While we have no issues with the draft being adopted we are currently only focused on developing section 5 and some extra work on that area is happening in https://tools.ietf.org/html/draft-thomson-webpush-encryption-00 as well so I think they will need to be merged at some point. This however does not need to block the adoption of https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt as the initial draft, the merge can happen later. On Tue, Jun 30, 2015 at 6:25 PM, Shida Schubert wrote: > All, > > I polled the list for adopting the draft in subject 2 weeks ago but saw no > feedback. I am trying to figure out what to make out of that. > > Seeing the discussion regarding the draft on the list, I am assuming > people do care. > > Do people see reasons why the draft should not be adopted as a starting > point for working on the only milestone for the WG? If so I would > appreciate it if you can share what you want to see in the draft before the > draft is adopted as a WG item. > > Thanks! > Shida (as co-chair) > > > On Jun 14, 2015, at 10:00 PM, Shida Schubert wrote: > > (as WG cochair) > > We have a draft for the core push protocol: > > https://tools.ietf.org/id/draft-thomson-webpush-protocol-00.txt > > As mentioned at the last IETF, the call for adopting the merged draft as > the WG item was to be brought to the list as the two drafts presented at > the last IETF were merged. The draft referenced above is such draft, so I > am here to call the adoption of this draft as WG item. > > Please respond by June 29th as to whether the text is acceptable to adopt > and work on as WG draft, or not. > > Regards > > Shida > > > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --001a1141bd963be4a80519bfd91c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We (Google) n= ever replied to the first call (our apologies for that) due to some key mem= bers of the team being on vacation.

While we h= ave no issues with the draft being adopted we are currently only focused on= developing section 5 and some extra work on that area is happening in=C2= =A0https://tools.ietf.org/html/draft-thomson-webpush-enc= ryption-00=C2=A0as well so I think they will need to be merged at some = point.

This however does not need to block the = adoption of=C2=A0https://tools.ietf.org/id/draft-thomson= -webpush-protocol-00.txt=C2=A0as the initial draft, the merge can happe= n later.

On Tue, Jun 30, 2015 at 6:25 PM, Shida Schubert <shida@ntt-at.com>= ; wrote:
All,=C2=A0

I polled the list for a= dopting the draft in subject 2 weeks ago but saw no feedback. I am trying t= o figure out what to make out of that.

Seeing the = discussion regarding the draft on the list, I am assuming people do care.= =C2=A0

Do people see reasons why the draft should = not be adopted as a starting point for working on the only milestone for th= e WG? If so I would appreciate it if you can share what you want to see in = the draft before the draft is adopted as a WG item.=C2=A0

Thanks!=C2=A0
=C2=A0Shida (as co-chair)
=C2=A0

On Jun = 14, 2015, at 10:00 PM, Shida Schubert <shida@ntt-at.com> wrote:

(as WG cochair)

We have a draft for the = core push protocol:

https://tools.ietf.org/id/dra= ft-thomson-webpush-protocol-00.txt

As mentioned at the last IETF= , the call for adopting the merged draft as the WG item was to be brought t= o the list as the two drafts presented at the last IETF were merged. The dr= aft referenced above is such draft, so I am here to call the adoption of = =C2=A0this draft as WG item.

Please respond by June 29th = as to whether the text is acceptable to adopt and work on as WG draft, or n= ot.=C2=A0

Regards

Shida


______________________________________= _________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush


--001a1141bd963be4a80519bfd91c-- From nobody Tue Jun 30 16:15:31 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E611B334B for ; Tue, 30 Jun 2015 16:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 gwAPCZge4abd for ; Tue, 30 Jun 2015 16:15:28 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4345A1B3343 for ; Tue, 30 Jun 2015 16:15:20 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t5UNFJwE031356; Tue, 30 Jun 2015 17:15:19 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 30 Jun 2015 17:15:04 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 17:15:15 -0600 From: Darshak Thakore To: Elio Damaggio , "Brian Raymor (MS OPEN TECH)" , "webpush@ietf.org" Thread-Topic: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCq6jHpdIsjhqcjQPeKa7MgtolfFwCMbHOAAG0bOWAA83LhAA== Date: Tue, 30 Jun 2015 23:15:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="euc-kr" Content-ID: <19A7E809E7CE784E8460005653CBC679@cablelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 30 Jun 2015 23:15:29 -0000 SGkgRWxpbywNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBJIGRvIGhhdmUgYSBmb2xsb3cgdXAg Y29tbWVudCBtZW50aW9uZWQgYmVsb3cuLg0KDQpPbiA2LzI0LzE1LCA1OjEzIFBNLCAiRWxpbyBE YW1hZ2dpbyIgPGVsaW9kYUBtaWNyb3NvZnQuY29tPiB3cm90ZToNCg0KPkhpIERhcnNoYWssDQo+ DQo+Q29tbWVudHMgaW5saW5lLg0KPg0KPj4NCj4+PiBJZiBzbywgZG9lcyB0aGUgUHVzaCBTZXJ2 ZXIgc3RpbGwgbmVlZCB0byBzZW5kIGJhY2sgYSAyMDEgQ3JlYXRlZA0KPj4+KHdpdGggdGhlIExv Y2F0aW9uIGhlYWRlciBwb3B1bGF0ZWQpIG9yIHNob3VsZCBpdCBzZW5kIGJhY2sgYSAyMDAgT0sN Cj4+Pmluc3RlYWQuDQo+Pg0KPj5JJ20gdW5jZXJ0YWluIHdoaWNoIG9wZXJhdGlvbiBvciBzZWN0 aW9uIGlzIGJlaW5nIHJlZmVyZW5jZWQuIENhbiB5b3UNCj4+Y2xhcmlmeT8NCj4NCj5EVD4gSan2 bSByZWZlcnJpbmcgdG8gdGhlIGV4Y2hhbmdlIGluIFNlY3Rpb24gNSAoUE9TVA0KPi9wL0xCaGh3 ME9vaE8tV2w0T2k5NzFVR3NCN3NkUUdVaWJ4IEhUVFAvMS4xKS4gSW4gcmVzcG9uc2UgdG8gdGhp cyBwb3N0LA0KPnRoZSBQUyBzZW5kcyBiYWNrIGEgMjAxIENyZWF0ZWQgd2l0aCB0aGUgVVJJIG9m IHRoZSBwdXNoIG1lc3NhZ2UgcmVzb3VyY2UNCj4oTG9jYXRpb246IGh0dHBzOi8vcHVzaC5leGFt cGxlLm5ldC9kL3FESVlITmNmQUlQUF81SVR2VVJyLWQ2Qkd0WW5UUm5rKS4NCj5UaGUgb25seSBy ZWFzb24gZm9yIHRoaXMgVVJJIHRvIGJlIHByb3ZpZGVkIHRvIHRoZSBhcHBsaWNhdGlvbiBzZXJ2 ZXIgaXMNCj5zbyB0aGF0IGl0IGNhbiBnZXQgYSByZWNlaXB0IGZvciBpdCBsYXRlciAod2l0aCB0 aGUgc3ludGhlc2l6ZWQgR0VUDQo+cmVxdWVzdCBhbmQgdGhlIDQxMCBHT05FIHJlc3BvbnNlIGNv ZGUpLiBIb3dldmVyLCBpZiB0aGUgYXBwbGljYXRpb24NCj5zZXJ2ZXIgZG9lc26p9nQgd2hhdCBy ZWNlaXB0cyBvZiBtZXNzYWdlcywgdGhlbiB0aGUgUFMgY2FuIHNlbmQgYmFjayBhIDIwMA0KPk9L IGluc3RlYWQgb2YgdGhlIDIwMSB3aXRoIExvY2F0aW9uLiBJbiB0aGlzIGNhc2UsIHRoZSBQUyBj YW4gYWxzbw0KPmltbWVkaWF0ZWx5IGNsZWFyIG91dCB0aGUgc3RhdGUgb2YgdGhlIHB1c2ggbWVz c2FnZSByZXNvdXJjZSBhcyBzb29uIGFzDQo+aXRzIGRlbGl2ZXJlZCB0byB0aGUgVUEgYW5kIGRv ZXMgbm90IG5lZWQgdG8gbWFpbnRhaW4gaXQgdGlsbCB0aGUNCj5hcHBsaWNhdGlvbiBzZXJ2ZXIg YXNrcyBmb3IgdGhlIHJlY2VpcHQuDQo+DQo+RWxpbz4gVGhlIFBTIHdpbGwgbm90IGhhdmUgdG8g bWFpbnRhaW4gYW55IGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUNCj5zdGF0ZSBvZiBhIG5vdGlm aWNhdGlvbi4gVGhlIHJlYXNvbiBpcyB0aGF0IHRoZSBQUyAoYXMgcGVyIHByb3Bvc2FsKSBkb2Vz DQo+bm90IHN1cHBvcnQgYSBHRVQgDQo+aHR0cHM6Ly9wdXNoLmV4YW1wbGUubmV0L2QvcURJWUhO Y2ZBSVBQXzVJVHZVUnItZDZCR3RZblRSbmsgY2FsbCB0bw0KPnJlY2VpdmUgdGhlIHJlY2VpcHRz LiBUaGUgcmVjZWlwdHMgYXJlIGRlbGl2ZXJlZCBhcyBQVVNIX1BST01JU0VzIHRvIHRoZQ0KPkFT IG9ubHkgaWYgdGhlIEFTIHdhbnRzIHRvIChhcyBkZXRhaWxlZCBpbiBTZWN0aW9uIDYuMikuDQoN CkRUPj4gVGhhbmtzIGZvciB0aGUgY29ycmVjdGlvbiBvbiB0aGUgR0VULiBJIHdhcyByZWZlcnJp bmcgdG8gdGhlIDQxMCBHT05FDQpQVVNIX1BST01JU0UgDQptZXNzYWdlIHRoYXQgaXMgc2VudCBi eSB0aGUgUFMuIFNlY3Rpb24gNi4yIGV4cGxhaW5zIGhvdyBhbiBBUyByZXF1ZXN0cw0KcHVzaCBy ZWNlaXB0cy4gDQpIb3dldmVyIGl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIEFTIG1heSBub3QgcmVx dWVzdCBwdXNoIHJlY2VpcHRzDQppbW1lZGlhdGVseSwNCnNwZWNpZmljYWxseSBpbiBJb1QgbGlr ZSBzY2VuYXJpb3Mgd2hlcmUgdGhlIEFTIGl0c2VsZiBtYXkgZ29lcyB0byBzbGVlcA0KaW50ZXJt aXR0ZW50bHkuDQpJbiBzdWNoIGNhc2VzLCB0aGUgUFMgd291bGQgYXRsZWFzdCBuZWVkIHRvIHN0 b3JlIHRoZSBpbmZvcm1hdGlvbiB0aGF0IGENCnBhcnRpY3VsYXINCk1lc3NhZ2Ugd2FzIGRlbGl2 ZXJlZCBhbmQgZXZlbiB0aG91Z2ggdGhlIG1lc3NhZ2UgaXRzZWxmIGdvdCBkZWxldGVkIChieQ0K dGhlIERFTEVURQ0KT3BlcmF0aW9uIGluIFNlY3Rpb24gNi4xKSwgaXQgaGFzIHRvIHN0b3JlIHRo ZSBVUkkgYW5kIG90aGVyIG1ldGEgaW5mbw0KdGlsbCBpdCBzZW5kcyANCnRoZSBQVVNIX1BST01J U0UgdG8gdGhlIEFTLiBGb3IgdGhlIHNpdHVhdGlvbnMgd2hlcmUgdGhlIEFTIGhhcyByZXF1ZXN0 ZWQNCnRoZSBwdXNoIHJlY2VpcHQsIHRoZSBQUw0KaGFzIG5vdCBjaG9pY2UgYnV0IHRvIHN0b3Jl IHRoYXQgaW5mb3JtYXRpb24gdGlsbCBpdCBzZW5kcyB0aGUgUFAuIEhvd2V2ZXINCmlmIHRoZSBB Uw0KSXMgbm90IGxvb2tpbmcgdG8gZ2V0IGEgcmVjZWlwdCAod2hpY2ggc2hvdWxkIGJlIGZsYWdn ZWQgYnkgdGhlIGxhY2sgb2YNCnRoZSBQdXNoLVJlY2VpcHQgaGVhZGVyIHdoZW4NClJlcXVlc3Rp bmcgcHVzaCBtZXNzYWdlIGRlbGl2ZXJ5IGFzIHBlciBTZWN0aW9uIDUpLCB0aGUgUFMgY2FuIGNv bXBsZXRlbHkNCqGwZm9yZ2V0obEgdGhlIG1lc3NhZ2UNClRoYXQgd2FzIGRlbGl2ZXJlZC4NCg0K DQoNCg0KPg0KPj4NCj4+PiBUbyB0YWtlIGFuIGV4YW1wbGUgb2YgYSBwdXNoIG1lc3NhZ2UgZm9y IGEgY2FsbCBub3RpZmljYXRpb24sIHRoZSBBUw0KPj4+aXMgZXhwZWN0aW5nIHRoZSBub3RpZmlj YXRpb24gdG8gYmUgZGVsaXZlcmVkIGltbWVkaWF0ZWx5IGFuZCBpdHMNCj4+PmdvaW5nIHRvIGdl dCBhbiBpbmhlcmVudCBhY2tub3dsZWRnZW1lbnQgIGJ5IHRoZSBtZXJlIGZhY3QgdGhhdCB0aGUN Cj4+PmFjdHVhbCBhcHAgd2FzIHdva2VuIHVwIHRvIHJlY2VpdmUgdGhlIGNhbGwuDQo+Pg0KPj5U aGVyZSdzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZSBtZXNzYWdlIHdvdWxkIGJlIGRlbGl2ZXJlZCBp bW1lZGlhdGVseQ0KPj5kdWUgdG8gaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eS4NCj4+SG93IGRv ZXMgdGhlIGFwcGxpY2F0aW9uIHNlcnZlciBrbm93IHRoYXQgdGhlIGFwcCBoYXMgd29rZW4gdXAg YW5kDQo+PnJlY2VpdmVkIHRoZSBjYWxsPw0KPg0KPkRUPiBJbiB0aGlzIHBhcnRpY3VsYXIgZXhh bXBsZSwgdGhlIGFwcGxpY2F0aW9uIHNlcnZlciBkb2Vzbqn2dA0KPkRUPiBuZWNlc3NhcmlseQ0K PmNhcmUgaWYgdGhlIHVzZXIgZGlkbqn2dCBwaWNrIHVwIGEgY2FsbCBiZWNhdXNlIHRoZXkgd2Fu dGVkIHRvIG9yIGJlY2F1c2UNCj50aGUgbm90aWZpY2F0aW9uIGRpZG6p9nQgcmVhY2ggdGhlIGFw cCAoZm9yIHdoYXRldmVyIHJlYXNvbikuIEl0IHdvdWxkDQo+YXV0b21hdGljYWxseSBrbm93IHRo YXQgdGhlcmUgd2FzIG5vIHJlc3BvbnNlIHNpbmNlIHRoZSBhcHAgZGlkbqn2dA0KPmFjdHVhbGx5 IGVzdGFibGlzaCB0aGUgY2FsbCBzZXNzaW9uIGFuZCB0aGF0qfZzIGVub3VnaCBmb3IgdGhlIGFw cGxpY2F0aW9uDQo+c2VydmVyIHRvIGRvIHdoYXRldmVyIGl0IG5lZWRzIHRvIGRvIChkaXJlY3Qg dGhlIG90aGVyIGVuZC1wb2ludCB0bw0KPnZvaWNlbWFpbCBhbmQvb3Igc2VuZCBhbiBhY3R1YWwg Y29uZmlybWFibGUgbm90aWZpY2F0aW9uIHRvIHRoZSBhcHAgdGhhdA0KPnRoZXJlIHdhcyBhIG1p c3NlZCBjYWxsIGV0YykuIFRoaXMgaXMganVzdCBvbmUgZXhhbXBsZSwgdGhlcmUgYXJlIG90aGVy DQo+SW9UIGNhc2VzIHdoZXJlIHRoZSBhcHBsaWNhdGlvbiBzZXJ2ZXIgaXRzZWxmIG1pZ2h0IGJl IGEgY29uc3RyYWluZWQNCj5kZXZpY2UgYW5kIGFsbCBpdHMgZG9pbmcgaXMgc2VuZGluZyBzb21l IHJlYWRpbmcgZXZlcnkgc28gb2Z0ZW4gKGxpa2UgYQ0KPnRoZXJtb21ldGVyKSBhbmQgaWYgb25l IG9mIHRoZSByZWFkaW5ncyBpcyBtaXNzZWQsIGl0IHdvdWxkbqn2dCBtYXR0ZXIgc28NCj50aGUg YXBwbGljYXRpb24gc2VydmVyIGRvZXNuqfZ0IG5lY2Vzc2FyaWx5IG5lZWQgdG8gY2FyZSBmb3Ig bm90aWZpY2F0aW9uDQo+cmVjZWlwdHMuDQo+DQo+RWxpbz4gSSBhZ3JlZSB0aGF0IHRoZXJlIG1p Z2h0IGJlIGNhc2VzIHdoZXJlIGFuIGV4cGxpY2l0IGFjayBpcyBub3QNCj5yZXF1aXJlZC4gQWRk aW5nIGEgZmxhZyB0byBhbiBpbmNvbWluZyBub3RpZmljYXRpb24gaXMgYSBwb3NzaWJsZQ0KPnNv bHV0aW9uIHRvIGF2b2lkIHNlbmRpbmcgdGhlIGFjayBmcm9tIHRoZSBkZXZpY2UgZm9yIGVhY2gg bm90aWZpY2F0aW9uLg0KPkF0IHRoaXMgdGltZSB3ZSBkbyBub3Qga25vdyB0aGUgaW1wYWN0IHRo aXMgd2lsbCBoYXZlIG9uIHBvd2VyDQo+Y29uc3VtcHRpb24gKGhhdmluZyBqdXN0IHJlY2VpdmVk IGEgbm90aWZpY2F0aW9uIHRoZSBhbnRlbm5hIGlzIGFscmVhZHkNCj5pbiBoaWdoIGdhaW4pIG9y IHRoZSBwZXJjZW50YWdlIG9mIG5vdGlmaWNhdGlvbnMgdGhhdCB3aWxsIGJlIGFmZmVjdGVkLg0K DQpEVD4+IEkgYWdyZWUgdGhhdCB3aGVuIHRoZSBVQS9hcHBzIGFyZSBhbHJlYWR5IHVwIGFuZCBn ZXR0aW5nIHRoZQ0Kbm90aWZpY2F0aW9ucywNClNlbmRpbmcgdGhlIGFjayBmcm9tIHRoZSBVQSB0 byB0aGUgUFMgKEkuZSB0aGUgZXhwbGljaXQgREVMRVRFIG9wZXJhdGlvbikNCmlzIG5vdCBhDQpI dWdlIGJ1cmRlbi4gQXMgbWVudGlvbmVkIGFib3ZlLCBJIHdhcyByZWZlcnJpbmcgbW9yZSB0aGUg YW1vdW50IG9mIHdvcmsNCnRoYXQgdGhlIFBTDQpIYXMgdG8gZG8gYW5kIHRoZSBhbW91bnQgb2Yg bWV0YWRhdGEgaXQgaGFzIHRvIHN0b3JlLg0KDQoNCg0KDQo= From nobody Tue Jun 30 16:22:38 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205751B335A for ; Tue, 30 Jun 2015 16:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 KS1X-ANpzc37 for ; Tue, 30 Jun 2015 16:22:36 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id E71D71B3359 for ; Tue, 30 Jun 2015 16:22:35 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t5UNMZ8U031950; Tue, 30 Jun 2015 17:22:35 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 30 Jun 2015 17:22:20 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 17:22:31 -0600 From: Darshak Thakore To: "Brian Raymor (MS OPEN TECH)" , "webpush@ietf.org" Thread-Topic: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCuyBzIdIsjhqcjQPeKa7MgtolfFwEw4dmA Date: Tue, 30 Jun 2015 23:22:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 30 Jun 2015 23:22:37 -0000 Thanks for the clarification Brian. So I=B9m trying to understand why is it needed to send the =B3:push=B2 and = the =B3:push:receipt=B2 URI=B9s when the =B3Prefer: wait=3D0=B2 is sent by the = UA? Is the expectation that those URI=B9s will expire after that particular connection is concluded (I.e. After all undelivered push messages have been delivered)? Or is there some other purpose that I=B9m missing ? Darshak On 6/24/15, 4:11 PM, "Brian Raymor (MS OPEN TECH)" wrote: >On Thursday, Jun 18, 2015, Darshak Thakore >wrote: > >> Section 6 - Sentence in second last paragraph - >> "In response to this request, the push service SHOULD return link >>references to the push and receipt subscribe resources, plus expiration >>information"=20 >> Are these the original URL's generated by the PS (i.e. >>/p/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV and >>/receipts/xjTG79I3VuptNWS0DsFu4ihT97aE6UQJ) >> or are these the corresponding uri's generated in response to the >>application server's messages (i.e. r/3ZtI4YVNBnUUZhuoChl6omUvG4ZM9mpN >>and >> /d/qDIYHNcfAIPP_5ITvURr-d6BGtYnTRnk). > >The link references are the urn:ietf:params:push and >urn:ietf:params:push:receipt returned in the Subscription response. > >> Also I'm assuming here that the "expiration information" refers to the >>expiration info of the push messages >> (i.e their TTL), correct? > >I agree that "expiration information" is ambiguous in this context. The >reference is to subscription expirations. >For the moment, Martin has added a small clarification: > =20 >https://github.com/unicorn-wg/webpush-protocol/commit/181b620837aa39276b0a >23b1a02d66f5f145cd0c > >This is another case that could be clarified with an example. From nobody Tue Jun 30 16:31:48 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6971B1AD364 for ; Tue, 30 Jun 2015 16:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 SJgQb4ZQyITA for ; Tue, 30 Jun 2015 16:31:45 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 3EB4E1AD352 for ; Tue, 30 Jun 2015 16:31:45 -0700 (PDT) Received: by ykdr198 with SMTP id r198so24018462ykd.3 for ; Tue, 30 Jun 2015 16:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Vp2j8q8+uQHjaf5smmS64FFs0ObVSKYsFaVZc5z6N14=; b=tPKzJ1bkehzzBjXSEYXB4au00zL8yTxegmdB1eEPl8mPQskQRs1kcjUbTD2UJe4UHD d0q3jwrN57qcuJ8RhyW8+I9WE3Gt90CcMH0nh9E0W1TVLSG2fzYbH3N5kcHGV23/g7rc lIg0ufQlu9F2haYwIZPkxIYIrlJ9vcH4S5z4m2XhLyh978nMUIvSCuyqYozyBr4gwJ3z P7jXdKqM7R7qBQ7RPnvQ3eSHQ5WSXXHkN65kEJL/Z5SXKIcwhGk52BT+iGGSxbkMFsVI q6hDppferolUg5AO70VsCkcL9KgOoB84s1O/X6XupsKsPm0VPUdsH2FLjJ0irF66bw+b CNCA== MIME-Version: 1.0 X-Received: by 10.170.160.4 with SMTP id b4mr15744477ykd.26.1435707104082; Tue, 30 Jun 2015 16:31:44 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 30 Jun 2015 16:31:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jun 2015 16:31:44 -0700 Message-ID: From: Martin Thomson To: Darshak Thakore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Brian Raymor \(MS OPEN TECH\)" , "webpush@ietf.org" Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 30 Jun 2015 23:31:46 -0000 On 30 June 2015 at 16:22, Darshak Thakore wrote: > So I=C2=B9m trying to understand why is it needed to send the =C2=B3:push= =C2=B2 and the > =C2=B3:push:receipt=C2=B2 URI=C2=B9s when the =C2=B3Prefer: wait=3D0=C2= =B2 is sent by the UA? This means that a client need only hold the subscription URL; it can re-learn the push and receipt subscribe resources by making this request. And inclusion of these links need not be based on receiving Prefer: wait=3D0, though other requests might longer to complete than would be ideal (or useful). From nobody Tue Jun 30 17:31:00 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F7A1A00E8 for ; Tue, 30 Jun 2015 17:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 4OEPKEGAClag for ; Tue, 30 Jun 2015 17:30:57 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B23C11A00E5 for ; Tue, 30 Jun 2015 17:30:57 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t610UucM006483; Tue, 30 Jun 2015 18:30:56 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 30 Jun 2015 18:30:41 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 18:30:53 -0600 From: Darshak Thakore To: Martin Thomson Thread-Topic: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCuyBzIdIsjhqcjQPeKa7MgtolfFwEw4dmAAAzkwQD//6vzgA== Date: Wed, 1 Jul 2015 00:30:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="euc-kr" Content-ID: <726695F45191FE429E9DD3BDFBBDFCE5@cablelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Brian Raymor \(MS OPEN TECH\)" , "webpush@ietf.org" Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 00:30:58 -0000 QWhoLi4gVGhhbmtzLiANCkluIHRoZSBsaWdodCBvZiB0aGlzIGV4cGxhbmF0aW9uLCBpdCBzZWVt cyB0byBiZSBqdXN0IHNvbWUgd29yZC1zbWl0aGluZw0KcHJvYmxlbS4NCg0KTWlnaHQgSSBzdWdn ZXN0IHRoYXQgeW91IG1vdmUgdGhlIHNlbnRlbmNlOg0KIkEgdXNlciBhZ2VudCBjYW4gcmVxdWVz dCB0aGUgY29udGVudHMgb2YgdGhlIHB1c2ggbWVzc2FnZSBzdWJzY3JpcHRpb24NCnJlc291cmNl IGltbWVkaWF0ZWx5IGJ5IGluY2x1ZGluZyBhIFByZWZlciBoZWFkZXIgZmllbGQgW1JGQzcyNDBd IHdpdGggYQ0KIndhaXQiIHBhcmFtZXRlciBzZXQgdG8gobAwLqGxDQoNCg0KdG8gYmUgYWZ0ZXIg dGhlIHNlbnRlbmNlOg0KDQoiSW4gcmVzcG9uc2UgdG8gdGhpcyByZXF1ZXN0LCB0aGUgcHVzaCBz ZXJ2aWNlIFNIT1VMRCByZXR1cm4gbGluaw0KcmVmZXJlbmNlcyB0byB0aGUgcHVzaCBhbmQgcmVj ZWlwdCBzdWJzY3JpYmUgcmVzb3VyY2VzLCBwbHVzIGV4cGlyYXRpb24NCmluZm9ybWF0aW9uIGZv ciB0aGUgc3Vic2NyaXB0aW9uLiINCg0KVGhhdCB3YXkgdGhlIHJlY29tbWVuZGF0aW9uIGZvciB0 aGUgUFMgdG8gc2VuZCB0aGUgbGluayByZWZlcmVuY2VzIGRvZXMNCm5vdCBnZXQgYXNzb2NpYXRl ZCAoYXMgSSBtaXN0YWtlbmx5IGRpZCkgd2l0aCB0aGUgcmVxdWVzdCB0aGF0IGNvbnRhaW5zDQqh sFByZWZlcjogd2FpdD0wobEgaGVhZGVyLg0KDQpEYXJzaGFrDQoNCg0KT24gNi8zMC8xNSwgNToz MSBQTSwgIk1hcnRpbiBUaG9tc29uIiA8bWFydGluLnRob21zb25AZ21haWwuY29tPiB3cm90ZToN Cg0KPk9uIDMwIEp1bmUgMjAxNSBhdCAxNjoyMiwgRGFyc2hhayBUaGFrb3JlIDxkLnRoYWtvcmVA Y2FibGVsYWJzLmNvbT4gd3JvdGU6DQo+PiBTbyBJqfZtIHRyeWluZyB0byB1bmRlcnN0YW5kIHdo eSBpcyBpdCBuZWVkZWQgdG8gc2VuZCB0aGUgqfg6cHVzaKn3IGFuZCB0aGUNCj4+IKn4OnB1c2g6 cmVjZWlwdKn3IFVSSan2cyB3aGVuIHRoZSCp+FByZWZlcjogd2FpdD0wqfcgaXMgc2VudCBieSB0 aGUgVUE/DQo+DQo+DQo+VGhpcyBtZWFucyB0aGF0IGEgY2xpZW50IG5lZWQgb25seSBob2xkIHRo ZSBzdWJzY3JpcHRpb24gVVJMOyBpdCBjYW4NCj5yZS1sZWFybiB0aGUgcHVzaCBhbmQgcmVjZWlw dCBzdWJzY3JpYmUgcmVzb3VyY2VzIGJ5IG1ha2luZyB0aGlzDQo+cmVxdWVzdC4NCj4NCj5BbmQg aW5jbHVzaW9uIG9mIHRoZXNlIGxpbmtzIG5lZWQgbm90IGJlIGJhc2VkIG9uIHJlY2VpdmluZyBQ cmVmZXI6DQo+d2FpdD0wLCB0aG91Z2ggb3RoZXIgcmVxdWVzdHMgbWlnaHQgbG9uZ2VyIHRvIGNv bXBsZXRlIHRoYW4gd291bGQgYmUNCj5pZGVhbCAob3IgdXNlZnVsKS4NCg0K From nobody Tue Jun 30 18:04:00 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5411A1BD2 for ; Tue, 30 Jun 2015 18:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 kIw5B3b7B3YV for ; Tue, 30 Jun 2015 18:03:54 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 83F771A1BB1 for ; Tue, 30 Jun 2015 18:03:54 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id t6113rgS009270; Tue, 30 Jun 2015 19:03:53 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 30 Jun 2015 19:03:38 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 19:03:50 -0600 From: Darshak Thakore To: "Brian Raymor (MS OPEN TECH)" , "webpush@ietf.org" Thread-Topic: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 Thread-Index: AdCuzhtddIsjhqcjQPeKa7MgtolfFwEy7AsA Date: Wed, 1 Jul 2015 01:03:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <269D3C432266D042AE7E3201C212A3F9@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 01:03:58 -0000 I did look at that thread and the issue. I=B9m not necessarily suggesting that we solve the prioritization problem i= n this draft itself. I agree that we first need to gather use cases and requirements. All I was suggesting for now is that given that the Prefer header is a good candidate to carry such information, can we for now also use it to carry the TTL semantics instead of defining a new header. Darshak On 6/24/15, 4:40 PM, "Brian Raymor (MS OPEN TECH)" wrote: >On Thursday, Jun 18, 2015, Darshak Thakore >wrote: > >> Push message prioritization - Would it make sense to use the Prefer >>header instead of the TTL header. This would allow carrying >>prioritization info for >> messages (the prioritization is only relative to the application >>server's own set of messages) to be carried in the Prefer header (e.g. >>Prefer: priority=3D5, wait=3D10). >> Also the wait 0 can be used to indicate the equivalent of TTL 0 or we >>can even define a new preference token. > >Dan Druta raised the question of priorities earlier on the mailing list. >The thread starts: > =20 >https://mailarchive.ietf.org/arch/msg/webpush/7ltW-kU9katoRX6J0hlv-QAFplM > >There's also a related issue open on our github: > https://github.com/unicorn-wg/webpush-protocol/issues/28 >which references - https://tools.ietf.org/html/draft-thomson-http-nice-02 >- as an option to explore. > >It would be helpful to first clarify use cases and requirements as Dan >concluded in the earlier >thread? > > > > From nobody Tue Jun 30 21:06:54 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140AA1A9075 for ; Tue, 30 Jun 2015 21:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 1EGWIBMwDepZ for ; Tue, 30 Jun 2015 21:06:48 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 C6BCD1A9067 for ; Tue, 30 Jun 2015 21:06:48 -0700 (PDT) Received: by ykfy125 with SMTP id y125so28438541ykf.1 for ; Tue, 30 Jun 2015 21:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yNJmLHTOBKYXfHByoUjLj9DrGwy58RIhuZhRGUToYok=; b=oBv3EsFR1MKuB8An9ZxxNK0lqRfEEXErGqLtzmDXXkE8LTGD63xUlRL3L2Olupq3MZ KAxCmoo6m7IoFzwoPP2/+IwcpYfjhmIralSlF3RoIXjmC1lhJ9Hzp1qCnfYqA8k/eyRp Y0LCAWw6m505XyHqurTn8p76rS2Z23tRysy67ImM7CYC69IuaBej/qXf/tj9hIGdLVPY 4af9q8sxgfjgCDOVoRyo7imNuThDUMUZYpTBJQ4bhj5AgW+ZaQk711UMu+1fD1tdwzGV WAOjTvP7QrotjnADf5pp0bRX7WSMxCca4LkOUu3jSsncplPO6y7vJcLiQVhviFU4rvJc JmCg== MIME-Version: 1.0 X-Received: by 10.170.124.19 with SMTP id q19mr30020358ykb.1.1435723608426; Tue, 30 Jun 2015 21:06:48 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 30 Jun 2015 21:06:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jun 2015 21:06:48 -0700 Message-ID: From: Martin Thomson To: Darshak Thakore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Brian Raymor \(MS OPEN TECH\)" , "webpush@ietf.org" Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 04:06:53 -0000 An excellent suggestion, thanks: https://github.com/unicorn-wg/webpush-protocol/commit/274723b4d52cd1baf On 30 June 2015 at 17:30, Darshak Thakore wrote: > Ahh.. Thanks. > In the light of this explanation, it seems to be just some word-smithing > problem. > > Might I suggest that you move the sentence: > "A user agent can request the contents of the push message subscription > resource immediately by including a Prefer header field [RFC7240] with a > "wait" parameter set to =E2=80=9C0.=E2=80=9D > > > to be after the sentence: > > "In response to this request, the push service SHOULD return link > references to the push and receipt subscribe resources, plus expiration > information for the subscription." > > That way the recommendation for the PS to send the link references does > not get associated (as I mistakenly did) with the request that contains > =E2=80=9CPrefer: wait=3D0=E2=80=9D header. > > Darshak > > > On 6/30/15, 5:31 PM, "Martin Thomson" wrote: > >>On 30 June 2015 at 16:22, Darshak Thakore wrote= : >>> So I=C2=B9m trying to understand why is it needed to send the =C2=B3:pu= sh=C2=B2 and the >>> =C2=B3:push:receipt=C2=B2 URI=C2=B9s when the =C2=B3Prefer: wait=3D0=C2= =B2 is sent by the UA? >> >> >>This means that a client need only hold the subscription URL; it can >>re-learn the push and receipt subscribe resources by making this >>request. >> >>And inclusion of these links need not be based on receiving Prefer: >>wait=3D0, though other requests might longer to complete than would be >>ideal (or useful). > From nobody Tue Jun 30 21:08:43 2015 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207021A9232 for ; Tue, 30 Jun 2015 21:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 nxpaAjTg5v11 for ; Tue, 30 Jun 2015 21:08:41 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 EDDA31A9131 for ; Tue, 30 Jun 2015 21:08:40 -0700 (PDT) Received: by ykdr198 with SMTP id r198so28411491ykd.3 for ; Tue, 30 Jun 2015 21:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WebOoMRPNRIXVjoro9tNlMWVzJ6bOLillzLGjqghGuc=; b=CNLJjk/gUDtku/UPYCAd49o3tL44fHybi0ULlmE2j/W6P2cMfuulZ+zR1cLewrqECE 5ijEtiMa9/G0v56rsx69tDXM+ON25e6LmyJ7GXByycyNlRY6za7SvBSxNvsTCB0Mg5RW 9jId2Pt9otDXd/mFZNoZShblCaYqQpjCK3ewJwIARskHorpfMwr9eGRI7AwNRylQ2O++ t1SKql+Oid401M+uaiq4+IZ/hnVlIcK5hEhvu6Q6l8+ExN9D/itv11RT0onR+vaGX8lH L1XN9icpp5A159jAL0r3ZJXtJag/UBZpWCWOkMuOXduDKjgGNxbCHsmWYFLc8mUn6emw s07g== MIME-Version: 1.0 X-Received: by 10.170.112.17 with SMTP id e17mr29896772ykb.57.1435723720745; Tue, 30 Jun 2015 21:08:40 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 30 Jun 2015 21:08:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jun 2015 21:08:40 -0700 Message-ID: From: Martin Thomson To: Darshak Thakore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Brian Raymor \(MS OPEN TECH\)" , "webpush@ietf.org" Subject: Re: [Webpush] some comments and feedback on the draft-thomson-webpush-protocol-00 X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 04:08:42 -0000 On 30 June 2015 at 18:03, Darshak Thakore wrote: > All I was suggesting for now is that given that the Prefer header is a > good candidate to carry such information, can we for now also use it to > carry the TTL semantics instead of defining a new header. Generally speaking, I believe Prefer to be better suited to requesting variations in request handling; whereas this is an example of information that describes the resource itself. That said, I'm not wed to the idea of a new header; Prefer: ttl=10 would work.