nk3 fido2 status

[Ingo-Albrecht]

Hi,
new nk3 A with factory fw1.5.0 and 41-udev rules. 'nitropy nk3 test' and nitropy fido2 verify work as expected.

Executing nitropy fido2 status results in Critical error: An unhandled exception occurred Exception encountered: CtapError('CTAP error: 0x01 - INVALID_COMMAND')
It also fails after doing a fido2 reset, with/without PIN, I tried stopping pcscd too.
nitropy.log.r8w6lsar.txt

[robin-nitrokey]

Historically, the fido2 subcommand refers to the Nitrokey FIDO2 devices. Some commands implement standard FIDO2 operations, others are specific to the Nitrokey FIDO2. As the Nitrokey 3 also implements the FIDO2 protocol, some fido2 subcommands like list-credentials, set-pin, etc. work with the Nitrokey 3. status is not one of these commands. So from a developer’s POV, the error you shared is expected. But obviously, this is not a great UI.

I’m not sure what’s the best way to solve this. Ideally, we would have separate subcommands for the FIDO2 protocol and the FIDO2 device, but how would we call them? Maybe nk-fido2 for the device? So nitropy fido2 would work for Nitrokey devices implementing the FIDO2 protocol, and nitropy nk-fido2 would work for Nitrokey FIDO2 devices. Still confusing, but probably better than the current state.

As a first improvement, we could add messages to the problematic subcommands indicating that they are only for Nitrokey FIDO2 devices.

[Ingo-Albrecht]

Interesting, I was not aware the FIDO2 protocol does not know a status command. I reported it after looking for similar issues here and the support forum and did not see any, so it certainly is a minor issue.
A message and/or mention in the help-text would be good, yes.

If you think about refactoring nomenclature, consider prepending "nk-" to the respective commands, for example change it to nitropy fido2 nk-status. Then, the help can stipulate that "nk-" commands are Nitrokey FIDO2 device specific (or nk3- at some point) and you can perhaps even alias them, so the respective NK FIDO2 users (and setup automatisms?) are not thrown off-guard.

NB I saw this fido2-hmac-secret support question recently, which refers to another example of a custom FIDO2 command. While nitropy fido2 challenge-response --help basically states it is an extension of the protocol, it may generally be beneficial to prepend such accordingly.

[Ingo-Albrecht]

I'd like to make yet another proposition regarding the command nomenclatura. What led to me opening the issue was not being aware of what's FIDO spec standard/NK FIDO specific. If the nitropy fido2 --help did point out differences, that would have been perfectly fine for me. For example:

$ nitropy fido2 --help
Command line tool to interact with Nitrokey devices 0.4.41
Usage: nitropy fido2 [OPTIONS] COMMAND [ARGS]...

  Interact with Nitrokey FIDO2 devices, see subcommands.
  Note Nitrokey FIDO2 devices implement more 
  subcommands than Nitrokey 3 devices, as denoted by 
  (NK FIDO2 only) per subcommand below.
...
Commands:
    status             Print device's status (NK FIDO2 only) 

Another solution may be that nitropy detects the hardware model and prints something like "This subcommand is not part of the FIDO2 specification and implemented specifically for Nitrokey FIDO2 devices.", but for me as a user the --help info would have sufficed.

By the way, "subcommand" in the helptext should generally be renamed "command", as this help only lists "Commands:".