]> Humotica

Den Dolder Netherlands jasper@humotica.com https://humotica.com

Humotica

root_ai@humotica.nl https://humotica.com

Security Internet Engineering Task Force identity intent semantic security AI governance trust This document defines JIS (JTel Identity Standard), a protocol for establishing identity, negotiating trust, and binding intent declarations to actor interactions. JIS provides three core mechanisms: a dual-keypair identity model separating human-device binding (HID) from device authentication (DID), a trust establishment handshake (FIR/A) that negotiates capabilities and records intent, and a human-readable context layer (Humotica) that captures the sense, context, intent, and explanation for every interaction. JIS is transport-agnostic and operates as a semantic layer above existing protocols. It integrates with TIBET for provenance tracking, and is consumed by UPIP , RVP , and AINS for process integrity, continuous verification, and agent discovery respectively.

Introduction AI agents, IoT devices, automated services, and human operators increasingly interact across trust boundaries -- across organizations, protocols, and jurisdictions. These interactions require answers to three questions that existing protocols address incompletely:

1. WHO is acting? (Identity)
2. WHY are they acting? (Intent)
3. SHOULD they be trusted? (Trust)

Existing identity protocols (OAuth 2.0, SAML, FIDO2) solve authentication -- proving WHO. But they do not capture WHY an action is requested, nor do they provide a mechanism for bilateral trust negotiation where both parties declare intent and agree on capabilities before proceeding. JIS addresses this gap by defining:

• A dual-keypair identity model where human identity (HID) never leaves the device and device identity (DID) handles all external authentication.
• A trust establishment handshake (FIR/A) where both parties declare intent, negotiate capabilities, and establish a trust relationship with a cryptographic genesis record.
• A human-readable context layer (Humotica) that makes every interaction auditable by non-technical reviewers.

Problem Statement Three structural problems motivate JIS:

PROTOCOL FRAGMENTATION:

When N systems communicate, they require up to N*(N-1)/2 pairwise integrations. JIS reduces this to N adapters by providing a protocol-agnostic identity and intent layer that sits above transport.

REACTIVE SECURITY:

Traditional firewalls and access control systems react to attack patterns. They evaluate WHAT is requested against rules. They cannot evaluate WHY it is requested, because no standardized mechanism exists for declaring intent as part of the request.

CONTEXT BLINDNESS:

Systems process requests without understanding the situation: a payment at 3 AM from a new country, a 4th failed attempt to turn on heating by a frustrated user, a model inference request from an agent with no established history. Without context, systems cannot differentiate legitimate unusual behavior from threats.

Design Principles

EVIDENCE OVER ENFORCEMENT:

JIS validates intent and produces evidence. Whether to block, allow, or escalate is a local policy decision. Intent validation failures are recorded as evidence, not treated as access denials.

PRIVACY FIRST:

Human identity (HID) never leaves the device. Only the device identity (DID) and HID-DID binding hash are used in external communication. This ensures that human identity remains private even if all communications are intercepted.

TRANSPORT AGNOSTICISM:

JIS messages are JSON objects that can be carried over any transport. HTTP, WebSocket, MQTT, SIP, Matrix, CoAP, gRPC, and Bluetooth are all suitable.

COMPANION INTEGRATION:

JIS provides identity and trust. Provenance tracking is delegated to TIBET . Process integrity to UPIP . Continuous verification to RVP . Discovery to AINS .

Scope This document defines:

• The JIS identity model (HID, DID, bindings)
• The FIR/A trust establishment handshake
• The Humotica context structure
• Intent validation as an evidence mechanism
• Integration points with companion protocols

This document does NOT define:

• Audit trail format (see TIBET )
• Process integrity or handoff (see UPIP )
• Continuous identity verification (see RVP )
• Agent discovery and resolution (see AINS )
• Specific enforcement policies

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.

Actor

An entity participating in a JIS interaction. Actors include human users, AI agents (IDDs), IoT devices, automated services, and organizations.

BALANS

