- From: Petr Dvořák via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Mar 2025 16:54:03 +0000
- To: public-webauthn@w3.org
@ve7jtb Thank you for the comments! 😊 Examples with failed implementation along these lines would be helpful, though. > It won't work with discoverable credentials We are generally OK with that. For login, we do not need data as a part of the flow. If the user is identified, we can use non-discoverable credentials with no practical penalty. > large credential ID currently trigger bugs in iOS and MacOS processing of allow and exclude lists(I hope that gets fixed soon). We have never seen this one, and we shipped ~10k authenticators. It is likely because our transaction data is relatively small, we basically append the following to the base 16bytes of credentials ID: ``` A1*A100CZK*ICZ2730300000001165254011*D20180425 ``` > It likely also violates CTAP requirements for certification (this is a Fido discussion). Unlikely. We went through interop testing already and will move forward with certifications soon. The CTAP explicitly works with credential ID as a byte array. The value is intended to carry different authenticator ID formats, including support for fully stateless authenticators. Which is, in principle, what we do. Yes, we are a bit unusual in what we do (the [definition of Credential ID](https://www.w3.org/TR/webauthn-2/#credential-id) does not explicitly mention it), but we do not see how this would offend anyone. From the ontology perspective, we can easily solve the transaction signing problem if we ship an infinite number of authenticators that can sign any operation to the user. The user would have to choose the right one for the given operation. But shipping infinite HW devices is... well, complex... so we do it via software by identifying a virtual authenticator. We have an identifier prefix and identifier suffix. Authenticator recognizes itself by recognizing its ID, which is based on prefix and suffix combination. > Authenticators have tried similar things in the past and have been blocked by Chrome and other browsers. I would be very interested in how Chrome and other browsers could do this. Practically, I am convinced the web browser has absolutely no way to screw this up for us (even though reading through the discussion above does not inspire much confidence). The browser cannot make any assumption about the credential ID value structure or measure its randomness (it is a byte array), especially if we have the firmware and connection of our authenticator under control (we can forcefully reconnect the authenticator). -- GitHub Notification of comment by petrdvorak Please view or discuss this issue at https://github.com/w3c/webauthn/pull/2020#issuecomment-2758761346 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 27 March 2025 16:54:04 UTC