You can register new credential (through Windows Hello PIN/Camera/FingerPrint) but Authenticate doesn't work displaying "error occurred during assertion request. I debugged it on server Java side code and it looks like it fails in com.google.webauthn.gaedemo.server.Server class -> if (!Crypto.verifySignature(publicKey, signedBytes, assertionResponse.getSignature(),
signatureAlgorithm)) {
throw new ServletException("Signature invalid");
}

Basically, Crypto.verifySignature signature returns false. Further debugging into Java native crypto code indicates javax.crypto.badpaddingexception error.
Again, this happens only when using Edge (Windows Build 1809) and Windows Hello Credentials (PIN, fingerprints, camera). It works on Edge, same Windows Build 1809 when using USB Yubico key.

Microsoft has its own demo of webauthn - https://github.com/MicrosoftEdge/webauthnsample and https://webauthnsample.azurewebsites.net. It works just fine with both USB/Yubico/feitian (cross-platform) and Windows Hello (platform) authenticators. Please, advice if you support Windows Hello authenticators and if yes, then how to fix this issue.

Thanks,
Aleksey
[email protected]

After I click "AUTHENTICATE" in the demo, I see the pop-up below, but touching the YubiKey C nano doesn't register. I can use that security key to log into corp sites (I'm a Googler) without problem.

Pixelbook running Chrome OS Version 71.0.3558.0 (Official Build) dev (64-bit).

1. The clientdatajson should just be passed through as a strong until after signature verification, at which time it could be unpacked for other types of verification.

2. The current handling of the json in this class is a little unorthodox and could lead to inconsistent ordering of json pairs. (i.e. the stuff involving bytes):

https://github.com/google/webauthndemo/blob/37c77737a51f929a7601c3733b9a38af8a937fd0/src/main/java/com/google/webauthn/gaedemo/objects/AuthenticatorAttestationResponse.java

MacBook Pro with TouchID shows error "User verifying platform authenticator is NOT available."

Hi,
I would like to raise a PR to fix the issue of self-attestation format not supporting RSA crypto. In production traffic, at eBay, we encountered a lot of traffic coming from windows platform where self attestation format assertions were using RSA crypto which caused lot of registrations to fail using this code. Hence, I wanted to raise a PR to help fix the issue and also let other users benefit from the same.
I tried to raise PR a few times, however it seems that we have someone at eBay who has signed the corporate CLA and I am unable to find the same point of contact. Would you be able to. help me look up the contact and let me know who from eBay I can contact as someone has signed the corporate CLA back in 2019.

PR I raised but had to close : #80

Thanks for your help in advance,

It'd be great to be able to exercise the AppID extension in the tests here, too.

steps:

1. run chrome 108.0.539.128 on android 13
2. navigate to https://try-webauthn.appspot.com/
3. select discoverable cred "required" on the top left
4. click "register new credential" and receive an error "a user attempted to register an authenticator that contains one of the credentials already registered with the relying party". See short video.

I don't have any other creds registered, the screen shows empty list. Even if somehow there are creds/passkeys registered for /try-webauthn.appspot.com is there a way to clear these on Android device?

Thanks,
Aleksey
Deltek

This is just a question

How to get a unique identifier for the key so that the user can't register it again?

Looks like there is a problem in how latest Chrome handles the following authenticatorSelection criteria during navigator.credentials.create call:
authenticatorSelection: {residentKey: 'preferred', userVerification: 'preferred'}

Chrome first allows to register the key which is correct

but then after successful registration it goes into a loop and presents another dialog asking to verify your identity with try-webauthn.appspot.com

.

If you remove (residentKey: 'preferred') from authenticatorSelection - use just {userVerification: 'preferred'}, then it works fine. Tested with Yubico 5 PIN protected series key

It worked also fine with previous version of Chrome (not the current released in July 2022 - 103.0.5060.134 (Official Build) (64-bit)).

Copy/paste from the issue filed by QA.

Scenario 1:

1. Open Chromium
2. Visit a FIDO2 enabled website on Chromium and Provide any account that works. And it does not have any key that is registered yet.
3. Click “Authenticate”

Actual:- An error occured during Assertion requested.[NotReadableError: An unknown error occured while talking to the credential manager]

Scenarion 2:

1. Visit a FIDO2 enabled website on Chromium on Device 1 and register a key from that particular device
2. On device 2, visti a FIDO2 enable website on Chromium
3. Click "Authenticate"

Actual:- An error occured during Assertion requested.[NotReadableError: An unknown error occured while talking to the credential manager]

Chrome desktop and Android are about to have implementations for this API call. Would be great if we could test via the demo site. Thanks!

As no browser will support WD05, the demo should move to the WD06 format.

When testing USB hardware CTAP2 authenticator from https://webauthndemo.appspot.com/ using Chrome 67+ on Windows , if the 3-tier attestation certificates (recommended on https://w3c.github.io/webauthn/#sec-attestation-security-considerations ) are returned by authenticatorMakeCredential ( https://drafts.fidoalliance.org/fido-2/latest/fido-client-to-authenticator-protocol-v2.0-wd-20180623.html#authenticatorMakeCredential ) and the certificates are little longer, the webpage will not response by always showing "Waiting for user touch". After more testing, I found, if the authenticatorMakeCredential command returns more than 0x75F bytes, the webpage will not response. If I shorter the certificates and the authenticatorMakeCredential response is short than 0x75F bytes, the demo website will work well. But there is no limitation in CTAP2 spec. Is it the problem of chrome? Same version Chrome on mac can work well.

