| Internet-Draft | The Cosmos Protocol Specification (Trust | January 2026 |
| Hernandez | Expires 5 July 2026 | [Page] |
The Cosmos Protocol (Trust-Native Semantic Protocol) defines a badge-based identity and communication system intended for deployments that prefer not to rely on external consensus or blockchain infrastructure. Cosmos supports trust-native communication and decentralized identity management through cryptographically signed badges that operate without mandatory external trust systems. The protocol also supports passwordless authentication flows using badge-based credentials and biometric authenticators, reducing reliance on traditional password mechanisms.¶
The Cosmos Protocol introduces several foundational innovations that together form an integrated identity-native communication substrate. These include: (1) Badge-Based Identity -- cryptographically signed, capability-bearing identifiers designed to operate without requiring blockchain or distributed ledger infrastructure, while allowing deployments to integrate such systems if desired; (2) Trust Scoring -- reputation-anchored trust models (domain-bound for DNS networks, star-bound for Cosmos-native networks) that enable cross-star capability granting and trust-based authorization without requiring new badges; (3) Lumen Encryption -- uses post-quantum candidate cryptographic primitives (see [RFC-XXXX-Lumen]), badge-native encryption designed to support forward secrecy; (4) Echo Grammar -- semantic message structures that provide intent clarity, UI hints, and agent compatibility; (5) Capsule System -- universal, encrypted containers for communication and storage; (6) Slipstream Transport (TNTP) -- a trust-native transport protocol with badge-based sessions, intent-aware routing, and the ability to operate without blockchain or external consensus dependencies; (7) Ramp and SDFF Serialization -- deterministic text and binary formats that provide canonical structure for all Cosmos data; (8) Profile System -- portable, domain-scoped user profiles with badge-based access control; and (9) Productivity Protocols -- standardized scheduling, contacts, and calendaring protocols (Comet, Nebula, Nova) that provide a badge-native model that can serve as an alternative to multiple legacy standards.¶
Cosmos badges are Ramp (Slope Data Format, SDF) documents with optional DID compatibility, allowing integration with existing decentralized identity systems while preserving the protocol's self-contained architecture within Cosmos deployments. The badge system addresses key limitations in current identity approaches, including the lack of enterprise-grade lifecycle management, star-bound trust establishment, and the ability to operate independently of external infrastructure in constrained or disconnected environments.¶
The protocol provides a viable alternative to complex identity stacks while maintaining interoperability with existing standards, making it suitable for both greenfield deployments and integration with existing systems.¶
This document is in draft status and represents a proposed standard for the Cosmos Protocol specification.¶
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 5 July 2026.¶
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 (https://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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This document specifies the Cosmos Protocol, a trust-native, badge-based identity and communication system designed for enterprise deployment without requiring blockchain or distributed ledger infrastructure. The protocol provides a viable alternative to existing decentralized identity solutions by combining identity management, trust scoring, encryption, and communication in a unified, self-contained system within Cosmos deployments.¶
This document does not obsolete or update any existing RFCs. It defines a new protocol specification intended for use in enterprise identity and communication systems, decentralized applications, and environments that can operate without external consensus or blockchain infrastructure.¶
Current decentralized identity and communication systems face fundamental limitations that prevent widespread adoption and practical deployment:¶
Infrastructure Dependencies: Most decentralized identity solutions require complex infrastructure dependencies including blockchain networks, distributed ledgers, or specialized consensus mechanisms. These dependencies create barriers to deployment, especially in constrained environments, enterprise settings, or scenarios requiring rapid deployment.¶
Trust Quantification Challenges: Existing systems lack effective mechanisms for quantifying trustworthiness between entities. Without reliable trust metrics, users cannot make informed decisions about communication partners, leading to either excessive caution or inappropriate trust.¶
Enterprise Integration Gaps: Current solutions often focus on individual identity management but fail to address enterprise requirements such as lifecycle management, organizational hierarchies, domain-based policies, and integration with existing infrastructure.¶
Communication Fragmentation: Identity and communication systems are typically separate, requiring complex integration work and creating security gaps between authentication and messaging.¶
Walled Garden Communication: Modern communication platforms create walled gardens where users on different platforms cannot communicate effectively. This forces users to rely on email systems for cross-platform communication, even when other chat and messaging solutions may be preferred. Users must maintain multiple accounts across different platforms, fragmenting their communication and social graph. Cross-platform interoperability is limited or non-existent, preventing users from choosing preferred communication tools while maintaining universal connectivity.¶
Profile Data Fragmentation and Lock-in: User profiles are fragmented across multiple platforms, each with its own data silo. Users must recreate their profiles on each platform, losing their social graph and content when switching providers. Profile data is locked into individual platforms with no portability, preventing users from migrating their profiles, content, and relationships. Users lack control over their profile data and privacy settings across platforms, leading to data silos and vendor lock-in.¶
Scalability Limitations: Many decentralized systems struggle with scalability, either requiring significant computational resources or failing to handle enterprise-scale deployments effectively.¶
Password-Based Authentication Weaknesses: Traditional password-based authentication systems suffer from fundamental security weaknesses including password reuse, weak passwords, password theft, phishing attacks, and the burden of password management. Users are forced to create, remember, and manage passwords across multiple services, leading to security vulnerabilities and poor user experience. Password-based systems also lack built-in identity verification and trust establishment mechanisms, requiring external trust systems.¶
The Cosmos Protocol addresses these challenges through a comprehensive badge-based identity and communication system that supports the following capabilities:¶
Infrastructure Independence: Cosmos can operate without blockchain, distributed ledgers, or external consensus mechanisms. The protocol is self-contained within Cosmos deployments and can be deployed in any environment, including constrained environments and enterprise data centers, without external consensus or blockchain infrastructure.¶
Star-bound Trust Scoring: A trust algorithm designed to reduce manipulation risks that quantifies trustworthiness using star reputation, network effects, and behavioral patterns, enabling informed trust decisions without centralized authorities.¶
Enterprise-ready Identity Management: Lifecycle management for badge issuance, renewal, revocation, and organizational hierarchies, designed for enterprise deployment scenarios.¶
Productivity Protocols: Integrated scheduling, contacts, and calendar protocols (Comet, Nebula, Nova) that interoperate with the badge-based identity system, reducing security gaps between authentication and communication.¶
Cross-Provider Interoperability: Interlink enables cross-provider interoperability for participating platforms. Users can communicate seamlessly across different providers while each provider maintains their unique features and user experience. This enables users to use preferred chat and messaging solutions for cross-platform communication while maintaining connectivity across participating platforms. Users maintain a single identity and social graph that works across participating providers.¶
Profile System: The Cosmos Profile System is designed to support portability across participating providers, subject to provider implementation and policy. Cosmos reduces fragmentation by defining a consistent profile format with domain-scoped data spaces. Users maintain a single canonical profile that functions across participating providers, reducing duplication and data silos. Domain spaces allow each service to store its own data within the user's profile, while users retain full control over privacy settings and migration. Users may migrate their profiles, content, and social graph between participating providers without data loss, subject to provider support. Profiles are private by default and require explicit user action to make public, ensuring user-controlled visibility.¶
Scalability: The architecture is intended to support deployments ranging from small installations to large multi-service environments, with design considerations for maintaining performance and security across varying scales.¶
Passwordless Authentication: Cosmos authentication flows are designed to minimize password usage by supporting badge-based credentials and FIDO2/Passkey-compliant biometric authenticators. Badge-based authentication reduces reliance on passwords and mitigates common password-related vulnerabilities such as password reuse, weak passwords, password theft, and phishing attacks. Badge-based authentication also provides built-in identity verification and trust establishment within Cosmos deployments without requiring external trust systems.¶
DIDs [W3C-DID] provide a flexible decentralized identity model. Cosmos focuses on a different deployment profile by emphasizing self-contained operation and integrated trust scoring. The following differences highlight Cosmos's approach:¶
Infrastructure Complexity: DIDs require complex resolver infrastructure, method-specific implementations, and often depend on blockchain or distributed ledger technology. This creates deployment barriers and operational complexity that Cosmos avoids through its self-contained design within Cosmos deployments.¶
Trust Quantification Gap: DIDs provide cryptographic verification but lack built-in trust scoring mechanisms. Cosmos includes star-bound trust scoring that supports informed decisions about communication partners without relying on external trust systems.¶
Enterprise Lifecycle Management: DIDs focus on individual identity but do not provide enterprise features such as organizational hierarchies, star-based policies, or integrated lifecycle management, which Cosmos is designed to support.¶
Communication Integration: DIDs are primarily identity-focused and require separate integration with communication systems. Cosmos provides unified identity and communication protocols, reducing integration complexity and security gaps between identity and communication systems.¶
Deployment Flexibility: DIDs often require specific infrastructure choices (blockchain, resolver networks) that limit deployment options. Cosmos can be deployed in any environment without infrastructure dependencies.¶
Badge-DID Compatibility: Cosmos badges are Ramp (Slope Data Format, SDF) [RFC-XXXX-Ramp] documents with optional DID [W3C-DID] compatibility, allowing integration with existing decentralized identity systems while preserving the protocol's self-contained architecture within Cosmos deployments. This enables Cosmos deployments to interoperate with DID ecosystems without depending on external DID infrastructure.¶
The Cosmos approach provides an integrated, enterprise-oriented solution that addresses practical deployment needs while maintaining interoperability with existing decentralized identity standards.¶
LDAP [RFC4511] and Active Directory provide mature directory services. Cosmos targets scenarios that require integrated trust scoring, badge-based authentication, and unified communication semantics. The following differences highlight Cosmos's approach:¶
Password-Based Authentication: All LDAP implementations (including Active Directory, OpenLDAP, 389 Directory Server, Apache Directory Server, FreeIPA, eDirectory, and other LDAP-based directory services) rely on password-based authentication, which is vulnerable to password reuse, weak passwords, password theft, and phishing attacks. Cosmos uses badge-based authentication with FIDO2/Passkey-compliant biometric authentication, eliminating the need for passwords within standard Cosmos authentication flows and providing cryptographic proof of identity.¶
Centralized Architecture: LDAP and Active Directory are centralized systems with single points of failure, domain controller dependencies, and global catalog bottlenecks. Cosmos supports distributed, edge-based deployment models that reduce single-point-of-failure risks, enabling global distribution and automatic scaling.¶
Trust Establishment Gap: LDAP and Active Directory lack effective mechanisms for establishing and quantifying trust between entities. Cosmos includes star-bound trust scoring that enables informed decisions about communication partners without requiring external trust systems.¶
Communication Integration: LDAP and Active Directory are primarily identity/directory-focused and require separate integration with communication systems. Cosmos provides unified identity and communication protocols, reducing integration complexity and security gaps between authentication and messaging systems.¶
Directory Scope Limitation: LDAP is purely a directory query protocol for hierarchical data structures. Cosmos is an integrated identity and communication protocol that includes directory-like query capabilities (Manifest) as one component of a broader system that integrates identity, trust, encryption, messaging, and productivity protocols into a unified, badge-native system.¶
Key Advantages: Cosmos provides passwordless authentication, trust-based access control, integrated communication, distributed architecture, cryptographic verification, cross-star federation, intended post-quantum resistance, platform-agnostic enforcement, and real-time policy updates. Cosmos implementations can integrate with existing LDAP/Active Directory infrastructure through adapter layers, enabling gradual migration.¶
This specification defines the full Cosmos Protocol, including:¶
The protocol is applicable to:¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document defines the following key terms:¶
Protocol Name vs. Brand Name:¶
The relationship between "TNSP" (Trust-Native Semantic Protocol) and "Cosmos" follows the same pattern as IEEE 802.11 and WiFi, or IEEE 802.15.1 and Bluetooth:¶
Usage Guidelines:¶
Implementation Note: Protocol versioning and evolution rules, including deprecation lifecycle, version compatibility, and version negotiation procedures, are defined in [RFC-XXXX-Protocol-Versioning]. This document provides only a high-level overview of the Cosmos Protocol primitives.¶
The Cosmos Protocol is built on five fundamental principles:¶
Infrastructure Independence: The protocol operates without requiring blockchain, distributed ledgers, or external consensus mechanisms, enabling deployment in any environment without external consensus or blockchain infrastructure.¶
Star-bound Trust: Trust is established and managed at the star (domain) level through accretion relationships, providing natural organizational boundaries and policy enforcement.¶
Badge-centric Identity: All identity, capability, and trust information is contained within cryptographically signed badges that are self-contained and verifiable.¶
Federated Communication: Identity and communication systems are integrated, enabling cross-provider interoperability for participating platforms while maintaining security and reducing integration complexity.¶
Enterprise Readiness: The protocol is designed for enterprise-scale deployment with comprehensive lifecycle management and organizational support.¶
The Cosmos Protocol consists of several integrated components:¶
Implementation Scope Note: While the protocol defines all components, different entities implement different parts based on their role:¶
All components work together to provide an integrated identity and communication system:¶
The Cosmos Protocol provides trust-native, identity-aware networking that can operate over existing TCP/IP infrastructure or without IP infrastructure (see Deployment Phases). Cosmos can operate in environments where TCP/IP infrastructure is available and can also operate without IP infrastructure for scenarios that can operate without external consensus or blockchain infrastructure (see Phase 4: Independent Operation).¶
These components operate as functional alternatives within Cosmos-native deployments; they do not require or mandate replacement of existing Internet protocols.¶
Cosmos provides alternative protocols that correspond to layers of the TCP/IP network stack:¶
Layer 1-2 (Physical/Data Link): Cosmos retains existing physical and data link layers (Ethernet, WiFi, Fiber, MAC addressing). These layers remain unchanged as they provide fundamental hardware communication.¶
Layer 3 (Network): Cosmos provides the Trust-Native Semantic Protocol (TNSP) as an alternative to IP. Capsules serve as the fundamental unit of TNSP, analogous to IP packets at the network layer. They operate at the application/identity layer with built-in trust, identity, and semantics. In Phase 4 deployments, Badge IDs provide network-layer addressing as an alternative to IP addresses, and intent-based routing (defined in TNSP and service discovery protocols) provides an alternative to IP routing.¶
Layer 4 (Transport): Cosmos provides Slipstream (Trust-Native Transport Protocol, TNTP) [RFC-XXXX-Slipstream] as an alternative to TCP/UDP. Slipstream provides badge-based sessions, trust-aware flow control, and the ability to operate without external consensus or blockchain infrastructure.¶
Layer 5+ (Application): Cosmos provides Manifest federation as an identity-native alternative to DNS within Cosmos-native deployments (see Deployment Phases). DNS is still used for bootstrap Manifest discovery in early deployment phases. BEAP (Badge-Enabled API Protocol) [RFC-XXXX-BEAP] with Echo Grammar provides an application protocol model for identity-addressed operations, badge-based authentication, and intent-aware routing, serving the role that HTTP/HTTPS plays in traditional web architectures. Echo Grammar provides structured, semantic message formats in place of HTTP's unstructured payloads. Badge IDs serve as identity anchors analogous to domain names, but with cryptographic trust semantics.¶
Implementation Note: The complete Slipstream (Trust-Native Transport Protocol, TNTP) specification is defined in [RFC-XXXX-Slipstream]. Slipstream is the recommended transport protocol for Cosmos deployments and can operate both independently of IP (Layer 2 mode) and over IP networks (via UDP/TCP encapsulation). Slipstream does not require blockchain or external consensus dependencies, but may require Manifest for badge validation in Cosmos deployments (see [RFC-XXXX-Slipstream] for standalone operation details).¶
Cosmos can be deployed in phases, from operation over TCP/IP infrastructure to independent operation:¶
Phase 1 (TCP/IP Infrastructure): Cosmos runs on TCP/IP infrastructure. Slipstream (TNTP) is the recommended transport protocol and can operate over IP networks via UDP/TCP encapsulation. DNS is used for bootstrap Manifest discovery. This enables immediate deployment without requiring infrastructure changes.¶
Phase 2 (Application Layer Alternatives): Manifest federation provides an identity-native alternative to DNS resolution within the Cosmos substrate. BEAP (Badge-Enabled API Protocol) [RFC-XXXX-BEAP] with Echo Grammar provides an application protocol model for identity-addressed operations and structured messaging, serving the role that HTTP/HTTPS plays in traditional web architectures. Capsules provide a structured, semantic alternative to HTTP content formats. Slipstream (TNTP) operates over existing IP networks via UDP/TCP encapsulation, and Cosmos continues to use IP for the network layer during this phase.¶
Phase 3 (Transport Layer Alternatives): Slipstream (Trust-Native Transport Protocol, TNTP) [RFC-XXXX-Slipstream] provides an alternative to TCP/UDP, providing badge-based sessions. Cosmos continues to use IP for network layer.¶
Phase 4 (Independent Operation): TNSP provides an alternative to IP at the network layer. In Phase 4 deployments, Badge IDs provide an alternative to IP addresses (see [RFC-XXXX-Badge] for Badge ID structure and routing properties), and intent-based routing (defined in TNSP and service discovery protocols) provides an alternative to IP routing. Slipstream (Trust-Native Transport Protocol, TNTP) operates directly over Layer 2 (Ethernet frames) or via TNSP capsules. This enables deployment without external consensus or blockchain infrastructure, including environments where IP infrastructure is not available or desired. Phase 4 deployments still require Manifest for badge validation and trust establishment (see [RFC-XXXX-Manifest]).¶
Cosmos implementations MUST use the Badge System as specified in [RFC-XXXX-Badge] for all identity, capability, and trust management operations. Badges are cryptographically signed Ramp (Slope Data Format, SDF) [RFC-XXXX-Ramp] documents that serve as identity, capability, and trust containers without requiring blockchain or external infrastructure.¶
Implementation Note: The complete Badge System specification, including detailed badge structure, badge types, lifecycle management, DID compatibility, group badges, and security considerations, is defined in [RFC-XXXX-Badge]. This document specifies only the requirement to use badges and the integration points with the Cosmos Protocol.¶
Each star participates in the Cosmos Protocol through its Manifest service, which acts as the star's authority for badge issuance, validation, and policy distribution. Deployment models, availability strategies, and operational requirements for Manifest are defined in [RFC-XXXX-Manifest].¶
Note: Detailed specifications for cross-domain registry hosting, including hosting relationships, federated service model, termination requirements, and high availability requirements, are defined in [RFC-XXXX-Manifest]. This document provides only a high-level overview of Manifest's role in the Cosmos Protocol.¶
The Policy Substrate is a network-wide governance layer that defines and enforces policies across all Cosmos components. Unlike traditional policy systems that are component-specific, the Policy Substrate provides a unified governance model for Cosmos deployments where implemented (see [RFC-XXXX-Manifest] for Policy Substrate requirements and deployment models), covering access control, compliance, security, data management, and system configuration.¶
Implementation Note: Detailed Policy Substrate specifications, including policy categories, network-wide enforcement mechanisms, compliance policies, security policies, data management policies, and Access Control Grammar, are defined in [RFC-XXXX-Manifest] (see Section 9). This document provides only a high-level overview of the Policy Substrate's role in the Cosmos Protocol.¶
The Cosmos Protocol's security properties derive from cryptographic badge signatures, post-quantum encryption (Lumen; see [RFC-XXXX-Lumen]), domain-bound trust scoring, and the ability to operate without blockchain or external consensus dependencies. Cosmos provides confidentiality through post-quantum candidate primitives (see [RFC-XXXX-Lumen] for algorithm details and security considerations), integrity through cryptographic signatures, authentication through badge-based verification, authorization through badge capabilities and trust scores, and non-repudiation through cryptographically signed operations that include timestamp fields defined in the Badge specification (see [RFC-XXXX-Badge] for signature structure and validation requirements), subject to the security properties of the underlying algorithms.¶
Key security considerations include: identity spoofing prevention through cryptographic verification, trust manipulation resistance through algorithms designed to reduce manipulation risks, communication interception protection through post-quantum candidate primitives (see [RFC-XXXX-Lumen]), and cross-domain security through domain-bound policies and cryptographic isolation.¶
Implementation Note: Detailed security considerations, including threat models, attack resistance analysis, privacy protection mechanisms, single-point-of-failure analysis, and implementation security requirements, are defined in component RFCs. See [RFC-XXXX-Badge] for badge security, [RFC-XXXX-Manifest] for Manifest security requirements and SPOF mitigation, [RFC-XXXX-Lumen] for encryption security, and [RFC-XXXX-Slipstream] for transport security. This document provides only a high-level overview of the Cosmos Protocol's security properties.¶
This document defines the Cosmos Protocol specification and uses existing DNS record types (TXT, SRV, CNAME). The protocol defines transport-agnostic requirements and internal data structures and algorithms that do not require IANA registration. This document defines no new IANA registries. Transport protocols such as Slipstream define their own IANA considerations in separate documents.¶
Badge types, trust levels, capabilities, and other protocol-internal elements are defined within this specification and do not require separate IANA registries. Service discovery uses existing SRV record types. Domain authority declaration uses existing TXT record types.¶
A separate specification document defines the COSMOS DNS record type, which will require IANA registration. That specification contains the necessary IANA considerations for the new DNS record type.¶
This document has no IANA actions.¶
The authors would like to thank the contributors to the Cosmos Protocol specification and the broader decentralized identity community for their insights and feedback.¶