Noethrion Foundation

team@noethrion.com https://noethrion.com

Security attestation RATS COSE EAT CBOR energy This document specifies an attestation token format and verification protocol for hardware-rooted measurements of electricity generation. The protocol enables a tamper-evident chain of custody from the secure element at a metering device to a publicly verifiable settlement layer, using ECDSA P-256 signatures generated inside a certified secure element and carried in a COSE_Sign1 structure. It defines: (a) the CBOR-encoded attestation token, aligned with the Entity Attestation Token format of RFC 9711 and the Remote ATtestation procedureS (RATS) architecture of RFC 9334; (b) a Merkle-aggregation and on-chain commitment scheme for scalable verification; and (c) a registry mechanism for endorsing device public keys. The token is intended for use by relying parties, such as energy producers, consumers, regulators, and standards bodies, that require cryptographic provenance for clean-energy claims.

Introduction Clean-energy claims today rest on accounting infrastructure: Renewable Energy Certificates (RECs) in the United States, Guarantees of Origin (GoOs) in the European Union, and International RECs (I-RECs) elsewhere. These instruments are issued annually, traded through brokered email confirmations, and reconciled against grid-level dispatch records that the issuance system does not cryptographically verify. Published analyses of certificate markets have reported material discrepancies between dispatched generation and registered certificate issuance. Two regulatory and industrial trends, both effective in 2026, make this verification gap acute:

1. Twenty-four-hour, hourly carbon-free energy matching has become a procurement requirement in several energy-intensive industrial and computing sectors, backed by long-term contracts for dedicated firm generation capacity. Hourly matching cannot be evidenced by annual certificate aggregation.
2. The European Union's Carbon Border Adjustment Mechanism (CBAM) , effective 1 January 2026, requires importers of cement, iron, steel, aluminum, fertilizer, electricity, and hydrogen to demonstrate embedded carbon content at the source. There is no globally interoperable system for verifiable energy provenance that can satisfy this requirement.

This document specifies an open standard intended to close that gap. The protocol places a hardware secure element adjacent to a kilowatt-hour meter; the secure element signs the tuple (energy delta, timestamp, device identifier) with a private key that is generated on-chip and cannot be extracted; the resulting attestation tokens are aggregated into Merkle trees and committed to a public settlement layer; any relying party holding the device's endorsed public key can independently verify any single attestation. The protocol is deliberately narrow in scope. It defines verification, not trading. It does not specify payment rails, market-clearing mechanisms, or currency-like token economics. The unit of accounting in the protocol (NOET) represents one verified kilowatt-hour and is a verifiable attestation unit used internally by the protocol. It is not a payment instrument, a currency, or a store-of-value asset, and this document specifies no transfer, pricing, or settlement-of-value semantics for it. This document is intended for review by the Remote ATtestation procedureS (RATS) Working Group and other interested IETF participants. Comments are welcome at the address given in the Authors' Addresses section.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here.

Terms

Attester:

A metering device, paired with a secure element, that produces attestation tokens. This aligns with the Attester role in the RATS architecture .

Verifier:

Any party that reconstructs and validates an attestation, including its Merkle inclusion proof and on-chain commitment.

Relying Party (RP):

An economic actor consuming an attestation as evidence of clean-energy generation: a producer, consumer, regulator, or integrator.

Endorser:

An entity that issues an endorsement linking a device's public key to a real-world identity, such as a manufacturer, a certification authority, or a self-attested operator.

Reference Values:

The expected device configuration, firmware hash, and certification status against which Verifiers may assess an Attester.

Attestation Token:

A CBOR-encoded COSE_Sign1 object carrying the signed measurement and ancillary claims.

Evidence Payload:

The CBOR claims map carried inside an Attestation Token, as defined in .

Settlement Layer:

A publicly accessible verifiable data structure on which Merkle roots of attestation batches are committed. In this version, the Settlement Layer is an EVM-compatible Layer 2 rollup; future revisions MAY broaden this.

Batch:

An ordered collection of attestation tokens whose hashes form the leaves of a single Merkle tree.

Epoch:

The sequence number identifying a batch in time. Epochs increase monotonically.

Challenge Window:

A configurable period following batch submission during which the batch can be challenged before finalization.

NOET:

