Policies

Policies live on the LFA side, registered for your account by the Octet team alongside your OIDC clients. Your application never evaluates location data. It names a policy, and LFA answers pass or fail.

What a policy contains

When you ask Octet for a policy, you choose two things:

• The country. The user must prove presence in this country, identified by its ISO 3166-1 alpha-2 code (for example GB).
• Which anti-spoof tiers pass. By default only a VERIFIED proof passes. You can also let a PLAUSIBLE proof pass. See Anti-spoof tier.

Every policy also applies the same fixed checks, which you do not configure: the device must be hardware-attested, and the proof must be fresh for this login.

How a policy is selected

• Direct OIDC integrations pass octet_policy_id on the /authorize request to pick a policy per login: one client, many policies. Omitting the parameter uses the client's pinned default. An unknown id is rejected.
• Brokers (Okta and similar) pin the policy per registered client: one client per policy. A broker runs a fixed token exchange and does not set octet_policy_id, so each policy gets its own client. Enforcing UK presence for one app and US presence for another means two clients.

Geofences

LFA currently supports country-level geofences. The user proves presence in a country, identified by its ISO code, and the tokens assert exactly that. Finer regions (state or province, city, custom areas) are on the roadmap. They will not need changes to your integration.

See regions for how a region is expressed and matched on the device.

Attestation and freshness

Every policy requires a proof rooted in the phone's secure hardware, carrying a per-login signature from the enrolled device key. iOS and Android both meet this (see device attestation), and a passing login carries acr: urn:octet:loc:strong. A proof that does not meet it is denied.

The proof must also be recent when LFA checks it, so a proof made for an earlier moment cannot pass. The location assertion LFA then issues is valid for 120 seconds.

Anti-spoof tier

Every proof carries an assurance tier, described in verdicts. The policy sets which tiers pass:

• Default. Only VERIFIED proofs pass. Use this for anything security-relevant.
• Opt-in. PLAUSIBLE proofs also pass. This lowers both friction and assurance. Use it for flows where a false rejection costs more than accepting a less-corroborated proof.

Where to go next

• Direct OIDC integration. The octet_policy_id parameter in practice.
• How a login works. Where the policy check sits in the flow.