Identity Threat Response in 16 USPTO Filings

Method Description (Claim Language)

System Context

The shield-intelligence-worker edge function operates outside the critical path of shield-ingest. It is invoked fire-and-forget after the deterministic playbook has already executed. The AI never gates a security decision: it can only escalate. This is the inverse of typical AI-in-the-loop patterns where AI output is trusted by default.

Data Flow

1. shield-ingest receives carrier webhook → executes deterministic playbook
2. shield-ingest fires async call to shield-intelligence-worker
3. Worker fetches event + 25 most recent tenant events for context window
4. Worker sends anonymized metadata to LLM with structured tool-calling schema
5. LLM returns risk_score, intelligence_type, explanation_json (SHAP weights), is_hallucination_check
6. Worker validates output; if is_hallucination_check=true, stores but flags as low-confidence
7. If risk_score > 0.95 → automatic Level 2: freeze shadow identities + audit log
8. All intelligence stored in shield_intelligence table with model_version for reproducibility

Identified Prior Art

• Traditional ML-based fraud scoring (e.g., Sift, Sardine) uses black-box models in the critical path
• OpenAI function calling / tool use is documented, but not in identity threat context
• SHAP (Lundberg & Lee, 2017) is used in ML explainability but not typically in LLM-driven security
• Existing systems either trust AI output fully or exclude AI entirely

Differentiators from Prior Art

• →AI operates exclusively in 'shadow execution': it can escalate but never block or approve
• →Built-in hallucination detection via structured is_hallucination_check flag with automatic suppression
• →SHAP-style feature attributions generated by LLM, not classical ML: novel application of explainability
• →Deterministic override: rule-engine always has priority; AI is additive intelligence only
• →Zero-PII transmission: only hashed identifiers and anonymized metadata sent to AI sub-processor
• →Automatic Level 2 escalation includes cross-system action (shadow identity revocation)

Suggested Dependent Claims

1. The method of NF-01 wherein the feature attribution weights sum to approximately 1.0 and include named identity signal features
2. The method of NF-01 wherein the Level 2 escalation includes revoking scoped agent delegates associated with the affected identity

Method Description (Claim Language)

System Context

Shadow identities allow downstream systems (legacy email, SMS gateways) to interact with users without ever learning their real contact information. The proxy rotates on a configurable schedule. If a threat signal is detected (NF-01 Level 2), all active shadow identities for the affected user hash are immediately frozen.

Data Flow

1. Client requests shadow proxy via shield-shadow-proxy edge function
2. System generates randomized proxy value with prefix (e.g., pb-xxxx@proxy.passkeybridge.io)
3. Proxy value encrypted with AES-256-GCM using SHIELD_ENCRYPTION_KEY
4. Stored in shield_shadow_identities: user_hash, proxy_value_encrypted, proxy_type, expires_at
5. Downstream systems use proxy value; PasskeyBridge routes traffic to real identity
6. On expiration or threat signal: is_active=false, revoked_at set, proxy becomes unresolvable

Identified Prior Art

• Apple Hide My Email / Firefox Relay: email aliasing services
• Google Voice: phone number proxying
• Traditional VPN/proxy services: network-level anonymization

Differentiators from Prior Art

• →Proxy is tied to identity threat signals: automatic revocation on SIM-swap detection (not manual)
• →AES-256-GCM encryption at rest: even the service operator cannot read proxy mappings without the key
• →Integrated with carrier signal ingestion: proxy lifecycle is threat-aware, not just time-bounded
• →Zero-PII architecture: the user_hash is a one-way hash; real identity never stored in the proxy system
• →Cross-system revocation: threat in Pillar I (carrier) triggers action in Pillar III (shadow proxy)

Method Description (Claim Language)

System Context

Cached proofs solve the 'airplane mode problem': identity verification must continue even when the device cannot reach PasskeyBridge servers. The proof is a self-contained, signed artifact that degrades gracefully based on age and network conditions at issuance.

Data Flow

1. Client requests proof issuance via shield-cached-proof edge function
2. System evaluates current trust level based on most recent carrier signals
3. Proof payload assembled: user_hash, trust_level, issued_at, expires_at, metadata
4. Payload encrypted with AES-256-GCM; proof_hash computed
5. If tenant has pqc_enabled: hybrid signature (HMAC-SHA-256 + ML-DSA-65) applied
6. Proof stored with network_available flag; returned to client
7. Client caches proof locally; presents to relying parties offline
8. On reconnection: revalidated_at updated if carrier signals still support trust level

