If successful WebAuthn registration on desktop via caBLE and the mobile device returns a credential with only "cable" for a transport. Then what is intended to happen when the user visits the RP's site on the mobile device that possesses the credential? Let's assume the RP stores `["cable"]` with the credential.
Normally we'd expect to see "internal" on a credential in `excludeCredentials`/`allowCredentials` to indicate to the client that the local platform authenticator should be excluded/used, but right now it appears the RP will only receive from and pass back to clients "cable" for that credential.
Will the browsers be responsible for attempting to communicate with local platform authenticators when they encounter a credential with "cable" transport?
Perhaps authenticators will become responsible for also returning "internal" with "cable"?
And now I'm wondering how the other side of the coin is intended to work: if a phone registers on a site and returns a credential with "internal" transport, how is the RP intended to leverage that for caBLE auth? The spec states
that RP's shouldn't manipulate the list of transports it gets back:
> When registering a new credential, the Relying Party SHOULD store the value returned from getTransports(). When creating a PublicKeyCredentialDescriptor for that credential, the Relying Party SHOULD retrieve that stored value and set it as the value of the transports member.
So I would imagine it'll fall on the browser to handle figuring out when "cable" or "internal" credentials are available for use for either local platform auth or caBLE.
I know none of the tech enabling experimentation can be considered "final" yet, and what we can practically observe now is likely to change. However it feels like caBLE is just around the corner. I would hope we're close to answers for these scenarios so we can start advising RP's on how to properly leverage this new technology.