jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-webpush-vapid

Commentary: can you check that this is all OK with you ? I 've made you an author :) 
 SG , thanks . The only difference with my PR seems to be removal of details , which I guess are too specific for the proposal phase .
Paragraph (version A):
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.  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.
Paragraph (version B):
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, and
reduce the need for endpoint secrecy by being able to associate
subscriptions with an 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.
Paragraph (version B):
Additionally, this design also relies on endpoint secrecy as any
application server in possession of the endpoint is able to send
messages, albeit without payloads.  In situations where usage of a
subscription can be limited to a single application server, the
ability to associate said subscription with the application server
provides could reduce the impact of a data leak.
Paragraph (version B):
A stable identifier for an application server - such as a public key
or a token - could also be used to associate a subscription with the
application server.
Paragraph (version B):
Subscription association reduces the reliance on endpoint secrecy by
requiring proof of possession to be demonstrated by an application
server when requesting delivery of a push message.  This provides an
additional level of protection against leaking of the details of the
push subscription.
Paragraph (version B):
The user agent includes the public key or token of the application
server when requesting the creation of a subscription.  For example,
the Web Push API API could allow an application to provide a public
key as part of a new field on the "PushSubscriptionOptions"
dictionary.
Paragraph (version B):
This token might then be added to the request to create a push
subscription.
Paragraph (version B):
Allowing the inclusion of multiple keys when creating a subscription
would allow a subscription to be associated with multiple application
servers or application server instances.  This would require more
state to be maintained by the push service for each subscription.
Paragraph (version B):
When a 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 subscription.  Requests that do not contain proof of
possession are rejected with a 401 (Unauthorized) status code.