Draft: draft-thomson-webpush-protocol

Commentary: I realized that I had n't done due diligence in adding the message URL . This should address that ( I have hooks in here for acknowledgment too ) .
Paragraph (version A):
"Push" URIs MUST NOT provide any basis to correlate communications
for a given user agent.  It MUST NOT be possible to correlate any two
"push" URIs based solely on the content of the "push" URIs.  This
allows a user agent to control correlation across different
applications, or over time.
Paragraph (version A):
In particular, user and device information MUST NOT be exposed
through the "push" URI.
Paragraph (version A):
In addition, "push" URIs established by the same user agent MUST NOT
include any information that allows them to be correlated with the
user agent.
Paragraph (version B):
The URIs provided for "push" resources MUST NOT provide any basis to
correlate communications for a given user agent.  It MUST NOT be
possible to correlate any two "push" URIs based solely on their
contents.  This allows a user agent to control correlation across
different applications, or over time.
Paragraph (version B):
Similarly, the URIs provided by the push service to identify a push
message MUST NOT provide any information that allows for correlation
across subscriptions.  Push message URIs for the same subscription
MAY contain information that would allow correlation with the
associated subscription or other push messages for that subscription.
Paragraph (version B):
User and device information MUST NOT be exposed through a "push" or
push message URI.
Paragraph (version B):
In addition, "push" URIs established by the same user agent or push
message URIs for the same subscription MUST NOT include any
information that allows them to be correlated with the user agent.
Paragraph (version A):
Authorization for subscriptions is managed using "subscription" and
"push" capability URLs (see CAP-URI).  A capability URL grants access
to a resource based solely on knowledge of the URL.  Capability URLs
are used for their "easy onward sharing" and "easy client API"
properties.  These make it possible to avoid relying on relationships
between push services and application servers, with the protocols
necessary to build and support those relationships.
Paragraph (version A):
A "subscription" or "push" URI therefore acts as a bearer token.
Knowledge of the "subscription" URI implies authorization to either
receive push messages or delete the subscription.  Knowledge of the
"push" URI implies authorization to send push messages.
Paragraph (version A):
Encoding a large amount of random entropy (at least 120 bits) in the
path component ensures that it is difficult to successfully guess a
valid "subscription" or "push" URI.
Paragraph (version B):
Authorization for subscriptions is managed using "subscription" and
"push" capability URLs (see CAP-URI).  A capability URL grants access
to a resource based solely on knowledge of the URL.
Paragraph (version B):
Capability URLs are used for their "easy onward sharing" and "easy
client API" properties.  These make it possible to avoid relying on
relationships between push services and application servers, with the
protocols necessary to build and support those relationships.
Paragraph (version B):
A "subscription", "push" or push message URI therefore acts as a
bearer token.  Knowledge of a "subscription" URI implies
authorization to either receive push messages or delete the
subscription.  Knowledge of a "push" URI implies authorization to
send push messages.  Knowledge of a push message URI allows for
reading that specific message.
Paragraph (version B):
Encoding a large amount of random entropy (at least 120 bits) in the
path component ensures that it is difficult to successfully guess a
valid capability URL.
Paragraph (version A):
Server request logs can reveal subscription-related URIs.  Acquiring
a "subscription" URI enables the receipt of messages or deletion of
the subscription.  Acquiring a "push" URI permits the sending of push
messages.  Logging could also reveal relationships between different
subscription-related URIs for the same user agent.
Paragraph (version B):
Server request logs can reveal subscription-related URIs.  Acquiring
a "subscription" URI enables the receipt of messages or deletion of
the subscription.  Acquiring a "push" URI permits the sending of push
messages.  Logging could also reveal relationships between different
subscription-related URIs for the same user agent.  Encrypted message
contents are not revealed to the push service.