Relationship to KERI Ecosystem

ToIP serves as the primary standardization body for KERI-related specifications. The KERI protocol suite, including ACDC and CESR, transitioned from earlier governance at the Decentralized Identity Foundation (DIF) and IETF draft status to ToIP governance. This transition reflects ToIP's comprehensive approach to both technical and governance aspects of decentralized identity.

KERI Specifications Under ToIP:

• KERI Protocol Specification: Key Event Receipt Infrastructure core protocol
• ACDC Specification: Authentic Chained Data Container credential format
• CESR Specification: Composable Event Streaming Representation encoding
• OOBI Specification: Out-Of-Band Introduction discovery protocol
• IPEX Specification: Issuance and Presentation Exchange protocol
• did:webs Method: DID method leveraging KERI and web infrastructure

GLEIF Integration

The Global Legal Entity Identifier Foundation (GLEIF) operates its vLEI (verifiable Legal Entity Identifier) Ecosystem under governance frameworks that reference and build upon ToIP specifications. GLEIF's vLEI Ecosystem Governance Framework explicitly adopts ToIP's four-layer model and references ToIP technical specifications as normative requirements.

ToIP-GLEIF Relationship:

• GLEIF vLEI credentials are implemented as ACDCs (ToIP specification)
• vLEI infrastructure uses KERI protocol (ToIP specification)
• GLEIF governance frameworks cite ToIP specifications as technical requirements
• GLEIF participates in ToIP working groups and specification development

Roles & Responsibilities

Primary Mission

ToIP's fundamental responsibility is defining the complete architecture for Internet-scale digital trust. This encompasses both technical protocols and governance frameworks, recognizing that sustainable digital trust requires addressing human, legal, and business concerns alongside cryptographic security.

Technical Standardization

Specification Development: ToIP develops and maintains technical specifications through its Technical Stack Working Group. These specifications undergo community review, implementation testing, and formal approval processes before publication. The foundation maintains version control, manages intellectual property through contributor agreements, and ensures specifications remain open and freely implementable.

Key Technical Responsibilities:

• Maintain normative specifications for KERI protocol suite
• Define interoperability requirements across implementations
• Establish cryptographic algorithm requirements and security parameters
• Provide reference implementations and test suites
• Manage specification versioning and backward compatibility policies

Governance Framework Development

ToIP recognizes that technical protocols alone are insufficient for establishing trust at scale. The foundation develops governance frameworks that address:

Governance Stack Layers:

1. Layer 1 - Utility Governance: Governance of underlying infrastructure (witnesses, watchers, registries)
2. Layer 2 - Provider Governance: Governance of credential issuers and verifiers
3. Layer 3 - Credential Governance: Governance of specific credential types and schemas
4. Layer 4 - Ecosystem Governance: Governance of complete trust ecosystems

Governance Responsibilities:

• Define governance framework templates and patterns
• Establish best practices for trust assurance
• Provide guidance on legal and regulatory compliance
• Support ecosystem-specific governance development

Community Coordination

ToIP serves as a neutral convening body bringing together diverse stakeholders including technology vendors, enterprises, government agencies, standards bodies, and academic institutions. The foundation facilitates collaboration through:

Community Activities:

• Regular working group meetings (bi-weekly for most groups)
• Annual member meetings and technical symposia
• Public comment periods for draft specifications
• Interoperability testing events
• Educational webinars and documentation

Intellectual Property Management

ToIP manages intellectual property through the Open Web Foundation Agreement (OWFa) and related contributor agreements. This ensures that:

IP Protections:

• Specifications remain freely implementable without patent encumbrances
• Contributors grant necessary patent licenses for implementation
• Copyright is managed to enable broad adoption
• Trademark protection for ToIP branding and certification marks

Authority and Permissions

Specification Authority

