Based on our understanding, the web platform features have moved towards scoping on origin as compared to the site. This has been called out as a Warning in the HTML standard doc under “Site section”

For the reasons explained in URL, the same site and schemelessly same site concepts should be avoided when possible, in favor of same origin checks

For IPA, there are two places where we need to make this choice:

1. Match Key Providers
   When a match key is set, we propose using the origin. Correspondingly, when calling getEncryptedMatchKey(), the first argument to that method is the “match key provider”. This should also be an origin.

2. Storage of encrypted match key values
   The return value of getEncryptedMatchKey() should be consistent for a given site (for a given epoch). The User-Agent should compute the value once and store it to be returned on subsequent calls. Unfortunately, here we cannot use origin and must use site. There are a few reasons for this:

   • Privacy Budgeting is to be implemented at the “site” level. Doing so requires the helpers to check the site to which encrypted match keys are bound. We cannot give a separate privacy budget per origin as cookies enable linkage across origins belonging to the same site. Thus, scoping privacy budget to “origin” could allow sites to obtain an unlimited privacy budget.
   • The helper nodes need to know which “site” an encrypted match key was bound to in order to decrypt it. This is information helpers see in the clear. Helpers should not see data about origins, just the top level site.
   • Our current ideas about “DP Sharding” involve sensitivity capping that requires all records from a given user on a given site (in a given browser, in a given epoch) are consistent. Generating different values per origin would violate this constraint. (See: IPA Sharding with Sensitivity Bound #35)