The attestation accounting unit of the protocol. One NOET represents one verified kilowatt-hour. NOET is a unit of attestation, not a payment instrument, a currency, or a store of value; this document specifies no transfer, pricing, or settlement-of-value semantics for it.

Architecture and Roles This document follows the role decomposition of the RATS architecture . Each role has a specific scope of responsibility and security boundary.

Attester The Attester is composed of two physical components: a kilowatt-hour meter (the measurer) and a secure element (the signer). The Attester:

• MUST generate the device's signing key inside the secure element using on-chip entropy.
• MUST NOT permit the signing key to leave the secure element under any operational condition.
• MUST sign each evidence payload with the device's private key, as a COSE_Sign1 structure (), before transmission.
• SHOULD include in each attestation a hash of the previous attestation produced by the same device, forming a per-device hash chain.
• MAY include firmware version, model identifier, and configuration claims in the attestation token.

Verifier The Verifier is software, executed by any interested party, that:

• MUST validate the COSE_Sign1 signature of the attestation token, as specified in , using the Attester's endorsed public key, and MUST reject any token whose protected header names an algorithm the Verifier does not accept.
• MUST verify the Merkle inclusion proof against the on-chain committed root for the corresponding epoch.
• SHOULD check the endorsement chain of the Attester's public key against a trusted Endorser registry.
• MAY apply additional Reference Values checks (firmware version, model, certification status) where required.

Relying Party The Relying Party consumes attestations and acts on them. A Relying Party:

• MUST independently invoke a Verifier, either as a library or as a service; it MUST NOT rely on an Attester's self-report alone.
• SHOULD apply use-case-specific validity criteria beyond signature verification, for example timestamp freshness or jurisdiction.

Endorser An Endorser issues an endorsement binding a device public key to identity metadata such as manufacturer, model, and certification batch. Endorsers:

• MUST publish their own public key in a manner that is itself verifiable, such as an X.509 certificate, a well-known DNS record, or an on-chain registry.
• SHOULD specify the procedure by which they obtain assurance that a given public key originates from a tamper-evident secure element.

This document does not mandate a single Endorser hierarchy. A federation of Endorsers is expected to emerge in practice; relying parties choose which Endorsers to trust.

Validator The Validator is an on-chain role responsible for confirming Merkle root submissions before they are finalized for claim. Validators extend the RATS architecture; they exist because the on-chain commitment layer requires a defined set of accountable parties whose signed actions are the basis of finalization. A Validator:

• MUST hold the validator role granted by the holder of the settlement contract's administrative role. Production deployments place that administrative role in a multi-signature wallet.
• MUST independently verify the Merkle root it is voting on against its own reconstruction of the underlying leaf set before broadcasting a batch proposal or a vote. A Validator that votes without independent verification is a single point of trust and defeats the m-of-n property the quorum is designed to provide.
• SHOULD publish its identity (operator, jurisdiction, and contact) so that fraud-proof challengers and relying parties can attribute votes.
• MAY be operated by the standards body, by a delegated operator, or by an independent third party. The m-of-n design treats Validators as Byzantine-tolerant peers, not as trusted authorities.

Validator accountability is enforced through two mechanisms whose details appear in :

1. Quorum. No single Validator can cause finalization on its own; the m-of-n threshold ensures that a minimum of "threshold" distinct Validators must independently agree. The threshold value is a deployment parameter; production deployments SHOULD select a threshold of at least ceil(2n/3) for Byzantine fault tolerance, where n is the size of the active Validator set.
2. Slashing. A Validator proven to have voted for a fraudulent batch loses the validator role and has the off-chain evidence hash recorded on-chain. A Validator that has been slashed for a prior epoch retains the vote it cast before the slash: historical votes are durable in order to preserve the audit trail.

The Validator role is distinct from the Attester (the on-device measurer and signer) and from the Verifier (the relying-party-side software). The Attester proves a measurement was taken on certified hardware; the Validator proves a quorum of independent parties agree the measurement appeared in a legitimate batch; the Verifier checks both layers when consuming an attestation.

Attestation Token Format An attestation token is a CBOR object consisting of a claims map (the evidence payload, ) enveloped in a COSE_Sign1 structure (). Both the claims map and the COSE_Sign1 structure MUST be serialized using the deterministic encoding requirements of , Section 4.2.1, so that signature inputs and leaf hashes are unambiguous. Throughout this document, "attestation token" refers to the complete tagged COSE_Sign1 structure, and "evidence payload" refers to the claims map that it carries.

