"options: {up: false}" is ignored.

[KenTaylorPhoenix]

It should be possible to verify that a particular credential ID was generated by a specific SoloKey without actually requiring the user to press a button. The easiest way to do this is to ask the key for an assertion that doesn't verify user presence (options: {up: false}).

At this time, the SoloKey ignores this option, and always attempts to verify user presence. According to the CTAP specification, the authenticator must recognize this option and either implement it or return unsupported. So this is also a violation of the CTAP specification.

[My1]

just to clarify, are you invoking CTAP directly?

because at least Webauthn (maybe some other ways of invoking ctap are as well) is forcing the UP to be the inverse of UV, thereby there is ALWAYS either presence or validation.

[KenTaylorPhoenix]

My software starts at the USB host controller layer, so yes, I'm invoking CTAP directly.

If I'm not supposed to set the flags like this, I may have to find some other solution. But this works on all the authenticators I've tried so far except the SoloKey, both those that support UV and those that do not.

The problem I have is that I'm doing local authentication, and I have a potential use case in which there may be multiple users of the same authentication mechanism who all have different levels of access but are all using the same brand and model of authenticator. Think users vs. IT administrator.

I can't easily tell if a key generated a particular credential, because all keys of the same model have the same AAGUID. Also, I don't even have an AAGUID for CTAP 1 devices, which I also need to support.

I need a simple way to tell if a key that is currently plugged in generated a particular credential without waiting for the user to authenticate, preferably without requiring the user to enter a user identifier.

I don't have a fancy multithreaded OS running. I can either present the user with a password dialog box or a prompt to push a button on their FIDO device, not both, and I'd like to get the UI right.

[conorpp]

This and #306 should be fixed with latest 2.5.3 update. Also, I added a simple way to detect firmware version, by sending an HID packet with command 0x61. Here it is in python.

data = solo.send_data_hid(0x61, b'')
assert len(data) == 3
print(f'Version is {data[0]}.{data[1]}.{data[2]}')

Older Solo versions will return invalid command error.

[KenTaylorPhoenix]

Thank you Conor. Is 0x61 a raw vendor specific U2F formatted command? I notice it lands squarely between U2FHID_VENDOR_FIRST and U2FHID_VENDOR_LAST.

From: Conor Patrick [mailto:notifications@github.com] Sent: Tuesday, September 17, 2019 2:28 AM To: solokeys/solo Cc: Ken Taylor; Author Subject: Re: [solokeys/solo] "options: {up: false}" is ignored. (#305)

This and #306https://github.com/solokeys/solo/issues/306 should be fixed with latest 2.5.3 update. Also, I added a simple way to detect firmware version, by sending an HID packet with command 0x61. Here it is in python.

data = solo.send_data_hid(0x61, b'')

assert len(data) == 3

print(f'Version is {data[0]}.{data[1]}.{data[2]}')

Older Solo versions will return invalid command error.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/solokeys/solo/issues/305?email_source=notifications&email_token=AIN7C4EKIC64ZAZWHBHONCTQKCPIRA5CNFSM4IUDHFOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD635C4A#issuecomment-532140400, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIN7C4EIKOKWOLK6J4WOMATQKCPIRANCNFSM4IUDHFOA.

[conorpp]

Yes that's correct