Sustainability Data Reference Gateway

This gateway serves one conformant declaration per reporting subject at /{domain}/.well-known/sustainability-data, so the format can be tested against real, sourced disclosures before organizations publish their own. In real use the declaration lives on the subject's own origin; a gateway only demonstrates and tests the format.

Please read. The declarations about third parties are ILLUSTRATIVE MAPPINGS, prepared by the gateway operator from those organizations' own published reports. They are NOT published, reviewed, authorized or endorsed by their reporting subjects, and this gateway is not an authoritative source for them. Every figure is read from, or is the stated sum of figures read from, the public source document named in the declaration's methodology-uri member; nothing is estimated or apportioned on a subject's behalf. Subjects with a reserved .example name are synthetic and describe nothing real.

Subjects served (15)

Adapter demonstrations (8)

One subject per upstream-backed adapter of the published sustainability-wellknown-publisher package, so every adapter runs end to end here. Live subjects fetch a real upstream daily (only where the license permits attributed republication; the attribution is in the document). Replay subjects run the same adapter code against a recorded response, because no free legal live access exists; their figures are synthetic and say so in the document. All use reserved .example names and describe no real organization.

Wire-format examples (22)

Every case of the specification's canonical example-responses set, served live. Trend cases follow the draft's rule: the parameterless request answers the most recent entry, and the sorted array is returned only for a period sliced by a finer granularity, on documents that declare capabilities:extended. All figures are synthetic; the subjects are reserved .example names.

This gateway's own report

The gateway also reports on itself, as a service, at /.well-known/sustainability-data (target: sustainability-data-gateway). The figures are a model, not a measurement: a constant container power draw, times the hours the gateway has been live, times a cited grid intensity. The document says so (measurement-method: third-party-modeled) and every constant is in the methodology it links.

This one document offers the draft's Extended service. Any period since go-live (2026-07-30T00:00:00Z) can be requested with period (YYYY, YYYY-MM or YYYY-MM-DD) and sliced with granularity (monthly or daily). A period before go-live returns 404; a period in progress reports the completed part so far; a parameter given twice, or a period that is not a real calendar date, returns 400; a target returns 404, because one process has no path prefixes and the published prefix set is therefore empty. Without parameters the answer is the most recently completed month.

curl -s "https://sustainability.up.railway.app/.well-known/sustainability-data?period=2026-07"
curl -s "https://sustainability.up.railway.app/.well-known/sustainability-data?period=2026&granularity=monthly"
curl -s "https://sustainability.up.railway.app/.well-known/sustainability-data?period=2026-07&granularity=daily"

Integrity and attestation

Signature. The gateway's own declaration is signed in place: each object carries a signed member (EdDSA, key id DKH8kCbA0D1pjZv12xq8eGudqEHP2i0tq4h_RMYJxWo), a JWS Compact Serialization (RFC 7515 §7.1, cty: sustainability-data+json) whose payload is that same object without signed. There is no separate signature resource: the signature travels inside the body, so a cache that serves a re-encoded copy cannot separate the two, and each object of an Extended trend array carries its own. The public key is in the signature's header and also published at https://andreibesleaga.com/keys/sustainability-gateway-signing-key.jwk, so a verifier can pin it. A signature proves that the object you hold is the object this key signed, and that successive declarations came from the same key. It does not prove who holds the key, and says nothing about whether the figures are accurate: a correctly signed estimate is still an estimate. The precedent for carrying a signature as a member of the object it secures is the signed_metadata parameter of RFC 8414.

Attestation. The self document links, through verifiable-attestation-uri, to https://andreibesleaga.com/attestations/sustainability-data-gateway-2026.vc.jwt: a W3C Verifiable Credential (Data Model 2.0) secured as vc+jwt, valid five years, in which the issuer attests the model behind the report — its constants and formula — so every month's document is covered without re-issuing. This is the draft's only mechanism that speaks to authenticity. The operator of this gateway and the issuer of that credential are the same person. The credential demonstrates the mechanism — a second key, a second identity, a statement verifiable against a published key — and is not independent assurance of the figures (how signing and attestation are deployed).

The gateway's own declaration carries no upstream member: the hosting platform publishes no declaration of its own, so naming one would be false.

The third-party declarations are deliberately not signed or attested: this gateway can vouch for its own bytes, never for another organization's figures, and a signed member on a relayed declaration would suggest otherwise. The reference consumer reports a signature as verified, unsigned or unverified — never the data as "true" or "false":

npx -y -p sustainability-wellknown-consumer sustainability-fetch https://sustainability.up.railway.app --strict --verify-attestation
npx -y -p sustainability-wellknown-consumer sustainability-fetch https://sustainability.up.railway.app --verify --verify-attestation

Consumer cross-validation

