Apply revisions requested in w3c/strategy#146

[dotproto]

This PR attempts to address the feedback received in w3c/strategy#146 as of October 7, 2025.

For clarity, the initial revision of this PR is separated into two commits:

• bf17e998 normalizes the formatting of the document using Visual Studio Code + the VSC Prettier extension. No special configuration was applied.
• e19a5051 contains the substantive changes in this PR.

This diff view shows all commits except bf17e998.

Updates include:

• Scope
  • Add a new "User agent extensibility" section to better cover the possibility that any feature or subsystem of a browser could be exposed to web extensions in the future.
  • Updated "Extensions model" to include interactions between extensions.
  • Update "Permissions model" to include a link to the Permissions spec.
  • Update "Resource files and formats" description to clarify the role these assets fill and to make it clear that the set of items provided is an incomplete list.
  • Add a "WebDriver integration" description that covers both implementers and extension developers.
  • Add a new "Extension/Web interactions" section to explicitly cover interactions between extensions and websites.
  • Add a new "Network request modification" section to indirectly address the request "to cover extension-specific credential handling...".
• Other deliverables
  • Add "Threat Model document" to the list of other deliverables.
• Coordination, W3C Groups
  • Added entries and draft descriptions for each of the following groups: Web Applications Working Group, Web Applications Security Working Group, Threat Modeling Community Group, Web Authentication Working Group, and FedCM Working Group.

[dotproto]

Thanks for the clean up, @sideshowbarker!

[Rob--W]

I haven't seen any WECG discussiong about FedCM, only Credential management (that is already covered by the webauthn group reference preceding this item).

And only Chrome (not Firefox nor Safari) currently implement FedCM. There is no evidence of this work getting picked up soon, Mozilla's standard position towards FedCM is neutral, and WebKit's s-p is yet to be published.

I expect that we will seek out specific groups as needed if we ever get involved in that space, but since there we have had zero signals of relevance, let's drop this entry for now?

Suggested change

	</dd>
	<dt>
	<a href="https://www.w3.org/groups/wg/fedid/"
	>FedCM Working Group</a
	>
	</dt>
	<dd>
	We will collaborate with this group on topics of mutual interest,
	such as WebExtensions APIs that enable third party developers to
	integrate with existing federated authentication flows or
	experiment with novel federated authentication flows.

[dotproto]

This was added in response to TAG feedback. That said, @Rob--W succinctly captured my own abstract hesitation with this addition and I'm supportive of removing it.