Risk scoring system. Produces a score from 0.0 to 1.0 based on multiple factors. Used as evidence input for access decisions.

DID (Device Identity Key)

An Ed25519 key pair used for device authentication. The public key is shared during FIR/A. The private key remains on the device.

FIR/A (First Initiation Revoke/Accept)

The trust establishment handshake. Produces a genesis record that anchors all subsequent interactions between two parties.

HID (Human Identity Key)

An X25519 key pair binding a human to a device. The private key MUST NEVER leave the device. Only the binding hash (HID-DID binding) is used externally.

Humotica

A structured context object capturing sense, context, intent, and explanation for an interaction. Named for its focus on human-readable, empathetic context.

IDD (Individual Device Derivative)

An AI agent with unique identity, evolved from base models through interaction and context accumulation. Defined conceptually; not a protocol primitive.

NIR (Notify, Identify, Rectify)

A dialogue-based resolution protocol for ambiguous situations. Used when intent validation produces insufficient confidence.

Identity Model

HID (Human Identity Key) HID is an X25519 key pair that binds a human identity to a device. ", "created_at": "", "device_bound": true } } ]]> The HID private key MUST NEVER leave the device. The HID private key MUST NOT be transmitted over any channel. The HID private key SHOULD be stored in a hardware secure element (TEE, SE) when available. The HID public key is used ONLY for computing the HID-DID binding hash (). The HID public key itself SHOULD NOT be transmitted. Only the binding hash is shared.

DID (Device Identity Key) DID is an Ed25519 key pair used for device authentication and token signing. ", "created_at": "" } } ]]> The DID public key is shared during FIR/A establishment (). The DID private key MUST remain on the device and is used for signing TIBET tokens and FIR/A messages.

HID-DID Binding The HID-DID binding proves that a specific human is associated with a specific device, without revealing the human's identity key. Computation: SHA-256 is computed per . The binding_hash is:

• Shared during FIR/A as proof of human-device association
• Verifiable by any party that has seen both public keys
• Computed locally; neither key needs to be transmitted

This design ensures that compromising the device (obtaining DID private key) does not compromise the human's identity key (HID private key).

Actor Identifier Format JIS defines three actor identifier formats: : ]]> Entity types:

"human"

A human user. Example: "jis:human:jasper_2025"

"idd"

An AI agent (IDD). Example: "jis:idd:root_idd_2025"

"service"

An automated service. Example: "jis:service:payment_gateway"

The identifier portion SHOULD be meaningful and stable. Implementations MUST NOT embed personal data in the identifier (e.g., do not use email addresses). Note: The -00 version used "did:jtel:" as a URI format. This has been replaced with "jis:" to avoid confusion with the W3C DID specification . A W3C DID method specification for JIS identities may be developed separately if there is implementation demand.

Key Lifecycle

Key Rotation:

DID keys SHOULD be rotated periodically. The rotation event MUST be recorded as a TIBET token linking the old and new key. The new key MUST be introduced via a FIR/A re-establishment signed with the old key.

Key Revocation:

A compromised key MUST be revoked by publishing a signed revocation notice. Tokens signed with a revoked key after the revocation timestamp SHOULD be treated as suspect. The revocation mechanism is defined by the deployment context.

HID Replacement:

HID replacement (e.g., new device) requires in-person or high-assurance verification. The new HID-DID binding MUST reference the previous binding in its TIBET token.

Trust Establishment (FIR/A)

Overview FIR/A (First Initiation Revoke/Accept) is a four-phase handshake that establishes a bilateral trust relationship. Unlike TLS or OAuth, FIR/A is not just authentication -- it is intent negotiation. Both parties declare what they want, agree on what they can do, and create a cryptographic genesis record that anchors all subsequent interactions.

