-
Notifications
You must be signed in to change notification settings - Fork 290
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
Client pin features #127
Client pin features #127
Conversation
This is a CTAP2.1 feature, tracked in #106 . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, letting others approve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took a closer look to the pin_protocol_v1. I didn't look into all the details of the protocol, but I have a few nits regarding Rust code. Other than that looks good!
Thanks @gendx for the review and the Rust comments. Concerning reviewing for details of the protocol, the old comments are thoroughly tested and mostly taken from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few remaining nits, but otherwise it looks good :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from a few nits that had unfortunately slipped through, and rebasing/merging with master, this looks good to me.
This PR adds new subcommands from CTAP 2.1 in clientPin.
CTAP 2.1 introduces an interface for PIN protocol versions, since a v2 is currently being drafted. I decided to move all clientPin code for the existing PIN protocol v1 to a separate module. For better code sharing with a potential v2, we might introduce the common interface later when needed. I decided to not proactively refactor v1 into that interface, and wait until it is stable.
This has the added benefit of moving some complexity out of
ctap/mod.rs
which will have to accommodate more commands as they are introduced.We will need to do more testing of changes for 2.1 in the wild when platforms and relying parties support it.
This PR contains some unused functions, this is intentional. They will later be used by the "Minimum PIN Length Extension" to allow some relying parties to see the minimum PIN length required by this authenticator, and include it in its attestation during MakeCredential. This feature establishes trust with relying parties with strict PIN policies.
Other open TODOs are (1) enforcing PIN length in code points and (2) places where the specification is ambiguous and discussed in the FIDO Alliance (you might lack permissions).