Specify whether identity providers can constrain the set of helper parties

[dominiccooney]

The getEncryptedMatchKey operation must encrypt identity secret shares towards specific helpers. Because the user agent implements the operation, it can exercise control over whether a set of helpers is acceptable to the user. Likewise, the site can exercise discretion about whether to call the operation and which helpers to request.

Can the identity provider constrain the set of helper parties it supports encrypting its identities towards? If so, how is it set? Updated? setMatchKey could be elaborated, or the identity provider could publish a separate statement about these.

[martinthomson]

I don't think that we allow the match key provider to constrain how the information it provides might be used.

Let's say that we did. Consider then a case where someone creates a new browser build that doesn't respect these constraints. What prevents this modified browser from doing whatever it pleases with the information?

We could maybe use some form of encryption, but that might leave the browser with no way of knowing what information is being passed to a helper. Though, come to think of it, that's already a communications channel that exists... and I need to think about whether that could be exploited somehow. I don't think that it can if the browser performs secret sharing as the helpers never see the value provided by the match key provider.

[dominiccooney]

Consider then a case where someone creates a new browser build that doesn't respect these constraints. What prevents this modified browser from doing whatever it pleases with the information?

Nothing. Taken to the extreme the question is equivalent to "what's to stop the user agent leaking the match key to every website?" There's a security policy and sites rely on the UA implementing it. ... unless I'm missing some nuance of it.

We could maybe use some form of encryption, but that might leave the browser with no way of knowing what information is being passed to a helper.

I expect identity providers will be encrypting match keys to preserve business secrets like number of accounts, etc. Maybe the spec could recommend that match key providers "SHOULD" do that encryption. From the UA's point of view I hope it won't try to parse the schema-less n (=64?) bits of match keys.

I don't think that [match keys are an exploitable communication channel] if the browser performs secret sharing as the helpers never see the value provided by the match key provider.

Slightly off topic, but consider a use case like a device with multiple browsers. It would be good if there was interop between the browsers so a match key set in UA X could generate a report in UA Y. In some settings this is possible. For example, Android apps are in signed packages; packages are related to sites through digital asset links; and the sender and receiver of IPC (specifically Intents) can be verified. In that setting app A could request an encrypted match key using the identity of app B, and app B can confidently generate one with the "current principal" A.

The practical problem is that browsers simply assert that they're acting on behalf of site X. This is fine within one browser, effectively the browser is "the kernel." But is there something... tokens? ... that could make this work between browsers on a given device?

If we could make this work for web browsers it would be a great thing for accurate conversion measurement and browser choice.

This is important for browser choice. Without it, the component that mediates match keys and generated reports for apps and sites needs to be the same. An operating system may "lock in" a specific browser to do that. Or on an open platform, there could be a proliferation of implementations, probably one in each browser, and the caller side gets in the habit of only trying to invoke the top-N share browsers creating a barrier.