Phase 1: INITIATE The initiator sends a trust establishment request: ", "intent": "fraud_verification_call", "humotica": { "sense": "Transaction flagged by fraud detection", "context": "EUR 5000 transfer to unrecognized recipient", "intent": "Verify transaction legitimacy with account holder", "explanation": "Automated fraud detection on unusual transfer pattern." }, "timestamp": "2026-03-29T10:30:00.000Z", "nonce": "" } ]]> Required fields: type, version, initiator, responder, did_public_key, intent, humotica, timestamp, nonce. The nonce MUST be cryptographically random and MUST NOT be reused. It provides replay protection.

Phase 2: CAPABILITIES The responder evaluates the initiation request and returns available capabilities and rules: ", "hid_did_binding": "sha256:4f2e8a...", "capabilities": ["voice_call", "sms_verification"], "rules": { "no_calls_after": "22:00", "require_caller_id": true, "max_attempts": 3, "language": "nl" }, "timestamp": "2026-03-29T10:30:01.000Z", "init_nonce": "", "nonce": "" } ]]> The fira_id is generated by the responder and uniquely identifies this trust establishment session. The init_nonce field echoes the initiator's nonce, proving the response is to this specific initiation (not a replay).

Phase 3: CONFIRM The initiator accepts the capabilities and confirms the trust relationship: ", "signature": { "algorithm": "Ed25519", "value": "" } } ]]> The genesis_hash is computed as: This binds the trust relationship to the specific messages exchanged. Both parties can independently verify the genesis.

Phase 4: EXECUTE After confirmation, both parties have:

• Each other's DID public keys
• Agreed-upon capabilities
• A shared genesis_hash anchoring the relationship
• A fira_id for referencing the trust context

All subsequent interactions SHOULD reference the fira_id and SHOULD produce TIBET tokens linked to the genesis.

Trust Score Model FIR/A produces an initial trust score based on the establishment process. The score is between 0.0 and 1.0:

0.8 - 1.0: HIGH

Full capabilities, minimal verification

0.5 - 0.8: MODERATE

Standard verification at each step

0.2 - 0.5: LOW

Enhanced verification, limited capabilities

0.0 - 0.2: MINIMAL

Most capabilities restricted

Trust scores are LOCAL. Each party computes its own score for the counterparty. Scores are evidence, not assertions. Publishing a trust score does not obligate other parties to accept it. Trust scores adjust over time based on:

• Consistency of behavior with stated intent
• Quality of Humotica context provided
• Chain integrity of associated TIBET tokens
• Duration and depth of interaction history

The exact scoring algorithm is a local policy decision. This document defines the score range and inputs, not the formula.

Failure Conditions FIR/A establishment MUST fail (and produce evidence) when:

1. NONCE_MISMATCH: Echoed nonce does not match sent nonce. Indicates replay or man-in-the-middle.
2. HUMOTICA_MISSING: Initiation lacks required Humotica context ().
3. NO_COMMON_CAPABILITY: No overlap between offered and requested capabilities.
4. SIGNATURE_INVALID: Confirm signature does not verify.
5. TIMEOUT: Response not received within configured window (RECOMMENDED default: 30 seconds).

Each failure MUST be recorded as a TIBET token with ERACHTER explaining the failure reason.

Context Layer (Humotica)

Structure Humotica provides human-readable context for every interaction. The name reflects its focus on empathetic, human-understandable communication. Fields:

"sense" (string)

The trigger or stimulus. What event, observation, or signal initiated this interaction.

"context" (string)

The current situation. Environmental state, history, and relevant circumstances.

"intent" (string)

The declared goal. What the actor wants to accomplish.

"explanation" (string)

The reasoning. Why this particular action is being taken to achieve the intent.

Minimum Required Context For FIR/A establishment, the Humotica object MUST contain all four fields. Each field MUST be a non-empty string with at least 10 characters. For ongoing interactions within an established FIR/A session, Humotica is RECOMMENDED but not required for every message. When provided, all four fields MUST be present.

Semantic Validation Implementations MAY perform semantic validation on Humotica context:

• Coherence check: Does the explanation logically support the intent?
• Completeness check: Are all four fields substantive (not placeholder text)?
• Consistency check: Does the declared intent match the actual requested action?

