W4GEO.org
W4GEO-RFC-001· DEVELOPMENT ROADMAP

W4GEO Development Roadmap

A complete path from open specification to interoperable global trust infrastructure for the Internet of Agents.

Protocol version: Draft 3.0
Reference implementation: Partial
Production adoption: Initial
§ 1

1.Overview

This roadmap organizes the development of the entire W4GEO architecture: protocol, specifications, schemas, reference implementation, tooling, testing, security, governance, validators, federation, adoption and maintenance.

The roadmap describes development stages, not reductions in scope. Every architectural layer remains part of the W4GEO vision.

§ 2

2.Current Priorities

Based on the real state of the repository right now — no percentages or dates.

  1. 1Consolidate the complete architecture
  2. 2Update the public site
  3. 3Formalize the discovery document
  4. 4Publish the first JSON Schemas
  5. 5Specify cryptographic identity (rotation and multiple keys)
  6. 6Specify Agent Identity
  7. 7Specify Delegation
  8. 8Specify Revocation
  9. 9Structure the Evidence Registry
  10. 10Create initial conformance tests
§ 3

3.Parallel Tracks

Development is not strictly sequential — several tracks advance in parallel:

1.Protocol Specification
2.Reference Implementation
3.Security and Privacy
4.Governance
5.Interoperability
6.Developer Ecosystem
7.Validation and Pilots
8.Federation and Global Network
§ 4

4.Phases 0–20

Each phase shows its objective, scope, status, primary dependency and related tracks. No phase has been removed or reduced — status only reflects the current stage.

Status
Track

21 of 21 phases

PHASE 0ActiveProtocol SpecificationGovernance

Foundation and Project Definition

Define the mission, global scope, principles and initial structure of the project.

Dependency

Foundational phase — depends on no other.

Scope
Problem definitionInternet of Agents definitionW4GEO missionPositioning as an open protocolIndependence from SegloxNeutrality principlesEntities and participants definitionComplete architectureSecurity principlesPrivacy principlesVersioning strategyDocumentation structurePublic project identityInstitutional siteInitial documentationPublic repositoryInitial contribution process

Mission, positioning, independence from Seglox, complete architecture and a public repository are already defined and published; formal versioning and a contribution process have not been structured yet.

PHASE 1In DevelopmentProtocol SpecificationReference Implementation

Discovery Protocol

Allow humans, systems and agents to find W4GEO information by domain.

Dependency

Depends on the initial definition (Phase 0).

Scope
/.well-known/w4geo.jsonDocument structureJSON SchemaVersioningEntity identificationEndpointsPublic keysServicesAgentsPoliciesEvidenceRevocationsFederationCacheContent typeValidationSecurityFallbackExamplesTest vectorsImplementation guideConformance tests

The base document is already published in production and signature-verified; a formal JSON Schema, versioning, test vectors and the remaining endpoints do not exist yet.

PHASE 2In DevelopmentProtocol SpecificationReference ImplementationSecurity and Privacy

Cryptographic Identity

Create verifiable identity and proof of control.

Dependency

Depends on the initial definition (Phase 0); evolves in parallel with the Discovery Protocol.

Scope
IdentifiersInitial Ed25519Cryptographic extensibilityCanonicalizationDocument signingKey IDsProof of controlDomain bindingTimestampsNoncesReplay protectionKey rotationMultiple keysRecovery keysCompromised key processEvent signingReference librariesTest vectorsConformance

Ed25519 signing and verification with canonicalization already work in production (w4geo-verify); key rotation, multiple keys and replay protection are still in specification.

PHASE 3In SpecificationProtocol Specification

Entity, Domain and Business Context

Represent and validate people, organizations, domains and digital assets.

Dependency

Depends on Cryptographic Identity (Phase 2) and the initial definition (Phase 0).

Scope
Entity schemaEntity typesLegal namePublic nameJurisdictionRegistrationsRepresentativesOwnership declarationsDomain ownershipDomain controlOfficial servicesRelated domainsCredentialsVerified claimsEvidence referencesExpiryPrivacy classificationSelective disclosureStatus lifecycleEntity resolutionDomain intelligenceBusiness verificationConflict handling
PHASE 4In SpecificationProtocol SpecificationSecurity and Privacy

Agent Identity and Runtime Attestation

Identify agents, their responsible parties, implementations and execution environments.

Dependency

Depends on Cryptographic Identity (Phase 2).

