Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User interface for approvals? #13

Open
jo-vf opened this issue Nov 14, 2022 · 3 comments
Open

User interface for approvals? #13

jo-vf opened this issue Nov 14, 2022 · 3 comments

Comments

@jo-vf
Copy link

jo-vf commented Nov 14, 2022

I tried the https://demo.yubico.com/webauthn-technical/registration with virtual-fido on windows. The user experience right now is working but rudimentary - touching the stick as requested by the page in firefox requires pressing Y in the console I used to start the demo.
Do you have ideas on how to make this more user friendly? Could this be approval be automatic, and if yes, what are pros and cons? Or a windows notification approve site yes/no? I assume the specific means to implement a user interface are OS-dependent. On windows I would assume the usb and virtual fido parts could end up in services, that could trigger an approval ui. As I already wrote services and notifications (C#) I could probably contribute some parts, but guidance on what and how highly appreciated.

@cmdli
Copy link
Contributor

cmdli commented Nov 15, 2022

Right now I am working on a frontend GUI to this system to make it more user friendly, but I am open to others also building potential frontends as well. Personally, I think it is important (and required by the FIDO spec) to get actual user approval, because otherwise any random process could request a login/assertion from the device and get it automatically. The FIDO spec requires that the device verify user presence (and potentially user authentication with a PIN) so I would default to doing that.

@jo-vf
Copy link
Author

jo-vf commented Nov 16, 2022

Haven´t read the spec in detail. Was just curious whether really two user interactions are required. May be the firefox prompt could be turned off instead of doing auto-approval.
I don´t want to interfere with you implementing a GUI. Actually I am happy just to use software as provided. However, can you really do decent native UIs, assuming that notification mechanisms are usually OS-dependent? Which OSes are you going to tackle? Probably the first step is to define an API between the fido component and a notification component, and whether the notification component is launched on demand or not.

@cmdli
Copy link
Contributor

cmdli commented Nov 18, 2022

The goal for this package is for that interface between FIDO and the frontend to be clearly defined with the FIDOClient interface, where this package handles all of the FIDO/USB protocol stuff and then people being able to build any secret storage or interface on top of it. I wouldn't say that interface is perfect, so I'm happy to take suggestions/feature requests for exactly how to define that interface. The current interface is mainly just built out of requirements for getting the demo up and running, as well as a few additional features for the separate GUI stuff I'm building.

The GUI that I'm building right now is essentially the software version of the hardware buttons you might find on a Yubikey; you can approve various requests to the device as well as view and manage the various credentials that are stored on the device. Unfortunately it seems like it might be hard to support Mac since Mac doesn't support USB/IP, but I'm taking a look at alternate USB emulation (that I would add to this project).

For the auto-approval/UX part, it's difficult since the various operating systems and browsers seem to be intent on adding extra clicks in front of the device, even with hardware devices like Yubikeys. For instance, on Chrome+Windows, you have to approve it inside Chrome, then approve it on Windows, then approve it on the Yubikey/Virtual FIDO device, which is an annoying user experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants