Verifiable, Scope-Bound Advisories for Authorization Posture (EMILIA Eye)

Introduction Authorization decisions are made at a moment in time, but the conditions that justified a decision change continuously. A device becomes non-compliant; a credential is reported phished; an anomaly-detection system observes impossible travel; a regulator publishes a sanctions update. Continuous access evaluation frameworks exist precisely to communicate such changes as they happen. What those frameworks deliberately do not define is (a) whether the recipient can verify, offline and without trusting the transmitter's live infrastructure, that a given signal genuinely originated from a trusted source; (b) how a signal is bound to one specific scope so it cannot be replayed against a different subject; and (c) what a recipient is permitted to do with a signal - in particular, whether a signal may, on its own, grant or deny access. This document closes those three gaps for the narrow but high-consequence case of authorization posture. It does so without reinventing the envelope or the transport. Eye advisories reuse the Security Event Token as their wire envelope and MAY ride existing CAEP streams (, ). The contribution is three properties layered on top: signed offline verifiability, cryptographic scope binding, and a normative fail-safe rule that an advisory may only tighten posture and may never be the sole gate. The gaps this document closes:

The verifiability gap. A posture change delivered as plain JSON over an authenticated channel is only as trustworthy as the channel and the live database behind it. A relying party that caches, forwards, or audits the signal later cannot reconfirm its origin without re-querying the source. Eye signs the advisory so any holder of the issuer's public key can verify it offline, mirroring the offline-verifiability property of the EP authorization receipt.
The scope-binding gap. A signal that says "elevated risk" with a loosely attached subject reference can be copied and presented against a different subject. Eye binds each advisory to one scope via a scope-binding hash carried inside the signed payload, so re-targeting invalidates the signature.
The authority gap. Frameworks that carry session and posture events leave entirely to the consumer what to do with them, including the option of treating a signal as an autonomous enforcement trigger. Eye forbids that. An advisory is an input to a decision, never the decision.

Design Goals

G1 - Signed offline verifiability. An Eye advisory MUST be verifiable by any party holding the issuer's public key, with no network access to the Eye service, mirroring the offline-verifiability property of the EP authorization receipt ().
G2 - Scope binding. An advisory MUST carry a scope-binding hash inside its signed payload so it cannot be replayed against, or re-targeted to, a scope other than the one it was issued for ().
G3 - Never the sole gate. An advisory MUST NOT be the sole gate between an entity and an action. A signal MAY only tighten posture; it MUST NOT itself constitute the authorization (). This is the central invariant of this specification.
G4 - Deterministic posture mapping. The mapping from advisory status to recommended action to a posture change at the enforcement point MUST be deterministic and specified, so two conformant enforcement points consuming the same advisory tighten posture identically ().
G5 - Compose, do not reinvent. Eye advisories MUST be expressible as a Security Event Token payload, and SSF/CAEP transport is OPTIONAL. Eye defines the verifiable, bound, fail-safe layer; it does not define a new event envelope or a new delivery protocol (, ).
G6 - Append-only honesty. Advisories and their underlying observations are append-only; a status change is a new advisory that supersedes its predecessor, never a mutation of an existing one ().

Scope This document defines the advisory artifact, its scope binding, its signature, the observation signal registry, and the deterministic status-to-posture mapping that bridges into an enforcement point. It does not define a policy language, an anomaly-detection method, the transport stream's management and verification (which SSF provides), or the authorization artifact itself (which the EP authorization receipt provides). Eye produces advice; it never produces an authorization. Implementation status is honestly noted in : the signing, SET-envelope, and CAEP-transport layers specified here are experimental and not yet present in the reference implementation, which currently computes scope-binding hashes but does not asymmetrically sign advisories.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Eye / Eye Service. The service that ingests observations from trusted sources and issues advisories. The Eye service is an advice-producing party; under this protocol it is never an authorizing party. Observation. A single, source-attributed, scope-bound signal that some condition relevant to authorization posture has been detected (e.g., a device became non-compliant). Observations are the inputs from which advisories are derived (). Signal Code. A registered identifier naming the kind of an observation (). Signal codes are the vocabulary in which sources speak to Eye. Advisory. The terminal Eye artifact: a signed, scope-bound statement of posture (status) and recommendation (recommended_action) for one scope, derived from one or more contributing observations (). Scope. The object an advisory is about, identified by a scope_type (entity, action, resource, or environment) and a scope_ref. An advisory speaks only about its scope. Scope-Binding Hash. A SHA-256 digest over the canonical scope identity, carried inside the signed advisory, that binds the advisory to exactly one scope (). Enforcement Point. The component that consumes an advisory and may tighten authorization posture in response - for example, by raising the required authentication level or demanding human signoff. In the EP family this is the verifying executor of the EP authorization receipt (). The enforcement point - not Eye - owns the decision. Posture. The strength of the checks an enforcement point applies to a prospective action. Tightening posture means requiring more (stronger auth, signoff, escalation); it never means granting access that policy would otherwise deny.

