Re: [Webpush] vapid issue 24: supplementary data in tokens

[jr conlin <[e-mail]>]

I think it's absolutely fine to point out the additional claims. It may
also be a good idea to provide some guidance about what name prefix to
use to avoid potential conflicts should this header be compounded like
the Crypto-Key header. (e.g.
"""
Subscription providers may wish to include additional information using
prefixed keys such as
{ "vap_servid": "ami-123", "vap_custid": "abc012", ...}
to assist in quickly isolating and resolving issues with a given feed.
"""
It may also be worth noting that some servers (like apache) limit the
maximum acceptable size of headers to 8K, so it's best not to go too
nuts with the amount of extra data you're storing.

On 6/30/2016 7:02 PM, Martin Thomson wrote:
> JR requests that we allow the inclusion of extra stuff in a vapid token:
>
> https://github.com/webpush-wg/webpush-vapid/issues/24
> As noted in the arguments of #23, there is a need for an "extra data"
> field which would be used by the parties using the VAPID claims. This
> data would contain information useful to the publisher of the claim
> (e.g. the originating server ID, transaction ID, or other possibly
> VAPID consumer opaque data).
>
> This extra data ("vapid-ext" ?) field would allow consistent,
> predictable definition rather than a set of 'one-offs' that may be
> difficult to find or ignored by operators.
> <<<
>
> I think that the general idea is fine.  Better this than trying to
> pack the "sub" field with extra stuff.
>
> JR, would it suffice to point out that the
> [private](https://tools.ietf.org/html/rfc7519#section-4.3) (or even
> [public](https://tools.ietf.org/html/rfc7519#section-4.2)) claims can
> be added to the token?  Allowing multiple fields gives the application
> server a fair bit more flexibility.
>
> If that's OK, we should point out that this is possible so that push
> services don't lose the extra data because they aren't aware that it
> might exist.