@sideshowbarker, any concerns with removing this entry? (P.S. I'm still relatively new to working with other W3C groups & formal process, so I may end up leaning on you a bit too much until I get a better lay of the land.)

[sideshowbarker]

I have zero concerns with removing that entry. So yeah let’s go ahead and do that.

(Also, as far as the TAG’s review comments at w3c/strategy#146 (comment), I see that they asked just that in general “the charter should include or clarify relevant coordination points [with other groups and organizations]” — but they didn’t ask that we list the FedCM Working Group specifically. And you added some other relevant working groups and a CG to the Coordination section — so we already have that to show as one of the concrete changes that got made in response to the TAG comments.)

[sideshowbarker]

(Also, as far as the TAG’s review comments at w3c/strategy#146 (comment), I see that they asked just that in general “the charter should include or clarify relevant coordination points [with other groups and organizations]” — but they didn’t ask that we list the FedCM Working Group specifically.

Well, only after having written that did I bother to follow the link in the TAG’s comment to #690 where they do actually include the FedCM Working Group specifically in the list of groups they suggest we add to the charter.

So, if we decide we don’t want to include, then we should also then post a comment to #690 explaining why we’re not including it, and linking to Rob’s comment at #711 (comment)

But all that said, I also want to note here that the deliverables of the FedCM WG include not just the Federated Credential Management API — which is what Mozilla's standard position is about — but also the Digital Credentials API.

And unlike the Federated Credential Management API, the Digital Credentials API is actually already being implemented in WebKit too (not just in Chrome) — and one of the editors is even from Apple.

Now, I can’t speak with any insight about how relevant the Digital Credentials API might end up being to the WebExtensions work, so @dotproto I defer to you and @Rob--W and any other WebExtensions domain experts here on whether the existence and implementation status and possible relevance of the Digital Credentials API changes the calculus here such that you think the FedCM WG may actually merit being specifically listed in the charter.

Otherwise, I think it’s fine to just not include (and then to post a comment to #690 explaining why).

[sideshowbarker]

And only Chrome (not Firefox nor Safari) currently implement FedCM. There is no evidence of this work getting picked up soon, Mozilla's standard position towards FedCM is neutral, and WebKit's s-p is yet to be published.

There is a WebKit position at WebKit/standards-positions#309, right?

[sideshowbarker]

By the way, it’s also not clear that the Threat Modeling CG merits being specifically listed. I realize it’s specifically suggested in the list at #690, but that doesn’t mean we should necessarily include it — unless we reckon ourselves that there’s some reason we think it should be.

We do already include the Web Applications Security Working Group. And that group is among the groups that — as part of the normal W3C process — we will be specifically seeking out “horizontal review” feedback from anyway. And the review from that group will necessarily already be based on some expertise they have in the area of threat modeling. So I’m not sure what we would gain from also specifically listing the Threat Modeling CG.

If we were to omit it, then I think we could post a comment to #690 giving the rationale above — or even just saying, “It’s not clear that the work of that CG is specifically relevant enough to the scope of this particular working group to merit being explicitly listed in the Coordination section”.

(In general, I think we should only be including a given CG in the Coordination sections of charters for groups the CG is very specifically related to. So, for example, the Threat Modeling CG might be a good candidate for listing in a Web Applications Security Working Group charter — but offhand other than that group, I can’t really think of any other groups whose charter Coordination sections it’d be a good candidate for including in.

[csarven]

Regarding coordination in #690 and TAG's review, the intention was that the group working on the charter consider additional groups relevant to what is in scope. With respect to authentication, the point was that the group should look into incorporating or bridging with what may be necessary rather than expecting this group to adopt specific mechanisms. If the group deems that some other groups or work is more suitable, that is fine. Ultimately, the specifics are left to the discretion of the group.

[csarven]

These ("packaging format" and "methods for signing extensions") marked as "out of scope" seem like very important areas for the WG try to address to fill a persistent gap the market has not historically solved. A common format could support decentralisation and reduce reliance on "stores".

I'd suggest to consider including them in scope.

[dotproto]

While I personally agree that a common distribution format could enable decentralized alternatives to the prevailing "store" based approach to distribution and discovery, to my knowledge none of the browser vendors currently participating in the WECG are interested in pursuing this. That's why this was also out of scope for the CG's charter since its inception.

Does it make sense to include an area as in scope when there's nontrivial opposition to working on that area?

[sideshowbarker]

While I personally agree that a common distribution format could enable decentralized alternatives to the prevailing "store" based approach to distribution and discovery, to my knowledge none of the browser vendors currently participating in the WECG are interested in pursuing this. That's why this was also out of scope for the CG's charter since its inception.

Does it make sense to include an area as in scope when there's nontrivial opposition to working on that area?

It would not make sense to include it, in my experience.

If it’s already known among the stakeholders active in some particular work that the target implementors for it have made it clear they aren’t interested in implementing a particular feature, then we shouldn’t include it in a charter. And even more so if implementors have expressed actual opposition to it (rather than just lack of interest).

[csarven]

The TAG discussed this thread earlier today (minutes -- will be published this week).

The understanding was that given that a common packaging format and signing model would improve interoperability and support decentralisation, what are the specific reasons for the opposition from implementers to addressing these in scope?

Aside: happy to join the CG call sometime if it helps to discuss this (or other) matter.

[csarven]

Suggested change

	</p>
	Independent implementations must be developed by separate parties
	and cannot reuse or derive code from another qualifying implementation
	relevant to this specification.
	</p>

[csarven]

Regarding coordination in #690 and TAG's review, the intention was that the group working on the charter consider additional groups relevant to what is in scope. With respect to authentication, the point was that the group should look into incorporating or bridging with what may be necessary rather than expecting this group to adopt specific mechanisms. If the group deems that some other groups or work is more suitable, that is fine. Ultimately, the specifics are left to the discretion of the group.

[rdcronin]

semi-random comment spot:

The community group charter includes a section that explicitly calls out that we anticipate browsers providing (significantly) more than what's covered in the spec. This is important, since there may be browser features that we want to allow extensions to interact with, but only exist in one browser.

The language in the community group is

"We recognize that browser vendors need to provide functionality that is specific to their browser and also need the ability to experiment with new features. Our process embraces this and seeks to provide mechanisms for specifying inconsistencies and working towards eventual unification where appropriate. Given this, we expect browser vendors to offer APIs and capabilities beyond what's specified."

I think it's worth including something like this here, since I think this is significantly different from most other specs / groups. Can we hoist this (or something like it) to here, so that it's clear this also applies to any specs produced by this working group?

[carlosjeurissen]

Suggested change

	<p>The following things are in-scope for this Working Group:</p>
	<p>The following features are in-scope for this Working Group:</p>

This terminology aligns with the template.

[carlosjeurissen]

Suggested change

	<strong>Permissions model</strong> - what sorts of powerful features
	<strong>Permissions model</strong> - which powerful features

[carlosjeurissen]

Suggested change

	home page will link to a more comprehensive page with detailed
	homepage will link to a more comprehensive page with detailed

[carlosjeurissen]

Suggested change

	Users can extend their browsers with extensions: small applications
	that run within a browser that can modify its behaviors and alter page
	content. Inspired by improvements to interoperability over the last
	Users can extend their browsers with extensions: small applications that
	run within a browser that can change the behaviour of the user agent,
	alter the content of web pages and add to and replace features of the browser
	interface. Inspired by improvements to interoperability over the last

[carlosjeurissen]

Explicitly mentioning the ability of extensions to alter and add to the browser user interface as not to skip this common oversight (like the way permissions are handled).