Scope
agent_idAgent schemaprincipalowneroperatordeveloperdeployerpurposeAgent classModel metadataSoftware versionRuntime metadataDeployment environmentCapabilitiesRestrictionsTool manifestTool manifest hashEndpoint bindingVersion historyAgent statusProvenanceSoftware attestationRuntime attestationTPM compatibilityTEE compatibilityConfidential computing compatibilityRemote attestationAttestation evidenceFallback for unattested agentsPrivacy protectionsConformance tests
PHASE 5In SpecificationProtocol SpecificationSecurity and Privacy

Delegation and Capability Authorization

Define verifiable authority that is limited and transferable in a controlled way.

Dependency

Depends on Agent Identity (Phase 4) and Cryptographic Identity (Phase 2).

Scope
Delegation schemaCapability schemadelegatordelegateresourcesactionsscopesconditionsaudienceexpirationjurisdictionparent delegationdelegation chainsattenuationmaximum depthcycle detectionprivilege escalation preventionnon-transferable capabilitiesusage limitsfinancial limitstemporal limitsgeographic limitspurpose restrictionsproof chaincapability tokensCompatibility analysis with MacaroonsCompatibility analysis with BiscuitCompatibility analysis with UCANCompatibility with OAuthCompatibility with OIDCPolicy enforcementConformance tests

Delegation MUST NOT expand authority.

PHASE 6In SpecificationProtocol SpecificationSecurity and Privacy

Revocation, Suspension and Recovery

Enable a secure response to compromise, error, expiration and loss of control.

Dependency

Must evolve alongside Identity (Phase 2), Agents (Phase 4) and Delegation (Phase 5).

Scope
Revocation modelRevocation registryKey revocationIdentity revocationAgent revocationCredential revocationDelegation revocationEvidence revocationSuspensionExpirationStatus checkingPropagationCache invalidationEmergency shutdownRecovery keysDomain recoveryOrganization recoveryOwnership transitionIncident responseCompromised validator processAudit trailFederation propagationConformance tests

Architectural reference: /.well-known/w4geo-revocations.json. This endpoint is not operational yet.

PHASE 7In SpecificationProtocol Specification

Evidence and Proof Registry

Standardize facts, proofs, validations and events used in decisions.

Dependency

Can start early and evolve continuously alongside the other phases.

Scope
Evidence event modelEvidence schemaEvent typessubjectissuerverifiersourceevidence hashsignaturestimestampexpirationjurisdictionstatusconfidenceprivacy classificationselective disclosureevidence chainsprovenanceevidence revocationevidence disputesissuer reputationvalidator evidenceappend-only optionspublic registriesprivate registriesfederated registriesAPIquery modelconformance tests
Evidence states
PROPOSEDAUTHENTICATEDADMISSIBLECONFIRMEDDISPUTEDREVOKEDEXPIREDSUPERSEDEDREJECTED
evidence — kyc_verified
{
  "type": "kyc_verified",
  "issuer": "example-platform",
  "subject": "w4geo:entity:123",
  "status": "confirmed"
}
evidence — fraud_confirmed
{
  "type": "fraud_confirmed",
  "issuer": "example-bank",
  "subject": "w4geo:entity:456",
  "status": "confirmed"
}
PHASE 8ResearchProtocol Specification

Trust and Reputation Context

Organize historical and contextual trust signals without creating an absolute universal authority.

Dependency

Depends on signals and evidence (Phase 7).

Scope
Trust signal taxonomyPositive signalsNegative signalsContextual trustEntity reputationAgent reputationCapability reputationDomain reputationIssuer reputationValidator reputationEvidence qualityBehavioral historyIncident historyTemporal decayConfidence intervalsDispute handlingReputation portabilityAnti-manipulationSybil resistanceCollusion resistanceTransparencyExplainabilityPrivacyOptional scoring profilesNo universal mandatory score
PHASE 9ResearchProtocol SpecificationSecurity and Privacy

Risk Intelligence Engine

Assess risk based on verifiable context, policies and signals.

Dependency

Depends on signals and evidence (Phase 7).

Scope
Risk signal schemaIdentity riskDomain riskAgent riskRuntime riskTool riskCapability riskDelegation riskEvidence riskTransaction riskFraud riskJurisdiction riskBehavioral riskAnomaly detectionCompromise indicatorsContradictory evidenceConfigurable modelsLocal risk policiesRisk thresholdsExplainabilityConfidenceModel versioningAuditabilityHuman reviewData minimizationAdversarial testingRed-team testingAPIReference engine
PHASE 10In SpecificationProtocol Specification

Policy and Decision Context

Turn identity, authority, evidence, trust and risk into auditable decisions.

