Google's Role in Attestation for Core APIs and Tools (ie Aggregation Service), DUNS And Non DUNS, Single/Multi Site

[thegreatfatzby]

Hey @alextcone-google @michaelkleber et al, I'd like to understand the intended amount of discretion, editorial, and gatekeeping power on Google's part in granting access to use the APIs and tools that require attestation. I'm confused based on my experience going through the process on MSFTs behalf, for my own demo sites, and from reading the docs. I'm curious because it will impact how these APIs can be used, how developers (individual and corporate) can innovate, and the ability to automate this process. I'd guess most of this is the challenge of documenting these processes under considerable pressure, evolution of underlying APIs, and time constraint, but unless I'm missing something I think some clarity is needed.

(I want to be super upfront and say that I have both professional and personal motivations for this question: on MSFTs behalf, as we have gone through the Core API Multi Site process, in which we got questions we didn't expect, and we will go through Private Aggregation soon; on my personal behalf, as I've been trying to get my test demo sites separately attested and am getting questions I wasn't expecting; and for the industry/ecosystem in the long run, as I hope we can get on the same page as to how these APIs/tools can be used/experimented-with.)

What I Think I See

Digging through the attestation document and blog post again, I would tend to think no discretion is implied, and even explicitly forsworn:

• The non goals explicitly say "The attestation model does not seek to enforce or validate the truthfulness of the attestations made by developers".
• In both docs I don't see any technical or editorial guidelines indicated, as are in the RWS submission guidelines.
• In the validation and transparency section, the phrase "Developers who submit an enrollment form are then sent a file that contains the attestations for the APIs they requested to use" implies it is mostly procedural.
• Most of the public discussion I've been a part of does not indicate a gatekeeping role with any discretion.

What I've Seen

• From my MSFT experience It seems like for Multi Site Attestation there is a higher bar, and I'm not totally clear a) why or b) what it is.
• From my personal demo sites application, which is not Multi Site, I've been asked to provide details about my use cases, provided them, and then asked for more detail.

What I'd Like to See ASAP

• To the extent that there is either a) discretion or b) requirements for attestation for documentation (for instance, same vertical companies under the same holding company, or use cases), for any combination of multi/single duns/non-duns, it should be documented. If it is already, please point to it in the github and other common docs.
• Once we establish that in some documentation, I'd like to discuss those more to see how we can remove the need for a browser operator to play any gatekeeping role for basic usage.

What I'd Like to Understand Better

I'd really like to understand what the intentions are for attestations, understanding there may be nuance between a) single and multi site as well as b) businesses vs individuals. I really hope we are planning on moving to an automated production of the attestation file, with something like a blacklist approach to enable dealing with bad actors, but not a whitelist approach.

(moved over from WICG/turtledove#1164)