Claim Set The evidence payload is a CBOR map using the integer labels listed in . These labels are local to this profile and are scoped to the payload map only; they are independent of the COSE header labels used in the enveloping structure (). Evidence payload claim set

Label	Claim	Type	Required	Description
1	iss	bstr	MUST	Device identifier: the 9-byte serial number of the secure element.
2	iat	uint	MUST	Issued-at timestamp, in seconds since the UNIX epoch, UTC.
3	wh	uint	MUST	Energy delta in watt-hours since the previous attestation from the same device.
4	seq	uint	MUST	Per-device monotonic sequence number, starting at 1 and incremented for each emitted attestation.
5	prev	bstr / null	MUST	Hash of the previous attestation token from the same device. It is CBOR null for the first attestation, that is when seq equals 1.
6	fwv	tstr	SHOULD	Firmware version string.
7	mdl	tstr	SHOULD	Device model identifier.
8	cfg	bstr	MAY	Hash of the device configuration relevant to measurement integrity.

The evidence payload carries no signature claim and no algorithm claim. The signature, the signature algorithm, and the key identifier are carried by the enveloping COSE_Sign1 structure as described in and .

Algorithm and Key Identification Algorithm agility in this protocol is provided exclusively by the COSE protected header of the enveloping COSE_Sign1 structure. Specifically:

• The "alg" header parameter (COSE header label 1) identifies the signature algorithm. It MUST be present in the protected header. For this version of the protocol its value MUST be -7 (ES256), as registered in .
• The "kid" header parameter (COSE header label 4) identifies the endorsed device key used to produce the signature. It SHOULD be present in the protected header. Where it is absent, a Verifier MUST resolve the key from the "iss" claim through the registry of .

An implementation MUST NOT convey the signature algorithm as a claim inside the evidence payload. A Verifier that encounters an algorithm indication inside the evidence payload MUST reject the token, because such an indication would create a second and possibly disagreeing source of truth for algorithm selection.

CDDL Definition The following CDDL defines the attestation token. It is normative for the structures it covers. int, ; alg; MUST be -7 (ES256) in this version ? 4 => bstr, ; kid; endorsed device key identifier * cose-label => any } Noethrion-Unprotected-Header = { * cose-label => any } Noethrion-Claims = { 1 => bstr, ; iss: secure element serial number 2 => uint, ; iat: issued-at, UTC seconds 3 => uint, ; wh: energy delta, watt-hours 4 => uint, ; seq: per-device monotonic counter, >= 1 5 => bstr / null, ; prev: hash of previous token; ; null if and only if seq == 1 ? 6 => tstr, ; fwv: firmware version ? 7 => tstr, ; mdl: device model identifier ? 8 => bstr, ; cfg: device configuration hash } cose-label = int / tstr ]]> The Merkle aggregation layer of and the claim-record encoding of are not yet expressed in CDDL. [TBD: full CDDL covering the batch, inclusion-proof, and claim-record structures in -01]

Mapping to EAT The claim set above is intentionally compatible with the Entity Attestation Token (EAT) format defined in . EAT is itself carried in COSE, so the envelope chosen in is the same one an EAT profile would use. Implementations MAY choose to additionally emit a fully EAT-conformant variant by mapping "iss", "iat", and "seq" to their CWT-registered claim numbers. A formal EAT profile for energy attestation will be specified in a follow-up document. [TBD: EAT profile claim mapping table in -01]

Signature Scheme This document specifies a single signature algorithm for this version of the protocol: ECDSA over the NIST P-256 curve (secp256r1) with SHA-256, denoted ES256 and assigned COSE algorithm value -7 in .

Signature Envelope Attestation tokens MUST be signed as a COSE_Sign1 structure as defined in , Section 4.2, tagged with CBOR tag 18. COSE_Sign1 is chosen over a bare signature field for three reasons:

1. It is the envelope used by the Entity Attestation Token and by the wider RATS ecosystem , so that evidence produced under this specification can be consumed by existing COSE and EAT tooling without a bespoke parser.
2. It provides integrity protection over the algorithm and key identifiers themselves, through the protected header, which a bare signature over a claims map does not.
3. It gives a single, already-specified path for algorithm rotation ().