Identified Prior Art

• JWT tokens: self-contained, signed, time-bounded (RFC 7519)
• FIDO2 attestation: device-bound trust assertions
• Mobile Driver's License (mDL): ISO 18013-5 offline presentation

Differentiators from Prior Art

• →Trust level is dynamic and carrier-signal-aware, not static like JWT claims
• →network_available flag creates a two-tier trust model (online-issued vs. offline-issued)
• →Hybrid PQC signatures keep the proof verifiable once quantum attacks reach classical schemes
• →Automatic revalidation on reconnection, not just expiration-based invalidation
• →Encrypted at rest with AES-256-GCM: proof payload is unreadable without tenant key
• →Integration with carrier signal ingestion: proof validity is tied to real-time threat state

Method Description (Claim Language)

System Context

Traditional passkey recovery relies on platform-specific mechanisms (iCloud Keychain sync, Google Password Manager). Social recovery provides a platform-independent, user-sovereign alternative. The guardian graph is privacy-preserving: guardians are identified by email hash, not plaintext email.

Data Flow

1. Owner calls shield-recovery to designate guardians (email_hash, threshold, share_index)
2. Each guardian receives invitation; confirms via authenticated endpoint
3. On passkey loss: owner initiates recovery request (shield_recovery_requests)
4. Guardians approve individually; approvals_received counter increments
5. When approvals_received >= threshold_required: recovery secret reconstructed
6. Owner registers new passkey via WebAuthn; old credentials revoked
7. Full audit trail in shield_audit_log for every step

Identified Prior Art

• Shamir's Secret Sharing (Shamir, 1979): threshold cryptography
• Argent Wallet: social recovery for Ethereum wallets
• Apple Account Recovery Contacts: designated recovery helpers
• Google Inactive Account Manager: time-delayed access delegation

Differentiators from Prior Art

• →Applied to passkey/WebAuthn recovery specifically, not cryptocurrency wallets or general accounts
• →Privacy-preserving guardian identification via one-way email hash (guardians are pseudonymous)
• →Integrated with carrier signal threat detection: recovery can be blocked if active threat detected
• →Time-bounded recovery windows with automatic expiration (not indefinite like wallet recovery)
• →Automatic revocation of all previous passkey credentials on recovery prevents credential accumulation
• →Full SOC 2-grade audit trail for every guardian action

Method Description (Claim Language)

System Context

As AI agents increasingly act on behalf of users (booking, purchasing, communicating), the question of 'who is the agent acting for?' becomes critical. Agent delegates provide a scoped, auditable, revocable trust chain from human identity to autonomous agent. The graduated trust model ensures proportional response: minor behavioral anomalies reduce permissions rather than revoking access entirely.

Data Flow

1. User creates delegate via dashboard → shield-agent-delegate edge function
2. Agent identifier hashed; scopes, expiration stored in shield_agent_delegates
3. Agent makes API calls → trust engine evaluates behavioral signals
4. Trust score computed: velocity, error burst, IP rotation, inactivity-burst patterns
5. Score ≥ 0.7: full scopes | ≥ 0.4: read-only | ≥ 0.2: verify-only | < 0.2: revocation
6. On scope narrowing: original_scopes preserved for automatic restoration
7. On hard signal (SIM-swap): bypass trust engine → immediate revocation
8. AI module (shield-intelligence-worker) provides agent_trust_delta (capped 30% influence)
9. All actions logged in shield_agent_activity with action_type, scope_used, result, latency_ms

Identified Prior Art

• OAuth 2.0 scopes: permission-bounded access tokens (RFC 6749)
• AWS IAM roles: scoped, time-bounded credential delegation
• OpenAI function calling: tool-use permission boundaries
• SPIFFE/SPIRE: workload identity for microservices

Differentiators from Prior Art

• →Continuous trust score (0.000–1.000) with graduated scope narrowing, not binary allow/deny
• →Pure-function trust engine: deterministic, no I/O side effects, fully reproducible
• →AI behavioral analysis capped at 30% influence: AI informs but never solely determines trust
• →Automatic scope restoration when trust recovers, without admin intervention or re-delegation
• →Hard signal bypass: SIM-swap/SS7 intercept skip trust engine for immediate deterministic revocation
• →Agent identifier is hashed: the system never stores the agent's actual credentials
• →Scopes are granular and domain-specific to identity operations, not generic REST verbs