Dependency

Depends on Risk Intelligence (Phase 9) and Delegation (Phase 5).

Scope
Policy schemapolicy issuerapplicable jurisdictionpolicy versionrequired evidencerequired assuranceaccepted validatorsdenied capabilitiesrestrictionsthresholdshuman approval rulesallowdenyconditionalrequire_more_evidencerequire_human_reviewsuspendquarantinedecision reasonsdecision expirationpolicy conflictjurisdiction conflictappeal pathpolicy enginedecision APIdecision receiptsconformance tests

Identity + Authority + Delegation + Evidence + Reputation + Risk + Policy = Decision Context.

PHASE 11ResearchProtocol SpecificationValidation and Pilots

Semantic Quorum

Resolve conflicts between evidence, validators, sources and interpretations.

Dependency

Depends on Evidence (Phase 7), validators and decisions (Phase 10).

Scope
Quorum modelValidator responsesWeighted quorumMinimum quorumDomain specializationValidator diversityConflicting evidenceConflicting policiesSemantic versionsConsensusRegistered dissentAggregate confidenceValidator accountabilityAnti-collusionAnti-Sybil mechanismsTrust boundariesAppealRe-evaluationQuorum receiptsPublic quorumPrivate quorumRegulated quorumPluggable consensus mechanismsReference implementationSimulationsAdversarial testing

Semantic Quorum does not require blockchain — the architecture allows different consensus mechanisms.

PHASE 12ResearchFederation and Global Network

Federation

Enable interoperability between different operators, sectors, countries and networks.

Dependency

Depends on identity, revocation (Phase 6), governance (Phase 13) and interoperability (Phase 16).

Scope
Federation modelPublic federationPrivate federationRegulated federationSector federationValidator admissionValidator removalTrust anchorsRoot policiesCross-federation recognitionCross-federation evidenceCross-federation revocationFederation discoveryFederation metadataNode discoveryProtocol negotiationVersion compatibilitySynchronizationTrust listsBlock listsPolicy translationJurisdiction boundariesDispute resolutionFederation exitCompromised federation handlingFederation conformance
PHASE 13ProposedGovernance

Governance and Standardization

Create an open, neutral, transparent and sustainable governance model.

Dependency

Must evolve alongside every phase that requires shared rules.

Scope
Governance charterMaintainer rolesContributor rolesTechnical steeringSecurity councilConflict-of-interest rulesProposal processRequest for commentsSpecification changesVoting mechanismsConsensus mechanismsRelease processSemantic versioningBackwards compatibilityDeprecationIntellectual property policyTrademark policyCode of conductVulnerability disclosureSecurity responseTransparency reportsValidator governanceFederation governanceDispute proceduresAppealsIndependent participationInternational participationStandardization strategy

No foundation or council has been constituted yet.

PHASE 14In SpecificationSecurity and PrivacyProtocol Specification

Audit, Accountability and Compliance

Enable reconstruction, explanation, contestation and oversight of decisions.

Dependency

Must exist from the earliest implementations and expand with every layer.

Scope
Audit record schemaDecision receiptIdentity snapshotAgent snapshotRuntime snapshotDelegation trailEvidence trailReputation contextRisk contextPolicy trailQuorum resultValidator responsesTimestampsSignaturesSoftware versionsData sourcesDecision resultExplanationHuman interventionAppealRetentionRedactionSelective disclosurePrivacy controlsCompliance exportAuditor roleIndependent auditRegulated auditTamper evidenceVerification tools
decision audit object
{
  "decision": "approved",
  "subject": "w4geo:agent:payments-001",
  "action": "release_payment",
  "policy": "w4geo-payment-policy-v1",
  "evidence": [],
  "authority_chain": [],
  "delegation_chain": [],
  "risk_factors": [],
  "validators": [],
  "timestamp": "2026-07-11T00:00:00Z",
  "proof_hash": "sha256:..."
}
PHASE 15In DevelopmentReference ImplementationDeveloper Ecosystem

Reference Implementation and Developer Ecosystem

Provide real tools for adoption.

Dependency

Depends on every specification that already has enough content to implement.

Scope
Reference serverReference resolverIdentity librarySigning libraryValidation libraryDelegation libraryRevocation clientEvidence registryRisk reference enginePolicy engineQuorum engineAudit verifierValidator nodeFederation nodeCommand-line interfaceJavaScript SDKTypeScript SDKPython SDKJava SDKGo SDKExamplesStarter templatesTest suiteConformance suitePlaygroundValidator dashboardDocumentation portalAPI referenceMigration guidesIntegration guides

