Add "Credential Manager Trust Group (CMTG) Key" extension by timcappalli · Pull Request #2377 · w3c/webauthn

timcappalli · 2026-01-08T22:34:50Z

Closes #2338

The following tasks have been completed:

Modified Web platform tests (link)

Implementation commitment:

WebKit (link to issue)
Chromium (link to issue)
Gecko (link to issue)

Documentation and checks

Affects privacy
Affects security
Updated explainer (link)

Preview | Diff

nsatragno

Thank you so much for doing this work! Here's a first pass at a review.

Co-authored-by: Nina Satragno <nsatragno@gmail.com>

nsatragno · 2026-07-03T19:20:27Z

+
+    1. Let |cmtgPrivateKey| be the newly created or existing [=Credential Manager Trust Group private key=].
+
+    1. Let |cmtgKeySig| be the result of signing the [=assertion signature=] [input](#fig-signature) with |cmtgPrivateKey|,


This is ambiguous in a subtle way. The assertion signature input is the authenticatorData + clientDataHash. However, the authenticatorData is not the same for the authenticator get assertion and make credential operations.

I think for make credential, you mean to use the computed authenticatorData with the attestedCredentialData. This makes the most sense to me.

So, saying "assertion signature input" for make credential seems subtly wrong. Why not spell out what is signed exactly?

Add basic virtual authenticator support for CMTG keys at the device layer. This lets us write tests without needing the enclave. Later, we'll wire this to devtools and the chromedriver testing API. See w3c/webauthn#2377. Bug: 485888879 Change-Id: I19330587a3246b49e0c533d8c7915085e675b0ce Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8041160 Reviewed-by: Ken Buchanan <kenrb@chromium.org> Commit-Queue: Nina Satragno <nsatragno@chromium.org> Cr-Commit-Position: refs/heads/main@{#1657412}

nsatragno

Approved with two nits.

Thank you so much for taking on this feature. I really appreciate it!

nsatragno · 2026-07-20T17:53:54Z

+    };
+    partial dictionary AuthenticationExtensionsClientInputsJSON {
+      boolean cmtgKey;
+}   ;


nit: remove the extraneous whitespace.

nsatragno · 2026-07-20T17:59:10Z

+
+1. Let |extensionOutput| be the value of <code>|clientExtensionResults|.{{AuthenticationExtensionsClientOutputs/cmtgKey}}</code>.
+
+1. If |extensionOutput| does not contain the required members of {{AuthenticationExtensionsCmtgKeyOutputs}},


nit: extensionOutput may not be present.

If |extensionOutput| is not present or |extensionOutput| does not contain...

MasterKale · 2026-07-21T19:01:28Z

