backup states in authenticator data #1695
Conversation
timcappalli
changed the title
timcappalli
changed the title
|
Call on 2022-02-09: TODO - Add validation process to section 7.2 (and also check 7.1 registration) |
|
@timcappalli Thank you for kicking off this effort to make use of these extra bits. We here at Duo (and the greater Cisco) are eager for the extra insight into passkey utilization as we continue to champion WebAuthn adoption for passwordless auth. Once passkeys launch it's just a matter of time before customers start asking us for greater control over the use of passkeys by their users. If we can have the data in these bits on Day 1 RPs like us can better adapt our product to respond to these requests, instilling confidence in our users that WebAuthn is the preferred way to achieve a more secure authentication experience. |
There was a problem hiding this comment.
Here's some comments/suggestions building on @emlun's review... 😄
…al terms as discussed on the 2022-04-06 call
|
The platforms might decide whether the new device is capable of restoring the backup credential? Is there any policy for this? |
Wouldn't this also imply a change in the attestation chain of the credential when it's restored since it's on a different piece of hardware that has different UV capabilities? |
I believe this question is what the But it's a good point that we should probably include some guidance or disclaimers about how this interacts with UV. Presumably, a credential restored from backup onto a new authenticator would use whatever UV option(s) available on the new authenticator, unrelated to any UV configured on the original authenticator. So for example, if the original authenticator had a PIN configured, then after restoring the credential onto a new authenticator, the new authenticator may have a different PIN configured or no PIN at all. Whether my presumption above is accurate or not, I think we should call out in the User Verification definition how credential backup is expected to interact with UV. This might relate to |
|
In practice, the three platform authenticators only support credential release via UV if the RP requests it or not. However, from a specification point of view, those are just current implementation choices. Unless we say explicitly that multi-device credentials need to be protected with some form of user verification, then we need to remind RP that a credential might always be returned without UV even if it was created with UV. That is also the case now as the UV flag can be tampered with in the request. Chrome and Windows will prompt a user to add a pin for roaming authenticators if you send UV required in the request. |
|
At least, during registration process, RP has a way to specify their preference or policy for the authentication. But, if the restored credential has different properties, it will cause unexpected situation. So, my thought is that the backup credential needs to keep the basic properties from the original one. |
https://bugs.webkit.org/show_bug.cgi?id=240353 rdar://problem/93191958 Reviewed by Brent Fulgham. Source/WebCore: Add flags for credential backup state: w3c/webauthn#1695 * Modules/webauthn/WebAuthenticationConstants.h: Source/WebKit: This patch adds support for backup state flags, which will be added to the Web Authentication spec soon via w3c/webauthn#1695 These flags are set whenever a credential is "backup eligible" and "backed up" hinting to RPs that the credential is "durable" and may persist through device restores. This is useful for RPs that may choose to offer to remove the user password if a credental is in this state. * UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm: (WebKit::LocalAuthenticatorInternal::authDataFlags): (WebKit::LocalAuthenticator::continueMakeCredentialAfterUserVerification): (WebKit::LocalAuthenticator::continueGetAssertionAfterUserVerification): Canonical link: https://commits.webkit.org/250501@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@294122 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WebAuthn] Include backup state in authenticatorData
https://bugs.webkit.org/show_bug.cgi?id=240353
rdar://problem/93191958
Reviewed by Brent Fulgham.
Source/WebCore:
Add flags for credential backup state: w3c/webauthn#1695
* Modules/webauthn/WebAuthenticationConstants.h:
Source/WebKit:
This patch adds support for backup state flags, which will be added to
the Web Authentication spec soon via w3c/webauthn#1695
These flags are set whenever a credential is "backup eligible" and "backed up"
hinting to RPs that the credential is "durable" and may persist through device
restores. This is useful for RPs that may choose to offer to remove the user
password if a credental is in this state.
* UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm:
(WebKit::LocalAuthenticatorInternal::authDataFlags):
(WebKit::LocalAuthenticator::continueMakeCredentialAfterUserVerification):
(WebKit::LocalAuthenticator::continueGetAssertionAfterUserVerification):
Canonical link: https://commits.webkit.org/250501@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@294122 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Canonical link: https://commits.webkit.org/250381.18@safari-7614.1.13-branch
git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-7614.1.13-branch@294134 268f45cc-cd09-0410-ab3c-d52691b4dbfc
|
Agreed to merge at face-to-face meeting. |
SHA: b24eb36 Reason: push, by @nicksteele Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This PR adds backup state bits to authenticator data as described in #1692
WIP
fixes #1692
improves #1665
Preview | Diff