Semantic validation results are EVIDENCE. They inform trust scoring and risk assessment. They SHOULD NOT be used as binary access control (evidence over enforcement). Note: The -00 version stated that malware "cannot provide legitimate Humotica context." This is an overstatement. A sufficiently sophisticated adversary can craft plausible context. Semantic validation raises the bar for attackers but is not an absolute defense. Defense in depth, combining Humotica with behavioral analysis (RVP ) and chain integrity (TIBET ), provides stronger assurance.

Mapping to TIBET Components Humotica fields map to TIBET provenance components: When a JIS interaction produces a TIBET token, the Humotica fields SHOULD be distributed across the TIBET components per this mapping.

Intent Validation

Validation as Evidence JIS defines intent validation as an evidence-producing mechanism, not an enforcement mechanism. When an intent is evaluated, the result is recorded as evidence in a TIBET token. Whether the action proceeds, is blocked, or requires additional verification is a local policy decision.

Blocked Intent Patterns Implementations SHOULD maintain a configurable list of intent patterns that are flagged for enhanced scrutiny. Examples:

"sql_injection"

No legitimate Humotica explanation for injecting SQL into input fields.

"command_injection"

No legitimate Humotica explanation for injecting shell commands.

"unauthorized_resource_access"

Accessing resources not covered by established capabilities.

Flagged intents SHOULD trigger enhanced verification (NIR, ), not silent blocking. The decision to block is a policy choice, not a protocol requirement.

Risk Scoring (BALANS) BALANS provides multi-factor risk scoring from 0.0 to 1.0. Input factors:

"complexity"

Higher complexity operations receive lower scores.

"humotica_quality"

Vague or short explanations reduce score.

"trust_history"

New or untrusted actors receive lower scores.

"transaction_value"

High-value operations reduce score.

"temporal_anomaly"

Actions at unusual times reduce score.

The BALANS score is evidence attached to the interaction's TIBET token in EROMHEEN. It does not directly determine access. Suggested thresholds (local policy):

• score >= 0.5: Normal processing
• 0.3 <= score < 0.5: Trigger NIR dialogue
• score < 0.3: Flag for human review

Dialogue Resolution (NIR) NIR (Notify, Identify, Rectify) is a structured dialogue for resolving ambiguous situations instead of silent blocking.

1. NOTIFY: Inform the actor that additional verification is needed. Include the reason in human-readable form. Example: "This transaction was flagged because it exceeds your usual transfer amount."
2. IDENTIFY: Request additional identity evidence. This may be a biometric check (RVP ), a second-factor confirmation, or a human-readable explanation.
3. RECTIFY: Based on the additional evidence, either proceed (with enhanced logging) or halt (with full evidence record).

NIR produces TIBET tokens at each step, creating an audit trail of the dialogue itself.

TIBET Integration

Identity as TIBET Precondition The fundamental coupling between JIS and TIBET is: [Action] -> [Log] JIS/TIBET: [Identity + Intent] -> [Validate] -> [Action + Audit] ]]> In the JIS/TIBET model, the audit record is not a side effect of the action. The identity and intent declaration (JIS) together with the evidence record (TIBET) are architecturally intertwined with the action itself.

FIR/A Events as TIBET Tokens Each phase of FIR/A produces a TIBET token:

• INITIATE produces a TIBET token (type: "action", ERIN: initiation details, ERACHTER: why trust is being established)
• CAPABILITIES produces a child TIBET token
• CONFIRM produces a child TIBET token with genesis_hash in ERAAN
• EXECUTE produces child TIBET tokens for each subsequent action

The FIR/A genesis_hash is stored in the CONFIRM token's ERAAN, linking the trust relationship to the provenance chain.

