refactor: draw an abstraction line between WebAuthn and AndroidSafetynet's AttestationResponse

[grzuy]

in part helps with #140

[grzuy]

Anyone looking this feel free to critique.
Would be very valuable to have another pair of eyes.

[brauliomartinezlm]

@grzuy I was wondering what difference are you considering in the AndroidSafetynet attestation statement that motivates extracting and isolating just this kind of response outside the scope of this gem?

It's just I'd like to understand the reasons behind that move better.

[grzuy]

Doing just this extraction now doesn't mean to me we should rule out extraction of other parts of attestation statement verifications.

To me this was the one more clearly outside of WebAuthn's domain, given the Recommendation treats it that way in the "Verification procedure", when it's says:

Verify that response is a valid SafetyNet response of version ver.

and then provide a link to the official Android SafetyNet Attestation API documentation.

To me that's reads "Do whatever Android says is needed to consider a SafetyNet attestation response verified".

That's the abstraction line I was trying to draw here.
I even searched for any existent gem that would provide verification of an Android SafetyNet Attestation, but there wasn't any.

Regarding other formats, I can say on top of my head that "packed" it's on the "other side" given its WebAuthn optimized format.

Need to assess specifically others like android-key, tpm (once implemented) and fido-u2f.

FWIW for android-key we did build some abstractions (not yet extracted outside of WebAuthn's namespace) already in #145.

[bdewater]

I even searched for any existent gem that would provide verification of an Android SafetyNet Attestation, but there wasn't any.

I think because the 'easy way' is to use Googles API to verify - perhaps not many bothered to write code for offline verification?

Need to assess specifically others like android-key, tpm (once implemented) and fido-u2f.

U2F as the predecessor standard of WebAuthn will be the only one that meets your criteria, I think. All the other formats are existing attestation formats adapted for WebAuthn.

All formats except Android keystore are required to be implemented according to FIDO Server spec, WebAuthn seems to not be prescriptive in this regard.

[brauliomartinezlm]

@grzuy @bdewater thank you for your explanations!
It makes more sense to me know. I see mostly benefits on extracting the verification of responses. I hope we end up extracting this into separate gem in the long run.

[grzuy]

I think because the 'easy way' is to use Googles API to verify - perhaps not many bothered to write code for offline verification?

It seems offline SafetyNet Attesation is the recommended way for production use, per SafetyNet official docs:

During initial testing and development (but not in production), you can call an online API for verifying the signature of the JWS statement. This process has also been shown in the android-play-safetynet sample API usage made available on GitHub. Note that online verification API is solely for early-stage testing, and you have a fixed quota of 10,000 requests per day.

Important: The use of the online verification API only validates that the JWS message was signed by the SafetyNet Attestation API's servers. This online API cannot verify whether the fields in the payload match the values that your service expects.

source: https://developer.android.com/training/safetynet/attestation#verify-attestation-response

[grzuy]

Need to assess specifically others like android-key, tpm (once implemented) and fido-u2f.

U2F as the predecessor standard of WebAuthn will be the only one that meets your criteria, I think. All the other formats are existing attestation formats adapted for WebAuthn.

All formats except Android keystore are required to be implemented according to FIDO Server spec, WebAuthn seems to not be prescriptive in this regard.

👍