ToIP specifications carry normative authority within the ToIP ecosystem. Organizations implementing ToIP-compliant systems reference these specifications as authoritative requirements. However, ToIP does not have regulatory authority—compliance is voluntary unless required by specific ecosystem governance frameworks (such as GLEIF's vLEI requirements).

Specification Status Levels:

• Draft: Under active development, subject to change
• Approved: Completed community review, stable for implementation
• Deprecated: Superseded by newer versions, maintained for backward compatibility

Governance Framework Authority

ToIP governance frameworks serve as templates and guidance rather than binding regulations. Individual ecosystems (like GLEIF's vLEI) adopt and adapt ToIP frameworks to their specific needs. ToIP provides:

Governance Guidance:

• Recommended governance structures
• Best practice policies
• Risk assessment frameworks
• Compliance verification approaches

Ecosystems retain authority to modify frameworks for their specific requirements while maintaining ToIP compatibility.

Certification and Compliance

ToIP does not currently operate a formal certification program. Compliance claims are self-asserted by implementers, though the foundation provides:

Compliance Support:

• Test suites for specification conformance
• Interoperability testing frameworks
• Reference implementations
• Compliance checklists

Future certification programs may be developed as the ecosystem matures.

Limitations

Regulatory Boundaries

ToIP is not a regulatory body and cannot enforce compliance. The foundation develops voluntary standards and frameworks. Regulatory authority remains with government agencies and industry regulators. ToIP specifications may be referenced by regulations but do not themselves carry legal force.

Implementation Neutrality

ToIP maintains implementation neutrality, meaning specifications define requirements without mandating specific implementation approaches. Multiple implementations in different programming languages and architectures are encouraged, provided they meet specification requirements.

Ecosystem Autonomy

While ToIP provides foundational specifications and governance frameworks, individual ecosystems retain autonomy over their specific implementations and governance decisions. ToIP does not control how ecosystems apply its specifications or govern their operations.

Related Governance Documents

ToIP Core Specifications

Technical Stack Specifications:

• KERI Specification: trustoverip.github.io/tswg-keri-specification/
• ACDC Specification: trustoverip.github.io/tswg-acdc-specification/
• CESR Specification: trustoverip.github.io/tswg-cesr-specification/
• OOBI Specification: (in development under TSWG)
• IPEX Specification: (in development under TSWG)
• did:webs Method Specification: trustoverip.github.io/tswg-did-method-webs-specification/

Governance Framework Documents

ToIP Governance Stack:

• ToIP Governance Architecture Specification: Defines four-layer governance model
• ToIP Governance Metamodel: Structural model for creating governance frameworks
• ToIP Design Principles: Foundational principles for ToIP stack

Integration with GLEIF vLEI

vLEI Governance Framework References:

• vLEI Ecosystem Governance Framework v3.0: Primary governance document referencing ToIP specifications
• Technical Requirements Part 1 - KERI Infrastructure: Normative requirements based on ToIP KERI specification
• Technical Requirements Part 2 - vLEI Credentials: ACDC implementation requirements
• Credential-Specific Governance Frameworks: QVI, Legal Entity, OOR, and ECR credential frameworks

Contributor Agreements

Intellectual Property Documents:

• Open Web Foundation Agreement (OWFa) 1.0: Patent and copyright licensing for specifications
• Contributor License Agreement (CLA): Individual and corporate contributor agreements
• Source Code Licenses: Apache 2.0 for reference implementations

ToIP Four-Layer Architecture

Layer 1: Utility Layer

Provides the foundational infrastructure for decentralized key management and verifiable data registries. In KERI context, this includes:

Layer 1 Components:

• Witnesses: Provide key event receipting and availability
• Watchers: Monitor for duplicity and maintain KEL copies
• Registries: Transaction Event Logs (TELs) for credential status
• Discovery Infrastructure: OOBI endpoints and resolution mechanisms

Layer 2: Provider Layer

Defines how credential issuers and verifiers operate within the trust framework:

Layer 2 Functions:

• Issuer Operations: Credential creation, signing, and registry management
• Verifier Operations: Credential verification and policy enforcement
• Agent Services: Cloud agents (KERIA) and client agents (Signify)

Layer 3: Credential Layer

Specifies credential formats, schemas, and exchange protocols:

Layer 3 Specifications:

• ACDC Format: Authentic Chained Data Container structure
• Schema Definitions: JSON Schema for credential types
• IPEX Protocol: Issuance and presentation exchange workflows
• Graduated Disclosure: Compact, partial, selective, and full disclosure mechanisms

Layer 4: Application Layer

Where end users interact with trust applications and make trust decisions:

Layer 4 Characteristics:

• User Experience: Wallets, browsers, and application interfaces
• Trust Task Protocols: Application-specific workflows
• Trust Decisions: User-driven verification and acceptance

ToIP Design Goals and Principles

Security Prioritization

ToIP explicitly prioritizes security properties in the following order:

Priority Order:

1. Authenticity: Cryptographic proof of origin and integrity (highest priority)
2. Confidentiality: Protection of content from unauthorized access
3. Privacy: Protection of metadata and correlation (optimized within constraints)

This prioritization reflects the PAC Theorem (Privacy, Authenticity, Confidentiality) which states that systems can achieve any two properties at the highest level but not all three simultaneously.

End-Verifiability

ToIP specifications emphasize end-verifiability—the ability for any party to cryptographically verify claims without relying on trusted intermediaries. This principle drives:

End-Verifiability Requirements:

• Self-certifying identifiers (KERI AIDs)
• Cryptographically verifiable data structures (KELs, ACDCs)
• Ambient verifiability (any-data, any-where, any-time, by any-body)
• Zero-trust architecture (never trust, always verify)

Interoperability

ToIP specifications are designed for universal interoperability across:

Interoperability Dimensions:

• Platform Independence: No dependency on specific blockchains or ledgers
• Implementation Diversity: Multiple language implementations (Python, Rust, TypeScript, etc.)
• Protocol Composability: Specifications work together as coherent suite
• Governance Flexibility: Frameworks adaptable to diverse ecosystems

Relationship to Other Standards Bodies

W3C (World Wide Web Consortium)

ToIP specifications complement W3C standards, particularly:

W3C Integration:

• Verifiable Credentials: ACDC extends W3C VC data model
• DIDs: did:webs and did:keri methods implement W3C DID specification
• JSON-LD: ACDC supports JSON-LD contexts for semantic interoperability

IETF (Internet Engineering Task Force)

KERI specifications originated as IETF drafts before transitioning to ToIP. The relationship continues through:

IETF Coordination:

• KERI specifications reference IETF RFCs (cryptographic algorithms, protocols)
• Potential future submission of mature ToIP specifications to IETF
• Alignment with internet architecture principles

ISO (International Organization for Standardization)

ToIP specifications reference ISO standards, particularly:

ISO Integration:

• ISO 17442: Legal Entity Identifier (LEI) standard used in vLEI
• ISO 20000: Service management referenced in vLEI governance
• ISO 27001: Information security management for credential issuers

Community Participation

Membership Structure

ToIP operates under Linux Foundation membership models:

Membership Tiers:

• Steering Members: Strategic governance and funding
• General Members: Participation in working groups
• Contributor Members: Individual technical contributors

Working Group Participation

Working groups are open to all members and operate transparently:

Participation Model:

• Open Meetings: Regular public meetings with published agendas
• Mailing Lists: Public discussion forums
• GitHub Repositories: Open source development and issue tracking
• Specification Reviews: Public comment periods for draft specifications

Getting Involved

Organizations and individuals can engage with ToIP through:

Engagement Pathways:

• Membership: Join as organizational or individual member
• Working Groups: Participate in specification development
• Implementation: Build ToIP-compliant systems and provide feedback
• Governance: Contribute to governance framework development
• Education: Attend webinars, conferences, and training sessions

Future Directions

Specification Maturity

ToIP continues evolving specifications toward greater maturity:

Development Roadmap:

• Transition specifications from Draft to Approved status
• Develop comprehensive test suites and conformance criteria
• Expand reference implementations across programming languages
• Establish formal certification programs

Ecosystem Growth

ToIP supports growth of trust ecosystems beyond vLEI:

Ecosystem Development:

• Supply chain traceability and provenance
• Healthcare credential exchange
• Educational credentials and transcripts
• Government identity and authorization
• Financial services and regulatory compliance

Governance Evolution

Governance frameworks continue maturing:

Governance Priorities:

• Refined governance metamodels and templates
• Legal and regulatory compliance guidance
• Risk assessment and audit frameworks
• Cross-ecosystem interoperability governance

Conclusion

The Trust over IP Foundation serves as the primary standardization and governance body for KERI-based decentralized identity infrastructure. Through its four-layer architecture combining technical specifications and governance frameworks, ToIP provides the foundation for Internet-scale digital trust. The foundation's work enables ecosystems like GLEIF's vLEI to implement production-grade verifiable credential systems while maintaining interoperability, security, and governance best practices. As the KERI ecosystem matures, ToIP's role in coordinating specification development, fostering community collaboration, and ensuring intellectual property protection becomes increasingly critical to the success of decentralized identity infrastructure globally.

Integration Patterns

With Existing Systems

Legacy Integration:

• Use ToIP specifications as overlay on existing infrastructure
• Implement KERI witnesses and watchers alongside traditional PKI
• Migrate credentials to ACDC format incrementally
• Maintain interoperability with non-ToIP systems during transition

With Other Standards

Standards Coordination:

• Map ToIP concepts to W3C VC terminology
• Implement did:webs for web-based DID resolution
• Use ISO standards for organizational identity (LEI)
• Align with NIST identity assurance levels