Align webauthn-swift more closely with Authentication Services Framework

[Jerry-Carter]

The existing entry points for webauthn-swift do not readily accept the data provided by Apple Authentication Services Framework. Here two new entry points are proposed.

A Swift server may handle standard web traffic, but it will also quite likely support native clients also written in Swift. Let's look at the details on the latter scenario. The registration flow sees the ASAuthorizationControllerDelegate performing registration after an ASAuthorizationPublicKeyCredentialRegistration is generated by the Authentication Services Framework. This object contains a rawAttestationObject:Data? and rawClientDataJSON:Data. In the Swift⇄Swift architecture, these two data objects would be passed by the client to the server for validation in webauthn-swift. The server might simply invoke a function like this:

public static func validateAuthenticatorAttestationResponse(_ rawAttestation: Data, clientDataJSON:Data, challengeProvided: Data, origin: String, logger: Logger) throws -> CredentialData {

A similar entry point should be added to handle the authentication flow.

Under the covers, the proposed entry points and the existing ones share considerable code. We are currently using a fork of webauthn-swift with these additions which can be contributed.

P.S. I am very thankful for @0xTim and @marius-se for their work on this library. This has saved considerable time and effort and I know that webauthn-swift will become part of many projects in the months ahead. But... There is an existential question that I cannot resolve in my mind. If Apple is serious about passkeys/webauthn and is serious about growing the Swift on Server community, then surely this functionality should be included in the Apple Authentication Services Framework to better support the Swift⇄Swift architecture.

[0xTim]

Apple Authentication Services is only available on Apple Platforms - it's unable to be used on Linux (and Windows) so frankly is not a concern of this library. We could try and maintain some kind of compatibility layer but a) Apple platform APIs evolve much slower than an open source library and b) we'll be constraining ourselves to whatever paradigms the Authentication framework is built upon. They have very different use cases, one's a client library and one's a server library so they are likely to be significantly different.

As an aside - the focus of the package to provide a server implementation for WebAuthn no matter the type of client. Swift is bigger than whatever is happening on Apple platforms.