public final class VaultCapabilities
- Object
- VaultCapabilities
What this device can do, asked before an application offers the user a choice.
The distinction this class draws is between available and in use. A platform can offer
a remembered device without this vault having one; Vault.protection() answers the second
question, this one answers the first. An application building a settings screen needs both: it
shows the switch based on this, and shows the switch’s state based on that.
Methods
public boolean supports(UnlockPolicy policy) | Whether an unlock policy can be honoured on this device. |
public ProtectionReport protectionFor(UnlockPolicy policy) | What a vault enrolled under this policy would be protected by, if it were enrolled now. |
public ProtectionReport deviceProtection() | What the device key store itself reports, unfiltered by any policy. |
public boolean requiresUserVerification() | Whether this device’s key store gates access on the user proving they are present. |
public String toString() | A line per capability, for a diagnostics screen. |
Inherited methods
Method details
supports
public boolean supports(UnlockPolicy policy)Whether an unlock policy can be honoured on this device.
UnlockPolicy.SESSION_ONLY needs no key STORAGE, because it stores no key – but it is
not free of platform prerequisites, and saying it was unconditionally supported was
wrong. Enrolling under it still persists a metadata record and still seals it with
AES-GCM, so a browser with no usable IndexedDB or Web Crypto – a restricted private
window – advertised a policy that could only fail, and fail after the user had already
typed a password.
Those prerequisites are measured DIRECTLY – can Storage answer for an entry, and does a small AES-GCM seal succeed – and deliberately not read off the device protection’s report. That was the first attempt and it was wrong in both directions: a device store is not what session-only uses, so an application-supplied DeviceProtection reporting no persistence, an unplugged hardware token say, refused a policy that never touches it.
The other two share those prerequisites and also need a device key. The strongest additionally needs that key to be gated on user verification.
protectionFor
public ProtectionReport protectionFor(UnlockPolicy policy)What a vault enrolled under this policy would be protected by, if it were enrolled now.
Under UnlockPolicy.SESSION_ONLY the key-storage answers are all NO, because there is
no stored key to protect – which is a stronger position than any of them and reads as a
weaker one, so an application showing this to a user should say “the password is required
every time” rather than listing flags.
deviceProtection
public ProtectionReport deviceProtection()requiresUserVerification
public boolean requiresUserVerification()toString
public String toString()