Presence

DeviceBound Presence™

Establish that a verified device and user completed the required verification at a specific time and, where required, at an authorized location.

What Presence establishes

Verified, at a moment, under a policy.

A Presence session ties together the pieces DeviceBound already produces: the device-bound credential, the local biometric or device check, the time it happened, the location evidence when the policy asks for it, the terms or NDA that applied, and the business or event that requested it. The result is one auditable record that answers who, what, when, where, for whom and whether it is still current.

Presence has three states:

  • GREEN: present and verified. Every required condition is current.
  • YELLOW: reverification required. The last verification is no longer current under the policy, and the person is asked to verify again on their device.
  • RED: not verified or not authorized. Verification failed, authorization was revoked, or a required condition was not met.

Status is decided on the server from stored verification timestamps and the applicable policy. DeviceBound does not track people continuously, and a phone saying it is still there does not count as presence. A live Presence screen shows the current state with changing detail, so an old screenshot cannot pass as proof.

Built on the same engine

No second identity system.

Presence reuses the DeviceBound trust engine behind DeviceBound Live and DeviceBound Business: the same device-bound credential, the same biometric ceremony, the same authorization and revocation, and the shared Location layer. Location permission is separate from DeviceBound consent, is explained before it is requested, and a declined permission never turns a successful device verification into a failed one.

Status: in development. DeviceBound Presence is being built on the shared trust engine and Location layer of the platform.