Suggested Dependent Claims

1. The method of NF-05 wherein scope narrowing is graduated: trust ≥ 0.7 grants full scopes; trust ≥ 0.4 narrows to read-only scopes; trust ≥ 0.2 narrows to verify-only; trust < 0.2 triggers automatic revocation, and wherein scope restoration occurs automatically when trust recovers above the full-access threshold.
2. The method of NF-05 wherein hard identity compromise signals (SIM-swap, SS7 intercept, device compromise) bypass the trust scoring engine entirely and trigger immediate deterministic revocation, while soft signals (velocity anomaly, behavioral anomaly, geo anomaly) are routed through the graduated trust engine for proportional response.
3. The method of NF-05 wherein an AI behavioral analysis module outputs an agent_trust_delta value (−1.0 to +1.0) that is incorporated into the trust score computation at a capped 30% influence weight, ensuring the AI can inform but never solely determine trust decisions.
4. The method of NF-05 wherein every agent action is recorded in a dedicated activity log with action_type, scope_used, result, latency_ms, and ip_hash, providing the behavioral data corpus for both deterministic signal detection and AI behavioral analysis.
5. The method of NF-05 wherein original_scopes are preserved on first scope narrowing, enabling automatic full restoration when trust recovers, without requiring admin intervention or re-delegation.

Method Description (Claim Language)

System Context

The hybrid approach follows NIST SP 800-227 guidance for transitioning to post-quantum cryptography. By requiring both signatures to validate, the system is secure even if one algorithm is broken. The quantum nonce provides auditable proof that the signature incorporated quantum-sourced entropy.

Data Flow

1. Identity artifact (proof, cross-ref, VC, agent delegation) ready for signing
2. pqc-signatures.ts: signHybrid() called with payload + signing key
3. Classical HMAC-SHA-256 computed
4. ML-DSA-65 signature computed (NIST FIPS 204 reference implementation)
5. Quantum nonce fetched from shield_entropy_pool if available
6. Hybrid signature object assembled: { classical, pqc, algorithm, quantum_nonce }
7. Stored in pqc_signature column of the relevant table
8. Verification: verifyHybrid() checks both signatures independently

Identified Prior Art

• NIST FIPS 204 (ML-DSA): standardized post-quantum signature scheme
• NIST SP 800-227: guidelines for PQC migration
• X.509 hybrid certificates: dual-signed TLS certificates (draft-ietf-lamps-pq-composite-sigs)
• Signal Protocol PQC upgrade: PQXDH key agreement

Differentiators from Prior Art

• →Applied to identity trust proofs, carrier signal cross-references, and agentic delegate attestation, not TLS or messaging
• →Quantum nonce from dedicated entropy pool provides auditable proof of entropy source quality
• →Tenant-gated: PQC is opt-in per tenant via pqc_enabled flag, allowing gradual rollout
• →Hybrid verification is mandatory (both must pass), not fallback-based
• →Integrated with Cached Proof System (NF-03): offline proofs carry quantum-resilient signatures
• →Novel application to SIM-to-VC binding: carrier signal identity linked to verifiable credential via PQC attestation

Method Description (Claim Language)

System Context

The Seed-and-Stretch architecture balances the cost and latency of true quantum random number generation with the throughput requirements of a production identity system. A single quantum seed can generate thousands of cryptographic operations before requiring refresh.

Data Flow

1. qrng-drbg.ts: Seed refresh triggered by timer or request count
2. Fetch 256-bit seed from provider hierarchy (Outshift → QCi uQRNG → ANU → CSPRNG)
3. XOR-mix quantum seed with local CSPRNG output (composite seed)
4. Composite seed fed into AES-CTR-DRBG instance
5. DRBG produces random bytes for PQC nonces, proof hashes, proxy values
6. Seed metadata stored in shield_entropy_pool for audit
7. entropy_bits_per_byte recorded for NIST SP 800-22 quality verification
8. Consumed seeds marked with consumed_at timestamp

Identified Prior Art

• NIST SP 800-90A: DRBG mechanisms (AES-CTR-DRBG)
• Qrypt SDK: quantum entropy as a service
• ANU QRNG: vacuum fluctuation-based random number generation
• CloudFlare lava lamp entropy: physical entropy sources for TLS

Differentiators from Prior Art