w4geo-verify (reference server, resolver, MCP server and signing scripts) already exists and is public; SDKs, CLI, playground and dashboard have not been built yet.

PHASE 16ResearchInteroperability

Interoperability

Integrate W4GEO with the existing ecosystem.

Dependency

Depends on the core specifications (Phases 1–10) being mature enough to map compatibility.

Scope
DNSHTTPSJSON-LDSchema.orgOAuth 2.0OpenID ConnectDIDVerifiable CredentialsMCPA2AAgent identity protocolsCapability systemsPKICertificate transparencyConfidential computingTPMTEECloud identityEnterprise IAMAPI gatewaysSecurity platformsCompliance systems

No official third-party endorsement is claimed — technical interoperability is planned only.

PHASE 17PlannedSecurity and Privacy

Security Validation

Test the protocol against real threats.

Dependency

Depends on enough implementation existing (Phases 1, 2, 15) to test against real threats.

Scope
Threat modelImpersonationKey theftReplayPrivilege escalationDelegation abuseCycle attacksStale revocationEvidence forgeryValidator collusionSybil attacksFederation compromisePolicy manipulationSemantic disagreementMalicious agentsCompromised runtimesTool substitutionModel substitutionMetadata tamperingPrivacy leakageCorrelation attacksDenial of serviceDependency compromiseSupply-chain attacksPenetration testingPublic security reviewBug bounty planningRed-team exercisesIncident response drills
PHASE 18PlannedValidation and Pilots

Pilot Implementations

Validate the protocol in real environments.

Dependency

Depends on the Reference Implementation (Phase 15) and Security Validation (Phase 17).

Scope
SoftwareAPIsE-commerceMarketplacesFinancial servicesHealthcareLegal servicesPublic administrationCreator platformsDigital identityCybersecurityAutonomous commerceEnterprise agentsAgent-to-agent services

Seglox acts as an early implementation environment, never as the owner of the protocol. No pilot beyond that is confirmed.

PHASE 19ProposedFederation and Global NetworkValidation and Pilots

Public Validator and Federation Network

Operate distributed, interoperable infrastructure.

Dependency

Depends on Federation (Phase 12), Governance (Phase 13) and Pilots (Phase 18).

Scope
Validator node specificationValidator admissionValidator identityValidator attestationValidator reputationPublic discoveryHealth monitoringRevocationFederation formationCross-federation testingPublic statusTransparency logsQuorum operationGovernance participationIncident responseGeographic diversityOrganizational diversityJurisdiction diversitySustainability model
PHASE 20ProposedFederation and Global NetworkGovernance

Global Adoption and Long-Term Evolution

Make W4GEO a sustainable global infrastructure.

Dependency

Depends on the public validator network (Phase 19) being operational.

Scope
International contributorsMultilingual specificationsRegional governance participationRegulated-sector profilesIndustry profilesGovernment profilesEducationCertification programsConformance certificationInteroperability eventsPublic researchProtocol maintenanceSecurity maintenanceBackward compatibilityNew cryptographyPost-quantum migrationLong-term archivalGovernance evolutionEcosystem sustainabilityStandardization submissionsIndependent implementations
§ 5

5.Dependencies Between Phases

The roadmap is not strictly sequential, but a few dependencies are central:

  • Discovery depends on the initial definition.
  • Agent Identity depends on Cryptographic Identity.
  • Delegation depends on identity and agents.
  • Revocation must evolve alongside identity, agents and delegation.
  • Evidence can start early and evolve continuously.
  • Risk depends on signals and evidence.
  • Decision Context depends on policy, risk and delegation.
  • Semantic Quorum depends on evidence, validators and decisions.
  • Federation depends on identity, revocation, governance and interoperability.
  • Audit must exist from the earliest implementations and expand with every layer.
  • Security and privacy are continuous and cut across every phase.
§ 6

6.Completion Milestones

There is no single absolute finish line — the protocol evolves through milestones:

Architecture Defined
Core Specifications Published
Reference Implementation Available
Conformance Suite Available
First Independent Implementation
First Public Pilot
Governance Operational
Validator Network Operational
First Federation
Cross-Federation Interoperability
Global Multi-Sector Adoption
§ 7

7.Certification & Conformance

Planned — nothing below exists today as an active certification program:

Implementation conformanceResolver conformanceIssuer conformanceValidator conformanceFederation conformanceSecurity profilePrivacy profileRegulated profileInteroperability testingCertification governanceCertification renewalCertification revocation