[L3 CR] Transition Request Draft

[simoneonofri]

Document title, URLs, estimated publication date

WD https://www.w3.org/TR/2025/WD-webauthn-3-20250127/
ED https://w3c.github.io/webauthn/

Abstract

https://www.w3.org/TR/webauthn-3/#abstract

Status

https://www.w3.org/TR/webauthn-3/#sotd

Link to group's decision to request transition

https://www.w3.org/2024/12/18-webauthn-minutes.html?#7cd1

Changes

https://www.w3.org/TR/webauthn-3/#revision-history

Requirements satisfied

N/A

Dependencies met (or not)

Considering the groups present in the charter:

• W3C groups: There is significant cross-participation across the various groups, both by the editors and by the groups, thanks also to cross-meetings during the various TPACs, particularly for the payments section.
• External groups: there has been formal communication with
  • IETF SecDir
  • FIDO (Team only)

Wide Review

Design:

• Request
• No Issues

Accessibility:

• Request
• No issues

Internationalization:

• Request
• only old issues open

Security:

• Request
• No issues

Privacy:

• Request
• Issues

Issues addressed

https://github.com/w3c/webauthn/milestone/32

Formal Objections

No

Implementation

#2249

Patent disclosures

https://www.w3.org/groups/wg/webauthn/ipr/

[simoneonofri]

Above the draft for the transition request.

There are a few aspects to discuss, possibly during today's call, net of privacy issues w/o answers by privacy (thanks @timcappalli).

If reviews give the key to entering CR, the key to exiting CR is in implementations.

• How do we want to demonstrate that implementations (e.g., Web Test) of the various features are present?
• Which features should be considered necessary for exiting, and which ones could be lost?
  • If the latter, they should be marked as “at risk” and can be removed.
  • If, on the other hand, there is a feature that is not “at risk” but lacks an implementation, the CR transition request must be redone.
• Set a date by which to exit CR (which is essentially the time for implementations)

To give some examples from the past.

CR L2

For the Web Authentication specification to move to Proposed Recommendation we must show two browser implementations supporting the new features and extensions. The spec will be run through the Level 2 test harness.

CR L1:

For the Web Authentication specification to move to Proposed Recommendation we must show two independent, interoperable implementations of the Web Authentication API in browsers. We will also have multiple interoperable implementations of the AppID extension, validating the extensions framework. All other extensions are "at risk". If there are not multiple interoperable implementations, each may independently be removed or made informative at Proposed Recommendation.

[cc'ing @timcappalli, @emlun, @MasterKale, @nadalin]

[emlun]

Should we do #2302 before or after this?

[simoneonofri]

@emlun before, when we have the CR, in general, we should limit to editorial changes

[emlun]

• Fold changes since L3WD2 into changes since L2 #2356

(Depends on #2346)

[simoneonofri]

@nsatragno regarding what you said about how to verify implementations during the call, do you think this is acceptable as exit criteria?

For the Web Authentication specification to move to Proposed Recommendation we must show two browser implementations supporting the new features and extensions. The spec will be run through the Level 3 on the Web Platform Tests.

[nsatragno]

Sounds fine. Check out https://wpt.fyi/results/webauthn?label=experimental&label=master&aligned for current WPT results on major browsers.