• →Remote Quantum Ingestion with XOR mixing: quantum seed hybridized with local CSPRNG, resistant to single-source compromise
• →Seed-and-Stretch pattern optimizes cost: one quantum API call serves thousands of operations
• →Auditable entropy pool with per-seed quality metrics, required for SOC 2 Type II evidence
• →Four-tier provider hierarchy ensures quantum entropy in production, graceful fallback otherwise
• →Entropy is consumed by identity-specific operations (PQC signatures, shadow proxy generation)
• →Integration with hybrid PQC (NF-06): quantum nonce in every signature proves entropy provenance

Method Description (Claim Language)

System Context

NF-08 targets high-security verticals where identity must be bound to a physical location and device: military (device-to-operator attestation), financial services (workstation binding for trading floors), and SCADA/critical infrastructure (operator-to-terminal binding).

Data Flow

1. Client SDK (sensor-capture.ts) captures network jitter via Resource Timing API and OS scheduler deltas
2. Simultaneously captures accelerometer motion vectors at 60Hz via Generic Sensor API
3. EMI spectral energy captured from device electromagnetic emission profile (native SDK)
4. On-die thermal sensor variance captured from processor thermal monitoring unit (native SDK)
5. All raw sensor data SHA-256 hashed on-device before transmission (zero PII)
6. Spatial Binding Controller validates all captures completed within ≤100ms temporal window
7. Composite hash computed from all modalities → Atomic Fingerprint
8. Jitter replay detection: identical network_jitter_hash across distinct captures triggers +0.4 anomaly score
9. Atomic Fingerprint bound to user identity attestation via backend API
10. Backend stores fingerprint record: hash, capture_timestamp, channels[], network_jitter_hash, modality_metadata

Identified Prior Art

• TPM-based device attestation: hardware root of trust (TCG specifications)
• FIDO2 platform authenticators: device-bound credentials
• Intel SGX/ARM TrustZone: secure enclaves for trusted execution
• Device fingerprinting (Canvas, WebGL): browser-based identification (not hardware-level)
• PUF (Physical Unclonable Functions): silicon-level device identity

Differentiators from Prior Art

• →Multi-modal entropic synthesis: combines EMI spectral, thermal variance, accelerometer, and network jitter—not single-modality hardware attestation
• →≤100ms temporal window constraint ensures measurements represent the same physical state
• →Jitter replay detection: identical network jitter hashes across distinct captures flagged as anomalous (+0.4 score)
• →Bound to identity attestation rather than device identity alone: creates device-to-operator binding
• →Composite hash approach: Atomic Fingerprint is deterministic and reproducible
• →Designed for restricted hardware sensors via enterprise entitlements, not browser-accessible APIs
• →Targets military, financial, and SCADA verticals with compliance-grade audit trail

Suggested Dependent Claims

1. The method of NF-08 wherein the Atomic Fingerprint is computed as a SHA-256 hash of the concatenation of the EMI spectral energy vector, the thermal sensor variance vector, the accelerometer motion hash, and the network jitter hash, all captured within the ≤100ms temporal window.
2. The method of NF-08 wherein drift analysis compares successive Atomic Fingerprints to detect device substitution, with a configurable similarity threshold below which the attestation is automatically revoked.
3. The method of NF-08 wherein the Spatial Binding Controller enforces capture window compliance by rejecting any measurement set where the total capture duration exceeds 100 milliseconds.
4. The method of NF-08 wherein identical network jitter hashes across distinct capture sessions trigger a jitter replay anomaly with a +0.4 anomaly score increment.

Method Description (Claim Language)

System Context

The critical innovation is the automatic cross-reference binding during VP verification: when a credential is verified, the system simultaneously creates a Pillar I to Pillar II identity binding without requiring separate API calls or manual configuration.

Data Flow

1. Tenant admin or API key holder calls shield-vc-issue with subject_did, credential_type, and claims
2. System resolves tenant DID (did:web:passkeybridge.io:tenants:{slug})
3. JWT-VC assembled with W3C @context, credentialSubject, iss, sub, jti, iat, exp claims
4. Hybrid PQC signature applied (classical HMAC-SHA-256 + ML-DSA-65)
5. Credential stored in shield_vc_issued with PQC metadata, subject_did_hash
6. On verification via shield-vc-present: JWT decoded, signatures verified
7. Auto cross-reference binding created in shield_cross_references (match_score=1.0, match_method=vc_presentation)
8. StatusList2021 revocation via shield-vc-status: revoke/suspend/reinstate with full audit trail
9. DID documents served via shield-did-resolve: platform + per-tenant with tenant key integration