At start-up, every document served here is produced by the published publisher library and validated by the published consumer library — the same code a third party would run. A validation failure stops the gateway from starting. This deployment: sustainability-wellknown-consumer@0.7.0 validated 49 documents at start-up (every subject listed above, the gateway's own report, and the Extended variants it checks).

Service level

The third-party declarations offer the Basic service: this gateway supports none of the query parameters for them, so it ignores them and returns the Basic response, never an error. Two exceptions: the gateway's own report is Extended (above), and the wire-format examples that declare capabilities: "extended" honour period and granularity, answering a sorted trend array only for a granularity finer than the period, as the draft defines.

• Media type. Successful responses use application/sustainability-data+json, the type draft -07 requires, with X-Content-Type-Options: nosniff. Error responses (400, 404, 405, 503) use application/json, also with nosniff.
• Caching. Cache-Control: public, max-age=86400 for the relayed subjects and max-age=3600 for the gateway's own report and this page; a strong ETag and Last-Modified; If-None-Match answers 304. Responses carry Access-Control-Allow-Origin: *. The signature is inside the body, so there is no second resource whose cache entry could drift out of step with the declaration's.
• Methods. GET and HEAD only; any other method answers 405 with Allow: GET, HEAD. An unknown subject answers 404.
• Generic media type. The service-wide default can be switched to the generic application/json type (not conformant publishing, but a type a consumer MAY still process) with the SUSTAINABILITY_MEDIA_TYPE variable, and one subject can be pinned to it regardless of the default, to show such a subject next to conformant ones; this deployment pins none (operator guide).
• Extensions. The top-level member set is closed, so data this specification does not define travels inside the OPTIONAL extensions member, an object whose keys are absolute URIs (RFC 3986, ASCII, scheme in lowercase, no fragment): either an https URI under the definer's control, which should identify documentation of the extension, or urn:uuid: plus a lowercase hyphenated UUID (RFC 9562) for a definer without a domain. A key is an identifier compared as a string, never dereferenced, and there is no registry; a consumer that does not implement one ignores its value. The names this gateway uses are listed in its methodology document. Seven documents served here carry the member: tenant-demo.example, device.example, extended.example, microsoft.com, ovhcloud.com, sfc-network.example and sfc-operator.example.

Check any of this with a click. Each link is a working GET on this deployment (or on the operator's site, for a hosted key or credential); the right-hand column is the expected response. Headers, conditional requests and the 405 case need a client that shows them — the commands in the next section do.

Verify these declarations yourself

Every declaration here can be fetched and validated with the specification's reference consumer (sustainability-wellknown-consumer, 0.7.0 or later — the revision that implements -07). --strict runs the conformance battery — schema, media type, caching, conditional requests, methods, the optional embedded signature — and labels each check with the strength of the requirement: a failed MUST is a conformance failure; an unmet SHOULD, or the generic media type, is reported but does not fail the battery (consumer documentation).

The gateway's own report, at this origin's true well-known location:

npx -y -p sustainability-wellknown-consumer sustainability-fetch https://sustainability.up.railway.app --strict

Any subject — curated, adapter demonstration or wire-format example — by its path-prefixed base URL; the consumer resolves the well-known path under the prefix:

npx -y -p sustainability-wellknown-consumer sustainability-fetch https://sustainability.up.railway.app/cloudflare.com --strict
npx -y -p sustainability-wellknown-consumer sustainability-fetch https://sustainability.up.railway.app/grid-intensity-demo.example --strict
npx -y -p sustainability-wellknown-consumer sustainability-fetch https://sustainability.up.railway.app/yearly.example --strict
npx -y -p sustainability-wellknown-consumer sustainability-fetch https://sustainability.up.railway.app/<any-domain-above> --strict

An Extended trend array, by the full declaration URL with a period and a finer granularity:

npx -y -p sustainability-wellknown-consumer sustainability-fetch "https://sustainability.up.railway.app/yearly.example/.well-known/sustainability-data?period=2025&granularity=monthly"

The embedded signature, the upstream chain and the attestation, on the declarations that carry them:

npx -y -p sustainability-wellknown-consumer sustainability-fetch https://sustainability.up.railway.app --verify
npx -y -p sustainability-wellknown-consumer sustainability-fetch https://sustainability.up.railway.app/tenant-demo.example --upstream

To just fetch and read a declaration (or pipe it into your own tooling):

curl -s https://sustainability.up.railway.app/wikimedia.org/.well-known/sustainability-data | python3 -m json.tool

Independently of this project's tooling, the JSON validates against the specification's JTD and CDDL schemas.

Machine-readable index and documentation

/index.json carries the same list, notices included. Full detail: the gateway README, operator guide, methodology and provenance rules, per-subject sources, signing and attestation, and the Internet-Draft.

References

• draft-besleaga-sustainability-wellknown — the Internet-Draft this gateway implements (IETF Datatracker).
• The Digital Sustainability Data Protocol — the author's article introducing the idea and its motivation (an earlier name for this convention).
• Specification repository — draft sources, schemas, reference publisher and consumer, this gateway, and its documentation.
• sustainability-wellknown-publisher and sustainability-wellknown-consumer — the reference implementations on npm.
• RFC 8615 — Well-Known URIs, the registry the path belongs to (IANA registry).
• RFC 9110 — HTTP Semantics (methods, conditional requests, caching headers used here).
• RFC 8927 (JSON Type Definition) and RFC 8610 (CDDL) — the two schema languages the declaration is defined in.
• RFC 3986 — URI Generic Syntax; the keys of the extensions member are absolute URIs, compared as strings and never dereferenced.
• RFC 9562 — UUIDs; the lowercase, hyphenated text form an extensions key takes after urn:uuid:, for a definer without a domain.
• RFC 7515 — JSON Web Signature; §7.1 defines the Compact Serialization the signed member carries, and §4.1.10 the cty that types its payload.
• RFC 8414 — OAuth 2.0 Authorization Server Metadata; its signed_metadata parameter is the precedent for a signature embedded in the object it secures, whose payload takes precedence over the members around it where the verifier trusts the key independently of the declaration.
• W3C Verifiable Credentials Data Model 2.0 and Securing Verifiable Credentials using JOSE and COSE — the shape of the attestation.
• GHG Protocol — the scope and accounting definitions the carbon members follow; Software Carbon Intensity — the sci-score member.