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

[Brian Raymor <[e-mail]>]

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.