Is there interest in a public client API?

[dimitribouniol]

I plan on implementing automatic seamless registration for a project I'm working on, and wanted to build this atop WebAuthn so the server can have a single registration/authentication flow for passkeys as well. Is there appetite for such a public client API to live in this same package (perhaps as a different target/product, though not strictly necessary), essentially providing the functionality navigator.credentials.create/navigator.credentials.get would provide within a browser? I can see this being used both on regular devices, but also server-to-server, not to mention lock-step support for new keys and capabilities.

V1 of this API can simply take care of key generation and signing, while custom attestation could be added over time.

(I'll crosspost to Slack as well in case that's a better avenue for discussion, but wanted an excuse to give GH discussions a try 😅)

[marius-se]

build this atop WebAuthn so the server can have a single registration/authentication flow for passkeys as well

I'm not sure if I understand what you mean. Passkeys are part of WebAuthn and supported by this library?

[0xTim]

Yeah I'm a bit confused by this as well. Which client are we talking about here? Server-to-server won't ever work because the client needs to store or access the keys and that should only happen on the client device during the attestation flow. This is handled by the OS in the case of apps or the browser for websites. There's definitely scope for improving the flow on iOS as I remember there was a fair amount of setup when I built the original prototype but that shouldn't live in this library

[dimitribouniol]

For instance, on tvOS, I'd like to automatically register an account and use it without bugging the user to pull out their phone. Unfortunately, passkeys can't be used for this scenario, since that requires a) the user to have an iCloud account connected to their profile and b) pull out their phone on first launch, which is a bit clunky.

For server to server, I guess I meant more of a headless client scenario, where that device could make a key pair and use that as its identifying information.

[dimitribouniol]

To elaborate, ideally, I'd like to be able to have my app behave like the browser would, and provide a key pair that can be used to sign the challenge and provide a registration/authentication identity. This would work fine if attestation preferences on the server are set to .none, however I can see some benefit to such functionality being a part of this library directly, namely a user of it would just need to shuttle the data and not be concerned with dealing with cryptographic primitives themselves.

A server-to-server use case would be to implement an account system similar to what Let's encrypt provides for cert generation — in this case, the server is a fancy client, but they do something very similar where the client generates a public-private key pair, and signs a challenge from the server (essentially WebAuthn before WebAuthn). Having a common implementation others can use would allow similar applications to be built atop the standard, rather that re-inventing the wheel in their own special way.

[dimitribouniol]

As I've been going through the W3C draft and implementing it for my specific use case, I wanted to circle back to see if there was still any ambiguity for the reasoning behind why a client library built in Swift might be useful to folks. I would say it's less about passkeys specifically and more about supporting a compatible key attestation framework for user account registration and authentication in a client-server codebase, specifically when:

• User intervention on a passkey-capable device is not required or wanted, ie. single device account creation on tvOS for data persistence (no long term persistence guarantee, no passkey support unless iCloud is enabled for a profile since it requires an iCloud device)
• Password and email-less authentication on devices that don't support Authentication Services (aka older Apple devices, devices not signed into iCloud (not sure here?), non-UI driven applications (ie. terminal apps), other non-Apple platforms)

I'm sure folks will creatively come up with other use cases, and crucially without inventing new key exchanges which is fraught and should be actively discouraged (ie. by providing tools to use standards-based handshakes instead 😉).

---

Through my implementation, I've identified several key areas that would need to be addressed to properly support a client implementation:

• Support for iOS, tvOS, etc…
  • I see this as being transitively useful to the server implementation, enabling apps that can establish trust with other devices on the local network without re-inventing a handshake protocol.
• Adding corresponding Decodable and Encodable support for matching types
  • This way the same types could be used on the client side, shovel ready from correspondence with the server implementation and vice versa.
• Adding additional fields to pkOptions types
  • This would allow the client to communicate with other WebAuthn implementations a bit more readily to properly handle relying party requests, and shouldn't impact the Swift server implementation.
• Make enums RawRepresentable structs instead, so they can more leniently decode unknown values.
  • Basically anywhere an array of string or numeric constants are used, decoding will fail if that array contains an unexpected value, like an unsupported algorithm amongst supported ones. Using structs here would allow the array to be properly decoded, and allow the unknown values to be skipped where it makes sense to do so, or throw an error when none are supported.

I essentially have three options for moving forward:

• Continue with my fork which will likely diverge significantly due to addressing the above constraints.
• Build a separate library that duplicates much of the code from this one, specifically around currency types and signing/verification primitives, which will run the risk of not getting updates to things like new algorithms in sync with the server implementation.
• Break the above down into bite-size PRs that address specific concerns ahead of the final client API landing and upstream them gradually to this repo.

I'm very much in favor of option 3, but I'm very much powerless to do it alone, so I'd like to work through any potential issues to make it happen.

A very much work-in-progress branch is available here that I'll be fleshing out, cleaning up, and adding test coverage for over the next few days: main...dimitribouniol:webauthn-swift:dimitri/client