spec compliance and the transports typing

[felix-brainfinance]

Describe the issue

The simpleWebAuthn/server library typing require AuthenticatorTransportFuture[] as the type for the transports array,
now the spec is not super clear but from my understanding, this should be typed as string[] instead, because the server should not reject, filter or modify the value in there in any ways.

The items SHOULD specify transports whenever possible. This helps the client optimize the user experience for any given situation. Also note that the Relying Party does not need to filter the list when requesting user verification — the client will automatically ignore non-eligible credentials if userVerification is set to required.

2.1.1. Enumerations as DOMString types
Enumeration types are not referenced by other parts of the Web IDL because that would preclude other values from being used without updating this specification and its implementations. It is important for backwards compatibility that client platforms and Relying Parties handle unknown values. Enumerations for this specification exist here for documentation and as a registry. Where the enumerations are represented elsewhere, they are typed as DOMStrings, for example in transports.

transports
The value returned from getTransports() when the public key credential source was registered.
Note: Modifying or removing items from the value returned from getTransports() could negatively impact user experience, or even prevent use of the corresponding credential.

do you think it would make sens to reduce the typing here?

[MasterKale]

Hello @felix-brainfinance, thanks for the question. I've thought string[] is too ambiguous a typing for transports because there is a discrete list of possible values that these strings should be. I take your point that the spec says that RPs should consider transports as an opaque value, but for sake of DX I continue to believe it's easier to explicitly constrain the possible values for reference and readability.

Is there some aspect of SimpleWebAuthn that's cumbersome for the fact that transports are more strictly typed?

[felix-brainfinance]

The transport is coming from the user in the first place, so when I looked at the type from the library I wondered if I should filter out unknown value or reject the request.
Looking at the spec, seem like I should do neither, and keep the value as they are send from the client. So my solution for now is to cast the unvalidated string array into AuthenticatorTransportFuture[] before sending the value in the library and then back to string[] when it come out. And it work because I took the time to ensure the library implementation did not rely on the string array to be those specific value, but it never feel safe to blindly cast typescript without validation into a library I will not be looking into in detail at each update

I have a working workaround since that only a type issue, but it is very heavy handed and open some type corruption risk I would rather avoid if possible

[felix-brainfinance]

on a side note, "authenticatorAttachment", who can currently have platform | cross-platform have the exact same issue of being typed as DomString in the spec and being strictly typed in the library

[314systems]

Hi @MasterKale,

The strict typing becomes an issue when using the native WebAuthn API (like PublicKeyCredential.toJSON()) on the client side instead of @simplewebauthn/browser.

The native API returns string[] for transports. Passing this directly to @simplewebauthn/server throws this error:

  The types of 'response.transports' are incompatible between these types.
    Type 'string[]' is not assignable to type 'AuthenticatorTransportFuture[]'.
      Type 'string' is not assignable to type 'AuthenticatorTransportFuture'.

This forces us to manually cast the array just to satisfy TypeScript. Allowing string[] for transports would make interoperability with the native API much smoother.

(Note: AI generated)