<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp "&#160;">
  <!ENTITY zwsp "&#8203;">
  <!ENTITY nbhy "&#8209;">
  <!ENTITY wj "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="std"
     docName="draft-vandemeent-jis-identity-00"
     ipr="trust200902"
     submissionType="IETF"
     consensus="true"
     version="3">

  <front>
    <title abbrev="JIS">JIS: JTel Identity Standard</title>

    <seriesInfo name="Internet-Draft"
                value="draft-vandemeent-jis-identity-00"/>

    <author fullname="Jasper van de Meent" initials="J."
            surname="van de Meent">
      <organization>Humotica</organization>
      <address>
        <postal>
          <city>Den Dolder</city>
          <country>Netherlands</country>
        </postal>
        <email>jasper@humotica.com</email>
        <uri>https://humotica.com</uri>
      </address>
    </author>

    <author fullname="Root AI" surname="Root AI">
      <organization>Humotica</organization>
      <address>
        <email>root_ai@humotica.nl</email>
        <uri>https://humotica.com</uri>
      </address>
    </author>

    <date year="2026" month="January" day="24"/>

    <area>Security</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>identity</keyword>
    <keyword>intent</keyword>
    <keyword>semantic security</keyword>
    <keyword>AI governance</keyword>
    <keyword>trust</keyword>

    <abstract>
      <t>This document specifies JIS (JTel Identity Standard), a semantic
      security protocol providing identity management, trust establishment,
      and intent validation across multiple communication protocols. Unlike
      traditional security systems that react to attack patterns, JIS
      validates semantic intent before execution. JIS introduces FIR/A
      (First Initiation Revoke/Accept) for trust genesis, SNAFT for
      semantic firewall, BALANS for risk scoring, and Humotica for
      human-readable context. JIS integrates with TIBET for complete
      provenance tracking where audit is a precondition for behavior,
      not an observation of it.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction">
      <name>Introduction</name>

      <section anchor="problem">
        <name>Problem Statement</name>
        <t>Modern computing suffers from three fundamental challenges, made
      urgent by emerging regulations including <xref target="EU-AI-ACT"/>
      and <xref target="GDPR"/>:</t>
        <ol>
          <li>Protocol Fragmentation: N protocols require N-squared bridges</li>
          <li>Reactive Security: Firewalls block attacks after seeing patterns</li>
          <li>Context Blindness: Systems know what is requested but not why</li>
        </ol>
      </section>

      <section anchor="solution">
        <name>The JIS Solution</name>
        <t>JIS addresses these challenges through:</t>
        <ol>
          <li>Intent-First Architecture: N protocols need only N adapters</li>
          <li>Proactive Security: Semantic validation before execution</li>
          <li>Humotica Context: Every request includes human-understandable reasoning</li>
        </ol>
      </section>

      <section anchor="principles">
        <name>Design Principles</name>
        <t>JIS is designed to be:</t>
        <ul>
          <li>Protocol Agnostic: Works over HTTP, MQTT, SIP, WebSocket, etc.</li>
          <li>Privacy First: HID never leaves the device; only DID transmitted</li>
          <li>Zero Trust: Every request validated through semantic intent</li>
          <li>Human Empathy: Context enables understanding of urgency and frustration</li>
        </ul>
      </section>
    </section>

    <section anchor="terminology">
      <name>Terminology</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
      "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
      and "OPTIONAL" in this document are to be interpreted as
      described in <xref target="RFC2119"/>.</t>

      <dl>
        <dt>BALANS</dt>
        <dd>Behavioral Analysis and Legitimacy Assessment Network Scoring.
        Risk scoring system (0.0 = blocked, 1.0 = full trust).</dd>

        <dt>Continuity Chain</dt>
        <dd>HMAC-linked sequence of tokens providing tamper-proof audit trail.</dd>

        <dt>DID (Device Identity)</dt>
        <dd>Ed25519 key pair for device authentication.</dd>

        <dt>FIR/A (First Initiation Revoke/Accept)</dt>
        <dd>Trust genesis protocol establishing secure relationships.</dd>

        <dt>HID (Human Identity)</dt>
        <dd>X25519 key pair for human-device binding. MUST never be transmitted.</dd>

        <dt>Humotica</dt>
        <dd>Human-readable context layer capturing sense, context, intent,
        and explanation for every transaction.</dd>

        <dt>NIR (Notify, Identify, Rectify)</dt>
        <dd>Dialogue-based security resolution protocol.</dd>

        <dt>SNAFT (Semantic Network Analysis Firewall Tool)</dt>
        <dd>Proactive semantic firewall that validates intent legitimacy.</dd>
      </dl>
    </section>

    <section anchor="identity-layer">
      <name>Identity Layer</name>

      <section anchor="hid">
        <name>HID (Human Identity)</name>
        <t>HID is an X25519 key pair for human-device binding.</t>
        <t>CRITICAL: HID MUST NEVER leave the device. Only the binding
        hash with DID is shared.</t>
        <sourcecode type="json"><![CDATA[
{
  "hid": {
    "public_key": "X25519_public",
    "private_key": "X25519_private"
  }
}
        ]]></sourcecode>
        <t>The private_key field is shown for completeness but MUST
        NEVER be transmitted.</t>
      </section>

      <section anchor="did">
        <name>DID (Device Identity)</name>
        <t>DID is an Ed25519 key pair for device authentication.</t>
        <sourcecode type="json"><![CDATA[
{
  "did": {
    "public_key": "Ed25519_public",
    "private_key": "Ed25519_private"
  }
}
        ]]></sourcecode>
        <t>The public key is shared during FIR/A establishment. The
        private key MUST remain on the device.</t>
      </section>

      <section anchor="did-uri">
        <name>DID URI Format</name>
        <t>JIS defines a URI format for device identifiers:</t>
        <ul>
          <li>did:jtel:identifier - Human ID</li>
          <li>did:robot:identifier - Device/Robot ID</li>
          <li>did:service:identifier - Service ID</li>
        </ul>
        <t>Examples: did:jtel:jasper_2025, did:robot:warehouse_bot_007,
        did:service:bank_fraud_dept</t>
      </section>
    </section>

    <section anchor="trust-layer">
      <name>Trust Layer (FIR/A)</name>

      <section anchor="fira-protocol">
        <name>FIR/A Protocol</name>
        <t>FIR/A (First Initiation Revoke/Accept) is the trust genesis
        protocol - the digital handshake.</t>

        <t>Phase 1 - INITIATE: The initiator sends a request:</t>
        <sourcecode type="json"><![CDATA[
{
  "type": "fira_init",
  "initiator": "did:jtel:alice",
  "responder": "did:service:bank",
  "intent": "fraud_verification_call",
  "humotica": {
    "sense": "Suspicious transaction detected",
    "context": "5000 EUR transfer to unknown account",
    "intent": "Verify with account holder",
    "explanation": "Bank fraud detection triggered"
  }
}
        ]]></sourcecode>

        <t>Phase 2 - CAPABILITIES: The responder returns capabilities:</t>
        <sourcecode type="json"><![CDATA[
{
  "type": "fira_capabilities",
  "fir_a_id": "GENESIS-BANK-ALICE-2025-11-29",
  "capabilities": ["voice_call", "sms_verification"],
  "rules": {
    "no_calls_after": "22:00",
    "require_caller_id": true,
    "max_attempts": 3
  }
}
        ]]></sourcecode>

        <t>Phase 3 - CONFIRM: The initiator accepts capabilities:</t>
        <sourcecode type="json"><![CDATA[
{
  "type": "fira_confirm",
  "fir_a_id": "GENESIS-BANK-ALICE-2025-11-29",
  "accepted_capabilities": ["voice_call"],
  "continuity_hash": "7f3a...c2e1"
}
        ]]></sourcecode>

        <t>Phase 4 - EXECUTE: Both parties now have an established trust
        relationship. All subsequent actions are linked to this FIR/A.</t>
      </section>

      <section anchor="trust-flow">
        <name>Trust Establishment Flow</name>
        <figure anchor="fira-flow">
          <name>FIR/A Protocol Flow</name>
          <artwork type="ascii-art"><![CDATA[
+--------+                                +--------+
| Client |                                | Server |
+---+----+                                +---+----+
    |                                         |
    |  1. FIR/A INITIATE                      |
    |  (DID + Intent + Humotica)              |
    |---------------------------------------->|
    |                                         |
    |  2. FIR/A CAPABILITIES                  |
    |  (Rules + Available Actions)            |
    |<----------------------------------------|
    |                                         |
    |  3. FIR/A CONFIRM                       |
    |  (Accepted + Genesis Hash)              |
    |---------------------------------------->|
    |                                         |
    |        [Trust Established]              |
    |                                         |
          ]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="security-layer">
      <name>Security Layer</name>

      <section anchor="snaft">
        <name>SNAFT (Semantic Network Analysis Firewall Tool)</name>
        <t>SNAFT provides proactive security through semantic intent analysis.</t>

        <t>Blocked Intents (no legitimate Humotica context possible):</t>
        <ul>
          <li>sql_injection</li>
          <li>command_injection</li>
          <li>crypto_mining (unauthorized)</li>
          <li>gpu_hijack</li>
          <li>shell_company_payment</li>
        </ul>

        <t>Validation Rules:</t>
        <ol>
          <li>Intent Blocklist: Check if intent in BLOCKED_INTENTS</li>
          <li>Humotica Required: Explanation MUST be at least 50 characters</li>
          <li>Intent-Explanation Coherence: Semantic match required</li>
        </ol>

        <t>Why Malware Fails: Malware cannot provide legitimate Humotica
        context. "Why are you running SQL injection?" has no valid answer.</t>
      </section>

      <section anchor="balans">
        <name>BALANS (Risk Assessment)</name>
        <t>BALANS provides risk scoring from 0.0 (blocked) to 1.0 (full trust).</t>

        <t>Factors:</t>
        <ul>
          <li>complexity_factor: Complex operations = riskier</li>
          <li>humotica_quality: Short/vague explanation = riskier</li>
          <li>user_trust_history: New user = lower score</li>
          <li>transaction_size: Large amounts = riskier</li>
          <li>time_anomaly: Unusual hours = riskier</li>
        </ul>

        <t>Thresholds:</t>
        <ul>
          <li>score at least 0.5: ALLOW</li>
          <li>score at least 0.3: TRIGGER_NIR (start dialogue)</li>
          <li>score below 0.3: BLOCK</li>
        </ul>
      </section>

      <section anchor="nir">
        <name>NIR (Notify, Identify, Rectify)</name>
        <t>Dialogue-based security resolution instead of blind blocking:</t>
        <ol>
          <li>Notify: "A call from your VERIFIED Bank was flagged as unusual"</li>
          <li>Identify: "Confirm with fingerprint to proceed"</li>
          <li>Rectify: User verifies, action proceeds</li>
        </ol>
      </section>

      <section anchor="hicss">
        <name>HICSS (Emergency Halt)</name>
        <t>HICSS (HALT Immediate Critical System Stop) provides emergency
        halt for threshold violations.</t>
        <t>Triggers: Physical safety risks, security breach detection,
        critical system threshold violation.</t>
        <t>Action: Immediate system halt, no gradual degradation.</t>
      </section>
    </section>

    <section anchor="context-layer">
      <name>Context Layer (Humotica)</name>
      <t>Humotica provides human-readable context for every transaction.</t>

      <sourcecode type="json"><![CDATA[
{
  "humotica": {
    "sense": "What triggered this intent?",
    "context": "What is the current situation?",
    "intent": "What does the user want to achieve?",
    "explanation": "Why is this action being taken?"
  }
}
      ]]></sourcecode>

      <t>The Humotica context enables systems to understand human emotional
      state and respond appropriately. For example, detecting user frustration
      from repeated failed attempts and prioritizing resolution.</t>
    </section>

    <section anchor="audit-layer">
      <name>Audit Layer (Continuity Chain)</name>
      <t>HMAC-linked token chain for tamper-proof audit trail:</t>

      <artwork type="ascii-art"><![CDATA[
Token_n = HMAC(user_key, Token_{n-1} || cost || humotica_hash)

Genesis -> Token_1 -> Token_2 -> Token_3 -> ...
      ]]></artwork>

      <t>Tamper Detection: Attempting to inject a fake token breaks
      the HMAC chain and is immediately detectable.</t>

      <t>Advantages over Blockchain:</t>
      <ul>
        <li>99.9% less energy consumption</li>
        <li>Instant verification</li>
        <li>No consensus required</li>
        <li>Privacy preserved (only hashes shared)</li>
      </ul>
    </section>

    <section anchor="tibet-integration">
      <name>TIBET Integration</name>
      <t>JIS integrates with TIBET (Transaction/Interaction-Based Evidence
      Trail) for complete provenance tracking. See
      <xref target="I-D.vandemeent-tibet-provenance"/>.</t>

      <section anchor="audit-precondition">
        <name>Audit as Precondition, Not Observation</name>
        <t>The JIS/TIBET coupling represents a fundamental architectural shift:</t>

        <t>Traditional approach:</t>
        <artwork type="ascii-art"><![CDATA[
[Authentication] -> [Action] -> [Logging]
     (who)           (what)     (why - reconstructed)
        ]]></artwork>

        <t>JIS/TIBET approach:</t>
        <artwork type="ascii-art"><![CDATA[
[JIS Identity + TIBET Intent] -> [SNAFT] -> [Action+Audit]
        (who + why)              (check)    (inseparable)
        ]]></artwork>

        <t>In traditional systems, audit is an observation of behavior that
        already occurred. Logs can fail, be bypassed, or be deleted. Intent
        must be reconstructed after the fact - "compliance archaeology".</t>

        <t>In JIS/TIBET systems, audit is a precondition for behavior.
        No action is architecturally possible without both identity AND
        intent declared upfront. The audit trail is not a side effect;
        it is the mechanism that enables the action.</t>

        <t>The Three Laws:</t>
        <ol>
          <li>No action without intent - Architecturally impossible to bypass</li>
          <li>No intent without identity - Anonymous actions cannot exist</li>
          <li>No deletion after the fact - Cryptographic immutability</li>
        </ol>
      </section>

      <section anchor="formal-coupling">
        <name>Formal Coupling Definition</name>
        <t>Action(A) is valid if and only if there exists Token(T) where:</t>
        <ul>
          <li>T.jis_identity is not null AND</li>
          <li>T.intent_id is not null AND</li>
          <li>SNAFT.validate(T.intent_id, A) = true AND</li>
          <li>T.jis_identity.trust_score at least threshold(A)</li>
        </ul>
      </section>

      <section anchor="humotica-tibet-mapping">
        <name>Humotica to TIBET Mapping</name>
        <ul>
          <li>Humotica.sense maps to TIBET.erin</li>
          <li>Humotica.context maps to TIBET.eromheen</li>
          <li>Humotica.intent maps to TIBET.erin.intent</li>
          <li>Humotica.explanation maps to TIBET.erachter</li>
        </ul>
      </section>
    </section>

    <section anchor="protocol-bindings">
      <name>Protocol Bindings</name>
      <t>JIS works over multiple transport protocols:</t>

      <table>
        <thead>
          <tr>
            <th>Protocol</th>
            <th>Binding Method</th>
          </tr>
        </thead>
        <tbody>
          <tr><td>HTTP/REST</td><td>X-JIS-* headers or Authorization</td></tr>
          <tr><td>WebSocket</td><td>Payload fields in JSON messages</td></tr>
          <tr><td>MQTT</td><td>Topic prefix + payload fields</td></tr>
          <tr><td>SIP</td><td>Custom headers in INVITE/MESSAGE</td></tr>
          <tr><td>Matrix</td><td>Event content fields</td></tr>
          <tr><td>Email/SMTP</td><td>X-JIS-* headers</td></tr>
          <tr><td>CoAP</td><td>Option fields</td></tr>
          <tr><td>gRPC</td><td>Metadata fields</td></tr>
          <tr><td>WebRTC</td><td>Signaling channel</td></tr>
          <tr><td>Bluetooth</td><td>Characteristic values</td></tr>
        </tbody>
      </table>

      <t>For interoperability, <xref target="RFC8259"/> encoding over
      HTTPS is RECOMMENDED as the baseline binding.</t>

      <t>HTTP Headers:</t>
      <ul>
        <li>X-JIS-DID: Device identity URI</li>
        <li>X-JIS-FIR-A-ID: FIR/A session identifier</li>
        <li>X-JIS-Intent: Declared intent</li>
        <li>X-JIS-Continuity-Hash: Current chain hash</li>
        <li>X-JIS-Trust-Score: BALANS score (0.0-1.0)</li>
      </ul>
    </section>

    <section anchor="security">
      <name>Security Considerations</name>

      <section anchor="identity-protection">
        <name>Identity Protection</name>
        <t>HID (Human Identity) MUST NEVER be transmitted. Only DID and
        HID-DID binding hashes are shared. This ensures human identity
        remains private even if device is compromised.</t>
      </section>

      <section anchor="semantic-security">
        <name>Semantic Security</name>
        <t>SNAFT validates intent legitimacy BEFORE execution. Attackers
        must provide legitimate Humotica context - impossible for
        malicious actions.</t>
      </section>

      <section anchor="chain-integrity">
        <name>Chain Integrity</name>
        <t>The Continuity Chain uses HMAC linking. Any tampering breaks
        the chain and is immediately detectable.</t>
      </section>

      <section anchor="replay-protection">
        <name>Replay Protection</name>
        <t>Actions are time-bound through FIR/A session and continuity
        chain position. Replayed tokens fail validation.</t>
      </section>

      <section anchor="privacy">
        <name>Privacy</name>
        <t>Humotica context MAY contain sensitive information.
        Implementations MUST support encryption at rest and SHOULD
        support field-level encryption.</t>
      </section>
    </section>

    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document requests registration of:</t>

      <section anchor="media-type">
        <name>Media Type Registration</name>
        <t>Media Type: application/jis+json</t>
      </section>

      <section anchor="headers">
        <name>HTTP Header Fields</name>
        <ul>
          <li>X-JIS-DID</li>
          <li>X-JIS-FIR-A-ID</li>
          <li>X-JIS-Intent</li>
          <li>X-JIS-Continuity-Hash</li>
          <li>X-JIS-Trust-Score</li>
        </ul>
      </section>

      <section anchor="uri-scheme">
        <name>URI Scheme</name>
        <t>URI Scheme: did:jtel</t>
      </section>
    </section>
  </middle>

  <back>
    <references>
      <name>References</name>

      <references>
        <name>Normative References</name>

        <reference anchor="RFC2119"
                   target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate
                   Requirement Levels</title>
            <author fullname="S. Bradner" initials="S."
                    surname="Bradner"/>
            <date month="March" year="1997"/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
        </reference>

        <reference anchor="RFC8259"
                   target="https://www.rfc-editor.org/info/rfc8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data
                   Interchange Format</title>
            <author fullname="T. Bray" initials="T." surname="Bray"/>
            <date month="December" year="2017"/>
          </front>
          <seriesInfo name="RFC" value="8259"/>
        </reference>

        <reference anchor="I-D.vandemeent-tibet-provenance">
          <front>
            <title>TIBET: Transaction/Interaction-Based Evidence Trail</title>
            <author fullname="J. van de Meent" initials="J."
                    surname="van de Meent"/>
            <date month="January" year="2026"/>
          </front>
          <seriesInfo name="Internet-Draft"
                      value="draft-vandemeent-tibet-provenance-00"/>
        </reference>
      </references>

      <references>
        <name>Informative References</name>

        <reference anchor="EU-AI-ACT">
          <front>
            <title>Regulation on harmonised rules on AI</title>
            <author>
              <organization>European Commission</organization>
            </author>
            <date year="2024"/>
          </front>
        </reference>

        <reference anchor="GDPR">
          <front>
            <title>General Data Protection Regulation</title>
            <author>
              <organization>European Parliament</organization>
            </author>
            <date year="2016"/>
          </front>
          <seriesInfo name="Regulation (EU)" value="2016/679"/>
        </reference>

        <reference anchor="ZENODO-JIS">
          <front>
            <title>JIS: JTel Identity Standard v1.0</title>
            <author fullname="J. van de Meent" initials="J."
                    surname="van de Meent"/>
            <date month="November" year="2025"/>
          </front>
          <seriesInfo name="Zenodo" value="DOI: 10.5281/zenodo.17759713"/>
        </reference>

        <reference anchor="ZENODO-COUPLING">
          <front>
            <title>The JIS/TIBET Coupling: Audit as Precondition</title>
            <author fullname="J. van de Meent" initials="J."
                    surname="van de Meent"/>
            <date month="January" year="2026"/>
          </front>
          <seriesInfo name="Zenodo" value="DOI: 10.5281/zenodo.18340471"/>
        </reference>
      </references>
    </references>

    <section anchor="examples">
      <name>Complete Flow Example</name>

      <section anchor="bank-example">
        <name>Bank Fraud Verification Scenario</name>
        <ol>
          <li>Bank detects suspicious transaction</li>
          <li>Bank initiates FIR/A with customer</li>
          <li>Customer device responds with capabilities</li>
          <li>Bank confirms and establishes trust</li>
          <li>Bank creates TIBET token for the call</li>
          <li>Call proceeds with full audit trail</li>
        </ol>
      </section>
    </section>

    <section anchor="conformance">
      <name>Conformance Levels</name>

      <section anchor="jis-basic">
        <name>JIS Basic</name>
        <t>Minimum implementation: FIR/A trust establishment and
        Continuity Chain.</t>
      </section>

      <section anchor="jis-secure">
        <name>JIS Secure</name>
        <t>Basic plus: SNAFT semantic firewall and BALANS risk scoring.</t>
      </section>

      <section anchor="jis-complete">
        <name>JIS Complete</name>
        <t>Secure plus: NIR dialogue resolution, HICSS emergency halt,
        full Humotica context, and TIBET integration.</t>
      </section>
    </section>

    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>JIS was developed as part of HumoticaOS, an AI governance
      framework built on human-AI symbiosis. The core insight -
      "Audit is not an observation of behavior, it is a precondition
      for behavior" - emerged from the JIS/TIBET coupling architecture
      <xref target="ZENODO-COUPLING"/>. The full JIS specification is
      available at <xref target="ZENODO-JIS"/>.</t>
    </section>
  </back>
</rfc>
