public final class VaultOptions

Locks the vault after this many milliseconds without a vault operation. Zero, the default, never auto locks.

Enforced when the vault is next used rather than by a timer, so a vault that is idle stays nominally unlocked until something asks – at which point it locks and the call fails with VaultError.LOCKED. A timer would be tidier and would also keep a reference alive and wake a sleeping device; the check-on-use form cannot be late in any way a caller can observe, because nothing observes the vault except through a call.

Refuses any operation that would produce raw key bytes, at the cost of the encrypted database.

The one place this package hands out key material is Vault.databaseKey(String), because SQLCipher – on the device and in the browser’s WASM build alike – takes a key as bytes and there is no arrangement of opaque handles that changes that. A caller that cannot accept the exposure sets this, and that call then fails with VaultError.POLICY_NOT_MET rather than quietly doing the thing the policy forbade.

The consequence is real and is the point: a vault configured this way cannot key a managed encrypted database. An application that needs both has to seal its records through Vault.seal and store the ciphertext in a plain database, which is a different design rather than a setting.

Supplies the device key store rather than using the port’s.

The port’s is right for almost everything, and this exists for the cases where it is not: a library wrapping a hardware token, an application whose key belongs to a management agent rather than to the device, and a test that needs the remembered-device paths without a platform key store behind them.

Supplying one does not relax any check. A protection required through require(Protection) is still checked against what this reports, so an implementation that claims more than it provides fails the same way the port would.

Requires that a passkey used for UnlockPolicy.REQUIRE_USER_VERIFICATION cannot leave this device.

Why this is a choice and not a default

Most passkeys sync. An iCloud Keychain credential reaches every device on the Apple account, and a Google-account one every device signed into it – so the ordinary “remember this device” is closer to “remember this account”. For a note-taking application that is what the user wants: a new laptop unlocks with a face scan and no password. For something holding a second factor it is the opposite of what was asked for.

Requiring this narrows the ceremony to an authenticator built into the machine and checks the credential’s backup-eligibility flag, which is the part that actually decides. authenticatorAttachment: "platform" alone does not: an iCloud Keychain passkey is platform-attached and syncs anyway.

What it costs

Hardware security keys are excluded, and so is every authenticator whose browser will not report the flag – an unknown answer is treated as “may leave this device” rather than rounded up. A user whose only authenticator syncs cannot enrol, and enrolment fails with VaultError.POLICY_NOT_MET rather than quietly keeping a credential that does not meet the requirement. Offer the weaker policy as a fallback, or do not require this.