Merge branch 'WICG:main' into fix_fetch_api

README.md

@@ -1,6 +1,6 @@
 # Private State Token API Explainer
 
-This document is an explainer for a potential future web platform API that allows propagating limited private signals across sites, using the [Privacy Pass](https://privacypass.github.io) protocol as an underlying primitive.
+This document is an explainer for a Web Platform API that allows propagating limited private signals across sites, using the [Privacy Pass](https://privacypass.github.io) protocol as an underlying primitive.
 
 The current version of the spec is available at [https://wicg.github.io/trust-token-api/](https://wicg.github.io/trust-token-api/).
 
@@ -12,7 +12,7 @@ This API was formerly called the Trust Token API and the repository and API surf
 
 - [Motivation](#motivation)
 - [Overview](#overview)
-- [Potential API](#potential-api)
+- [API](#api)
   - [Private State Token Issuance](#private-state-token-issuance)
   - [Private State Token Redemption](#private-state-token-redemption)
   - [Forwarding Redemption Attestation](#forwarding-redemption-attestation)
@@ -43,7 +43,7 @@ The web ecosystem relies heavily on building trust signals to detect fraudulent
 
 Preventing fraud is a legitimate use case that the web should support, but it shouldn’t require an API as powerful as a stable, global, per-user identifier. In third party contexts, merely segmenting users into trusted and untrusted sets seems like a useful primitive that also preserves privacy. This kind of fraud protection is important both for CDNs, as well as for the ad industry which receives a large amount of invalid, fraudulent traffic.
 
-Segmenting users into very coarse sets satisfies other use cases that establish web trust as well. For instance, sites could use this as a set inclusion primitive in order to ask questions like, “do I have identity at all for this user?” or even do non-personalized cross-site authentication ("Is this user a subscriber?").  While we encourage exploration into solving a broad set of use cases, Private State Tokens should only be utilized for anti-fraud, anti-abuse, web security, or other web trust and safety purposes.  PSTs are not intented to convey artibrary cross-site information, such as user demographic information for ad targeting or measurement.  
+Segmenting users into very coarse sets satisfies other use cases that establish web trust as well. For instance, sites could use this as a set inclusion primitive in order to ask questions like, “do I have identity at all for this user?” or even do non-personalized cross-site authentication ("Is this user a subscriber?").  While we encourage exploration into solving a broad set of use cases, Private State Tokens should only be utilized for anti-fraud, anti-abuse, web security, or other web trust and safety purposes.  PSTs are not intended to convey artibrary cross-site information, such as user demographic information for ad targeting or measurement.  
 
 
 ## Overview
@@ -53,7 +53,7 @@ This API proposes a new per-origin storage area for “Privacy Pass” style cry
 When an origin is in a context where they trust the user, they can issue the browser a batch of tokens, which can be “spent” at a later time in a context where the user would otherwise be unknown or less trusted. Crucially, the tokens are indistinguishable from one another, preventing websites from tracking users through them.
 
 
-## Potential API
+## API
 
 
 ### Private State Token Issuance
@@ -260,10 +260,6 @@ A possible enhancement would be to allow for sending Redemption Records (and sig
 
 If the publisher can configure issuers in response headers (or otherwise early in the page load), then they could invoke a redemption in parallel with the page loading, before the relevant `fetch()` calls.
 
-### Non-web sources of tokens
-
-Private state token issuance could be expanded to other entities (the operating system, or native applications) capable of making an informed decision about whether to grant tokens. Naturally, this would need to take into consideration different systems' security models in order for these tokens to maintain their meaning. (For instance, on some platforms, malicious applications might routinely have similar privileges to the operating system itself, which would at best reduce the signal-to-noise ratio of tokens created on those operating systems.)
-
 ## Appendix
 
 

spec.bs

@@ -71,12 +71,6 @@ urlPrefix: https://www.ietf.org/archive/id/draft-robert-privacypass-batched-toke
         "publisher": "IETF",
         "title": "Batched Token Issuance Protocol"
     },
-    "ISSUER-PROTOCOL": {
-        "authors": ["S. Valdez", "A. Bulut", "S. Schlesinger"],
-        "href": "https://github.com/WICG/trust-token-api/blob/main/ISSUER_PROTOCOL.md",
-        "publisher": "Google",
-        "title": "ISSUER_PROTOCOL"
-    },
     "RFC4648": {
         "href": "https://www.rfc-editor.org/rfc/rfc4648"
     }
@@ -223,16 +217,15 @@ Requests to key commitment endpoints should result in a JSON response
     * Protocol version `“PrivateStateTokenV1VOPRF”` implements [[!VOPRF]] cryptographic
                protocol. Issuers can use up to six valid token signing keys.
 
-* `"id"` field provides the identifier of the key commitment. It is a string
-         representation of a non-negative integer that is within the range of
-         an unsigned 32 bit integer type. Values should be montonically
-         increasing.
+* `"id"` field provides the identifier of the key commitment. It is a
+         non-negative integer that is within the range of an unsigned 32 bit
+         integer type. Values should be montonically increasing.
 
 * `"batchsize"` specifies the maximum number of masked tokens that the issuer
                 supports for each token issuance operation. Its value is a
-                string representation of a positive integer. The user agent might send
-                fewer tokens in a single operation, but will generally default to
-                sending `batchsize` many tokens per operation.
+                positive integer. The user agent might send fewer tokens in a
+                single operation, but will generally default to sending
+                `batchsize` many tokens per operation.
 
 * `"keys"` field is a dictionary of public keys listed by their identifiers.
 
@@ -766,8 +759,6 @@ Sec-Private-State-Token: <token encoded as base64 string>
 ```
 </div>
 
-The details for servers implementing this protocol can be found in [[!ISSUER-PROTOCOL]].
-
 Handling Issue Responses {#issue-response}
 ----------------------------------------------------------
 
@@ -791,8 +782,6 @@ To <dfn>handle an issue response</dfn>, given [=request=] |request| and [=respon
     1. [=Insert a token=] for |issuer|, |token|, and |signingKey|.
 1. Return.
 
-The details for servers implementing this protocol can be found in [[!ISSUER-PROTOCOL]].
-
 Redeeming Tokens {#redeeming-tokens}
 ====================================
 
@@ -923,7 +912,7 @@ To <dfn>append private state token redemption record headers</dfn> given a [=/re
 
 <pre class="idl">
 partial interface Document {
-  Promise&lt;boolean> hasPrivateTokens(USVString issuer);
+  Promise&lt;boolean> hasPrivateToken(USVString issuer);
   Promise&lt;boolean> hasRedemptionRecord(USVString issuer);
 };
 </pre>
@@ -934,7 +923,7 @@ Query APIs {#query-apis}
 Token Query {#token-query}
 --------------------------
 
-When invoked on {{Document}} |doc| with {{USVString}} |issuer|, the <dfn export method for=Document><code>hasPrivateTokens(issuer)</code></dfn> method must run these steps:
+When invoked on {{Document}} |doc| with {{USVString}} |issuer|, the <dfn export method for=Document><code>hasPrivateToken(issuer)</code></dfn> method must run these steps:
 1. Let |p| be [=a new promise=].
 1. If |doc| is not [=Document/fully active=], then [=reject=] |p| with an "{{InvalidStateError}}" {{DOMException}} and return |p|.
 1. Let |global| be |doc|'s [=relevant global object=].