on 2020-03-11 call, @agl notes that UVM is impl'd in Android (at this point) (and Edge android?). @ve7jtb sez he will do PR to remove the above list other than UVM extension.

We may be able to get two implementations of UVM.
The caveat with UVM is that it is only implemented on Android for the platform authenticator, and even that may be removed due to the platform authenticator no longer knowing what UVM method was actually used.
We will see if we can get two implementations to get it into the final approved version of Level 2.

EXTS is also out due to no implementations.

Transaction Authorization provides a simple and effective method to implement the PSD2 Dynamic Linking requirement.
In the Browser case, Javascript injection attacks (as Adam Langley explained) are a problem for the relying party to know what the user really sees.
So I think it would be important to have Browsers implementing transaction authorization - rather than removing the extension.

We might even want to find a way to allow Browsers supporting Transaction Authorization even with authenticators that don’t have a display.
One idea would be to let the Browser include the transaction text in the “CollectedClientData” in the case the Authenticator doesn’t provide native support for txAuth.

With that the Browser would send the transaction text to the Authenticator if the authenticator support displaying it, and the browser would display the transaction if the authenticator doesn't support transaction confirmation, e.g. most security keys.

I agree a extension like that would be good.

That may need to be a new extension however.

The problem is mostly that the browsers are hesitant to display RP provided text in the browser chrome.

That is probably the first issue that needs to be addressed.
John B.

PSD2 Dynamic Linking requirement can be done without ANY involvement of FIDO/WebAuthn, I don't know why we would put this requirement on WebAuthn when it can be done elsewhere

I advocate us deleting all the Level 1 extensions that have not been implemented in any shipping browser. Note that they can continue to be referenced in the L1 spec, even though they have been deleted from the L2 spec.

I would also support removing these from L2. They can still be referenced in L1.

Except for UVM, I also support this.

Add Mike as a reviewer for pull request.

Fixed by #1399

It's a great shame that txAuthSimple and txAuthGeneric were dropped from the spec. Is there any chance these will be reintroduced (either in their original form or in some new form) again?

There already exist FIDO2 tokens with display (see below) and these extensions were perfect match for confirming transaction data on the device display.

There were no implementations to meet the interoperability requirements to publish them within the WebAuthn specification.

Furthermore, there were indications that browser and platforms would continue to not support the extension - mixing system UI with consent for security/privacy release with injected dynamic contact is a recipe for user confusion.

What may be more feasible would be extensions for specific use cases without arbitrary text. For instance, a future extension might be imagined for approving financial transactions, where the request contains structured data and the authenticator or client fully controls the presentation of the request.

where the request contains structured data and the authenticator or client fully controls the presentation of the request.

I guess extension like txAuthSimple but with CBOR instead of a simple string would be nice. Can you please advice how to suggest this addition? I am unfamiliar with the process ...

Note that the extensions will remain registered in the IANA Registry at https://www.iana.org/assignments/webauthn/webauthn.xhtml#webauthn-extension-ids and can still be used, if implemented.

1. Can somebody please explain what those changes in detail mean to WebAuthn - e.g. where is the official statement about this change?
2. If those extension have already been removed why is there no deprecation warning on e.g. https://www.w3.org/TR/webauthn-3. According to the documentation https://www.w3.org/2019/01/webauthn-extensions.html#impl all providers support all extensions. @ve7jtb Wrote in the initial message that those extension "have not be implemented". From my perspective this both statements are completely contrary. Can somebody please solve that riddle?

Long history, Jan (@jpstotz). FIDO2/WebAuthn was intended to be a merger of the original FIDO U2F and UAF protocols - the former designed primarily for browser platforms on desktops/laptops, and the latter exclusively for mobile rich client applications. As standards groups inevitably show us, the effort resulted in a third protocol that includes some features of U2F and UAF - but not all.

The implementation page you referenced describes UAF implementations - they are the source of WebAuthn extensions which were defined in the L1 spec, but as W3C rules mandate, unless there are 2 confirmed, interoperable implementations, they cannot remain. Hence the debate about removing unimplemented extensions in L2.

@jpstotz I believe the page you linked concerns support from authenticator vendors, but that is only half the picture. All WebAuthn extensions are explicitly declared to be optional for both authenticators and clients to support, so it's not enough that just the authenticator supports one. WG representatives for the major browsers have stated that they have no plans to implement support for these removed extensions, so they were removed in L2 to better reflect what's likely to be supported in practice.

@emlun @arshadnoor Thanks for clarification.

In my opinion the separation of the "passwordless authentication" into WebAuthn and CTAP2 managed by two organizations (W3C/FIDO) make it pretty hard to get the full picture of what is actually usable.

Another level of confusion is the "level concept" of the WebAuthn standard. Typically if you use levels so level 2 includes or bases on level 1, but as the removal of extensions shows this is not the case in WebAuthn. A third dimension of confusion is introduced by FIDO as there are the Certified Authenticator Levels - again levels that have nothing to do with WebAuthn levels.

Why not call it as it is a "version" so we have version 1.0 and an partially incompatible version 2.0. That would be in my opinion way more easy to understand.

"Level" is a W3C term not unique to WebAuthn. At https://www.w3.org/TR/ you can find many more documents using this terminology.

Typically if you use levels so level 2 includes or bases on level 1, but as the removal of extensions shows this is not the case in WebAuthn.

The removal was not a deprecation - the extensions are still valid to be used by their unchanged level 1 definitions.

They were removed from the level 2 spec to better represent the reality that they do not work in the real world, and client implementations have indicated no interest in supporting them regardless of authenticator support.

In my opinion the separation of the "passwordless authentication" into WebAuthn and CTAP2 managed by two organizations (W3C/FIDO) make it pretty hard to get the full picture of what is actually usable.

The quick rule of thumb is that WebAuthn is a dependency of CTAP 2.x, not vice-versa. If there are things needed to use the Web Authentication API or to process messages which are not defined in the Web Authentication specification, then those are areas of improvement.

The API defined in WebAuthn lists the sum capabilities exposed to the relying party through client javascript, including by authenticators which do not conform to CTAP. That includes defining extension mechanisms for new attestation schemes and message-level extensions. CTAP defines a few of the latter, including some which make no sense to expose in a browser javascript context.

You also tend to have non-javascript API for interfacing with authenticators that reference the WebAuthn spec - for instance, native application APIs on Android, Windows, and iOS/macOS platforms. These usually define a mapping into native API of the JavaScript API, and may define additional rules around RPID validation (e.g. specified origin should have a file in a well-known location with certain contents) or entitlements (such as an optional capability for an app to operate for all RPID, such as a web browser).