generateRegistrationOptions typings don't allow attestationType: "indirect"

[jviide]

Describe the issue

Version 13.0.0's typings do not allow giving attestationType: "indirect" as an option for generateRegistrationOptions. This was encountered when upgrading from v10, which allowed the value "indirect".

Reporting here in case this is was an unintentional change, as it was not documented in release notes.

Expected behavior

I suggest either of two actions:

1. Modifying the generateRegistrationOptions typings to accept attestationType: AttestationConveyancePreference.
2. Adding a short mention to release notes signaling that this was an intentional (and potentially breaking) change.

SimpleWebAuthn Libraries

$ pnpm -r list --depth=0 | grep @simplewebauthn
@simplewebauthn/server 13.0.0
@simplewebauthn/browser 13.0.0

Additional context

The change appears to have been made in commit 7cb7446 as a part of the pull request #653.

Thank you for this library 🙂

[MasterKale]

Hello @jviide, I apologize for making trouble for you by omitting "indirect". I intentionally didn't add it because I still can't see the practical utility of indirect attestation, especially as it gives the browser the ability to swap out the AAGUID and attestation statement with "privacy-friendly and/or more easily verifiable version of the same data" (source). I wondered if anyone was actually using it for all of the guidance to use "none" or "direct".

Can I ask you about how you're benefitting from indirect attestation? How are you establishing trust in the responses you're getting with the amount of agency indirect attestation gives browsers?

In the meantime I'll add back in "indirect".

[jviide]

Hello, and no apologies needed! This did not cause any major headache for us, and we reported this just in case it was not an intentional change.

We use SimpleWebAuthn in the specific context of offering passkey logins to our service. During the implementation we tried to decide between "none", "direct" and "indirect". All three options were (and are) acceptable for us, as we don't really rely on attestations.

However we opportunistically suggest names (that the users can then edit) for newly registered passkeys based on their AAGUIDs whenever possible. We noticed that attestationType: "none" made e.g. YubiKey Series 5 keys tend to return all-zero AAGUIDs, at least on Chrome. This combined with the following two sources made us pick "indirect":

• Passkeys.dev recommending either defaulting to "none" or going with "indirect".

  We recommend that most relying parties not specify the attestation conveyance parameter attestation (thus defaulting to none), or instead explicitly use the value indirect.

• Corbado recommending "indirect".

  However, to get the AAGUID, e.g. for better passkey management in the account settings, we recommend to set the attestation preference to indirect as this would still allow to get the AAGUID while the attestation statement is either sent (Windows) or not sent (iOS, macOS, Android).

In the end both "none" or "direct" are okay for us.

[MasterKale]

Hello @jviide, I've gone ahead and added a breaking change to the release notes for the dropping of support for attestationType: 'indirect' as having slept on it for a few days I still think the benefits of 'indirect' are not enough for most RP's to take on trying to decide between none/indirect/direct. If it changes later I'll add it back in.

https://github.com/MasterKale/SimpleWebAuthn/releases/tag/v13.0.0