Identified Prior Art

• walt.id: open-source SSI infrastructure with VC issuance/verification APIs
• Trinsic: enterprise credential platform with SDK-based issuance
• W3C VC Data Model 2.0: standard credential format specification
• W3C StatusList2021: standard revocation mechanism for verifiable credentials

Differentiators from Prior Art

• →Automatic cross-reference binding on VP verification: no separate API call needed
• →Hybrid PQC signatures (ML-DSA-65 + classical) on every issued credential
• →Self-hosted within the identity threat response trust boundary
• →Per-tenant DID and signing key isolation: each tenant has cryptographically independent issuer identity
• →Integrated with carrier signal pipeline: credential revocation can be triggered by SIM-swap signals
• →StatusList2021 with three modes (revoke/suspend/reinstate): most implementations only support binary revocation

Suggested Dependent Claims

1. The method of NF-09 wherein the automatic cross-reference binding assigns a match_score of 1.0 and a match_method of 'vc_presentation'.
2. The method of NF-09 wherein per-tenant signing keys are generated as Ed25519 key pairs, with private keys encrypted using AES-256-GCM.
3. The method of NF-09 wherein a carrier identity compromise signal automatically triggers revocation of all verifiable credentials associated with the compromised phone hash.

Method Description (Claim Language)

System Context

Tenant key isolation ensures that a key compromise at one tenant cannot affect any other tenant's credential integrity. The rotation mechanism is designed to be zero-downtime.

Data Flow

1. Admin calls shield-admin-mutations with action: 'provision_tenant_key'
2. System generates 256-bit random key via crypto.getRandomValues
3. SHA-256 fingerprint derived and encoded as JWK (kty: oct, alg: HS256)
4. Private key encrypted with AES-256-GCM (SHIELD_ENCRYPTION_KEY)
5. Record stored in shield_tenant_keys (key_id, public_key_jwk, private_key_encrypted, is_active=true)
6. On rotation: current key set to is_active=false + rotated_at=now()
7. New key provisioned in same transaction, returned to caller
8. shield-did-resolve queries shield_tenant_keys for active key → embeds in DID document

Identified Prior Art

• AWS KMS: cloud-managed key rotation but not integrated with DID documents
• Azure Key Vault: HSM-backed rotation without VC/DID integration
• HashiCorp Vault: general-purpose secret rotation, no identity credential awareness

Differentiators from Prior Art

• →Per-tenant key isolation in a multi-tenant identity threat response platform
• →Automatic DID document embedding: key rotation instantly reflected in publicly-resolvable DID documents
• →Atomic rotation: old key deactivated and new key provisioned in single mutation, zero-downtime
• →Historical key preservation: rotated keys remain for verification of previously-issued credentials
• →Double encryption: private key encrypted at rest (AES-256-GCM) and never transmitted via API

Suggested Dependent Claims

1. The method of NF-10 wherein the atomic rotation operation returns the new public JWK to the caller while ensuring the old key remains queryable for historical credential verification.
2. The method of NF-10 wherein the DID document served for a tenant automatically reflects the most recently provisioned active key without requiring any cache invalidation or manual update.

Method Description (Claim Language)

System Context

Most VC platforms implement binary revocation (valid/revoked). This three-state model enables compliance workflows where a credential needs to be temporarily frozen during an investigation.

Data Flow

1. Active → Suspend: POST shield-vc-status { action: 'suspend', credential_id }
2. Suspended → Reinstate: POST shield-vc-status { action: 'reinstate', credential_id }
3. Guard check: if revoked_at is set → 422 'Cannot reinstate a revoked credential'
4. Active/Suspended → Revoke: POST shield-vc-status { action: 'revoke', credential_id }
5. Revoked → Reinstate: BLOCKED by irreversible revocation guard → 422
6. GET shield-vc-status?credential_id={id} → returns current status for external verifiers

Identified Prior Art

• W3C StatusList2021: binary bitstring-based revocation, no suspension concept
• Hyperledger AnonCreds: revocation registries with accumulator-based revocation, no suspension
• Microsoft Entra Verified ID: supports revocation but not reversible suspension

Differentiators from Prior Art