The signature is computed over the Sig_structure defined in , Section 4.4, with:

• "context" set to the text string "Signature1";
• "body_protected" set to the serialized protected header;
• "external_aad" set to a zero-length byte string in this version;
• "payload" set to the deterministically encoded evidence payload of .

Implementations MUST NOT emit an attestation token as a bare claims map with an adjacent signature field. Pre-standard implementations of this protocol, including the genesis deployment of the reference implementation, used such a bare encoding. That encoding is historical, is not conformant with this document, and MUST NOT be used for new deployments. Verifiers MAY retain support for it solely in order to re-verify pre-standard historical records.

Rationale for P-256 P-256 is selected because:

1. It is the curve natively supported by widely available secure elements suitable for low-cost meter integration, including parts certified to Common Criteria EAL5+.
2. It is broadly understood, has mature implementations, and is acceptable to relying parties whose internal cryptographic policies typically permit NIST curves.
3. Performance on constrained microcontrollers is sufficient for the protocol's per-minute signing cadence.

Post-Quantum Migration It is acknowledged that P-256 is not post-quantum secure. A migration path to a post-quantum signature scheme, anticipated to be ML-DSA as standardized in , is part of the protocol's long-term plan. No new format machinery is required for that migration: the "alg" and "kid" parameters of the COSE protected header () are the algorithm and key rotation mechanism, and a future revision need only permit an additional "alg" value and specify the transition policy. Historical attestations remain verifiable because each token names, under integrity protection, the algorithm with which it was signed. A future revision of this document SHALL specify the migration procedure, including dual-signing transitions and the policy under which historical P-256 attestations remain verifiable.

Merkle Aggregation and Settlement

Off-Chain Aggregation Attestation tokens are aggregated off-chain into Merkle trees. Each tree contains up to 2^16 (65,536) leaves, where each leaf is the SHA-256 hash of the complete deterministically encoded, tagged COSE_Sign1 attestation token of . Interior nodes are computed with a commutative sorted-pair construction: where a and b are the two 32-byte child hashes and min and max denote lexicographic byte-wise ordering. Sorting each pair before hashing makes the construction order-independent: an inclusion proof carries only the sibling hashes, with no left/right position flags. This is the construction implemented by the widely used Merkle proof library employed by the on-chain reference contract and by the reference off-chain Verifier tooling. Off-chain builders MUST use this pair hash for any tree whose root is committed on-chain. Note on leaf domain separation: this construction deliberately omits the per-level domain-separation prefixes (0x00 for leaves, 0x01 for interior nodes) defined by . The second-preimage class those prefixes guard against, namely reinterpreting an interior node as a leaf or vice versa, is structurally closed here by preimage length: an interior-node preimage is exactly 64 bytes (two concatenated 32-byte hashes), whereas leaf preimages are never 64 bytes. The on-chain claim-record leaf () hashes a 160-byte encoded payload, and the attestation-evidence leaf hashes a tagged COSE_Sign1 token, which is substantially longer than 64 bytes for any token carrying the required claims of together with a 64-byte ECDSA P-256 signature. The attestation-evidence leaf additionally uses a different hash function, SHA-256, from the keccak256 node hash. informed the design of this layer and is listed as an informative reference. A batch is identified by a monotonically increasing epoch number. The aggregator MAY be operated by the device owner, by a service provider, or by the reference implementation; the choice does not affect verifiability.

On-Chain Commitment For each batch, the Merkle root is committed to a public EVM-compatible Layer 2 settlement network through a reference smart contract. Note that the reference contract is named "Attester" for historical reasons unrelated to the RATS Attester role of ; the two are distinct. The on-chain commitment record SHALL include, at minimum:

• the epoch number;
• the Merkle root (32 bytes);
• the total watt-hour sum claimed in the batch, for cross-check against grid-level dispatch records;
• the proposing validator's address, and, through separate vote events, the addresses of all validators who voted to reach quorum;
• the block timestamp at submission;
• the quorum threshold value active at the moment of submission. Snapshotting this at submission, rather than reading live storage at finalization, ensures that a subsequent administrative change to the global threshold cannot retroactively pass or block this specific batch;
• the challenge-window value active at the moment of submission. Snapshotting prevents retroactive shrinking, which would let an administrator finalize batches early, and retroactive extension, which would freeze finalization of legitimately voted batches.

