nit: having "/[=credential manager=]" everywhere is awkward. Do we really need to introduce this term to the spec? I'd say drop the "credential manager". It's cleaner.

nit: the details for when a new key pair is minted should not be under "relying party usage" imo. Paragraphs 3 onwards are all about authenticator actions, with no mention of what RPs should do with this information. Those can go under the previous heading instead.

optional: consider adding details on how to use the signal and what it means. Something like:

When a relying party observes a new CMTG public key during a create or assert operation, the CMTG public key should be added to the credential record. On subsequent assertions, after validating the CMTG signature, if an existing CMTG public key is observed, the relying party should use this as a signal that there is a strong relationship between the device that produced an assertion and previously used devices. Otherwise, if the CMTG public key is new, the device producing the assertion may not have a strong relationship with previously used devices. The new CMTG public key should be added to the credential record, signaling the start of a separate trust group.

An invalid CMTG signature is not expected and should invalidate the entire request.

Let's also add some javascript examples, both on the spec and the explainer. The explainer doesn't have any javascript for processing a response.

Somewhere we need a discussion of what happens when the UA understands the extension but the authenticator does not. In that case, no CMTG will be returned. Perhaps this is the right place for it.

And the signature as well?

As written, CMTG keys seem to have a 1:1 relationship with public key credentials. Even if we don't define the mechanism that determines which devices belong to a trust group, we should incorporate the concept of trust groups to the execution steps:

1. If a [=Credential Manager Trust Group Key=] does not already exist for this [=public key credential source=] and [=credential manager trust group=] tuple,

We should have a definition for "credential manager trust group" as well.

I believe from what you wrote above, clientExtensionResults["cmtgKey"] is not CBOR, but a javascript AuthenticationExtensionsCmtgKeyOutputs object.

So I think you want something like

1. Let |cmtgKey| be the value of the `cmtgKey` member of |clientExtensionResults|.
2. Let |attObjForCmtgKey| be the value of the `cmtgKey` member of |cmtgKey|
<-- this leads me to believe you might want to name that member something else
    to avoid confusion. Your call.
3. Verify that |attObjForCmtgKey| is valid CBOR COSE...
4. Verify that |cmtgKey|.{AuthenticationExtensionsCmtgKeyOutputs/signature}} is a valid signature over...

Related to the comment above, |signature| and |cmtgKey| are not CBOR members, they're javascript members. Perhaps you wanted to have the RP verify the integrity of the CBOR encoded COSE public key?

You should refer to the credential record object here instead.

In fact, the credential record object should be updated to add CMTG public keys.

(Same comments apply as above)

You should refer to the credential record object here as well.

Instead of this note why not make L7937 a loop per stored CMTG key.

Would it be possible to add virtual authenticator support for this feature? It feels it should be pretty simple, and it'll be required to write WPTs.