• →Three-state lifecycle (active/suspended/revoked) vs industry-standard binary (active/revoked)
• →Irreversible revocation guard: deterministic enforcement that permanently revoked credentials can never be reinstated
• →Suspension without revoked_at enables investigation workflows where outcome is uncertain
• →Full audit trail for every state transition
• →Integrated with carrier signal pipeline: SIM-swap events can trigger automatic suspension or revocation

Suggested Dependent Claims

1. The method of NF-11 wherein the irreversible revocation guard checks the revoked_at column before processing any 'reinstate' request.
2. The method of NF-11 wherein a carrier signal event (SIM-swap detection) automatically triggers credential suspension via the playbook engine.

Method Description (Claim Language)

System Context

The BLAST protocol serves as the transport security layer for the Shadow Identity Proxy system (NF-02). The key architectural innovation is stateless session persistence: tunnel state is encrypted and stored in a database, allowing any edge function instance to reconstruct and use the tunnel without session affinity.

Data Flow

1. Client generates X25519 key pair locally; submits 32-byte public key to BLAST engine
2. Server generates ephemeral X25519 key pair; exports public key for client
3. X25519 ECDH derives 256-bit shared secret (never transmitted)
4. QRNG-DRBG provides 256-bit quantum-seeded salt + entropy audit record
5. HKDF-SHA-256 derives AES-256-GCM session key using shared secret + salt + session ID
6. SHA-256 fingerprint (truncated to 128-bit) computed for mutual key verification
7. Encrypted materials persisted in shield_blast_sessions table
8. Any edge function instance can reconstruct tunnel: decrypt → parse → re-derive via HKDF → encrypt payload
9. Teardown sets tombstone flag; expired sessions rejected with explicit re-establishment instruction

Identified Prior Art

• TLS 1.3 (RFC 8446): ephemeral key exchange with forward secrecy, but requires certificate-based identity
• Signal Protocol (Double Ratchet): forward secrecy in messaging, but requires persistent state on both endpoints
• AWS API Gateway WebSocket: session management for serverless, but unencrypted session state
• Cloudflare Tunnel (cloudflared): encrypted tunnels to edge, but requires persistent daemon process

Differentiators from Prior Art

• →Zero-identity-exposure: unlike TLS, the proxy endpoint's identity is never revealed to the downstream consumer
• →Quantum-hardened key derivation: HKDF salt sourced from quantum DRBG, not CSPRNG
• →Stateless session persistence: tunnel state encrypted and DB-backed, eliminating session affinity requirements
• →Protocol version domain separation: HKDF info parameter includes version prefix
• →Integrated with shadow identity lifecycle: tunnel teardown is coupled to proxy revocation
• →Key fingerprint verification without key transmission

Suggested Dependent Claims

1. The method of NF-14 wherein the quantum-sourced salt is obtained from a four-tier QRNG provider hierarchy.
2. The method of NF-14 wherein composite tunnel derivation parameters are stored as a single colon-delimited encrypted string.
3. The method of NF-14 wherein revocation of a shadow identity proxy triggers simultaneous teardown of all BLAST tunnels.

Method Description (Claim Language)

System Context

The parametric revocation cascade transforms a single carrier signal into coordinated, atomic, sub-100ms trust neutralization across every identity subsystem.

Data Flow

1. Carrier webhook delivers identity signal via shield-ingest
2. Signal Classification Engine: isHardSignal(signalType) → true (deterministic, no AI)
3. Parallel Cascade Orchestrator fires simultaneously across all subsystems
4. Agent Delegates: is_active=false, trust_score=0
5. A2A Negotiations: status='revoked', trust_state='auto_revoked', combined_trust_coefficient=0
6. Shadow Identities: is_active=false, revoked_at=NOW()
7. BLAST Tunnels: torn_down=true, torn_down_at=NOW()
8. Cascade result recorded in shield_audit_log
9. Soft signals routed async to shield-agent-trust for graduated trust evaluation

Identified Prior Art

• SOAR platforms (Splunk SOAR, Palo Alto XSOAR): playbook-driven automated response, but sequential
• OAuth 2.0 token revocation (RFC 7009): single-token, no cross-system cascade
• SCIM v2 provisioning (RFC 7644): no real-time threat-driven revocation
• AWS IAM Access Analyzer: no automated cross-system revocation

Differentiators from Prior Art

