- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Jul 2022 03:50:05 +0000
- To: public-webauthn@w3.org
Firstyear has just created a new issue for https://github.com/w3c/webauthn: == Authenticator flag to indicate internal knowledge of rk (discoverable credential creation). == Suggestion: That in https://w3c.github.io/webauthn/#sctn-authenticator-data RFU2 or RFU1 is used to represent an authenticators internal knowledge of if it created a resident key. This flag would be 0 for "the authenticator may or may not have created an RK, and you should consult credProps or other knowledge sources". 1 would represent "the authenticator internally guarantees it created a resident key". Why: This is important is in high security and certified deployments, where absolute knowledge of the storage of the private key is required in a tamper resistant and attested signal. It is important for security teams to allow them to make decisions about their environment and possible risks. Compatibility: This would not be a "breaking" change since the property of the flag currently as 0 is "status quo", and devices in the future can indicate that flag set to "1" to provide a stricter assurance about the storage of the private key. In addition this positively coordinates with the backup state flags allowing an RP to distinguish a passkey that is resident vs a passkey that is a soft token or similar (such as a password manager). This would assist in threat modelling and risk assessment for RPs. Alternates: Currently as an RP there is no signed proof of resident key status during registration. The current signals we can use are to provide a discoverable authentication (empty allowed credentials) or to request the credProps extension. However, both have limitations. Discoverability to the client is not the same property as the key being resident and bound inside hardware. A client could theoretically populate allowedCredentials with key-wrapped-keys during an authentication which would satisfy client side discovery, but is not proof of the key being resident. And credProps as a client extension, may be altered by client side javascript, which may or may not undermine the RP's intent to have an RK created. credProps is a good signal for a user experience guide that discoverability *may* work, but it's not a security property that is asserted. Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1761 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 5 July 2022 03:50:07 UTC