FedCM "core": move "extensions" out of the current spec into an independent spec

[samuelgoto]

As we've been discussing in the CG/WG the last few calls, a few of us started looking into a possible subset of the FedCM specification, which we've been calling "core": a subset of FedCM that 2 independent implementations (in this specific exercise, Chrome and Firefox) agree to implement and ship.

We have been debating exactly what that means, but one good starting point is to "move" features in the current spec that are "clearly" not in "core" (as defined as a feature that any implementation chooses not to ship) into a separate spec, lets call it "extensions".

There are probably more, but here is a concrete list that came up:

• passive mode
• The Disclosure Prompt
  • The Client Metadata Endpoint
    • the client_metadata_endpoint
    • the fetch the client metadata algorithm
  • The Fields API
  • Disclosure in the id_assertion_endpoint:
    • disclosure_text_shown
    • disclosure_shown_for
    • fields
  • The request permission to sign-up algorithm
• anything else?

There are a lot of other features that are being incubated (e.g. idp registration and lighweight mode) that aren't yet in the spec, so as we review the PR we can decide in the PR itself (rather than here) whether it fits into the "core" or "extensions" specification.

There is also a list of issues that are blocking the candidate recommendation that we'd expect to be part of "core" at some point.

This issue is only covering:

1. Creating an independent "extensions" spec and
2. Moving what we classify as "extension" out of the current FedCM spec

This can be closed when/if the "core" FedCM spec only has features that have the support of 2 independent implementations (e.g. a strict subset of the spec that we can use for the Candidate Recommendation).

[selfissued]

Other W3C specifications have marked features as being "At Risk" if there aren't presently two interoperable implementations. That allows a spec to still go to CR. Doing that would seem cleaner than breaking the spec into multiple specs based on what is and isn't presently implemented.

[samuelgoto]

Other W3C specifications have marked features as being "At Risk" if there aren't presently two interoperable implementations. That allows a spec to still go to CR. Doing that would seem cleaner than breaking the spec into multiple specs based on what is and isn't presently implemented.

This sounds like a great suggestion to me and more incremental than breaking things into two separate specs. @bvandersloot-mozilla WDYT? Would that work for you as an implementation?

[npm1]

One thing that was not clear to me was what happens to 'at risk' features when we want to release CR. Does anyone mind explaining that again to me?

[TallTed]

"At Risk" features typically exist in CRs (Candidate Recommendations), and each warning or feature, as appropriate, is removed when transitioning from CR to PR (Proposed Recommendation).

If two or more independent implementations have demonstrated (or, in some cases, claimed) support for the feature by the end of CR, the "at risk" warning gets removed.

If only one or zero implementations have demonstrated (or claimed) support for the feature by the end of CR, the "at risk" warning and the feature get removed.

There are editorial tactics that can make each of the above easier, such as specifying each feature in its own atomic section within the document — so that the relevant section or warning can be easily deleted, without impacting the remainder of the document. Even so, some editing of the remainder of the document may still be needed, to remove any cross-references to the now-deleted feature.

If an At Risk feature is removed for PR, it may sometimes be transformed to a Note, or sometimes treated as one of the inputs to a subsequent version of a given spec, or sometimes be left to the mists of time.

[TallTed]

Folks may find reading over the W3C Process helpful, especially the section on Recommendation Track and its Maturity Stages.

[bvandersloot-mozilla]

On the one hand, this does make it easier to manage, on the other, I fear that "At Risk" may overstate the status of some of the features we are carving out. It isn't strictly "what is presently implemented" defining what is carved out, but rather things that have no plan for implementation in a second engine. In that sense, I think that an extensions document is probably more appropriate.

[wseltzer]

Discussed in 11 March meeting.

[samuelgoto]

In that sense, I think that an extensions document is probably more appropriate.

What if we started by marking sections of the spec "At Risk" so that we figure out which parts we want to break out, and then we can decide whether those sections should stay (maybe can use another label? say, "extensions") or move them to a separate spec?

Would that work?

[bvandersloot-mozilla]

I would really prefer if we kept along with our previous plan. I thought we had a sense of what we wanted to break out? This has the benefit of removing the need for a fine-tooth comb to determine what the cross browser bits are when looking at the spec. Is there unexpected difficulty in creating the extensions spec?