+    1. If this algorithm is being run as part of [=authenticatorMakeCredential=]:
+
+        1. Let |cmtgKeySig| be the result of signing the concatenation of |authenticatorData| (as constructed in [[#sctn-generating-an-attestation-object]],
+            which includes |attestedCredentialData|) and |clientDataHash|, with |cmtgPrivateKey|,
+            using the same signature algorithm as that used by the [=user credential=]'s [=credential key pair=].
+


Related to https://github.com/w3c/webauthn/pull/2377/changes#r3624840460, this might be a good place to add an additional step, after this existing one, to iterate over existing CMTG keys and ensure that the authenticator is still managing a credential source for each CMTG key's corresponding ([=public key credential source/id|Credential ID=], [=public key credential source/rpId|RP ID=], [=public key credential source/userHandle|User Handle=]) tuple. If not, delete the CMTG key.

bjorn3 · 2026-07-24T18:52:56Z

Why does the PR description not have "Affects privacy" checked? This would allow distinguishing between multiple devices of the same user without the user explicitly consenting to it. That is a fingerprintable signal, right?

harshlal028 · 2026-08-26T21:33:48Z

+
+    NOTE: [=[RPS]=] MUST ignore any keys in |extensionOutput| that are not defined in the {{AuthenticationExtensionsCmtgKeyOutputs}} dictionary.
+
+1. Parse |cmtgKey| as a COSE_Key.


harshlal028 · 2026-08-26T21:33:53Z

+1. Verify that the algorithm used for |signature| matches the COSE algorithm identifier of the [=credentialPublicKey=]
+    within the [=attestedCredentialData=] of |authData|.
+
+1. Verify that |signature| is a valid signature over the [=assertion signature=] [input](#fig-signature)


Registration produces an attestation object, not an assertion. Referring to the "assertion signature input" during registration might be confusing.

harshlal028 · 2026-08-26T21:33:59Z

+
+1. Verify that |signature| is a valid signature over the [=assertion signature=] [input](#fig-signature)
+    (i.e. |authData| and |hash|) by the [=Credential Manager Trust Group Key=] |cmtgKey|.
+


Maybe it would be worth explicitly calling out the case if verification fails.

harshlal028 · 2026-08-26T21:34:04Z

+1. Verify that the algorithm used for |signature| matches the algorithm of the public key
+    previously stored for the |credentialRecord|.
+
+1. Verify that |signature| is a valid signature over the [=assertion signature=] [input](#fig-signature)


Maybe it would be worth explicitly calling out the case if verification fails.

harshlal028 · 2026-08-26T21:34:11Z

+    1. Let |newEntry| be a new [=CMTG Key Record=] where its [$CMTG Key Record/publicKey$] is |cmtgKey|
+        and its [$CMTG Key Record/lastUsed$] is the current time.
+
+    1. Append |newEntry| to |credentialRecord|.[$credential record/cmtgKeyRecords$].


Would it make sense to add that appending |newEntry| to cmtgKeyRecords should only occur if the RP's policy allows accepting the new trust group (e.g., following successful step-up or risk checks) is passed.

harshlal028 · 2026-08-26T21:36:19Z

+        1. Let |cmtgKeySig| be the result of signing the [=assertion signature|assertion signature input=] with |cmtgPrivateKey|,
+            using the same signature algorithm as that used by the [=user credential=]'s [=credential key pair=].
+
+        Note: The [=assertion signature=] [input](#fig-signature) and |cmtgKeySig| covers the [=[RP]=]'s {{PublicKeyCredentialCreationOptions/challenge}}


Maybe it should be PublicKeyCredentialRequestOptions/challenge given it is assertion.

emlun · 2026-09-16T18:33:17Z

+##### Registration (`create()`) ##### {#sctn-cmtg-key-extension-verification-create}
+
+If a {{AuthenticationExtensionsClientOutputs/cmtgKey}} extension output is present in a {{CredentialsContainer/create()|navigator.credentials.create()}} call,
+the below verification steps are performed in the context of <a href=#reg-ceremony-verify-extension-outputs>this step</a> of [[#sctn-registering-a-new-credential]]


For the sake of the text making sense even if the hyperlinks get dropped (perhaps unlikely, but might be relevant for plain text quotations if nothing else), I think we should refer to this as a "step X" number. That's also the style currently used throughout the document.

emlun · 2026-09-16T18:38:56Z

+
+1. Parse |cmtgKey| as a COSE_Key.
+
+1. Verify that the algorithm used for |signature| matches the COSE algorithm identifier of the [=credentialPublicKey=]


|signature| is undefined here. I think this is meant to be <code>|extensionOutput|.{{AuthenticationExtensionsCmtgKeyOutputs/signature}}</code>?

Suggested change

1. Verify that the algorithm used for |signature| matches the COSE algorithm identifier of the [=credentialPublicKey=]

1. Verify that the algorithm used for <code>|extensionOutput|.{{AuthenticationExtensionsCmtgKeyOutputs/signature}}</code> matches the COSE algorithm identifier of the [=credentialPublicKey=]

(This should then also apply to further references to |signature| below.)

emlun · 2026-09-16T18:40:21Z

+
+    1. Terminate these validation steps as inconclusive.
+
+    NOTE: [=[RPS]=] MUST ignore any keys in |extensionOutput| that are not defined in the {{AuthenticationExtensionsCmtgKeyOutputs}} dictionary.


Per #1979, the normative MUST should not be in a NOTE block.

emlun · 2026-09-16T18:49:49Z

+    (The signature algorithm is the same as for the [=user credential=].)
+
+1. If |credentialRecord|.[$credential record/cmtgKeyRecords$] contains an entry |e|
+    where |e|.[$CMTG Key Record/publicKey$] matches |cmtgKey|:


"matches" might be a dangerous word here as it could be interpreted several ways (for example, a COSE_Key with kid might "match" a COSE_Key without kid but other members equal). But since §2.4 requires CTAP2 canonical CBOR for everything, and §6.5.1 further restricts the encoding of these public keys to forbid optional values (like kid), it should be safe to assume that all encodings of the same key should be byte-identical. So it should be safe to specify here that publicKey and cmtgKey should be equal byte arrays, which eliminates any ambiguity.

emlun · 2026-09-16T18:57:42Z

+The extension output includes the public key and a signature generated using the
+[=Credential Manager Trust Group private key=] (`cmtgKey1`).
+
+<div class="example">


Both of these two examples look like most of it is the usual base WebAuthn stuff, just with the addition of a cmtgKey: true extension input, right? If so, then I don't think these examples seem very helpful as is. They give an initial impression that you need a lot of code to use this extension, while actually the cmtgKey part is a very small fraction of the example volume (at least on the client side). It might be more helpful to reduce the example to concentrate on the extension parts specifically, and perhaps also include some abbreviated pseudocode for what needs to happen on the server side too.

@emlun what do you think of the updated example?

nsatragno · 2026-10-14T19:59:31Z

+standard [=authentication=] verification:
+
+```
+cmtgOutput = response.clientExtensionResults.cmtgKey


Perhaps we should tell relying parties that they need to obtain the CMTG key from the extensions section of the authenticator data rather than from the client extension results. Otherwise there's little point in having the CMTG key be signed by the passkey.

(This makes me think: is there a point then in copying the public key to the extensions output?)

…MTGK, a=testonly Automatic update from web-platform-tests [webauthn] Renderer implementation for CMTGK Implement the renderer side of Credential Manager Trust Group (CMTG) Keys. See w3c/webauthn#2377. Fuchsia-Binary-Size: Size increase is unavoidable. Bug: 485888879 Change-Id: I3a75a7d7d598ec8078d5424e292ec724eaf497b9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7841424 Reviewed-by: Ken Buchanan <kenrb@chromium.org> Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Auto-Submit: Nina Satragno <nsatragno@chromium.org> Commit-Queue: Nina Satragno <nsatragno@chromium.org> Cr-Commit-Position: refs/heads/main@{#1633722} -- wpt-commits: 2f1307421d80b0ef84dfe4b8fd26f3f8421feb70 wpt-pr: 59982

timcappalli added 9 commits November 25, 2025 20:30

initial shape of the cmtgKey extension

b0c1b60

add dfns

a67d081

simplify to assertion signature

ae644a8

Merge remote-tracking branch 'origin/main' into 2338-cmtg

75d43e6

spelling

01db582

line breaks

0a4ead0

Merge remote-tracking branch 'origin/main' into 2338-cmtg

cd9a036

intro text and RP usage

5f7b9f1

RP processing rules

adcef86

timcappalli marked this pull request as ready for review January 26, 2026 18:59

nsatragno self-requested a review February 2, 2026 21:05

nsatragno reviewed Feb 3, 2026

View reviewed changes

timcappalli and others added 18 commits February 4, 2026 10:38

first pass of editorial feedback from Nina

1f3fc61

Apply suggestion from @nsatragno

e2e857c

Co-authored-by: Nina Satragno <nsatragno@gmail.com>

add verification of algo step

4920b67

Apply suggestion from @nsatragno

a579300

Co-authored-by: Nina Satragno <nsatragno@gmail.com>

consistency with device references

85df71a

review feedback

2646a20

add CMTG credential record and registration update

49850fc

fix registratio verification steps

b5592ae

fix authentication verification steps

ff31f97

credential record for authentication

7b44471

accidential change

f1051fc

add No CMTG Key processing rules

3730964

typos and RP step fixes

4c93271

be more explicit about time

5ba9955

Fix references and variables

eaf26f8

Small tweaks

7577f5e

Add additional steps to client extension processing for clarity

38c0c5e

clarity

e95e03a

nsatragno reviewed Jul 3, 2026

View reviewed changes

nsatragno reviewed Jul 13, 2026

View reviewed changes

Comment thread index.bs

timcappalli added 2 commits July 15, 2026 21:11

Merge branch 'main'

b4e9e14

Split out make vs get signature

0b64432

nsatragno approved these changes Jul 20, 2026

View reviewed changes

Nina feedback

c0a4bef

MasterKale reviewed Jul 21, 2026

View reviewed changes

Spomky mentioned this pull request Aug 20, 2026

chore(spec-watch): upcoming WebAuthn changes to anticipate web-auth/webauthn-framework#926

Open

harshlal028 reviewed Aug 26, 2026

View reviewed changes

Comment thread index.bs Outdated

harshlal028 reviewed Aug 26, 2026

View reviewed changes

Comment thread index.bs

harshlal028 approved these changes Aug 26, 2026

View reviewed changes

nsatragno mentioned this pull request Aug 28, 2026

cmtgKey extension should allow returning more than one key to facilitate rotating keys to a new algorithm #2472

Open

emlun reviewed Sep 16, 2026

View reviewed changes

timcappalli added 7 commits September 23, 2026 13:54

remove dangling comma

fee0279

Added clarity around client/CM support

3ace13d

Simplify example and include server side

1fcdbf8

Split back out reg vs auth

630c98d

Remove note for MUST

798f4e3

s/PublicKeyCredentialCreationOptions/PublicKeyCredentialRequestOptions

4464d59

Clarify authenticatorData for create

d0cf465

nsatragno reviewed Oct 14, 2026

View reviewed changes


		1. Let \|cmtgPrivateKey\| be the newly created or existing [=Credential Manager Trust Group private key=].

		1. Let \|cmtgKeySig\| be the result of signing the [=assertion signature=] [input](#fig-signature) with \|cmtgPrivateKey\|,


		1. Let \|extensionOutput\| be the value of <code>\|clientExtensionResults\|.{{AuthenticationExtensionsClientOutputs/cmtgKey}}</code>.

		1. If \|extensionOutput\| does not contain the required members of {{AuthenticationExtensionsCmtgKeyOutputs}},


		NOTE: [=[RPS]=] MUST ignore any keys in \|extensionOutput\| that are not defined in the {{AuthenticationExtensionsCmtgKeyOutputs}} dictionary.

		1. Parse \|cmtgKey\| as a COSE_Key.


		1. Verify that \|signature\| is a valid signature over the [=assertion signature=] [input](#fig-signature)
		(i.e. \|authData\| and \|hash\|) by the [=Credential Manager Trust Group Key=] \|cmtgKey\|.


		1. Parse \|cmtgKey\| as a COSE_Key.

		1. Verify that the algorithm used for \|signature\| matches the COSE algorithm identifier of the [=credentialPublicKey=]

	1. Verify that the algorithm used for \|signature\| matches the COSE algorithm identifier of the [=credentialPublicKey=]
	1. Verify that the algorithm used for <code>\|extensionOutput\|.{{AuthenticationExtensionsCmtgKeyOutputs/signature}}</code> matches the COSE algorithm identifier of the [=credentialPublicKey=]


		1. Terminate these validation steps as inconclusive.

		NOTE: [=[RPS]=] MUST ignore any keys in \|extensionOutput\| that are not defined in the {{AuthenticationExtensionsCmtgKeyOutputs}} dictionary.

Conversation

timcappalli commented Jan 8, 2026 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nsatragno left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nsatragno left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjorn3 commented Jul 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

timcappalli commented Jan 8, 2026 •

edited by pr-preview Bot

Loading