#1213: Question: Capability Delegation stalled -- specs are implementing local workarounds
Discussions
Log in to see TAG-private discussions.
Comment by @yoavweiss Mar 30, 2026 (See Github)
^^ @mustaqahmed
Discussed
Apr 6, 2026 (See Github)
Jeffrey: Capability delegation... it is discussed in Eurasia breakout. What should we do with it? Marcos was complaining people are not doing work but it is not much we can do as TAG. It seems we all agree to have a consistent design for this problem.
Heather: I am motivated to see the results. Do we have any relation with WhatWG chairs?
JEffrey: there are now WHATWG chairs. ??? is the person working on this. We can say we think it should continue.
Heather: Yes
Jeffrey: I think we can comment that in the review.
Matthew: I was very itnerested into the decribtion by Marcos yesterday. He was saying there are some solutions for this, and most of it was not ideal. We don't want to see many of those solutions got accepted.
JEffrey: we can say freebe for new iframes is bad.
Matthew: ???
Heather: I have no objection for that. It will have some issue with the webAuthn. This might mean if there is no here, then it will be no to WebAuthn either.
Jeffrey: Draft comment:
We discussed this in two breakouts, and the TAG agrees that we'd like work to continue on Capability Delegation to act as infrastructure for these several related areas.
We agree with @marcoscaceres that we see potential abuse if each new iframe gets a call without activation. We think that WebAuthn needs to reconsider its design if it's open to this abuse.
Jeffrey: no objection to it so I will put it. Also, we need volunteer to refer to the specs affected. Marcos?
Heather: Maybe not Marcos.
Jeffrey: HEather do you want to be there?
Comment by @jyasskin Apr 10, 2026 (See Github)
We discussed this in two breakouts, and the TAG agrees that we'd like work to continue on Capability Delegation to act as infrastructure for these several related areas.
We agree with @marcoscaceres that we see potential abuse if each new iframe gets a call without activation. We think that WebAuthn needs to reconsider its design if it's open to this abuse.
Discussed
Apr 20, 2026 (See Github)
HF: updated brainstorming w/ comment. Please review.
Discussed
Apr 27, 2026 (See Github)
jyasskin: Updates, or do we just go talk to specs?
<crickets>
jyasskin: Ok, I guess we need to go talk to them
Discussed
May 11, 2026 (See Github)
Rick Byers thinks this might be a red herring.
Marcos: It's a common problem, and some of the solutions have some problems. Is the navigation-based system even necessary, since you could do it with a full-screen iframe?
Jeffrey: Rick pointed out that Chromium implemented Capability Delegation. Mozilla is implementing. Maybe Apple should implement before suggesting that we extend it?
Marcos: Independent of WebKit, the pattern is showing up repeatedly. If we can't do it with iframes, maybe we need an HTTP header. Don't be biased by a single solution, like the one coming from payment request.
Heather: What do we do? Take it back since WHATWG doesn't seem to be dealing with it? Lean on WHATWG?
Brian: Marcos, you said it expected to go to WHATWG but didn't. Can add it to WHATNOT. Don't think you're wrong that there's something different that people keep re-solving, that has similarity. Maybe there's an underlying primitive. Seems like a good place to bring it up. I can carry it over.
Marcos: In the DC API, Mohamed proposed relaxing activation for [navigation]. That's counter to TAG advice not to weaken things further.
Heather: And the justification was that WebAuthn did it. So it's ok in the same family. That's evidence that it's important.
Marcos: WebAuthn case is peculiar because it's doing something slightly different. How did WebAuthn get away with it? Ricky M on the WebKit side said it's privacy-protecting because X. For payments, it does something different. Becomes Chrome-specific. Things went different direction. Then on redirect. Mohamed, Mustaq, and I will talk. Brian, good to talk to WHATWG once it's in a good state. Would be good to get TAG input. We might be too credential-focused. Big project.
Jeffrey: Suggesting the TAG say: 1) Endorse idea of bringing existing Credential Delegation to WHATWG, and encouraging all implementations to implement it for iframes. 2) Be careful when extending this to navigations. Please bring us a fleshed out design review, with consensus from the various groups who want to design this.
Brian: Random thought: Has there ever been a time when TAG tried to do outreach to find out if there are other similar use cases. To say "we've observed X, Y, Z; gathering more information; tell us if your group is experiencing this." We have 2 use cases, and we're only seeing a tiny look at specific things.
Jeffrey: It's expensive to do that. Don't know we have an available neutral TAG member.
Brian: We could agree on a request, and email it to all chairs.
Jeffrey: Someone just needs to write that request.
Brian volunteers.
Jeffrey will post the above suggestion as the answer to Marcos' design review question.
Comment by @RByers May 11, 2026 (See Github)
I'm not sure this framing is correct. Chromium shipped capability delegation (everything in that spec I believe) back in 2022, but AFAIK no other implementations have shipped. Unfortunately, I believe the capability delegation spec has tackled only the easy case of delegating capabilities down the frame tree within a single page or from opener to popup window. The issues in PR and DC are about capability delegation across navigations, not about within a page. That's a much harder problem which AFAIK nobody has proposed a solution to.
I'm all for moving capability delegation forward, in Chromium it's proven to provide essential infrastructure for pragmatically mitigating cross-frame abuse without breaking legitimate scenarios. But I think positioning it as the fix for these problems is incorrect. I'll comment more on the payment-specific problem here.
Comment by @jyasskin May 13, 2026 (See Github)
Thanks @RByers. We discussed this again in a breakout yesterday, with the following conclusions:
- We endorse the idea of bringing the existing Capability Delegation spec to WHATWG, and we encourage all implementations to implement it for iframes.
- It looks from https://github.com/w3c/payment-request/issues/1064#issuecomment-4421890389 that the goal isn't actually to delegate the user activation across navigations, but rather to replace activation with actually-meaningful signals. We look forward to getting a consensus design review for whatever system eventually gets designed for these use cases.
OpenedMar 30, 2026
In 2021 the TAG reviewed Capability Delegation (#655) and closed it as satisfied. The work was expected to move to WHATWG. It hasn't. The last commit to the WICG repo is February 2023, and the upstreaming issue (WICG/capability-delegation#40) has had no activity.
In the absence of a general solution, specs are now solving the redirect-breaks-activation problem independently:
show()activation requirement from a hard requirement to a MAY in PR #1009 (June 2023), with security mitigations left to implementer discretion.Each spec is solving this locally, inconsistently, and in ways that are exploitable (the DC counter is bypassable via iframes and back/forward navigation). The precedent chain is accumulating.
This is directly relevant to the TAG's finding on preventing credential abuse, which warns against normalizing credential requests by reducing friction.
We have filed a PR on Payment Request to restore the hard requirement and replace it with a note pointing to the open problem, and a comment on the DC PR making the same case.
The question: Is there anything the TAG can do to help move Capability Delegation forward -- whether that means pushing for WHATWG uptake, issuing a finding that names the pattern and blocks per-spec workarounds, or something else? The problem is real and the gap is now producing concrete harm in multiple specs.
<!-- Content below this is maintained by @w3c-tag-bot -->Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1213