\/<\/p>Specification<\/a>\/<\/p>Flows<\/b> The functions in sequence.<\/h1> The twelve functions read in order, each handing the next the objects it produces.<\/p> Read the specification<\/a>Contribute<\/a> Functions<\/dt>12<\/dd> State machines<\/dt>11<\/dd> Objects<\/dt>21<\/dd> Standards<\/dt>48<\/dd> <\/dl> <\/section> Specification<\/a>Functions<\/a>State machines<\/a>Flows<\/a>Objects<\/a>Participants<\/a>Standards<\/a>Conformance<\/a>Governance<\/a>Changes<\/a>Implementers<\/a>Wire bindings<\/a>Reference scenes<\/a> <\/nav> On this page<\/p>Flows<\/span><\/li>References<\/span><\/li><\/ol><\/nav>From first contact to retirement, in order.<\/h2>Each function hands the next the objects it produces.<\/p> <\/header> Join<\/h3>A node proves what it is, receives an identity and a policy, then a signed plan. A node MUST present attestation evidence (RATS, RFC 9334, passport model) rooted in a hardware root of trust where the device class has one (TPM 2.0, DICE or a secure element), or a software root explicitly marked SOFTWARE_ROOT otherwise. A verifier MUST bind the result to a nonce and an expiry. Identity MUST be short-lived and renewable (X.509 SVID, SPIFFE-style URI). Long-lived shared secrets MUST NOT be used. The bootstrap bundle MUST be signed by the site’s enrolment key and carry the trust anchors, policy reference and the first plan digest. Evidence: enrolment receipt, attestation result, identity issuance record.<\/p>Objects<\/dt>8<\/dd> Actors<\/dt>0<\/dd> Standards<\/dt>5<\/dd> Domains<\/dt>6<\/dd> <\/dl> Objects it moves<\/h4> Actors it involves<\/h4> Standards it is drawn against<\/h4> Domains that rely on it<\/h4>5G core and edge computing<\/p>Positioning, navigation and timing<\/p>Edge hardware and runtime<\/p>IoT and low-power wireless<\/p>Security, identity and supply chain<\/p>Field deployment and operations<\/p> <\/section>References<\/h2>Sources for the historical and standards statements on this page.<\/p> <\/header>Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org\/rfc\/rfc2119<\/a><\/li>Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org\/rfc\/rfc8174<\/a><\/li><\/ol><\/section><\/main> Read it, test it, propose a change.<\/h2>The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>
\/<\/p>Flows<\/b> The functions in sequence.<\/h1>
The twelve functions read in order, each handing the next the objects it produces.<\/p> Read the specification<\/a>Contribute<\/a> Functions<\/dt>12<\/dd> State machines<\/dt>11<\/dd> Objects<\/dt>21<\/dd> Standards<\/dt>48<\/dd> <\/dl> <\/section> Specification<\/a>Functions<\/a>State machines<\/a>Flows<\/a>Objects<\/a>Participants<\/a>Standards<\/a>Conformance<\/a>Governance<\/a>Changes<\/a>Implementers<\/a>Wire bindings<\/a>Reference scenes<\/a> <\/nav> On this page<\/p>Flows<\/span><\/li>References<\/span><\/li><\/ol><\/nav>From first contact to retirement, in order.<\/h2>Each function hands the next the objects it produces.<\/p> <\/header> Join<\/h3>A node proves what it is, receives an identity and a policy, then a signed plan. A node MUST present attestation evidence (RATS, RFC 9334, passport model) rooted in a hardware root of trust where the device class has one (TPM 2.0, DICE or a secure element), or a software root explicitly marked SOFTWARE_ROOT otherwise. A verifier MUST bind the result to a nonce and an expiry. Identity MUST be short-lived and renewable (X.509 SVID, SPIFFE-style URI). Long-lived shared secrets MUST NOT be used. The bootstrap bundle MUST be signed by the site’s enrolment key and carry the trust anchors, policy reference and the first plan digest. Evidence: enrolment receipt, attestation result, identity issuance record.<\/p>Objects<\/dt>8<\/dd> Actors<\/dt>0<\/dd> Standards<\/dt>5<\/dd> Domains<\/dt>6<\/dd> <\/dl> Objects it moves<\/h4> Actors it involves<\/h4> Standards it is drawn against<\/h4> Domains that rely on it<\/h4>5G core and edge computing<\/p>Positioning, navigation and timing<\/p>Edge hardware and runtime<\/p>IoT and low-power wireless<\/p>Security, identity and supply chain<\/p>Field deployment and operations<\/p> <\/section>References<\/h2>Sources for the historical and standards statements on this page.<\/p> <\/header>Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org\/rfc\/rfc2119<\/a><\/li>Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org\/rfc\/rfc8174<\/a><\/li><\/ol><\/section><\/main> Read it, test it, propose a change.<\/h2>The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>
On this page<\/p>
Each function hands the next the objects it produces.<\/p> <\/header>
A node proves what it is, receives an identity and a policy, then a signed plan. A node MUST present attestation evidence (RATS, RFC 9334, passport model) rooted in a hardware root of trust where the device class has one (TPM 2.0, DICE or a secure element), or a software root explicitly marked SOFTWARE_ROOT otherwise. A verifier MUST bind the result to a nonce and an expiry. Identity MUST be short-lived and renewable (X.509 SVID, SPIFFE-style URI). Long-lived shared secrets MUST NOT be used. The bootstrap bundle MUST be signed by the site’s enrolment key and carry the trust anchors, policy reference and the first plan digest. Evidence: enrolment receipt, attestation result, identity issuance record.<\/p>
5G core and edge computing<\/p>
Positioning, navigation and timing<\/p>
Edge hardware and runtime<\/p>
IoT and low-power wireless<\/p>
Security, identity and supply chain<\/p>
Field deployment and operations<\/p> <\/section>References<\/h2>Sources for the historical and standards statements on this page.<\/p> <\/header>Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org\/rfc\/rfc2119<\/a><\/li>Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org\/rfc\/rfc8174<\/a><\/li><\/ol><\/section><\/main> Read it, test it, propose a change.<\/h2>The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>
Sources for the historical and standards statements on this page.<\/p> <\/header>
The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>