The two snapshot fields close the symmetric retroactive-shift class of administrative abuses. A challenge window, configurable and defaulting to one hour, follows submission. In the current reference contract the fraud-proof path during this window is off-chain: any party MAY report evidence of a fraudulent batch to the contract operators and validators, who can respond through the on-chain pause mechanism, blocking finalization, and administratively triggered slashing (). A dedicated on-chain challenge entry point, allowing any party to publish a fraud proof directly on-chain, is deferred to a future protocol extension, together with fraud-proof-verified slashing. After the challenge window expires without the batch being rejected, the batch is finalized; finalization is irreversible.

Verification Path A Verifier resolves a single attestation as follows:

1. Receive the candidate attestation token and a Merkle inclusion proof, consisting of the sibling hashes along the tree path.
2. Compute the SHA-256 leaf hash over the deterministically encoded, tagged COSE_Sign1 token.
3. Apply the inclusion proof to derive the candidate Merkle root.
4. Look up the on-chain commitment for the corresponding epoch.
5. Confirm that the candidate root equals the committed root.
6. Confirm that the batch is finalized, that is, that the challenge window has elapsed without a successful challenge.
7. Validate the COSE_Sign1 signature () against the device Attester's endorsed public key: the secure-element-bound key of , and not the on-chain contract of .

All seven steps MUST succeed for the attestation to be accepted.

Note on the Two-Layer Leaf Encoding The Merkle tree described in , whose leaves are SHA-256 hashes of deterministically encoded, tagged COSE_Sign1 attestation tokens, is the attestation-evidence layer. It proves that a particular signed measurement was included in a committed batch. The on-chain claim function in the reference contract enforces a separate claim-record layer: each on-chain leaf is the keccak256 hash of the encoded tuple (chain identifier, contract address, beneficiary, amount, epoch), identifying a specific redemption, that is, which address receives how many NOET against which epoch, bound to a specific contract instance on a specific chain. The first two fields act as a domain separator, so that a Merkle tree built for one contract instance cannot be replayed against a fork or a sibling deployment. The two layers are related but not identical: each claim record aggregates one or more attestation tokens whose summed energy underwrites the redemption amount. A future revision will document the aggregation function from attestation tokens to claim records explicitly. For this version, off-chain builders MUST produce claim-record trees whose leaves match the contract's encoding exactly, including the chain-identifier and contract-address domain separator. The attestation-evidence tree is verified separately by the off-chain Verifier path above and is not yet referenced on-chain.

Endorsement and Verification

Public Key Registry Endorsed device public keys are recorded in a registry. The registry MAY be:

• on-chain, as a smart-contract mapping from device serial number to public key and endorsement metadata, with role-based mutation rights restricted to Endorsers. This is the reference deployment;
• off-chain, distributed as signed JSON files at well-known URLs maintained by Endorsers;
• hybrid, with on-chain anchors and off-chain bulk distribution.

The choice is operational and does not affect the verification semantics: a Verifier MUST be able to obtain a device's endorsed public key, traceable to an Endorser whose own key is verifiable.

Endorser Revocation An Endorser MAY revoke an endorsement, for example on discovery of a compromised provisioning batch. Revocations SHALL be timestamped; a Verifier evaluating an attestation MUST consider revocations issued before the attestation's "iat" timestamp.

Device-Level Revocation A device's endorsement MAY be revoked individually, for example on suspicion of physical tampering reported through the protocol's challenge mechanism. Attestations from a revoked device with an "iat" value after the revocation timestamp MUST be rejected.

Threat Model The following adversaries are explicitly considered.

Compromised Host MCU The host microcontroller adjacent to the secure element may be compromised. Because the signing key is generated on-chip and never leaves the secure element, a compromised host can lie about what to sign but cannot forge signatures under the device's public key. The protocol mitigates this through Reference Values, namely the firmware hash and configuration hash included in the attestation claims. A Relying Party that knows the expected Reference Values can detect a tampered host.

