Skip to main content
WebViews cannot run WebAuthn themselves, so in the mobile shell the shell runs the ceremony and returns the result. In a browser or the desktop shell, the same call uses the page’s own navigator.credentials. Either way you get standard WebAuthn JSON to send to your server. The relying party is always cskn.app, so a passkey created in the mobile app also works when the user opens the same app in a browser.
The challenge must come from your server, and verification must happen there. A passkey’s security depends on both.

API

transport is native (the shell runs the ceremony), web (the page’s own WebAuthn) or none.

create options

string
required
Base64url challenge from your server.
{ id?, name?, displayName? }
In the mobile shell, the user handle is always the signed-in user’s sub.
PasskeyCredentialDescriptor[]
Credentials the user already has.
object
Standard WebAuthn selection, for example { userVerification: 'required' }.
…
Standard WebAuthn options.

get options

string
required
Base64url challenge from your server.
PasskeyCredentialDescriptor[]
Omit for discoverable sign-in.
'discouraged' | 'preferred' | 'required'
Standard WebAuthn option.

Details

  • Binary fields are base64url. Convert with base64UrlFromBytes(bytes) and bytesFromBase64Url(text).
  • response.publicKey from create is always DER SubjectPublicKeyInfo, the same as a browser’s getPublicKey(). The shell normalizes the platform differences.
  • Error codes: not_supported, not_configured, no_credentials, rp_not_allowed, invalid_request, interrupted, failed.
  • TV has no passkeys (transport: 'none').
Functions: isPasskeyAvailable, createPasskey, getPasskey.