Consider requiring a strong signal of user intent.

[mikewest]

I'd suggest that y'all take a look at some of the work going on in https://github.com/WICG/PEPC as a potential mitigation for a subset of the concerns around allowing developers to attempt to pull information from from users at arbitrary points in time.

It seems reasonable to me to consider shifting to a model in which access to information is mediated by initial user interaction with an element that provides a strong signal of the users' intent in the moment (because the browser controls the presentation of that element). That is, rather than allowing a prompt after any click on a page, allow a prompt only after interaction with a specific element, well-understood to be comprehensible and to set reasonable context.

This is a stronger version of the suggestion in #91. I've separated it out to consider separately, but I'm happy for y'all to fold this in there if that's easier to follow.

[RByers]

Yes, this is definitely a super interesting idea. I actually mentioned it on Friday to @marcoscaceres as something we should keep an eye on (also for FedCM where it's even more clearly exciting). But IMHO PEPC is still unproven and currently lacks any signals from non-Chromium engines, so is not something we could take a dependency on yet.

[npdoty]

It does seem like a promising setting for an interaction model where the user indicates their interest by taking action on an element in the page. Especially so because this is an information request model that will need substantial in-context explanation in order for it to be done safely.

Beyond just having a particular visual button, it would be useful if the browser could ensure that the surrounding HTML content provided some in-context explanation (and was visible to the user, etc.). That might also be the context to record on the device for a user who wants to review where a particular credential has been used (a legal requirement for EUDI wallet software, I believe).

[mikewest]

But IMHO PEPC is still unproven and currently lacks any signals from non-Chromium engines, so is not something we could take a dependency on yet.

We're talking to @marcoscaceres (👋) about PEPC in other contexts, so I do hope to get to a point where we have more agreement on the benefits that such a mechanism can provide. I agree that it's not something you can require today, but I do think that it's a direction that would be very reasonable to explore as we gain implementation experience with PEPC's initial experiments around cam/mic and location data. As @npdoty suggests, the browser is likely a trustworthy source of context around identity requests, even if all we can do is facilitate a "standard" entry UI from web contexts given protocol's opacity.

[bvandersloot-mozilla]

My working abstraction of PEPC is that it provides a sort of elevated version of user interaction. Using that as a requirement for invocation seems like a positive use of PEPC, and an boon to its utility.

[RByers]

Yeah, I'd argue that almost all the places we require a user activation today would be better served by a PEPC-like model where the user has some browser-drawn context on what tapping there will do. But of course this needs to be balanced with site authors having control over the UX on their site (similarly to how we handle text input on the web).

[samuelgoto]

I'm a big proponent of https://github.com/WICG/PEPC and have been exploring ways in which we can use it with FedCM, so I share @mikewest 's intuition that it can raise the bar in terms of gathering the user's intent.

However, I think it might be worth noting that there there is an extra implementation challenge in this specific case of the Digital Credentials API which doesn't appear in FedCM (and other PEPC elements), which is that the Credentials are actually in the Operating System layer (e.g. Android and iOS, who aggregate credentials from native Wallets), rather than in the browser layer. So, populating the https://github.com/WICG/PEPC element with useful data gets trickier, I think, from an implementation perspective.

This isn't necessarily an insurmountable problem, but seems like it would put PEPC a few steps further in terms of technical feasibility too (in addition to browser interoperability that @RByers noted too).