Feedback on using library for Apple App Attest

I’ve recently had to implement app validation on a REST API for Apple’s App Attest Service (which is based around issuing a WebAuthn Attestation object). Apple’s documentation is located at https://developer.apple.com/documentation/devicecheck/establishing_your_app_s_integrity (the WebAuthn Attestation specific stuff is at https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server, which was previously mentioned in #184).

Unfortunately, due to reasons I’ll detail below, the primary classes from Fido2NetLib (mainly AuthenticatorAttestationResponse.VerifyAsync()) can’t be entirely used in this scenario. So I wanted to offer this feedback/open a discussion with the aim of being able to use Fido2NetLib entirely in some future update.

1. The main roadblock is that the AttestationObject.Fmt for Apple’s App Attest Service has a value of apple-appattest. Currently there’s no way to inject custom implementations of AttestationVerifier, so we’ll get a Fido2VerificationException thrown from AuthenticatorAttestationResponse.VerifyAsync(). (A hack-around by changing ParsedAttestationObject.Fmt isn’t possible as this property doesn’t have a publicly accessible setter). In #184 mackie1001 suggested having attestation formats pluggable (and aseigler mentioned structural refactoring around this for v2.0), however I’m not sure if that was heading to an injectable AttestationVerifier factory or resolver that would be needed in this situation. (If it isn’t and nobody else is working on one, I could see about submitting a PR for this if I can find the time).

2. Another difficulty is that apple-appattest (and the corresponding root CA) isn’t listed in the spec’s Defined Attestation Statement Formats. Because of 1. I didn’t continue investigating this. However, would I be correct that supplying a custom implementation of IMetadataService to AuthenticatorAttestationResponse.VerifyAsync() that would provide the Apple App Attest Root CA from https://www.apple.com/certificateauthority/private/ would be all that is needed to complete the validation of certificates supplied through the attestation statement?

3. Steps 5 and 9 of Apple’s documentation mentions to verify the credentialId and SHA256 hash of the credCert public key against the keyId (obtained from DCAppAttestService.shared.generateKey(), and supplied to DCAppAttestService.shared.attestKey() to generate the attestation object). The existing Apple implementation of AttestestationVerifier compares those values from the attestation object itself, but doesn’t provide a way to check them against some externally provided value. I suppose this could be passed in a delimited clientDataJson, but points to extend the current classes to achieve this don’t currently exist (going back to 1.)

I’m unsure if there might be any similar potential difficulties around the assertion objects as I’m not currently using them or the receipts mentioned in the Apple documentation in our REST API, but likely will at some point in the future.

Thanks for what looks like a fantastic library at the moment (and certainly the premier library for working with WebAuthn objects in .NET). I appreciate any advice or concerns about the above points you all may have.

[aseigler]

Well, we have a unit test already for this that should run cross platform no problem…

[Sebbs128]

1. I agree that theoretically there shouldn’t be new attestation types (or at least will be well advertised in an update to the spec). However, as with Apple App Attest, there will be some attestation types that developers occasionally need to support that aren’t published in the spec. Having this extensibility point will hugely help developers that find themselves in that situation stick with this library.

I mentioned I might try to find the time to add that extensibility for AttestationVerifier. Would you consider accepting a PR if I can build that out? (It will at least remove that particular // TODO: in VerifyAsync() 😉 )

1. I’m glad to hear I can support the custom root via the IMetadataService. That will be a huge help.

2. I’ll be interested to see what you might be able to find. Currently I’ve just used a | delimiter in the client data to allow distinguishing, but that of course requires both the app and server to know to do this (and of course wouldn’t be suitable for a library).

Ok, that thing with the aaguid infuriates me as well now. Hard agree that Apple’s documentation should explicitly say what the values are, especially as a) their docs don’t mention favouring a particular endianness, and b) it only affects that pair of bytes.