The Fail-Safe Invariant: An Advisory Is Never the Sole Gate This is the architectural invariant that governs every other design choice in this document. It is stated first, before the wire format, because the wire format exists to serve it. Eye warns. The enforcement point verifies. An accountable human owns. An Eye advisory MUST NOT be the sole gate between an entity and an action. If an advisory is ever the only thing standing between an entity and an action, the integration is non-conformant with this specification. Two corollaries make the invariant precise and testable:

Tighten-only (one-directional). A signal MAY only cause an enforcement point to demand more than it otherwise would (stronger authentication, human signoff, escalation, or a hard stop pending review). A signal MUST NOT cause an enforcement point to demand less, and a "clear" advisory MUST NOT be treated as an authorization, an approval, or a grant. The absence of a warning is not a permission.
Necessary-not-sufficient. An action that the underlying authorization policy would deny MUST remain denied regardless of any advisory. An advisory can subtract nothing from the set of conditions an action must satisfy; it can only add conditions. The authorization decision is owned by the enforcement point and, where the policy requires it, an accountable human (the EP signoff); the advisory is one input among those the decision considers.

Rationale. Signals are derived from heuristics, third-party feeds, and detectors that fail in both directions. A false negative (no signal) must never be readable as an affirmative grant, and a feed outage must never widen access. Confining advisories to a tighten-only role means the worst an advisory error can do is over-restrict - a fail-safe, recoverable outcome - never over-authorize. A conformant enforcement point that receives no advisory, an expired advisory, or an unverifiable advisory MUST behave as though posture were unchanged by Eye and fall back to its baseline policy; it MUST NOT fail open.

The Observation An observation is a single source-attributed signal about one scope. It is the input to advisory derivation and is itself scope-bound. Rules:

source_id MUST identify a source authenticated to the Eye service. source_type MUST be one of internal, partner, regulatory, or infrastructure.
signal_code MUST be drawn from the signal registry (). An observation carrying an unregistered signal_code MUST NOT contribute to an advisory's posture; it MAY be logged.
severity MUST be one of info, low, medium, high, or critical.
scope_binding_hash MUST be computed as in over this observation's scope_type and scope_ref.
expires_at MUST be present. Observations are time-bounded inputs; an expired observation MUST NOT contribute to a newly issued advisory.

Scope Binding Scope binding prevents an advisory (or observation) from being copied and presented against a scope other than the one it was issued for. The scope-binding hash is the SHA-256 digest of the JSON Canonicalization Scheme serialization of the scope identity object: Rules:

The scope-binding hash MUST be carried inside the signed advisory payload (), so that altering either scope_type or scope_ref invalidates the signature.
An enforcement point applying an advisory to a candidate action MUST recompute the scope-binding hash from the scope it is actually evaluating and MUST reject the advisory if the recomputed hash does not equal the advisory's scope_binding_hash. This is the check that defeats re-targeting.
The scope-binding hash is a binding, not a secret: it commits to the scope but reveals only what the scope identity already reveals. Where scope_ref is sensitive, deployments MAY use a salted scope reference, provided the enforcement point can recompute it for the scope under evaluation.

The Advisory An advisory is the scope-bound statement (signed in the Eye-Verifiable class; see Section 13.6) Eye issues for a scope. It is the artifact a relying party verifies and an enforcement point consumes.

Advisory Payload Rules:

status MUST be one of clear, caution, elevated, or review_required ().
recommended_action MUST be one of none, log, step_up_auth, require_signoff, or escalate (), and MUST be the value the deterministic mapping () assigns to status.
reason_codes MUST NOT be empty for any non-clear status. Each entry SHOULD be a registered signal_code drawn from the contributing observations.
contributing_observations MUST list the observation_id of every observation that influenced status. For a clear advisory it MAY be empty.
scope_binding_hash MUST equal the hash of this advisory's scope ().
expires_at MUST be present. An enforcement point MUST treat an advisory whose expires_at is in the past as absent and fall back to baseline posture (); it MUST NOT infer a grant from expiry.