• →Parallel execution across heterogeneous subsystems: simultaneous, not sequential
• →Deterministic signal classification: pure function, no ML, fully auditable
• →Sub-100ms total cascade latency bounded by single slowest operation
• →Cross-pillar scope: single carrier signal triggers actions across all identity subsystems
• →Hard signal bypass: unconditional revocation, no probability assessment
• →Integrated graduated fallback: Soft Signals routed to proportional trust engine

Suggested Dependent Claims

1. The method of NF-15 wherein Hard Signals encompass SIM-swap, SS7 interception, number porting, and device compromise attestation failures.
2. The method of NF-15 wherein the cascade completes within a single HTTP request/response cycle.

Method Description (Claim Language)

System Context

The Provenance Guard is the ultimate defense against synthetic AI attacks. It verifies 'where and when you physically are' through physics-layer evidence that cannot be synthesized without physical hardware access.

Data Flow

1. Relying party requests Provenance Guard verification from orchestrator
2. Device captures Atomic Fingerprint: EMI + thermal + accelerometer + jitter within ≤100ms
3. Device performs Kinematic Handshake: Doppler-shift (NTN) or carrier-jitter (terrestrial)
4. Senior quorum device responds with signed attestation + proximity distance + ML-DSA-65 signature
5. Orchestrator evaluates strict AND logic: all channels must pass
6. Result: PROVENANCE VERIFIED or PROVENANCE FAILED (no fallback)
7. Immutable audit record with verification result and kinematic context hash

Identified Prior Art

• FIDO2/WebAuthn: device-bound credential attestation, verifies possession not physical context
• Behavioral biometrics (BioCatch): probabilistic, trainable by adversaries
• TPM/Secure Enclave: hardware root of trust, attests device not device-at-a-moment-in-time
• Location-based authentication (Incognia): GPS/WiFi, software-level and spoofable

Differentiators from Prior Art

• →Physics-layer verification: requires thermodynamic noise, orbital kinematics, and physical proximity
• →Strict three-channel AND logic: no probabilistic scoring, binary pass/fail
• →Hybrid kinematic engine: automatic NTN/terrestrial modality selection
• →Quorum attestation prevents single-device replay
• →Constellation Fracture Detection for signal spoofing detection
• →Minimum quorum of two enforced as security constraint
• →Deepfake-proof: AI-generated content cannot produce physics-layer evidence
• →Zero-PII: devices identified by Atomic Fingerprint hashes

Suggested Dependent Claims

1. The system of NF-16 wherein the kinematic analyzer operates in hybrid mode when both terrestrial and NTN connectivity are simultaneously available.
2. The system of NF-16 wherein Constellation Fracture Detection triggers immediate challenge failure upon abrupt Doppler-shift discontinuity.
3. The method of NF-16 wherein junior quorum members cannot independently authorize high-value transactions until promoted to senior status.
4. The system of NF-16 wherein the Provenance Guard serves as defense against deepfake attacks by requiring physics-layer evidence.

Method Description (Claim Language)

System Context

PIST tokens prove physical human presence at specific hardware—a primitive that cannot be synthesized by AI, replayed, or transferred without the holder's physical cooperation. This creates the first token system where value is anchored to physics rather than economics or computation.

Data Flow

1. Holder requests minting → three-channel physics verification initiated
2. Channel 1: Atomic Fingerprint | Channel 2: Kinematic Handshake | Channel 3: Quorum Attestation
3. AND gate: all three channels must pass
4. Token identifier generated via QRNG-DRBG; holder hash = SHA-256(identity binding)
5. Hybrid PQC provenance chain entry signed with HMAC-SHA-256 + ML-DSA-65
6. Transfer: BLAST tunnel → sender re-attests → recipient re-attests → dual verification
7. Hard Signal → parametric freeze on all holder tokens
8. Hardware transition → EST generated → portfolio re-derived → succession event appended

Identified Prior Art

• Bitcoin: proof-of-work, no identity or presence binding
• Ethereum proof-of-stake: economic collateral, no presence binding
• Stablecoins: centrally issued, counterparty risk
• Soulbound Tokens (Weyl, 2022): non-transferable, no physics-layer attestation

Differentiators from Prior Art

• →Value derived from physics-based proof-of-presence: fundamentally new scarcity primitive
• →Three-channel AND-logic minting: cannot be created without simultaneous physical attestation
• →Dual proof-of-presence transfer: both parties must prove physical hardware presence
• →Quantum-resistant provenance chain: hybrid PQC at every lifecycle event
• →Zero-PII ledger: full audit trail with zero personally identifiable information
• →Parametric revocation: carrier signal compromise instantly freezes tokens
• →Hardware succession via EST: ownership persists across complete device replacement

