Closed emlun closed 1 month ago
I aim to do a thorough review of this by the 2024-09-11 WG meeting.
The following errors may be thrown during create()
as of commit a871f796c591721c9556f119924ee29484b441f5 (2024-09-04):
During init:
During lifetimeTimer wait loop:
Rearranging this as a map of errors to causes of that error, and assigning numbers to each for easy reference:
Concern 1: (NA8) could cause an information leak that could identify the user without consent (§14.5.1. Registration Ceremony Privacy). The information leak occurs if the Relying Party can distinguish between these cases:
Preconditions:
Case (ii) requires that the client has first probed the authenticator for any credentials listed in excludeCredentials
.
Observations: The only preconditions for (NA8) are that the client successfully runs through the initialization steps 1-22, then offers the user an option to cancel, and the user exercising that option. There is no precondition of probing for excluded credentials.
Conclusion: (NA8) cannot cause an information leak that could identify the user without consent.
Concern 2: (NA7) and (NA8) should be indistinghishable in order to not facilitate the information leak in Concern 1.
Observations:
(NA7) and (NA8) are already distinguishable, since (NA7) likely occurs around options.publicKey.timeout
milliseconds after create()
was invoked, especially if options.publicKey.timeout
falls within the recommended reasonable range.
Since in Concern 1 we already concluded that (NA8) cannot cause the relevant information leak, the information leak cannot be made worse by (NA7) and (NA8) being distinguishable.
Conclusion: (NA7) and (NA8) do not need to be indistinguishable. (NA7) can be safely changed to a distinct TimeoutError.
Remark 3: (I2) does allow the Relying Party to detect that an excluded credential is available to the user. However, this error has an explicit consent precondition in the authenticator operation: (If looking up descriptor.id in this authenticator returns non-null, and the returned item's RP ID and type match rpEntity.id and excludeCredentialDescriptorList.type respectively) and (If the user confirms consent to create a new credential). If the user does not consent to this, then the authenticator instead returns an error code equivalent to "NotAllowedError", which does not immediately cause an error on the client layer but most likely eventually results in (NA7) or (NA8) instead.
The following errors may be thrown during get()
as of commit a871f796c591721c9556f119924ee29484b441f5 (2024-09-04):
During init:
During lifetimeTimer wait loop:
Rearranging this as a map of errors to causes of that error, and assigning numbers to each for easy reference:
Concern 4: (NA20) could cause an information leak that could identify the user without consent (§14.5.2. Authentication Ceremony Privacy). The information leak occurs if the Relying Party can distinguish between these cases:
Preconditions:
Both case (i) and case (ii) require that the client has first probed the authenticator for any credentials listed in allowCredentials
.
Observations: The only preconditions for (NA20) are that the client successfully runs through the initialization steps 1-20, then offers the user an option to cancel, and the user exercising that option. There is no precondition of probing for eligible credentials.
Conclusion: (NA20) cannot cause an information leak that could identify the user without consent.
Concern 5: (NA18) and (NA20) should be indistinghishable in order to not facilitate the information leak in Concern 4.
Observations:
(NA18) and (NA20) are already distinguishable, since (NA18) likely occurs around options.publicKey.timeout
milliseconds after get()
was invoked, especially if options.publicKey.timeout
falls within the recommended reasonable range.
Since in Concern 4 we already concluded that (NA20) cannot cause the relevant information leak, the information leak cannot be made worse by (NA18) and (NA20) being distinguishable.
Conclusion: (NA18) and (NA20) do not need to be indistinguishable. (NA18) can be safely changed to a distinct TimeoutError.
The spec contains privacy concerns such as this in the final steps of §5.1.3. Create a New Credential and §5.1.4. Use an Existing Credential to Make an Assertion:
These privacy concerns were written for an architecture of these operations that is no longer relevant, and may in fact not have been relevant even at the time the privacy concerns were written (see: https://github.com/w3c/webauthn/pull/2095#discussion_r1698881047). We should review whether these privacy concerns are still valid, or if they can be shown to be redundant under the current specification of these operations and thus removed. This would simplify initiatives such as #2096 and #2095.
Proposed Change
Review the validity of these privacy concerns. If they can be shown redundant, delete the prohibition against returning certain errors due to these privacy concerns.