Meter Substitution and Physical Tampering The Attester is composed of a measurer and a signer (). Every cryptographic guarantee in this document applies to the signer: a valid attestation proves that a particular secure element signed a particular set of numbers. It does not, on its own, prove that those numbers came from the meter the Endorser expects, nor that they correspond to physical energy flow. The measurer-to-signer interface is consequently the weakest link in the chain of custody, and it is where the adversaries below operate. Meter substitution. An adversary with physical access may replace the meter, or interpose on the measurer-to-signer interface, and present fabricated readings to the secure element. The secure element signs them faithfully and verification succeeds at every later stage: the signature is valid, the endorsement chain is intact, the hash chain is continuous, and the on-chain commitment is well formed. Where the measurer-to-signer interface is unauthenticated, as it is on a bare pulse output or an unauthenticated serial connection, no mechanism defined in this document detects this attack. Substitution after verification. A measurer that is verified only once, at commissioning or at Attester power-on, provides no continuing guarantee: an adversary may satisfy the check with a genuine meter and substitute afterwards. Implementations MUST NOT treat a commissioning-time verification of the measurer as evidence about readings produced later. Physical tampering of a genuine meter. The meter or its sealing may be tampered with in order to distort readings at the point of measurement. This protocol does not detect such tampering; the existing physical-seal and audit regime of revenue-grade metering, which predates this protocol, remains necessary. That regime is complementary to the mitigations below, not a substitute for them, because a seal constrains the meter itself and says nothing about what reaches the signer. Secure-element substitution. This case is detected, because the device serial number changes and the new public key has no endorsement chain. The following mitigations apply to the measurer-to-signer interface.

• Authenticated measurement. The Attester SHOULD be built on a meter whose metrology function authenticates each reading under a key held in the meter's own protected storage, and the secure element SHOULD verify that authentication before including a reading in the claim set.
• Continuous rather than one-time verification. Where the interface supports authentication, the Attester SHOULD verify it at every reporting interval rather than only at commissioning, so that no window exists in which a verified measurer can be exchanged for an unverified one without detection.
• Fail-closed behaviour. If the measurer cannot be authenticated, becomes unavailable, or returns readings inconsistent with the Attester's monotonic energy counter, the Attester MUST NOT emit an attestation covering the affected interval. Emitting an attestation over unauthenticated readings, or falling back to an unauthenticated interface, defeats the purpose of signing them. A Relying Party MUST treat the absence of an attestation as the absence of attested generation, and MUST NOT substitute an unattested reading in its place.

Residual risk. Deployments whose measurer-to-signer interface is unauthenticated retain the full meter-substitution risk described above. For those deployments the assurance offered by this protocol degrades from "this quantity of energy was generated" to "this secure element reported this quantity", and the binding to physical generation rests entirely on out-of-band procedures. Deployments supporting regulatory or financial settlement SHOULD use an authenticated measurement interface for this reason. A claim conveying the class of measurer-to-signer protection, so that a Relying Party can apply policy to it rather than assuming it, is [TBD in -01].

Secure-Element Key Extraction Extraction of the signing key from a Common Criteria EAL5+ secure element is currently considered infeasible against the design assumptions of state-of-the-art parts. If such an extraction becomes feasible, the affected device family's endorsements SHALL be revoked. The protocol's per-device hash chain, carried in the "prev" claim, limits the value of an extracted key for back-dating, because all historical attestations are anchored on-chain.

Validator Collusion A validator could withhold attestations or propose a batch with a Merkle root that does not correspond to the claimed leaves. Three mechanisms address this in combination:

1. m-of-n threshold quorum. Finalization requires a threshold number of distinct validator votes through the propose, vote, and finalize sequence. A single party cannot cause a batch to be finalized. The threshold MUST be selected such that coalition cost exceeds expected fraud value; analogous systems typically use ceil(2n/3) for Byzantine fault tolerance.
2. Challenge window. Independently of the threshold mechanism, between submission and earliest finalization any party MAY report evidence of fraud. In the current reference implementation this path is off-chain: evidence is reported to operators and validators, who block finalization through the pause mechanism and apply slashing. An on-chain challenge entry point is deferred to a future revision (). A batch successfully challenged within the window is never finalized.
3. Slashing. Validators proven to have voted for fraudulent batches MAY be slashed: the validator role is revoked and the off-chain evidence hash is recorded on-chain. The current reference contract implements administratively triggered slashing; on-chain fraud-proof verification feeding slashing automatically is deferred to a future revision.

