]> Independent

andrei.besleaga@ieee.org

Internet-Draft Sustainability Carbon Accounting Well-Known URI Energy Efficiency This document defines the "sustainability" well-known URI. This URI provides a uniform, out-of-band convention for web servers and digital services to publish their aggregated environmental impact, energy consumption, and carbon footprint metrics. By utilizing an asynchronous reporting model, this approach allows for transparent environmental accounting without the bandwidth and energy overhead associated with per-request HTTP headers.

Introduction The digital economy consumes a significant and growing percentage of global electricity. Emerging regulatory frameworks, such as the EU Corporate Sustainability Reporting Directive (CSRD) , industry standards like the Green Software Foundation's Software Carbon Intensity and the W3C Web Sustainability Guidelines , increasingly require organizations to disclose the environmental impact of their digital services. These transparency efforts align with the United Nations 2030 Agenda for Sustainable Development , specifically supporting energy efficiency and sustainable infrastructure targets, encouraging companies to integrate sustainability information into their reporting cycles. While initial proposals for carbon transparency focused on per-request HTTP headers, such methods introduce a "rebound effect" where metadata increases the carbon footprint of the transaction. This document leverages to define a /.well-known/sustainability URI for out-of-band reporting. This out-of-band mechanism allows servers to publish periodic, aggregated metrics, enabling workflows where environmental impact is a primary constraint alongside cost and performance. This document continues and replaces draft-besleaga-green-sustainability-wellknown. The rename reflects that this is an individual Independent Submission and is not scoped to any IETF Working Group. The field set and wire format are unchanged from that document; schema version 1.1 (which introduced the optional disclosure-uri field) is used as the default, and this revision adds only clarifications, which are summarized in the Changelog.

Requirements Language 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.

Goals and Non-Goals

Goals Provide a single, discoverable location, for environmental metrics for an origin. Define a minimal, machine-readable JSON structure, suitable for broad adoption. Ensure interoperability between clients and servers. Support alignment with GHG Protocol, EU CSRD, and Digital Product Passports. Mitigate security and privacy risks associated with publishing the data (like hardware fingerprinting).

Non-Goals This document does not mandate a specific calculation or measurement methodology. It does not define the verification, validation, certificates, or attestation mechanisms, for the data itself, though it provides links to external attestations. It does not replace domain-specific reporting standards; it defines discovery and semantics and provides a discovery surface for linking to authoritative reports.

Relationship to Other Work This document specifies an application-layer discovery mechanism for aggregated, origin-level environmental metrics. It is complementary to, and does not overlap with, efforts that define network-equipment energy metrics or management data models; it defines discovery and data semantics only and does not profile or constrain the underlying measurement methodology. This document does not update or obsolete any IETF-stream document. It can be used alongside related disclosure conventions such as carbon.txt , to which it may link through the optional disclosure-uri field.

The "sustainability" Well-Known URI