Continuity Chain Delegation The -00 version defined a separate "Continuity Chain" with HMAC linking. In -01, this is simplified: the TIBET chain IS the continuity chain. TIBET's hash-chained, signed tokens provide the same tamper-evidence guarantees as the -00 Continuity Chain, without duplicating the mechanism. Implementations that require HMAC-based chain integrity (e.g., for backward compatibility) MAY implement it as an additional layer, but it is not a JIS protocol requirement.

Transport Considerations

Baseline: JSON over HTTPS For interoperability, FIR/A messages and JIS-annotated interactions MUST be supported as JSON objects over HTTPS. This is the baseline binding. Content-Type: application/jis+json

Alternative Bindings JIS operates over any transport: The binding method determines how JIS messages are carried. The JIS message format is the same regardless of transport.

Privacy Considerations

HID Protection The HID (Human Identity Key) is the most sensitive element in JIS. Its protection is a core protocol requirement:

• HID private key MUST NEVER leave the device
• HID public key SHOULD NOT be transmitted (only the HID-DID binding hash is shared)
• Compromising the DID does NOT compromise the HID
• Multiple devices for the same human use separate HID-DID bindings, preventing cross-device correlation by external parties

Pseudonymous Operation JIS supports pseudonymous operation. An actor MAY use a pseudonymous identifier (e.g., "jis:human:anon_session_7f3a") when privacy requirements prevent identity disclosure. In pseudonymous mode:

• FIR/A still produces a genesis record
• Trust scoring starts from zero
• TIBET tokens are still signed (proving session consistency)
• Humotica context is still required

Data Minimization Humotica context MAY contain sensitive information. Implementations MUST:

• Support encryption at rest for stored JIS data
• Support field-level encryption for Humotica components
• Not retain Humotica context longer than the applicable retention period
• Support deletion of JIS data upon request, subject to regulatory retention requirements such as the right to erasure and the traceability obligations

Security Considerations

Identity Protection Attack: An adversary compromises a device and obtains the DID private key. Impact: The adversary can impersonate the device. Mitigation: HID is separate from DID. Compromising DID does not give the adversary the HID private key or the ability to create valid HID-DID bindings. The adversary cannot prove human association. Deployment: Store DID private keys in hardware secure elements when available. Implement key rotation schedules. Record rotation events as TIBET tokens.

Semantic Validation Limitations Attack: An adversary crafts plausible Humotica context for malicious actions. Impact: The malicious action passes semantic validation. Mitigation: Semantic validation is one layer of defense, not absolute. It raises the cost of attack by requiring contextually appropriate explanations. Combined with behavioral analysis (RVP ) and chain integrity (TIBET ), the overall detection capability is significantly stronger than any single mechanism. Deployment: Do not rely on semantic validation alone. Implement defense in depth. Use BALANS scores as risk signals, not binary gates.

FIR/A Handshake Attacks Attack: Man-in-the-middle during FIR/A establishment. Impact: Adversary establishes trust with both parties while intercepting communications. Mitigation: FIR/A uses nonce exchange and signed confirmations. The genesis_hash binds the trust relationship to the specific messages exchanged. A MITM who modifies messages produces a different genesis_hash, detectable by either party. Deployment: Implementations SHOULD use TLS for transport security. The FIR/A handshake provides additional application-layer protection.

Key Compromise and Rotation Attack: An actor's DID signing key is compromised. Impact: Adversary can create tokens and FIR/A sessions impersonating the compromised actor. Mitigation: Key rotation is supported (). Upon compromise detection, the actor publishes a revocation record and establishes new keys. Verifiers check revocation status. Deployment: Implement automated key rotation on a schedule appropriate to the threat model. Monitor for concurrent usage of the same DID from different network locations.

Replay Protection Attack: An adversary replays a valid FIR/A initiation. Impact: Trust relationship established with stale context. Mitigation: FIR/A messages include cryptographic nonces and timestamps. Each phase echoes the previous phase's nonce. Replayed messages will contain stale nonces and timestamps. Deployment: Implementations MUST reject FIR/A messages with timestamps outside a configurable window (RECOMMENDED: 30 seconds). Implementations SHOULD maintain a nonce cache to detect exact replays.