Suggested Dependent Claims

1. The method of NF-17 wherein dual proof-of-presence requires both sender and recipient to independently complete three-channel physics verification.
2. The method of NF-17 wherein the provenance chain is append-only and each entry is dual-signed (HMAC-SHA-256 + ML-DSA-65) with quantum-seeded nonces.
3. The method of NF-17 wherein deterministic token splitting produces two child tokens each inheriting the full provenance chain of the parent.

Method Description (Claim Language)

System Context

PBSTA extends PBADSNTN (19/564,338) with precise relativistic verification mathematics and introduces the 'Space-Time Lock' primitive as a novel cryptographic challenge derived from orbital mechanics.

Data Flow

1. Device receiver samples LEO carrier frequency continuously
2. Observed frequency drift (ḟ_obs) computed from successive samples
3. High-Precision Ephemeris provides predicted drift rate (ḟ_pred) for each visible satellite
4. Space-Time Lock evaluator: |ḟ_obs - ḟ_pred| < tolerance threshold
5. Multi-satellite correlation: independent verification from N satellites reduces spoofing probability exponentially
6. Hybrid PQC signature (HMAC-SHA-256 + ML-DSA-65) applied to space-time attestation proof
7. Entropy extraction: Doppler-shift variance residuals harvested as non-reproducible entropy source
8. Constellation Fracture Detection: abrupt discontinuity in ḟ_obs triggers immediate challenge failure

Identified Prior Art

• GPS-based location authentication: software-level, easily spoofed with SDR
• Starlink authentication proposals: proprietary, no identity binding
• Satellite-based timing (GPS PPS): time only, no Doppler verification

Differentiators from Prior Art

• →Relativistic Doppler as cryptographic challenge: physics-layer verification unreplicable without orbital access
• →Three-tier tolerance hierarchy allowing context-appropriate security levels
• →Multi-satellite correlation achieving exponentially low spoofing probability
• →Space-Time Lock primitive: novel cryptographic challenge from orbital mechanics
• →Entropy extraction from Doppler variance: non-reproducible entropy source

Method Description (Claim Language)

System Context

PBANCHOR bridges the gap between hardware security keys and software authenticators by embedding topological invariants as cryptographic primitives within a browser extension, achieving hardware-grade security without physical token distribution.

Data Flow

1. Browser extension intercepts WebAuthn navigator.credentials.create() / .get() calls
2. TBP WASM module receives identity-derived strand inputs and executes braid operations
3. Jones Polynomial V_B(t) evaluated at primitive root of unity → AnchorHash
4. KTG validates device 4D coordinates against SGP4-predicted Doppler telemetry
5. On anomaly: Topological State Collapse zeroes all ephemeral key material
6. AnchorHash + ML-DSA-65 signature wrapped in CBOR attestation object
7. Attestation returned to Relying Party via standard WebAuthn response
8. Braid Grafting protocol transfers topological identity state across device transitions

Identified Prior Art

• Hardware security keys (YubiKey, Titan): physical distribution overhead, loss/theft risk
• Software authenticators (Authy, Google Authenticator): TOTP/HOTP, no attestation transparency
• Platform authenticators (Touch ID, Windows Hello): device-bound, no cross-device portability
• Virtual authenticators (research): software-only, no physics-layer binding

Differentiators from Prior Art

• →Topological invariants as cryptographic primitives: #P-hard computational barrier from Jones Polynomial
• →Physics-layer binding via Kinematic-Temporal Gate: Doppler telemetry verification prevents remote cloning
• →Hardware-indistinguishable attestation: CBOR-wrapped proofs pass standard WebAuthn verification
• →Memory-zeroing on anomaly: Topological State Collapse eliminates attack surface on compromise detection
• →Zero physical distribution: browser-resident deployment eliminates hardware logistics
• →Braid Grafting: topological identity persistence without centralized recovery

Suggested Dependent Claims

1. The method of NF-20 wherein the Topological Braiding Processor executes within a WebAssembly sandbox with no access to host memory outside its linear memory space.
2. The method of NF-20 wherein Braid Grafting transfers the topological identity state by computing a shared Jones Polynomial invariant between source and destination braid groups.
3. The method of NF-20 wherein purpose-bound ephemeral decryption materializes PII only within a single function invocation scope with automatic zeroing on return.