A coalition of threshold-many validators colluding within the challenge window can still finalize a fraudulent batch. This is the residual risk; it shrinks but does not disappear with the threshold mechanism. Production deployments SHOULD treat the challenge-window fraud-proof path as load-bearing.

Replay Attacks The combination of the per-device monotonic "seq" claim and the previous-attestation hash chain, carried in "prev", prevents replay of an old attestation as a new one. A Verifier that observes a "seq" value that is not strictly greater than the highest previously observed value for the same device MUST reject the attestation.

Side-Channel Observation Side-channel attacks against the secure element, including power analysis, electromagnetic analysis, and fault injection, are mitigated by the Common Criteria certification regime governing the part. Operators SHOULD follow vendor guidance on physical deployment in order to reduce exposure.

Privacy Considerations The protocol produces a public, durable record of per-device energy generation. This has direct privacy implications, particularly for small-scale producers such as residential rooftop solar installations.

Inferences from Attestations A continuous record of per-device generation timestamps can be correlated with consumption patterns in order to infer the occupancy and behavior of a household. Aggregation and timestamp rounding mitigate but do not eliminate this risk.

Mitigations

• Timestamp rounding. Producers MAY round "iat" to a coarser resolution, for example ten-minute buckets, at the cost of reduced verification granularity.
• Batch padding. Aggregators SHOULD pad batches with dummy leaves so that a small-scale producer's contribution count is not distinguishable.
• Optional zero-knowledge extensions. A future revision will specify an optional zero-knowledge-friendly attestation variant in which the per-device identifier is replaced by a commitment, with selective-disclosure proofs available to authorized auditors.

Right to Opt Out Participation in the protocol is, by design, voluntary. Operators are not required to publish attestations; the protocol's value derives from voluntary adoption by parties that wish to be cryptographically credible.

Security Considerations In addition to the threat model in , implementers are advised of the following.

• Measurement-interface integrity. The protocol binds a signature to a set of readings, not to a physical quantity. The strength of the overall system is bounded by the protection of the measurer-to-signer interface, and an implementation that authenticates every other link while leaving that one open gains little. See .
• Time source integrity. The "iat" timestamp depends on the device's local clock. Implementations MUST authenticate the time source, for example by using NTP with cryptographic verification or GNSS-based time, in order to prevent clock-manipulation attacks.
• Key provisioning. Endorsement integrity depends on a trustworthy provisioning ceremony, in which the device's public key is read from the secure element under chain-of-custody guarantees. Implementations SHOULD use vendor-provided pre-provisioning programs where available.
• Smart-contract risk. The on-chain commitment contract is a security-critical component. Implementations SHOULD subject it to independent audit prior to production deployment and SHOULD support upgradability only through a transparent governance process.
• Settlement-layer reliance. The protocol depends on the liveness and integrity of the chosen settlement layer. Operators SHOULD evaluate the settlement layer's security model, including its consensus assumptions and its fault-recovery procedures.
• Algorithm agility. Because the signature algorithm is named only in the COSE protected header (), it is covered by the signature itself. Verifiers MUST apply a local policy for acceptable algorithms rather than trusting the value found in the token, in order to avoid algorithm-downgrade attacks.

IANA Considerations This document requests that IANA register the following media type in the "Media Types" registry.

Type name:

application

Subtype name:

noethrion+cbor

Required parameters:

N/A

Optional parameters:

profile (a URI identifying the attestation profile in use)

Encoding considerations:

binary

Security considerations:

See of this document.

Interoperability considerations:

See of this document.

Published specification:

This document.

Applications that use this media type:

Producers and consumers of energy attestation tokens as defined in this document.

Fragment identifier considerations:

N/A

Additional information:

Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A

Person and email address to contact for further information:

IETF RATS Working Group (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

See the Authors' Addresses section of this document.

Change controller:

IETF

Future revisions of this document may request additional CBOR tag allocations and CoAP profile registrations.

References Normative References Informative References National Institute of Standards and Technology European Union

Reference Implementation A reference implementation of the Attester (firmware) and of the Verifier (settlement contract plus off-chain library) is available from the project repository identified on the author's organization web site. The reference implementation is provided for interoperability testing and is not normative; where it differs from this document, this document prevails.

Acknowledgements The author thanks the participants of the RATS and COSE working groups whose published work this specification builds upon.