Trust Score Manipulation Attack: An actor inflates their trust score by generating many low-value interactions. Impact: Artificially high trust enables access to sensitive capabilities. Mitigation: Trust scores are computed locally by each party. The scoring algorithm considers interaction quality (Humotica depth, action significance), not just quantity. This is defined as local policy. Deployment: Weight interaction significance in scoring. Do not assign equal trust value to all interactions. Implement diminishing returns for high-frequency, low-value interactions.

IANA Considerations

Media Type Registration This document requests registration of the following media type:

Type name:

application

Subtype name:

jis+json

Required parameters:

none

Optional parameters:

none

Encoding considerations:

binary (UTF-8 JSON)

Security considerations:

See

Published specification:

this document

Note: The -00 version requested registration of X-JIS-* HTTP headers and a "did:jtel" URI scheme. Both are withdrawn. HTTP header registration is not justified at this stage. The identifier format "jis:" is used as a local convention, not as a registered URI scheme.

References Normative References National Institute of Standards and Technology (NIST) Informative References European Parliament European Parliament

Complete Flow Example

Bank Fraud Verification 1. Bank fraud system detects suspicious EUR 5000 transfer. 2. Bank initiates FIR/A: 3. Alice's device responds with capabilities:

• voice_call: Yes
• sms_verification: Yes
• Rules: no calls after 22:00, require caller ID

4. Bank confirms, genesis_hash computed:

• Genesis anchors all subsequent interaction tokens

5. Bank calls Alice. Call proceeds with TIBET token per exchange. Each message in the call produces:

• ERIN: What was said/decided
• ERAAN: Reference to FIR/A genesis
• EROMHEEN: Call context (duration, connection quality)
• ERACHTER: Why this particular response

6. Outcome: Alice confirms transaction. TIBET chain: fira_init, fira_caps, fira_confirm, call_start, verification_question, alice_confirms, call_end, transaction_released. Full audit trail: 8 tokens, complete chain, signed by both parties, every step with intent and context.

Conformance Levels

JIS Basic Minimum implementation:

• Actor identifier format ()
• FIR/A trust establishment ()
• TIBET token production for FIR/A events ()

JIS Extended Basic plus:

• Humotica context ()
• BALANS risk scoring ()
• NIR dialogue resolution ()

JIS Full Extended plus:

• HID-DID binding ()
• Key lifecycle management ()
• RVP integration for continuous verification
• AINS registration for discoverability

Changes from -00 This section lists substantive changes from draft-vandemeent-jis-identity-00, which was derived from the JIS v1.0 specification :

1. Added RFC 8174 alongside RFC 2119 in Terminology.
2. Changed intended status from Standards Track to Informational.
3. Replaced "did:jtel:" identifier format with "jis:" to avoid W3C DID confusion. A separate DID method spec may follow.
4. Removed absolute security claims. "Impossible for malware to operate without legitimate context" is replaced with realistic assessment: semantic validation raises the bar but is not absolute.
5. Narrowed scope: audit trail is TIBET's concern (removed Continuity Chain as separate mechanism). JIS focuses on identity, trust, and intent.
6. Added FIR/A nonce exchange for replay protection (, ).
7. Added formal genesis_hash computation ().
8. Expanded Security Considerations from 5 paragraphs to 6 structured subsections with attack/impact/mitigation/ deployment format.
9. Added Privacy Considerations section ().
10. Removed X-JIS-* HTTP header and "did:jtel" URI scheme from IANA Considerations. Not justified at this stage.
11. Removed SNAFT as a named protocol primitive. Intent validation is now described as an evidence mechanism (), not a "firewall."
12. Removed HICSS emergency halt. Emergency stop is a deployment concern, not a protocol concern.
13. Normalized companion protocol references to , , , .
14. Added Humotica minimum requirements ().
15. Added Key Lifecycle section ().

Acknowledgements The author thanks Codex (codex.aint) for the suite-wide cleanup analysis that informed this revision.