webauthn-rs
webauthn-rs copied to clipboard
Support native touchid devices
@micolous It sounds like @ericmarkmartin is keen to have a look at this, and it seems to overlap/be similar to your work with the windows apis.
Cool! I've not looked into it a huge amount, so I'll hold off for now.
Here is a good starting point:
- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys
- https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_security_key_authentication_using_physical_keys
I think what'd need to happen is pretty similar to what I did with the Windows stuff -- map all the webauthn-authenticator-rs types onto Apple's types, and call it through some ObjC FFI.
Do we have strong feelings about using an Objc FFI over Swift bindings?
Afaik, the rust-objc and swift-bridge crates are the standard for objc and swift bindings in rust respectively.
@ericmarkmartin given the way apple is trending, swift might be the safer choice to use here, unless there is a compelling reason to go with obj-c?
The only thing I can think of is that the rust objc binding foo might be more mature but I actually don't know enough to claim that for certain.
I don't have strong feelings either way – I hadn't looked into it a whole lot yet.
@ericmarkmartin Yeah, I think it'll be a case of investigating the two options and deciding :)
@madsmtm has finished some work on icrate so there's now a usable ASAuthorizationServices module! I'm getting started on using this as the layer to interface with macos.
I wouldn't use objC, it's the "legacy" option as far as Apple's concerned.
I don't think we have much of an option. Support for interacting with swift from rust is quite limited. Afaik there's the swift-rs and swift-bridge.
I think using the former would require us to write a lot of swift so we can expose the ASAuthorizationServices API with functions with @_cdecl annotations. The latter has the same problem, plus it's unclear how to use it to deal with a lot of common swift patterns, for example accessing vars.
I also don't think we're likely to run into an issue with Apple deprecating Objective C in some way. For newer APIs, all they're doing is writing the swift such that it's exposed to the objc runtime, and this is sufficiently low cost that I imagine they'll keep doing it.