Just a 'nice to have' feature :-)

When trying to register a credential containing a public key with its parameters encoded as strings instead of integers the credential is stored with an empty key.
When refreshing the page the URL https://webauthndemo.appspot.com/RegisteredKeys is called to display already registered credentials.
The code throws NullPointerExceptions when trying to encode the public key x and y coordinates with EccKey getX(), getY() or encode(). This renders the demo application unusable.

I'm trying to limit the authentication to only allow fingerprint through on my device and not pin or pattern. On a phone device at least I don't believe pin/pattern to be secure as parents are always giving out the pin to their children and pattern leaves a smudge on a dirty screen meaning it's easily visible in the correct light (and also given out to children).

I was hoping the UVM extension would be able to help but it returns the same flags (fingerprint, pin, pattern) every time, no matter which verification method I've used. This is blocking me implementing passwordless authentication on my site (credit cards (PCI compliant) are stored so future purchases are simpler). Is that intended or a bug?

Copy/paste the issue filed by QA.

1. Have a fingerprint and screen lock credential set up
2. Open Chromium
3. Visit a FIDO2 enabled website on Chromium and Provide any account that works
4. Click “REGISTER NEW CREDENTIAL”
5. Complete the flow of Registration with instructions on Screen for fingerprint
6. Complete another registration for screen lock
7. Now try to authenticate using either fingerprint or screen lock.

Expected: Successful assertion message plus will display in red or pink which key has been asserted like in the app

Actual: It does not really specify which one.

When I went to https://webauthndemo.appspot.com/, and clicked on REGISTER PLATFORM AUTHENTICATOR or REGISTER NEW CREDENTIAL,
I get this error: An error occurred during Make Credential operation []

The console when I clicked on REGISTER PLATFORM AUTHENTICATOR or REGISTER NEW CREDENTIAL:

My local environment is Google Chrome Version 92.0.4515.159 (Official Build) (64-bit) for Win10.
I'll try and fix this locally. Wish me luck!
😄

Would be very helpful to know which transports are supported by an authenticator, if transports are returned.

Per w3c/webauthn#1050

FYI publicKeyCredentialCreationOptions implementation in

violates the specs at https://w3c.github.io/webauthn/#user-handle

The user handle MUST NOT contain personally identifying information about the user, such as a username or e-mail address

I would like to test your demo on my laptop. But I don't have a physical security key. I would like to use my Android phone as a security key. But I am using Linux. On this site I read that you currently don't support Linux :(

https://support.google.com/accounts/answer/9289445?co=GENIE.Platform%3DDesktop&hl=en

Will you add support for Linux soon?

Several tests have been disabled to get fixes quickly pushed out for interop, demos, etc. At some point they should be brought up to speed :-)

The existing "userVerification" option is only added to the makeCredential request. We should add this option to getAssertion request as well.

Optionally would be nice to signal that this option applies to getAssertion.

Allow passing of the UVM extension input and display the output.

I was trying in the chrome with mac inbuilt fingerprint scanner (platform authenticator only) and wondering what will be the solution of the following use case for a relying party

1. Let's say user registered webauthn in device A with the relying party R.
   Authentication flow is like this, the user comes to the relying party R input username and clicks next, relying party pulls the previously registered credential Ids for the user to create allowCredentials and query the authenticator for authentication. All goes fine as authenticator has one of those allowCredentials associated private key

2. But let's say the same user goes to the device B not registered before and tries to login with the same relying party R by putting username and clicking next. This time again the relying party pulls over the registered credential Ids for the user to create allowCredentials and query the authenticator for authentication. But this time as the device B does not have any associated private key it shows an error popup window in chrome.

Is there any way we can pass any option to the navigator.credentials.get call so that if the associated private key is not present for the given allowCredentials we can just stop the webauthn flow by catching some error.

This will help to fall back to some other authentication method without showing the error popup window and ask the user later to register device B after successful login with other authentication methods.

I heard caBLE is supported by Chrome. If this demo supports caBLE, it would be helpful for relying parties who would like to support caBLE.

• Install Firefox browser for Android
• Open the page and click "ISUVPAA" (maybe rename the button? I have no idea what that means.)
  Problem: the toast message says "... NOT available".
  Actual: When clicking "REGISTER PLATFORM ..." the Firefox does work as expected (like Chrome does). So, yeah, it is available.

Suggestion:
Implement the ISUVPAA button using only client-side JavaScript.

One way to do this would be to have an option to set an abort signal timeout. After waiting for the specified timeout during a request, webauthndemo will then signal the abort controller to cancel the request.

In your demo https://webauthndemo.appspot.com/ when you try to register a new account with smartphone using a fingerprint, an error occurs

An error occurred during Make Credential operation [NotReadableError: An unknown error occurred while talking to the credential manager.]
os - android 9
smartphone - galaxy s9+
browser - chrome(v 72.0.3626.121) and chrome beta(v 73.0.3683.75)

Current drafts of the webauthn spec require COSE formatted keys. Support for decoding these keys is necessary for an RP.