Advisory Signature and Offline Verification The advisory is signed by the Eye operator's issuing key. The signed document mirrors the structure of the EP authorization receipt's evidence document so that the same verifier core can check both: The signature MUST be computed over the JCS canonicalization of the payload object, so that a verifier re-canonicalizes and re-derives the exact bytes the signature covers. Ed25519 is the RECOMMENDED algorithm.

Offline Verification Algorithm A verifier with (the signed advisory, the issuer's trusted public key, and the scope it is evaluating) and no network access MUST be able to establish all of the following:

Verify the signature over canonicalize(payload) against the issuer's public key. The signer key MUST be pinned to a source-independent trust root, never trusted solely because it accompanied the advisory.
Recompute the scope-binding hash from the scope under evaluation; confirm it equals payload.scope_binding_hash (). A mismatch MUST cause rejection: the advisory is for a different scope.
Confirm that recommended_action is the value the deterministic mapping () assigns to status; a divergent advisory MUST be rejected as malformed.
Confirm the current time is at or before expires_at. An expired advisory is treated as absent ().

As with the EP authorization receipt, offline verification establishes authenticity and scope binding as of issuance, not currency. Two properties are explicitly NOT established offline: (a) supersession - a later advisory may have replaced this one via superseded_by, which a cached holder cannot see; and (b) issuer-key revocation after issuance. A relying party with freshness requirements MUST additionally consult the Eye service or its published checkpoint online. Crucially, because advisories are tighten-only (), a stale advisory can only over-restrict, never over-authorize; the offline guarantee is therefore fail-safe. Implementations MUST NOT describe offline verification as establishing that an advisory is "currently the latest."

The Signal Registry The signal registry is the controlled vocabulary of observation signal codes. Each entry names a detectable condition, the scope_type it applies to, and the maximum status it MAY justify. The registry below is the experimental starting set; it is expected to grow. A deployment MAY register additional codes in a private namespace (prefix x-) but MUST NOT redefine a registered code.

signal_code	scope	meaning	max
`device.compliance.failed`	entity	endpoint posture check failed	elev.
`credential.phish.reported`	entity	credential reported phished	review
`auth.anomaly.impossible_travel`	entity	geographically impossible logins	elev.
`session.assurance.downgraded`	entity	assurance dropped mid-session	elev.
`resource.sensitivity.raised`	resource	resource reclassified higher	caut.
`action.velocity.anomaly`	action	rate/pattern deviates baseline	elev.
`counterparty.sanctions.hit`	action	counterparty on sanctions list	review
`environment.threat.elevated`	env.	environment threat level raised	caut.

The "max" column abbreviates the maximum status a single signal of that code may justify (caut. = caution, elev. = elevated, review = review_required). A "max status" caps how far a single signal of that code may move posture; it does not floor it. Eye derives an advisory's status from the contributing observations by taking the highest status any non-expired contributing observation justifies, bounded by each signal's max status. The full derivation is deployment policy and out of scope; what is normative is that the resulting status deterministically yields recommended_action per .

Deterministic Status-to-Posture Mapping This section is the bridge from an Eye advisory into an enforcement point - and, in the EP family, into EP verification. The mapping is normative and deterministic: every conformant enforcement point consuming the same advisory MUST tighten posture identically.

Status Semantics

clear. No active observations; no signals of concern. Not an authorization - see .
caution. Low-severity observations exist; context has changed but does not suggest immediate risk.
elevated. Medium-to-high severity observations exist; context suggests increased risk warranting additional verification.
review_required. Critical observations exist; context suggests the action should not proceed without explicit human review.

Recommended Action Semantics

none. No additional action required by Eye.
log. The enforcement point may record the advisory.
step_up_auth. Raise the required authentication level for the action.
require_signoff. Require accountable human signoff before the action proceeds.
escalate. Escalate for manual review or handling; the action does not proceed on Eye's recommendation alone.

The Mapping

advisory.status	recommended_action	Posture change at the enforcement point
`clear`	`none`	No change. Baseline policy applies unchanged. NOT a grant.
`caution`	`log`	Record the advisory; baseline policy otherwise unchanged.
`elevated`	`step_up_auth`	Require stronger authentication than baseline before proceeding.
`review_required`	`require_signoff` or `escalate`	Require accountable human signoff, or escalate; never proceed on Eye alone.

Every entry in the "posture change" column is monotonic in the tightening direction (): each named change adds a requirement and removes none.

Bridge into the Enforcement-Point Profile and EP Verification In an EP deployment, the enforcement point is the verifying executor of the EP authorization receipt (). The advisory tightens, but never replaces, EP verification:

On step_up_auth, the enforcement point SHOULD require an EP signoff key class corresponding to stronger assurance (e.g., a device-bound WebAuthn key) for the action's required approvals, raising the bar above the policy baseline.
On require_signoff, the enforcement point MUST require a valid EP authorization receipt with accountable human signoff before the action executes, even if the baseline policy would not otherwise have required one. The advisory adds the signoff requirement; the EP receipt - not the advisory - authorizes the action.
On escalate, the enforcement point MUST NOT allow the action to proceed on the advisory alone; it routes the action to human review, whose outcome (if it proceeds) is itself an EP signoff.

In every case the EP authorization receipt remains the artifact that authorizes; the advisory only determines how high the bar is set. An enforcement point MUST NOT synthesize, or treat the advisory as, an EP authorization receipt ().

Advisory Lifecycle and Supersession Advisories and observations are append-only. A posture change for a scope is expressed by issuing a new advisory and setting the prior advisory's superseded_by to the new advisory_id; an existing advisory's signed payload is never mutated. Because the signed payload is immutable, the superseding link is metadata visible only to a party querying the Eye service online; an offline holder sees only the advisory it holds, which is sound because tighten-only semantics make a stale advisory fail-safe (). Deployments SHOULD keep advisory expires_at windows short to bound the staleness an offline holder can carry.

Composition: SET Envelope and Optional SSF/CAEP Transport Eye does not define a new event envelope or a new delivery protocol. It composes over existing standards and adds only the verifiability, scope-binding, and fail-safe semantics those standards leave undefined.

Security Event Token Envelope An Eye advisory MUST be expressible as a Security Event Token . The signed advisory document () is carried as the event-specific payload of a SET event whose event-type URI is https://schemas.emiliaprotocol.ai/eye/advisory: The SET's own JWT-level protections (and any JWS signature over the SET) are complementary to, and do not replace, the advisory's embedded signature. The embedded signature is what survives re-transmission and caching and provides the offline verifiability of ; the SET envelope provides standards-aligned event framing. Per , the SET does not define how the event is delivered.

Optional SSF/CAEP Transport Eye advisories MAY be transported over the OpenID Shared Signals Framework as SET-formatted events on a stream between an Eye service (Transmitter) and an enforcement point (Receiver), alongside Continuous Access Evaluation Profile events. CAEP defines event types describing session and posture changes; Eye does not duplicate them. Where a CAEP event (e.g., a device compliance change) is the upstream cause of an observation, the observation's evidence_ref MAY reference that CAEP event. SSF/CAEP define the shape and transport of signals. They do not define whether a signal is verifiable offline, how it is bound to a scope, or what a recipient may do with it - in particular, they do not forbid treating a signal as an autonomous enforcement trigger. Eye supplies exactly those missing properties and is therefore the verifiable, bound, fail-safe advisory layer on top of SSF/CAEP, not a competitor to them. A deployment that uses SSF/CAEP transport MUST still enforce the fail-safe invariant () and scope-binding check () on every advisory it receives.

Conformance Classes Honesty about deployment topology is a protocol feature, as in the EP authorization receipt. An implementation MUST declare its class, and claims MUST NOT state a stronger class than deployed. Eye-Verifiable (STRONG). Advisories are asymmetrically signed () and verifiable offline; enforcement points perform the full offline verification algorithm and enforce both the scope-binding check and the fail-safe invariant. Eye-Bound (STANDARD). Advisories carry and enforce the scope-binding hash and the fail-safe invariant, but are not asymmetrically signed; integrity rests on transport authentication and the out-of-band-known hash. This matches the current reference implementation (). Eye-Advisory Only (BASIC). Advisories are consumed as policy input with the fail-safe invariant enforced, but without offline verification or scope-binding enforcement. No verifiability claim is made. The fail-safe invariant () is REQUIRED of every conformance class, including BASIC. It is the one property an Eye deployment may never omit.

Relationship to Other Work Security Event Token () defines the JWT-based event envelope Eye reuses as its wire container. Eye adds verifiable, scope-bound, fail-safe advisory semantics inside that envelope; it does not define a new envelope. OpenID SSF / CAEP (, ) define asynchronous SET delivery and a fixed set of session/posture event types. They standardize the shape and transport of signals but deliberately leave undefined the verifiable scope-bound advisory and the "never the sole gate" invariant. Eye supplies those and rides SSF/CAEP as OPTIONAL transport - complementary, not competing. EP authorization receipt () is the artifact that actually authorizes an action, binding an accountable human signoff to one exact action and verifiable offline. Eye composes with it: an advisory tightens the bar an EP receipt must clear () but never substitutes for the receipt. Eye warns; the EP receipt authorizes. AuthZEN and policy engines (OPA, Cedar). Authorization-decision semantics live in a policy decision point consulted by a policy enforcement point. Eye does not define a policy language; an Eye-aware enforcement point acts as (or alongside) a policy enforcement point and treats the advisory as additional context that can only tighten the decision, never as the decision itself.

Security Considerations

Fail-Safe, Never Fail-Open The defining risk this document guards against is an advisory being read as a permission. The fail-safe invariant () is the mitigation, stated as a normative MUST: a missing, expired, unverifiable, or clear advisory MUST leave baseline policy in force and MUST NOT be treated as a grant. An implementation that lets an Eye outage widen access has inverted the protocol's central guarantee. Because advisories are tighten-only, every other failure mode in this section degrades toward over-restriction, which is recoverable, rather than toward over-authorization, which is not.

False and Adversarial Signals A source may emit a false observation - through error, feed poisoning, or compromise of the source. Under tighten-only semantics the worst direct effect is denial of service by over-restriction (spurious step-up or signoff), not unauthorized access. Deployments SHOULD rate-limit and reputation-weight sources, SHOULD bound how far any single signal_code can move posture (the registry's max status, ), and SHOULD NOT let a single source unilaterally reach review_required for high-value scopes without corroboration. An adversary who can suppress true signals gains only the absence of tightening, which - by the fail-safe invariant - returns the system to its baseline policy, not to an open state.

Scope Replay and Re-Targeting Without scope binding, an advisory observed for one scope could be replayed against another. The scope-binding hash (), carried inside the signed payload and recomputed by the enforcement point against the scope it is actually evaluating, defeats this: a re-targeted advisory fails the hash comparison. Note that re-targeting an advisory can only ever add tightening to the wrong scope (a fail-safe denial), never authorize it; scope binding nonetheless MUST be enforced to prevent denial-of-service by misdirected advisories.

Issuer-Key Trust and Pinning Offline verification () is only as sound as the trust root for the issuer's key. A verifier MUST pin the issuer key to a source-independent trust root and MUST NOT trust a key solely because it accompanied the advisory or arrived over the same channel. Issuer-key revocation after issuance is not detectable offline; a relying party with revocation requirements MUST consult a current issuer-key checkpoint online. As elsewhere, the tighten-only property bounds the damage: a forged advisory from an untrusted key, if (wrongly) accepted, can only over-restrict.

Staleness and Supersession An offline holder cannot observe that a newer advisory has superseded the one it holds (). For a clear or low advisory this could mean acting on a posture milder than the current truth - but because a missing or milder advisory only fails to tighten (it never grants), the enforcement point's baseline policy still applies. Relying parties that require currency MUST query online and SHOULD keep expires_at windows short (). Implementations MUST NOT describe a cached advisory as the authoritative current posture.

Implementation Status and What Is Not Yet Built This is an experimental specification. The reference implementation currently computes scope-binding and advisory hashes over canonical fields and enforces append-only storage and the fail-safe invariant, but it does not yet asymmetrically sign advisories, does not yet emit the SET envelope (), and does not yet transport over SSF/CAEP. In the conformance terms of , the current implementation is Eye-Bound (STANDARD), not Eye-Verifiable (STRONG). The signing, SET-envelope, and CAEP-transport sections describe target behavior, not deployed behavior, and are marked experimental accordingly. No claim of production deployment, adoption, or third-party relying-party use is made.

What Eye Does and Does Not Decide Eye contributes context to an authorization decision; it never makes one. The strongest accurate claim is: "an Eye advisory can cause an action to require more before it proceeds." It cannot cause an action to require less, and it cannot, by itself, cause an action to proceed. Implementations MUST NOT represent Eye as an access-control system, an authorization service, or a gate; it is an advisory layer whose role is fixed by .

IANA Considerations This document has no IANA actions. A future version may register the SET event-type URI https://schemas.emiliaprotocol.ai/eye/advisory and the application/ep-eye-advisory+json media type.