Preventing Issuer Exhaustion

README.md

@@ -235,6 +235,11 @@ We have a number of mitigations against this attack:
 
 When the issuer detects a site is attacking its token supply, it can fail redemption (before the token is revealed) based on the referring origin, and prevent browsers from spending tokens there.
 
+### Issuer Exhaustion
+
+Given a cap on the issuers usable per top-level origin, there might be a race between third-party scripts to call `hasPrivateToken(issuer)` to ensure their preferred issuer is available.
+The top-level document can control this process by calling `hasPrivateToken(issuer)` for its preferred issuers before any other scripts are loaded.
+This would ensure the availability of the desired issuers and prevent a race to determine availability.
 
 ### Double-Spend Prevention
 

spec.bs

@@ -1132,6 +1132,15 @@ operations. In the context of a given origin, two redemptions are allowed initia
 the third redemption is only allowed once more than an [=implementation-defined=] amount of time,
 usually 48 hours, have elapsed since the first redemption.
 
+Preventing Issuer Exhaustion {#issuer-exhaustion}
+-----------------------------------------------
+Competing scripts might race to call <code>hasPrivateToken(issuer)</code> to ensure their |issuer|
+enters the [=issuerAssociations=] [=map=] before the |issuer| of others given a limit of two per
+[=environment/top-level origin=]. To control this process, the [=environment/top-level origin=]
+could call <code>hasPrivateToken(issuer)</code> up to twice before any other JavaScript is included
+to ensure their preferred |issuer|s are available.
+
+
 Preventing Double Spending {#preventing-double-spend}
 -----------------------------------------------------