Add "Credential Manager Trust Group (CMTG) Key" extension#2377
Add "Credential Manager Trust Group (CMTG) Key" extension#2377timcappalli wants to merge 14 commits intomainfrom
Conversation
nsatragno
left a comment
nsatragno
left a comment
There was a problem hiding this comment.
Thank you so much for doing this work! Here's a first pass at a review.
| : <dfn>Credential Manager Trust Group Key</dfn> | ||
| : <dfn>Credential Manager Trust Group Private Key</dfn> | ||
| : <dfn>Credential Manager Trust Group Public Key</dfn> | ||
| :: A [=Credential Manager Trust Group Key=], is a [=authenticator=]- / [=credential manager=]-, [=[RP]=]-, and [=user credential=]-specific |
There was a problem hiding this comment.
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.
index.bs
Outdated
|
|
||
| This [=authenticator extension|authenticator=] [=registration extension=] and [=authentication extension=] | ||
| enables an [=authenticator=]/[=credential manager=] to provide a signal to a [=[RP]=] | ||
| that two devices possessing the same [=backup eligible=] credential |
There was a problem hiding this comment.
| that two devices possessing the same [=backup eligible=] credential | |
| that two devices possessing the same [=backed up=] credential |
is slightly more precise, since by definition the credential must have been backed up for it to share the CMTG key.
index.bs
Outdated
| have established a trust relationship through a non-remote interaction, | ||
| such as a local setup or physical proximity. | ||
|
|
||
| This is done by creating an additional [=public key credential source=]-specific key pair |
There was a problem hiding this comment.
| This is done by creating an additional [=public key credential source=]-specific key pair | |
| This is done by creating an additional [=public key credential source=]-specific [=Credential Manager Trust Group key pair=] |
index.bs
Outdated
| This is done by creating an additional [=public key credential source=]-specific key pair | ||
| in the authenticator/credential manager, if such a key pair does not already exist for | ||
| the [=public key credential source=] being created or exercised, | ||
| and returning the [=Credential Manager Trust Group public key=] |
There was a problem hiding this comment.
At a given time, more than one CMTG may be valid for a credential on a device.
| and returning the [=Credential Manager Trust Group public key=] | |
| and returning one of the [=Credential Manager Trust Group public keys=] |
| (i.e. `authData` and `hash`) by the [=Credential Manager Trust Group public key=] |cmtgKey|. | ||
| (The signature algorithm is the same as for the [=user credential=].) | ||
|
|
||
| 1. If the [=[RP]=]'s [=user account=] mapped to the <code>|credential|.{{Credential/id}}</code> in play (i.e., for the user being authenticated) |
There was a problem hiding this comment.
You should refer to the credential record object here as well.
| (The signature algorithm is the same as for the [=user credential=].) | ||
|
|
||
| 1. Complete the steps from [[#sctn-registering-a-new-credential]] and, if those steps are successful, | ||
| store the |cmtgKey| value indexed to the <code>|credential|.{{Credential/id}}</code> in the [=user account=]. |
There was a problem hiding this comment.
You should refer to the credential record object here instead.
In fact, the credential record object should be updated to add CMTG public keys.
| 1. If the [=[RP]=]'s [=user account=] mapped to the <code>|credential|.{{Credential/id}}</code> in play (i.e., for the user being authenticated) | ||
| hold a `cmtgKey` value corresponding to the extracted |attObjForCmtgKey| fields, | ||
| then perform binary equality checks between the corresponding stored value and the extracted field value. | ||
| The [=[RP]=] MAY have more than one `cmtgKey` value mapped to the [=user account=] and <code>|credential|.{{Credential/id}}</code> pair |
There was a problem hiding this comment.
Instead of this note why not make L7937 a loop per stored CMTG key.
| 1. Store the extracted |cmtgKey| value indexed to the <code>|credential|.{{Credential/id}}</code> in the [=user account=]. | ||
| Terminate these verification steps. | ||
|
|
||
| See also [[#sctn-cmtg-key-extension-usage]]. |
There was a problem hiding this comment.
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.
| 1. If a [=Credential Manager Trust Group Key=] does not already exist for this {[=public key credential source/id|Credential ID=], | ||
| [=public key credential source/rpId|RP ID=], [=public key credential source/rpId|userHandle=]} tuple in the [=authenticator=]/[=credential manager=], |
There was a problem hiding this comment.
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:
- 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.
Co-authored-by: Nina Satragno <nsatragno@gmail.com>
Co-authored-by: Nina Satragno <nsatragno@gmail.com>
2 participants
Closes #2338
The following tasks have been completed:
Implementation commitment:
Documentation and checks
Preview | Diff