Subject: [Webpush] I-D Action: draft-ietf-webpush-vapid-00.txt

From: [email-masked]
Date: Wed, 13 Apr 2016 18:34:09 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web-Based Push Notifications of the IETF.

        Title           : Voluntary Application Server Identification for Web Push
        Authors         : Martin Thomson
                          Peter Beverloo
	Filename        : draft-ietf-webpush-vapid-00.txt
	Pages           : 11
	Date            : 2016-04-07

Abstract:
   An application server can voluntarily identify itself to a push
   service using the described technique.  This identification
   information can be used by the push service to attribute requests
   that are made by the same application server to a single entity.
   This can used to reduce the secrecy for push subscription URLs by
   being able to restrict subscriptions to a specific application
   server.  An application server is further able include additional
   information the operator of a push service can use to contact the
   operator of the application server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-webpush-vapid/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-webpush-vapid-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian Raymor <[email-masked]>
Date: Wed, 27 Apr 2016 21:59:21 +0000

I've reviewed vapid-00. My earlier editorial comments were all addressed.

Martin plans to move vapid-00 to a repo in the webpush-wg. In the interim:

Abstract

Editorial:

    An application server is further able [to] include additional
    information [that] the operator of a push service can use to contact the
    operator of the application server.

1. Introduction

    By the same measure, requesting the creation of a subscription for push message receipts
    has no prior authentication.

This will need to be updated when webpush-05 is published. There is no longer an explicit
request to create such a subscription. It's created implicitly as the result of requesting a 
push message delivery with receipts.

2. 1 Application Server Self-Identification

   Application servers SHOULD generate and maintain a signing key pair
   usable with elliptic curve digital signature (ECDSA) over the P-256
   curve [FIPS186].

What is the rationale for SHOULD rather than MUST? 

2.2. Example

    Authorization: Bearer

Is this intended to be WebPush rather than OAuth Bearer (RFC6750)?

    Push-Receipt: https://push.example.net/r/3ZtI4YVNBnUUZhuoChl6omU

When webpush-05 is published, this can be updated to:

Prefer: respond-async

and a reference to RFC7240 added.

    *This* equates to a JWT with the header and body shown in Figure 2.

"This" meaning the value of the Authorization header?

    Issue: The first part of the JWT is effectively fixed. Would be it
    acceptable to require *that that* segment is omitted from the header
    field?

What is "that segment"?

3. WebPush Authentication Scheme

Editorial:

    Therefore, this authentication scheme MUST NOT be used with [t]he

5.2 Using Restricted Subscriptions

There are multiple references to a *token* that I do not understand:

    When a push subscription has been associated with an application
    server, the request for push message delivery MUST include proof of
    possession for the associated private key or *token* that was used when
    creating the push subscription.

...

    A push subscription that is not restricted to a particular key MAY
    still validate a *token* that is present, except for the last check. A
    push service MAY then reject a request if the *token* is found to be
    invalid.