The practice this part continues.
- Federations Networks of networks
- The International Federation of Digital Seismograph Networks unites the groups responsible for installing and maintaining seismographs in their own regions; the International GNSS Service has provided open access to high-quality GNSS data products since 1994, giving access to the global reference frame, the ITRF. Each shows that a federation keeps local ownership and still yields one coherent record. The protocol’s rule of one owner per fact, and its federation function, follow that model. [1][2][3]
- 1984 End to end, rough consensus
- Saltzer, Reed and Clark argued that functions placed in the network can be completely and correctly implemented only with the knowledge of the end systems; RFC 1958 recorded the principle for the Internet’s architecture. The IETF’s working method, summarised in RFC 7282 as “rough consensus and running code”, sets the standard for how an open protocol should change. The protocol keeps authority at the site and changes only through open proposals. [4][5][6]
Draft, review, acceptance, implementation.
Every Observatory Improvement Proposal moves through the same states in public, or is withdrawn.
- 1 DraftWritten in the open, with motivation, text and compatibility.
- 2 ReviewOpen comment and implementer feedback.
- 3 AcceptedDecided under the steward’s process, with reasons.
- 4 ImplementedThe specification, schemas and tests change together.
The rules the protocol keeps.
15 governance and security rules.
- Stewardship
- The Observatory Protocol is an open protocol stewarded by the Nexus Consortium. Any party may implement it; changes are proposed upstream, in the open, before any implementation follows them.
- Versioning
- Protocol versions are written obsp/<major>.<minor>. Until 1.0 a minor version MAY break compatibility; from 1.0 only a major version does. Contract schemas carry their own schema version.
- Change proposals
- Changes are proposed in the open as Observatory Improvement Proposals: draft, review, accepted, implemented, or withdrawn. A proposal that changes a function updates the specification, the schemas and the conformance tests together.
- Conformance levels
- Declared, self-tested, lab-tested, qualified, with suspended and withdrawn. A level is reached only with the evidence the profile names. “Conformant” describes a tested scope only; it is never a conformity assessment.
- Not a public authority
- Warnings, emergency dispatch, regulation, spectrum assignment, insurance, conformity assessment and law enforcement stay with competent external bodies. A protocol receipt creates no legal, regulatory or financial authority.
- No token
- The protocol defines no token, coin or tradable unit.
- Architecture
- Zero trust (NIST SP 800-207): every request is authenticated, authorised and logged; network position grants nothing.
- Device identity
- Attested; hardware root where the class has one; short-lived certificates; revocation within the site’s offline window.
- Workload identity
- SPIFFE-style SVIDs, rotated; no shared secrets.
- Keys
- Site keys held by the grid operator; customer-held keys for upstream services; HSM or TPM-sealed where available.
- Supply chain
- SBOM, SLSA provenance, signed artifacts, TUF update metadata, SUIT for firmware.
- Time
- Authenticated time (P3, §5.4); time integrity gates receipts.
- OT environments
- IEC 62443 zones and conduits for industrial deployments.
- Privacy
- Observation data that can identify a person is a declared data class with its own policy; default is not to collect it.
- Break glass
- Logged, time-bound, receipted.
References
Sources for the historical and standards statements on this page.
- International Federation of Digital Seismograph Networks. “About the FDSN.” www.fdsn.org/about/
- International GNSS Service. “About the IGS.” igs.org/about/
- IGN, ITRF Product Center. “International Terrestrial Reference Frame.” itrf.ign.fr/en/homepage
- Saltzer, J. H., Reed, D. P., and Clark, D. D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems 2(4). web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
- Carpenter, B., ed. (1996). RFC 1958, “Architectural Principles of the Internet.” IETF. www.rfc-editor.org/rfc/rfc1958
- Resnick, P. (2014). RFC 7282, “On Consensus and Humming in the IETF.” IETF. www.rfc-editor.org/rfc/rfc7282
- Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org/rfc/rfc2119
- Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org/rfc/rfc8174