Network Working Group Harveer Singh Internet-Draft Ganpatsingh Rajput (GSR) Intended Status: Informational Rizz Wireless Inc. Expires: April 19, 2027 October 19, 2026 NOTE ON AUTHOR NAME FORMAT: The running header above uses the abbreviated column layout required by IETF I-D formatting rules (RFC 7322). Full author names are: Harveer Singh and Ganpatsingh Rajput. Full names appear in the Authors' Addresses section and throughout all copyright and authorship statements in this document. Rizz Negotiation Protocol (RNP) Version 1.0 draft-singh-rajput-rnp-00 Abstract This document specifies the Rizz Negotiation Protocol (RNP), version 1.0 -- a domain-configurable, machine-readable protocol governing autonomous AI-to-AI negotiation across any structured decision context. RNP defines a finite action space, a bounded round-based state machine, a Competitive Pressure Mechanism (CPM) for multi- thread simultaneity, a Context Layer for real-time situational intelligence, a Feedback Layer for continuous master data improvement, and a Loopback Learning Pipeline that trains agent models from observed outcomes. The protocol is domain-configurable: the same state machine and message envelope operate across commerce, logistics, task allocation, priority queuing, procurement, SLA negotiation, and rewards domains. RNP was first deployed in production within the Rizzentials platform (commerce domain) and is designed for enterprise integration with platforms such as SAP, Salesforce, and Atlassian Jira. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. NOTE: The authors have disclosed to the IETF Secretariat that they may have intellectual property rights relevant to this document. The IETF takes no position regarding the validity or scope of any Intellectual Property Rights claimed. See BCP 79 and http://www.ietf.org/ipr for more information. Table of Contents 1. Introduction 1.1. Design Goals 1.2. Scope of Application 1.3. Terminology 2. Negotiation Domain Model 2.1. Domain Registry 2.2. Domain Parameter Sets 2.3. Domain Extension 3. Protocol Architecture 4. Agent Identity and Authentication 5. RNP Message Format 5.1. Common Envelope 5.2. OFFER Message 5.3. COUNTER Message 5.4. ACCEPT Message 5.5. REJECT Message 5.6. WITHDRAW Message 6. Negotiation State Machine 7. Round Management 8. Competitive Pressure Mechanism (CPM) 9. Intent Encoding 10. Context Layer 11. Feedback Layer 12. Loopback Learning Pipeline 13. LLM Routing 14. Edge Compute and Offline Operation 15. B2B Platform Integration 15.1. SAP Integration Profile 15.2. Salesforce Integration Profile 15.3. Atlassian/Jira Integration Profile 16. Security Considerations 17. IANA Considerations 18. Normative References 19. Authors' Addresses 1. Introduction Traditional multi-party decision systems require human intermediaries at every negotiation point. A procurement manager reviews bids. A scrum master adjudicates sprint priorities. A logistics coordinator assigns routes. Each step is slow, inconsistent, and unlearnable -- the outcome of one negotiation does not improve the next. RNP eliminates the human intermediary from the negotiation loop without eliminating human oversight. Two AI agents negotiate on behalf of their respective principals using a bounded, auditable protocol. Every decision is logged. Every outcome improves the agents. Humans set policy and review exceptions; agents handle volume. 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 RFC 2119 [RFC2119]. 1.1. Design Goals o Deterministic state: given a session ID and message sequence, any observer MUST be able to reconstruct full negotiation state. o Minimal action space: the smallest set of message types sufficient to represent all commercially and operationally meaningful negotiation moves. o Domain configurability: the protocol envelope and state machine are fixed; the payload parameter set is domain-specific. o Multi-thread simultaneity: a single Initiating Agent MUST be able to run N independent RNP sessions concurrently with N responding agents, with competitive pressure signals flowing between threads. o Loopback trainability: all session outcomes MUST be captured as supervised fine-tuning training examples without additional labeling. o Identity accountability: both negotiating parties MUST be cryptographically identified. o Round boundedness: every session MUST terminate within a known maximum number of rounds (R_max). o Feedback compounding: every session MUST update the agents' master data records, enriching context for future sessions. 1.2. Scope of Application RNP applies to any structured interaction where two AI agents must converge on agreed terms within a bounded number of exchanges. The agents need not be consumer and merchant. Defined domains include: o COMMERCE -- price, discount, quantity between consumer and merchant agents o LOGISTICS -- route, carrier, SLA, capacity between orchestrator and carrier agents o TASK_ALLOCATION -- work scope, deadline, handover between project and executor agents o PRIORITY_QUEUE -- sprint ranking, resource allocation between stakeholder and delivery agents o PROCUREMENT -- RFQ terms, delivery, payment between buyer and vendor agents o SLA_NEGOTIATION -- service tier, response time, penalties between platform and client agents o REWARDS -- token allocation, redemption conditions, loyalty tier between platform and consumer agents 1.3. Terminology CAIA: Consumer AI Agent -- or more generally, the Initiating Agent in any RNP domain. Holds a KYC-gated agent identity. MAIA: Merchant AI Agent -- or more generally, the Responding Agent in any RNP domain. Holds a KYB-gated agent identity. Session: A single bounded negotiation between one Initiating Agent and one Responding Agent, identified by a UUID v4 Session ID. Round: One complete Initiating Agent action / Responding Agent action exchange. Indexed R = 1 through R_max (default 5). R_max: Maximum rounds per Session. Protocol default: 5. Configurable at Session creation. Cannot be modified after creation. Action Space: The finite set of message types: {OFFER, COUNTER, ACCEPT, REJECT, WITHDRAW}. CPS: Competitive Pressure Signal -- metadata injected by the Initiating Agent orchestrator into outbound messages to inform the Responding Agent of concurrent competing sessions. Context Snapshot: Real-time situational intelligence assembled for both agents at Session init from their respective master data and live platform data sources. Feedback Layer: The subsystem that writes Session outcomes and per- decision events back to the CAIA Master Record and MAIA Master Record after Session termination. Loopback: The training pipeline: Session outcomes -> SFT -> DPO -> LoRA adapter -> updated inference model. Domain: A named configuration profile specifying the parameter schema for OFFER and COUNTER payloads (e.g., COMMERCE, LOGISTICS, TASK_ALLOCATION). 2. Negotiation Domain Model RNP is domain-configurable. The negotiation_domain field in the Session record determines which parameter schemas are valid inside OFFER and COUNTER payloads. All other protocol elements -- the state machine, round management, CPS, agent identity, Context Layer, Feedback Layer, and Loopback pipeline -- are domain-agnostic. 2.1. Domain Registry Registered RNP domains as of this specification: Domain Primary Platform Targets ------ ----------------------------------------------- COMMERCE Rizzentials, Shopify, Salesforce Commerce Cloud LOGISTICS SAP Transportation Mgmt, Oracle TMS TASK_ALLOCATION Jira (Atlassian), Salesforce Service Cloud, SAP Project Systems PRIORITY_QUEUE Jira, Linear, Azure DevOps PROCUREMENT SAP Ariba, Salesforce Revenue Cloud, Coupa SLA_NEGOTIATION Salesforce Service Cloud, ServiceNow, Zendesk REWARDS Rizzentials/RZTO, Salesforce Loyalty Cloud 2.2. Domain Parameter Sets Each domain defines its own OFFER and COUNTER parameter schemas, replacing the commerce-specific fields with domain-appropriate parameters. The envelope (Section 5.1) and state machine (Section 6) are unchanged across all domains. COMMERCE domain_params: { "target_price_cents": integer, "min_order_qty": integer, "discount_pct": float (0.0-100.0), "delivery_terms": "STANDARD|EXPRESS|SAME_DAY", "validity_seconds": integer (min 30) } LOGISTICS domain_params: { "route_id": string, "carrier_agent_id": eSIM number, "sla_hours": float, "cost_per_unit_cents": integer, "capacity_units": integer, "pickup_window_utc": ISO 8601 interval, "delivery_commitment_utc": ISO 8601, "temperature_controlled": boolean } TASK_ALLOCATION domain_params: { "task_ids": [string, ...], "assignee_agent_id": eSIM number, "scope_description": string, "deadline_utc": ISO 8601, "effort_points": integer, "handover_conditions":[string, ...], "dependencies": [task_id, ...], "priority_score": float (0.0-10.0) } PRIORITY_QUEUE domain_params: { "item_ids": [string, ...], "proposed_ranking": [integer, ...], "sprint_capacity_units": integer, "resource_allocation_pct":float, "freeze_after_utc": ISO 8601, "rationale": string | null } PROCUREMENT domain_params: { "rfq_id": string, "unit_price_cents": integer, "quantity": integer, "delivery_schedule": ISO 8601 interval, "payment_terms_days": integer, "warranty_months": integer, "incoterms": string, "bid_validity_hours": integer } SLA_NEGOTIATION domain_params: { "service_tier": "BRONZE|SILVER|GOLD|PLATINUM", "first_response_sla_minutes": integer, "resolution_sla_hours": float, "uptime_commitment_pct": float, "escalation_threshold_minutes":integer, "penalty_per_breach_cents": integer, "contract_term_months": integer } REWARDS domain_params: { "token_symbol": string (e.g., "RZTO"), "tokens_offered": integer, "redemption_conditions":[string, ...], "loyalty_tier_change": "UPGRADE|MAINTAIN|DOWNGRADE|null", "expiry_days": integer, "bonus_multiplier": float } 2.3. Domain Extension New domains MAY be registered without modifying the core protocol. A domain registration requires: a domain identifier string (uppercase, underscore-separated), a parameter schema (JSON Schema Draft 7 compatible), and a context schema specifying relevant Context Layer fields. Custom domains registered by enterprise deployments MUST be prefixed with the deploying organization's identifier (e.g., SAP_ARIBA_PROCUREMENT, SFDC_SERVICE_SLA). 3. Protocol Architecture RNP operates across five layers. The Identity Layer authenticates agents via eSIM-bound cryptographic identities before any Session can be created. The Session Layer manages Session lifecycle, round tracking, state persistence, and termination. The Context Layer assembles real-time situational snapshots for both agents at Session init. The Learning Layer captures Session outcomes for the Loopback training pipeline. The Feedback Layer writes decision-level events and terminal outcomes back to agent master data records. In the Rizzentials production deployment: AWS Connect X Platform (CAIA Orchestrator), Amdocs CRM/BSS (OMS), T-Mobile Network GW (eSIM provisioning), Plaid API (financial context), PostgreSQL + DocumentDB (Intent Storage), and dynamic LLM routing across Kimi, DeepSeek, Claude, and a custom fine-tuned model. 4. Agent Identity and Authentication Every RNP Session participant MUST hold a valid Agent Identity consisting of: a dedicated eSIM number distinct from the human principal's personal number; a cryptographic key pair bound to the eSIM at provisioning; a role tag (CONSUMER_AGENT or MERCHANT_AGENT); and a verification status (KYC_VERIFIED or KYB_VERIFIED). Every RNP message MUST be signed by the sender's private key over the full message payload including Session ID, Round index, message type, and all parameter fields. Recipients MUST verify the signature before processing the message. Unsigned or unverifiable messages MUST be rejected. The Universal Number-to-Entity Assignment principle applies: a single eSIM number MAY be assigned to any entity type -- human individual, AI agent, IoT device, or BCI/HMI interface -- using the same identity infrastructure without protocol modification. 5. RNP Message Format 5.1. Common Envelope All RNP messages share a common envelope with message-type-specific payload fields: { "rnp_version": "1.0", "session_id": , "round": , "message_type": , "negotiation_domain": , "sender_agent_id": , "sender_role": , "timestamp_utc": , "signature": , "cps": , "payload": { } } 5.2. OFFER Message (Initiating Agent -> Responding Agent) An OFFER opens or advances negotiation. The payload MUST contain domain_params conforming to the Session's registered domain schema. The intent_vector field carries the consumer/initiator's demand encoding and is included in OFFER messages only. 5.3. COUNTER Message (Responding Agent -> Initiating Agent) A COUNTER proposes modified terms. For COMMERCE domain, discount_pct MUST be consistent with counter_price_cents relative to the listed price. Inconsistent values are a protocol violation and MUST be rejected by the receiving agent. 5.4. ACCEPT Message ACCEPT signals unconditional agreement to the most recent outstanding OFFER or COUNTER. The sender's signature constitutes a binding commitment to the accepted terms. ACCEPT transitions the Session to RESOLVED state. 5.5. REJECT Message REJECT signals refusal without terminating the Session (unless R = R_max). Valid reason_code values: PRICE_TOO_HIGH, QTY_MISMATCH, OUT_OF_STOCK, CAPACITY_UNAVAILABLE, DEADLINE_INFEASIBLE, POLICY, OTHER. 5.6. WITHDRAW Message WITHDRAW signals unilateral Session termination. The Session closes immediately with status WITHDRAWN. When reason_code is BETTER_OFFER_ACCEPTED, the winning_session_id field SHOULD be populated to enable Responding Agent Loopback capture of competitive loss events. 6. Negotiation State Machine Each Session exists in exactly one state at any time: State Terminal Description ----- -------- ----------- INIT No Session created, no messages exchanged. OFFERED No Initiating Agent sent OFFER. COUNTERED No Responding Agent sent COUNTER. RESOLVED Yes ACCEPT received. Terms agreed. REJECTED_TERMINAL Yes REJECT at R=R_max. No agreement. WITHDRAWN Yes Either party sent WITHDRAW. EXPIRED Yes validity_seconds elapsed with no message. State transition rules: INIT + OFFER (initiator) -> OFFERED OFFERED + COUNTER (responder) -> COUNTERED OFFERED + ACCEPT (responder) -> RESOLVED OFFERED + REJECT (responder), R INIT (next round) OFFERED + REJECT (responder), R=R_max -> REJECTED_TERMINAL OFFERED + WITHDRAW (either) -> WITHDRAWN COUNTERED + OFFER (initiator) -> OFFERED COUNTERED + ACCEPT (initiator) -> RESOLVED COUNTERED + REJECT (initiator), R INIT (next round) COUNTERED + REJECT (initiator), R=R_max -> REJECTED_TERMINAL COUNTERED + WITHDRAW (either) -> WITHDRAWN Any active + TTL expired -> EXPIRED Sessions in terminal states MUST NOT accept further messages. The Round index MUST be monotonically increasing. COUNTER MUST only be sent by the Responding Agent. OFFER MUST only be sent by the Initiating Agent. ACCEPT and REJECT MAY be sent by either party. 7. Round Management A Round consists of one Initiating Agent action and one Responding Agent action. Each Round is bounded by the validity_seconds of the most recently sent OFFER or COUNTER. Minimum validity_seconds: 30. The Session Layer MUST maintain a message hash log per Session. Duplicate (session_id, round, message_type, sender_agent_id) tuples MUST be rejected as replay attacks. When R = R_max and no ACCEPT or WITHDRAW has been sent, the next REJECT triggers REJECTED_TERMINAL. R_max MUST NOT be modified after Session creation. 8. Competitive Pressure Mechanism (CPM) CPM enables an Initiating Agent to conduct simultaneous Sessions with N Responding Agents and propagate competitive context between threads, inducing competitive behavior without explicit coordination. The Competitive Pressure Signal (CPS) schema: { "active_threads": integer, "thread_stage_distribution": { "OFFERED": integer, "COUNTERED": integer, "RESOLVED": integer }, "best_offer_percentile": integer (0-100), "urgency_signal": "LOW|MEDIUM|HIGH|CRITICAL" } CPS values MUST be computed from actual Thread state at message send time. Fabricated CPS values constitute a protocol violation. When any Thread reaches RESOLVED state, the Initiating Agent Orchestrator MUST immediately send WITHDRAW to all remaining active Threads with reason_code BETTER_OFFER_ACCEPTED and winning_session_id populated. 9. Intent Encoding Before a Session is created, the Initiating Agent's demand is encoded as an Intent Vector by the Intent Builder component. The Intent Vector is domain-specific. For COMMERCE: { "intent_id": UUID v4, "consumer_agent_id": eSIM number, "category": string, "budget_max_cents": integer, "quantity": integer, "urgency": "NOW|TODAY|THIS_WEEK|FLEXIBLE", "location_radius_km": float, "ttl_seconds": integer } An Intent Vector is valid for ttl_seconds from creation. If it expires before any Thread reaches RESOLVED, all active Threads are terminated with WITHDRAW (reason: INTENT_EXPIRED). 10. Context Layer The Context Layer assembles a real-time situational snapshot for both agents before and during each Session. It is distinct from the Intent Vector (what the initiator wants) and the Loopback Record (what happened in past sessions). The Context Snapshot captures what is true at this moment: inventory levels, financial position, competitive pricing, relationship history, and demand signals. Context is assembled at Session init (full snapshot, immutable for Session duration) and optionally refreshed mid-Session for volatile fields (inventory, competitor pricing, financial balance) for Sessions lasting longer than 60 seconds. CAIA context includes: consumer purchase history, price sensitivity scores, Plaid financial position, market category pricing, prior session outcomes, urgency decay factor, and active LoRA adapter version. MAIA context includes: SKU inventory position, floor price, maximum discount authority, demand signals (time-of-day, seasonal), competitive peer pricing percentile, and consumer segment classification for this principal. CAIA context fields containing consumer financial data (balance, raw price sensitivity) MUST NOT be transmitted to the MAIA. MAIA context fields containing floor_price_cents and max_discount_pct are internal to the MAIA and MUST NOT be transmitted to the CAIA. 11. Feedback Layer The Feedback Layer writes every negotiation decision back to the agent's master data on both sides. It operates in two modes: real- time Decision Event capture during the Session, and asynchronous Master Record update after termination. Every agent action generates a Decision Event capturing: Session ID, Round, action taken, context snapshot ID, and key context signals at decision time (CPS urgency, rounds remaining, price gap percentage, inventory pressure). Decision Events are immutable once written. The CAIA Master Record and MAIA Master Record are persistent, evolving profiles updated after every Session. CAIA Master Record fields include: lifetime negotiation statistics, category-level price sensitivity scores, per-merchant relationship scores, and strategy profile (opening aggressiveness, concession rate, CPS sensitivity, walk-away threshold). MAIA Master Record fields include: negotiation statistics, demand elasticity model per category, consumer segment performance models, competitive loss rate by CPS urgency level, and strategy profile (counter aggression, discount curve, CPS response multiplier). Master Record updates are committed within 30 seconds of Session termination. For Edge Compute nodes in offline mode, Feedback updates are deferred and applied on reconnect using session_id as the deduplication key. The Feedback Layer and Loopback Pipeline are architecturally parallel: Loopback trains LLM weights; Feedback updates structured master data that feeds the Context Layer. Both tracks compound on every Session. 12. Loopback Learning Pipeline Every terminated Session generates a Loopback Record containing the full message history, terminal state, final agreed terms (if RESOLVED), CPS values at each round, LLM model used for each action, and optional post-session consumer satisfaction signal. Stage 1 (SFT): Loopback Records from RESOLVED Sessions are converted to (context, action) supervised fine-tuning pairs. Stage 2 (DPO): Sessions with contrasting outcomes (RESOLVED vs REJECTED_TERMINAL for similar Intent Vectors) form preference pairs for Direct Preference Optimization. Stage 3 (LoRA): Trained weight updates are packaged as Low-Rank Adaptation adapters applied at inference time. New adapters require >= 2% acceptance rate improvement on a held-out evaluation set before deployment. 13. LLM Routing The CAIA Orchestrator dynamically selects the LLM provider for each inference call based on task complexity, latency budget (constrained by CPS urgency_signal), cost envelope, and provider availability. The custom fine-tuned model is the primary path for standard OFFER generation (< 200ms target). Commercial models (Kimi, DeepSeek, Claude) handle complex multi-variable counter analysis. 14. Edge Compute and Offline Operation Edge Compute Nodes host a quantized local model (INT8 or INT4) capable of generating valid RNP messages, maintain a local Session state cache, and implement a 15-second heartbeat protocol to detect connectivity loss. RNP message transport follows a priority-ordered resilient stack: WiFi/LTE (primary) -> Cellular fallback -> Voice channel encoding -> SMS encoding. All RNP message content is channel-agnostic; the same envelope is encoded for any channel. 15. B2B Platform Integration RNP is designed for embedding into existing enterprise platforms as an AI negotiation layer. The integration model is consistent: the platform's data model becomes the Context Layer source, the platform's agents become Session participants, and the Feedback Layer writes back to the platform's record system. Rizz Wireless licenses RNP as an embeddable SDK. Training data does not leave the enterprise's cloud boundary. 15.1. SAP Integration Profile Primary domains: PROCUREMENT (SAP Ariba), LOGISTICS (SAP TM), TASK_ALLOCATION (SAP Project Systems), PRIORITY_QUEUE (SAP PPM). Agent mapping: SAP Joule as CAIA-role buyer agent; Vendor Portal Agent as MAIA-role seller agent. Context sources: SAP S/4HANA, SAP Ariba vendor master, SAP BW/4HANA demand forecasts. Feedback write- back: vendor scorecard, Business Partner master data, contract repository. Integration: RNP SDK embedded in SAP BTP as sidecar service with REST bridge to SAP standard interfaces. 15.2. Salesforce Integration Profile Primary domains: COMMERCE (Revenue Cloud), SLA_NEGOTIATION (Service Cloud), TASK_ALLOCATION (case routing), REWARDS (Loyalty Cloud). Agent mapping: Salesforce Agentforce buyer/service agent as CAIA role; internal capacity agent as MAIA role. Context sources: Salesforce CRM, Data Cloud unified consumer profile, MuleSoft ERP feeds. Feedback write-back: Account record, Opportunity stage, Contract object, Loyalty points balance. Integration: RNP SDK as AppExchange managed package; native Agentforce Action and Flow triggers. 15.3. Atlassian/Jira Integration Profile Primary domains: TASK_ALLOCATION (Jira Software), PRIORITY_QUEUE (backlog grooming), SLA_NEGOTIATION (Jira Service Management). Agent mapping: Product Owner/Scrum Master agent as CAIA role; engineering team capacity agent as MAIA role. Context sources: Jira backlog, sprint velocity, team capacity, Confluence docs. Feedback write- back: sprint assignment, story point allocation, epic priority order, team capacity record. Integration: RNP SDK as Atlassian Forge app; Jira REST API v3 and Forge custom UI. 16. Security Considerations Replay Attack Prevention: all messages carry timestamp_utc. Messages timestamped more than 60 seconds before receiver clock MUST be rejected. Session Layer MUST maintain a message hash log and reject duplicate (session_id, round, message_type, sender_agent_id) tuples. CPS Integrity: CPS fields are populated exclusively by the Initiating Agent Orchestrator and covered by the sender's signature. Any Responding Agent that alters CPS fields is committing protocol fraud. Price/Parameter Manipulation: the Session Layer MUST validate domain_params against authoritative data at session time. Parameters the Responding Agent cannot honor MUST be rejected with reason_code POLICY. Identity Spoofing: agent private keys are stored in hardware-backed secure enclaves. Assuming another agent's identity requires physical access to the principal's device. Denial of Service: maximum session duration is bounded (R_max * validity_seconds). The Session Layer enforces TTL and purges expired sessions automatically. 17. IANA Considerations This document requests IANA to consider registration of the following: o A new registry 'RNP Negotiation Domains' containing the domain identifiers defined in Section 2.1, with a registration policy of Specification Required. o A new media type 'application/rnp+json' for RNP message payloads. This document has no other IANA actions pending at this time. 18. Normative References [RFC2119] Bradner, S., 'Key words for use in RFCs to Indicate Requirement Levels', BCP 14, RFC 2119, March 1997. [RFC4122] Leach, P., Mealling, M., and R. Salz, 'A Universally Unique IDentifier (UUID) URN Namespace', RFC 4122, July 2005. [RFC8259] Bray, T., Ed., 'The JavaScript Object Notation (JSON) Data Interchange Format', RFC 8259, December 2017. [RFC7517] Jones, M., 'JSON Web Key (JWK)', RFC 7517, May 2015. 19. Authors' Addresses Harveer Singh Co-Founder & CIO Rizz Wireless Inc. United States Email: harveer@rizzwireless.com Ganpatsingh Rajput Co-Founder Rizz Wireless Inc. United States Email: gsr@rizzwireless.com ------------------------------------------------------------------------ Harveer Singh & Ganpatsingh Rajput Internet-Draft [Page 1]