URI Definition This document defines the "sustainability" well-known URI and requests its registration in the "Well-Known URIs" registry (see the IANA Considerations section). A client requests metrics by issuing an HTTP GET (or HEAD) request. When published, the metadata MUST be located at the path /.well-known/sustainability on the origin. Origin: The combination of scheme, host, and optional port (e.g., https://example.com). Sustainability Metadata Document: The JSON document returned from /.well-known/sustainability. Provider: The entity operating the origin and publishing the sustainability metadata.

Mandatory Minimum Supported Service The resource SHOULD be served over HTTPS. Servers MUST respond with a 200 OK and a JSON body when metadata is available. If no metadata is published, servers SHOULD respond with 404 Not Found. Responses MUST use the application/json media type, SHOULD follow I-JSON (RFC 7493) for maximum compatibility, and SHOULD include appropriate caching directives (see Operational Considerations). A compliant server MUST support the following "Basic" service level: No Parameters: Requests to the root URI with no query strings. Scope: Metrics MUST represent the aggregate impact of the entire host. Default Period: The server MUST return the most recently completed full calendar month. Format: The server MUST return a single JSON object.

Optional, Extended, Query Parameters Servers MAY support "Extended" capabilities via the following parameters: target: Specifies a resource path (e.g., ?target=/api/v1/search). period: Specifies the timeframe using formats: Year: YYYY (e.g., 2025) Month: YYYY-MM (e.g, 2020-01) Day: YYYY-MM-DD (e.g., 2026-01-01) granularity: Defines the "slices" within a period (e.g., monthly, daily). If granularity is finer than the period, the server SHOULD return an array of objects. Servers that do not support the Extended parameters MUST ignore any such parameters and return the Basic response, rather than failing the request. If a supported parameter carries a malformed value (for example, a period that is not a valid date), the server MAY respond with 400 Bad Request, or ignore the offending parameter and return the Basic response.

Payload Format (JSON Data Model) A successful response MUST return a JSON object or an array of objects with the media type application/json.

Mandatory Response Fields version (string): The schema version of the document (e.g., "1.1"). updated (string, date-time): The timestamp (RFC 3339) when the document was last updated. capabilities (string): A self-declared indicator of the service level reflected by this document. It MUST be either "basic" or "extended". "basic" denotes the minimal service, in which the response carries only the mandatory fields. "extended" denotes that extended capabilities apply, meaning that the Extended query parameters are supported and/or one or more optional fields are present. The value is determined per response and MAY, at the provider's discretion, reflect the overall server, an individual response, or a specific resource path (the target). A value of "extended" does not, by itself, guarantee support for any particular Extended parameter or optional field; clients determine actual support from the fields present and from the server's behavior. provider (string): Information about the provider publishing the metadata. measurement-method (string): Short description or reference to the methodology used. This is a free-form string; the values hardware-metered, hardware-estimated, cloud-billing, and third-party-modeled are RECOMMENDED. methodology-uri (string): Link to the full methodology specification (calculation methodology). reporting-period (string): The timeframe covered by the object, expressed using the same date formats as the period parameter (YYYY, YYYY-MM, or YYYY-MM-DD). energy-consumption (numeric): A numerical value indicating the total energy consumed by the host or resource during the reporting period. energy-unit (string): A string indicating the unit of energy (MUST be one of: Wh, kWh, MWh, or GWh). carbon-footprint (numeric): Total impact in grams of CO2 equivalent. carbon-unit (string): A string indicating the unit of carbon measurement (MUST be one of: gCO2e, kgCO2e, or mtCO2e).

Unreported Numeric Metrics All required members MUST be present so that the document is schema-valid. However, a required numeric metric is not always available for a given scope or period. To distinguish "not reported" from a genuine zero measurement, a negative value (for example, -1) in a required numeric field (namely energy-consumption or carbon-footprint) MUST be interpreted as "not reported" for that field, rather than as an actual negative measurement. The carbon-footprint reports gross emissions and is therefore non-negative; carbon removals, offsets, or net-negative accounting are out of scope for this field and, where applicable, are conveyed through the linked attestation or disclosure resources. A client encountering a negative required metric SHOULD treat the metric as unavailable and, where present, consult the disclosure-uri (or the methodology-uri) for authoritative or alternative reporting. The anti-fingerprinting noise described in the Privacy Considerations section MUST NOT be applied to a field carrying the "not reported" sentinel. Optional numeric fields follow a different convention: when an optional metric is not reported it SHOULD simply be omitted, rather than set to a negative sentinel. Consumers that require a value not present (or marked unreported) in this document SHOULD look to the linked disclosure or reporting resources.

Optional Response Fields The JSON object MAY contain the following OPTIONAL keys to align with the , European Sustainability Reporting Standards (ESRS E1), other sustainability recommendations, and optional extended capabilities (a capabilities value of extended does not require every optional field to appear): target-path (string): The resource path requested as target carbon-accounting (string): "location-based" or "market-based" (following ). scope-1 (numeric): Estimated Scope 1 (direct) carbon emissions. scope-2 (numeric): Estimated Scope 2 (indirect/purchased energy) carbon emissions. scope-3 (numeric): Estimated Scope 3 (value chain) carbon emissions. sci-score (numeric): Software Carbon Intensity (SCI) score . functional-unit (string): If present, functional-unit MUST be defined (e.g., "per-request", "per-user") and it SHOULD be in the methodology-uri document. carbon-intensity-gCO2-per-kWh (numeric): Weighted carbon intensity in grams CO2 per kWh. estimated-annual-emissions-kgCO2 (numeric): Estimated annual emissions attributable to the origin. renewable-energy (numeric): Percentage (0-100) of energy from sustainable renewable sources. verifiable-attestation-uri (string): Link pointing to a verifiable credential or attestation to prevent greenwashing. disclosure-uri (string): URI of a machine-readable sustainability disclosure index for the origin, that is, a single document listing links to the origin's public sustainability disclosures (reports, certificates, hosting and energy-source evidence). The field is format-agnostic; the canonical example is a Green Web Foundation carbon.txt file , which is itself commonly published at /carbon.txt or /.well-known/carbon.txt. A disclosure-uri links to supporting evidence and MUST NOT be treated by clients as proof of the metrics in this document. Fields not defined in this specification MAY be present; clients MUST ignore unknown fields unless they are explicitly registered via IANA or agreed by implementers.

Versioning and Extensibility The version member MUST be present and follow the versioning pattern major.minor. A change that is backwards-compatible (additive fields) SHOULD increment the minor version. A change that is incompatible (removes or renames fields, or changes semantics) MUST increment the major version. Extensions MAY be added under a vendor or organization namespace to avoid collisions. Implementations MUST ignore unknown fields to preserve forward compatibility. Schema version 1.1 adds the optional disclosure-uri field; documents declaring version 1.0 remain valid.

Formal Definition (CDDL) The following CDDL describes the response:

Formal Definition (JTD) The following JSON Type Definition (RFC 8927) defines the reporting object:

Example Usage

Basic Response (Root Request) Request: GET /.well-known/sustainability

Yearly Trend (Monthly Granularity) Request: GET /.well-known/sustainability?period=2025&granularity=monthly The response is an array with one object per month; only the first two months are shown here for brevity.

Target-Specific Request (Day Period) Request: GET /.well-known/sustainability?target=/api/v1&period=2026-03-15

Target Specific Yearly Trend (Monthly Granularity) Request: GET /.well-known/sustainability?target=/api/v1&period=2026&granularity=monthly As above, the array holds one object per month; only the first two are shown for brevity.

Highly Detailed Combined Extended Request Request: GET /.well-known/sustainability?target=/app/storage&period=2026-03-20&granularity=daily This example utilizes almost all optional fields, including GHG Protocol Scopes and a verifiable attestation link to combat greenwashing.

Unreported Metric (Not-Reported Sentinel) Request: GET /.well-known/sustainability In this example the provider has a carbon figure (for example, from a supplier or a CSRD report) but does not report energy. The required energy-consumption field is therefore set to the negative "not reported" sentinel (see "Unreported Numeric Metrics"), and the disclosure-uri points to where the missing data can be found.

Operational Considerations

Caching Because this endpoint could be dynamic, hosts SHOULD implement heavy caching for the .well-known responses and enforce strict rate-limiting on requests containing time-range query parameters. Server cache mechanisms SHOULD be added: (e.g., Cache-Control: max-age=86400). For historical reports, a long max-age (e.g., one year) is RECOMMENDED. Use of ETag and Last-Modified is RECOMMENDED.

Interoperability To maximize interoperability: Servers SHOULD implement the latest schema version they support. Clients MUST tolerate unknown fields and future versions. Implementers SHOULD publish example payloads and test vectors. Aggregators SHOULD document how they map provider fields to their internal models.

Deployment For multi-tenant platforms, operators SHOULD decide whether to publish per-tenant metadata at the tenant origin or a platform-level summary. CDNs and reverse proxies MUST ensure that the /.well-known/sustainability path is routed to the authoritative publisher or proxied correctly. Automation: Providers SHOULD automate updates to the document to reflect changes in energy sourcing or measurement.

Security Considerations

Denial of Service (DoS) Because this endpoint may require internal database queries to aggregate data - especially when dynamic period or other query parameters are utilized - it could become a vector for Denial of Service (DoS) attacks. Dynamic aggregation of metrics for custom period parameters can be resource-intensive. Servers SHOULD rate-limit requests to the sustainability URI and cache all generated reports.

Array Size Limits To prevent Denial of Service (DoS) via memory exhaustion, servers supporting granularity MUST limit the maximum number of objects returned. A cap of 366 objects is RECOMMENDED.

Trust and Spoofing Publishing sustainability metadata at a well-known location is convenient but does not provide any cryptographic assurance of correctness. An attacker who controls DNS, TLS certificates, or the origin can publish false metadata. Clients MUST NOT treat the presence of a sustainability document as proof of any claim. For high-assurance use cases, clients SHOULD rely on additional attestations, signed statements, or third-party verification.

Greenwashing and Misrepresentation There is a risk that providers publish misleading or incomplete metrics to appear more sustainable. Providers SHOULD include links to measurement methodologies, authoritative reports, signed statements, additional attestations, or third-party verification. Consumers SHOULD treat the document as a discovery mechanism and validate claims against external sources when necessary. Providers SHOULD include links to cryptographically signed W3C Verifiable Credentials in the verifiable-attestation-uri field to combat greenwashing.

Privacy and Information Leakage Publishing detailed operational metrics may reveal sensitive information about infrastructure, traffic patterns, or deployment topology. Providers SHOULD avoid publishing data that could be used to infer internal architecture or expose personally identifiable information. Aggregators MUST consider privacy-preserving aggregation techniques when publishing derived datasets.

Integrity and Transport Security The resource SHOULD be served over HTTPS to protect integrity and privacy. Clients MUST validate TLS certificates according to standard practice.

Privacy Considerations Publishing sustainability metadata can have privacy implications when metrics are correlated with traffic or user behavior. Providers SHOULD evaluate the privacy impact of any metric that could be linked to individual users or small groups. When in doubt, aggregate or redact fine-grained data.

Traffic Analysis Servers SHOULD NOT report metrics at a granularity finer than 24 hours to prevent correlating energy spikes with specific real-time user actions. Real-time telemetry is NOT RECOMMENDED as it could allow an attacker to correlate energy usage with real-time actions.

Hardware Fingerprinting Precise metrics can reveal hardware architectures. Servers MAY apply "noise" (fuzzing) of approx 1% to reported values to mitigate identification while maintaining audit accuracy.

IANA Considerations IANA is requested to register the "sustainability" well-known URI in the "Well-Known URIs" registry maintained at IANA https://www.iana.org/assignments/well-known-uris, following the procedure outlined in . This registration is required to enable interoperable discovery of sustainability metadata. Following the registration template of , Section 3.1: URI Suffix: sustainability Change Controller: Andrei Nicolae Besleaga (andrei.besleaga@ieee.org) Specification Document(s): This document. Status: permanent Related Information: The response uses the application/json media type and SHOULD follow I-JSON . Formal definitions of the response are provided in this document using CDDL and JSON Type Definition (JTD) .

Acknowledgements Thanks to GREEN WG, to early reviewers and others who provided feedback on the initial drafts for sustainability metadata and discovery patterns.

&RFC2119; &RFC3339; &RFC8174; &RFC7493; &RFC8259; &RFC8610; &RFC8615; &RFC8927; World Resources Institute and World Business Council for Sustainable Development Green Software Foundation European Parliament and Council United Nations World Wide Web Consortium Green Web Foundation

Changelog

Since -00 Editorial/positioning update only; no change to the data model, field semantics, service levels, or wire format, and all published example payloads remain valid. Replaced "standardized" with "uniform convention" in the Abstract, to reflect that this is an Informational document describing a common, interoperable convention (suited to the Independent Submission Stream and Research Group discussion) rather than a standards-track specification.

draft-besleaga-sustainability-wellknown-00 (replaces draft-besleaga-green-sustainability-wellknown) This document is an administrative continuation of draft-besleaga-green-sustainability-wellknown, which it replaces. It makes no change to the field set or wire format; the previously published example payloads remain valid. Renamed the document from draft-besleaga-green-sustainability-wellknown to draft-besleaga-sustainability-wellknown and recorded a "Replaces" relationship. The prior name's "green" token could imply a scope tied to the IETF GREEN Working Group; this is an individual Independent Submission with no working-group affiliation. Adopted schema version 1.1 as the default across all examples (version 1.1 introduced the optional disclosure-uri field; documents declaring 1.0 remain valid). Clarified the meaning of a negative value in a required numeric field: it denotes an unreported metric (not a real negative measurement); see "Unreported Numeric Metrics". Also noted that carbon-footprint is gross (non-negative) and that the anti-fingerprinting noise is not applied to the "not reported" sentinel. Editorial and clarity corrections for publication: the URI Definition now states that this document requests the registration (rather than asserting it is already registered); added a "Relationship to Other Work" note (application-layer scope; does not update or obsolete any IETF-stream document; complementary to carbon.txt); and specified that servers not supporting the Extended parameters MUST ignore them and return the Basic response. Data-model and example corrections: clarified the capabilities semantics (a simple basic/extended indicator that is determined per response and MAY reflect the server, the specific response, or a resource path) and corrected the Target-Specific example, which had declared basic while carrying an optional field (target-path) and had reused the whole-host totals for a sub-path; pinned reporting-period to the same date formats as the period parameter; noted that measurement-method is a free-form string with RECOMMENDED values; bounded renewable-energy to 0-100; documented malformed-parameter handling (400 or ignore); and added a "Not-Reported Sentinel" example. The section headings below (Since -04, Since -03, etc.) refer to the revision history of the replaced document.

Since -04 This revision re-targets the document to the Independent Submission Stream and adds one optional field; the mandatory data model, field semantics, service levels, and security and privacy considerations are otherwise unchanged from -04, and all previously published example payloads remain valid. Set the submission type to the Independent Submission Stream and removed the GREEN working group and the "Operations and Management" area designations from the front matter. The document is an individual submission and is not a product of any IETF working group. The IANA "Change Controller" was set to the author accordingly, per RFC 8615, Section 3.1 (the "IETF" change controller applies to Standards-Track documents). Added the optional disclosure-uri field (schema version 1.1): a format-agnostic link to a machine-readable sustainability disclosure index for the origin, with a Green Web Foundation carbon.txt file given as the canonical example (added as informative reference ). The field is optional and additive; version 1.0 documents remain valid.

Since -03 This revision contains only editorial and reference corrections; the data model, field semantics, service levels, and security/privacy considerations are unchanged from -03, and all published example payloads remain valid. Corrected the CDDL normative reference from RFC 8949 (CBOR) to RFC 8610 (CDDL). Added the normative references RFC 7493 (I-JSON) and RFC 8927 (JSON Type Definition), both of which were already cited in the text but missing from the references. Noted that the Green Software Foundation Software Carbon Intensity specification has since been standardized as ISO/IEC 21031:2024. Completed the IANA "Well-Known URIs" registration template to the full set of fields in RFC 8615, Section 3.1. Editorial: the CDDL, JTD, and JSON example listings are now emitted as proper source-code blocks so the example content renders without stray code-fence markers, and a few listing lines were wrapped or shortened so no rendered line exceeds 72 characters.

Since -02 Version -03 was a major revision. It added the "Goals and Non-Goals", "Interoperability", "Deployment", and "Acknowledgements" sections; mandated HTTPS (SHOULD) and defined the 200 OK / 404 Not Found semantics; added the mandatory version, updated, and provider fields; renamed methodology-type to measurement-method; introduced the formal JTD schema alongside CDDL; and added recommendations for I-JSON, ETag, and Last-Modified. It created a dedicated Privacy Considerations section and expanded Security Considerations (trust and spoofing, greenwashing, information leakage, and transport security), and overhauled the examples accordingly.

Since -01 Version -02 simplified the period query parameter (removing the quarterly YYYY-QX option, leaving Year, Month, and Day) and enriched the JSON examples (demonstrating scope-1, scope-2, scope-3, and sci-score), with minor formatting fixes.

Since -00 Version -01 introduced the mandatory "Basic" service level; added the capabilities, methodology-type (later measurement-method), and methodology-uri members and the mandatory carbon-footprint field; expanded the units (Wh/kWh/MWh/GWh and the addition of mtCO2e); added the granularity parameter with array responses; and added operational safeguards (the 366-object array cap and the ~1% anti-fingerprinting noise).

Initial version (-00) The first version established the core proposal: the /.well-known/sustainability well-known URI per , a JSON data model reporting energy (in kWh) and carbon (in gCO2e) as a single object, custom bounded timeframes via explicit start and end date-times, an initial CDDL schema, and preliminary security and caching considerations.