Open mrchrisadams opened 5 years ago
For some hosted websites it is not possible to add DNS records or upload a file to the root level of a domain. If you make it too complicated website owners will not use it.
Therefore it should be possible to have different ways of making the carbon information discoverable.
If you have it within the DNS, providers who host large amount of websites can add this information automatically. Websites that run on a CMS could create a dynamic Meta-Tag.
Thanks @fknet - the dynamic meta-tag approach was one that i hadn't thought of, and I think that's a smart approach - I think you could totally implement that as a large hoster of sites for users.
Lemme check if I understand tho - you're essentially suggesting that company like shopify, netlify, or wix, if they had their own 'master' carbon.txt
file on their main domain, might be able to automatically add the meta-tag to the generated markup in user's websites?
So, to give a concrete example, mom-and-pop-shop.com
which was really hosted by shopify, might have a tag generated automatically, which might be able to point shopify.com automatically?
You have an idea on how much data/text you need to store in the carbon.txt file? I'm not sure on the upper limits of all suggested solutions but that might have impact on if they can be a solution.
@mrchrisadams Yes. I was originally thinking about Wordpress.org where you can have it hosted under a subdomain or your own domain name. Both hosted at the same datacenter(s). Instead of having to manually ask everyone to upload a file - this could be done centralised.
@fknet hah! okay, that's useful to know :)
I actually started working on a wordpress plugin to support the creation of carbon.txt files, but I hadn't thought about the meta tag approach - I really like it.
For context, here's the WIP PR, for generating them on the existing plugin:
https://github.com/jacklenox/the-green-web-widget/issues/1
I can see how a hoster, if they have a themes or plugins pre-installed, could have a small plugin to generate this tag automatically.
@arendjantetteroo in the read me, I've outlined a straw man, but this convo makes me think it might be better to have an examples folder showing concrete cases, to get an idea of how much content might be in each carbon.txt file.
I'll make an issue for it.
The process to register a .well-known/ URI is pretty straightforward: https://github.com/protocol-registries/well-known-uris
But that would generally come after there's a settled specification and some sign that people are using it. In the meantime, I think just recommending that people place their test documents in example.com/.well-known/carbon.txt would be good.
It's not uncommon to have a well-known location so that this kind of info can be looked up about domains, and then also have meta tags or link relations in specific responses for people who want to point to something more specific to a particular request.
Search engines discover JSON-LD and RDFa when they parse pages for Structured Data.
Search engines could be encouraged to index a (new)? Schema.org RDFS Class and Properties for e.g. carbon.txt data, if necessary? https://schema.org/docs/full.html
@danbri @rvguha @richardwallis @thadguidry How could we make this (RDFa/JSONLD) in the footer to indicate sustainable [web] business practices happen with schema.org structured data and maybe something like Dataset search to alleviate load? (E.g. GCP is 100% green with PPAs; could there be a "200% green"?)
To broaden the scope a bit, could such RDFa in a footer to claim sustainable business practices specify that a site is doing [x,y,z] to satisfy e.g. the UN Sustainable Development Goals (the #GlobalGoals)?
[(search)] use cases:
- I want to find an organinization with a project with similar goals and objectives.
- I want to find other objectives linked to indicators.
- I want to say "the schema:Project described in this schema:WebPage is relevant to one or more #GlobalGoals" (so that people searching for ways to help can model similar goal-directed projects)
FWIU, there are a number of blockchains which intend to record claims about supply chain sustainability; some with with schema.org/gtin and GS1 identifiers.
@kimdhamilton @msporny Is there a way for sites to sign a claim with e.g. ld-proofs and then have an e.g. an independent auditor - maybe also with a W3C DID Decentralized Identifier - sign to independently verify? (RDFS vocabularies and e.g. fact-check https://schema.org/ClaimReview probably should have such ld-proofs cryptographic hashes and/or signatures, too)
@kimdhamilton @msporny Is there a way for sites to sign a claim with e.g. ld-proofs and then have an e.g. an independent auditor - maybe also with a W3C DID Decentralized Identifier - sign to independently verify?
The short answer is: yes, there is a way. :)
The longer answer is: It depends on how you want to model it (and there are many legitimate ways).
One way is:
The original set of claims by the site could be expressed as a Verifiable Credential (self-issued GreenPower Credential):
https://www.w3.org/TR/vc-data-model/
... which could be published at some standard URL: https://website.example/.well-known/carbon
and could look something like this:
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/carbon/v1"
],
"type": ["VerifiableCredential", "CarbonCredential"],
"issuer": "did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5", // website or auditor
"issuanceDate": "2021-01-15T10:00:00.0000000-07:00",
"expirationDate": "2022-08-27T12:00:00.0000000-06:00",
"credentialSubject": {
"id": "https://website.example", // identify the website that the carbon report is for
"carbonReport": {
"type": "CarbonReport",
"monthlyPowerConsumption": "1243", // value is in kWh
"powerProvider": "https://green-power.example" // identify the power provider
// ... you can add any arbitrary number of claims about the website or the power provider,
// including other verifiable credentials for the power provider issued by other auditors
},
},
"proof": {
"type": "Ed25519Signature2020",
"created": "2021-06-20T00:17:01Z",
"verificationMethod": "did:key:z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5
#z6MkjxvA4FNrQUhr8f7xhdQuP1VPzErkcnfxsRaU5oFgy2E5",
"proofPurpose": "assertionMethod",
"proofValue": "z4zKSH1WmuSQ8tcpSB6mtaSGhtzvMnBQSckqrpTDm3wQyNfHd6rctuST2
cyzaKSY135Kp6ZYMyFaiLvBUjJ89GP7V"
}
}
If an auditor agrees with the statement, they can express the exact same Verifiable Credential (auditor-issued GreenPower Credential). In this case, the only thing that changes is the issuer and creator of the digital signature.
The first Verifiable Credential (the self-issued one) is fairly useless. The second Verifiable Credential (the auditor-issued one) actually means something (as long as you trust the auditor). Both VCs could be published at https://website.example/.well-known/carbon in a Verifiable Presentation (or similar data structure).
Does that help?
That does help, thanks.
Blockcerts builds on many or all (?) of these W3C specs; and there are open issuer and verifier implementations in JS and Python. https://github.com/blockchain-certificates/cert-schema#cert-schema https://github.com/blockchain-certificates
There are more energy-efficient DLTs for trust roots and for CSR request, CSR signed, and Cert revoked event messages; "Certificate Transparency Blockchain" .
Is there an existing open stack more appropriate for - I guess this would really be - a decentralized auditable log of ~mini / excerpted ESG / CSR sustainability reports?
Thanks for this folks!
I didn't know there was a spec for Verifiable Credentials- thanks for sharing the link to it.
One of the original ideas for carbon.txt was to make it human readable as well as machine readable - a bit like how robots.txt or security.txt can still be read by mere mortals.
I'm working with another provider to prototype some of this, based on this gist from a while back.
It's written in TOML, for a few reasons:
https://gist.github.com/mrchrisadams/5ac8bdbd1d1904d3fa3bbc16ea2905dd
And you can see an example here we were trying out, for an organisation that uses multiple domains and brands:
https://www.bergfreunde.it/carbon.txt
I've also pasted the content below:
[upstream]
providers = [
{ domain = 'syseleven.com', doctype = 'sustainability-page', url = 'https://www.syseleven.de/en/about-us/our-data-centers/' },
{ domain = 'akamai.com' , doctype = 'sustainability-page', url = 'https://www.akamai.com/company/corporate-responsibility/sustainability' }
]
[org]
credentials = [
{ domain = 'www.bergfreunde.de', doctype = 'sustainability-page', url = 'https://www.bergfreunde.de/klimaneutral/' },
{ domain = 'www.bergfreunde.de', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'alpinetrek.co.uk', doctype = 'sustainability-page', url = 'https://www.alpinetrek.co.uk/climate-neutral/' },
{ domain = 'alpinetrek.co.uk', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.nl', doctype = 'sustainability-page', url = 'https://www.bergfreunde.nl/klimaatneutraliteit/' },
{ domain = 'bergfreunde.nl', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'alpiniste.fr', doctype = 'sustainability-page', url = 'https://www.alpiniste.fr/carbone-neutre/' },
{ domain = 'alpiniste.fr', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.eu', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' },
{ domain = 'bergfreunde.eu', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'berg-freunde.at', doctype = 'sustainability-page', url = 'https://www.berg-freunde.at/klimaneutral/' },
{ domain = 'berg-freunde.at', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'berg-freunde.ch', doctype = 'sustainability-page', url = 'https://www.berg-freunde.ch/klimaneutral/' },
{ domain = 'berg-freunde.ch', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.dk', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' },
{ domain = 'bergfreunde.dk', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.se', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' },
{ domain = 'bergfreunde.se', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.no', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' },
{ domain = 'bergfreunde.no', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.fi', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' },
{ domain = 'bergfreunde.fi', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.it', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' },
{ domain = 'bergfreunde.it', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.es', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' },
{ domain = 'bergfreunde.es', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bfgcdn.com', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' },
{ domain = 'bfgcdn.com', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
]
One thing in these examples is this notion of different 'document types', which are referred to as doctypes
here.
The idea here is that these are extendable, so support other kinds of claims you'd point to (for example, the carbon-compensation claim could be replaced with a different kind of validated claim in future)
I'm going to have a bash at implementing a parser for some existing content to use for our own green web foundation checker, as much to learn about the process as anything, and I'll share back here what I pick up along the way.
Who will implement your custom parser for your custom TOML schema with custom validation? A linked data format is best for anything that we want search engines to index: because there are so many file formats to parse and they just don't. I.e. Google does not and probably will never run indexed pages through a TOML parser, but they do parse for RDFa, JSON-LD, and Microdata. And they do parse some Schema.org types.
Getting search engines to index an additional schema.org RDFS Class/"type" and instances of such represented in RDFa, JSON-LD, or Microdata is going to be far more likely than getting anyone to consider another parser for a non-Linked Data spec.
In general and for this application, it's probably wasteful to reinvent the schema and validation wheel. Because I, too, will probably never install a TOML parser in my browser, for example.
Don't even waste your time with those TOML guys, JSON-LD is really easy and great and they index at least some of it.
https://github.com/blockchain-certificates/cert-issuer (Python)
https://github.com/blockchain-certificates/cert-verifier-js#verify-a-blockcert-certificate
The badge.issuer.id field in the Blockchain Certificate says where to find the issuer's current information about which keys are valid. Currently, this is a HTTP URI (although the schema allows for other implementations), which (when dereferenced) contains an array of public keys claimed by the issuer.
A Blockchain Certificate must have a certificate.signature.anchors field, which must contain at least one anchor to a blockchain transaction
For high risk applications at least, it's definitely justified to have a blockchain tx per blockcert, but there are DLTs with much lower kWhr/tx consumption .
What advantage over fake, green washing TOML would issued blockcerts linked to a blockchain tx, GlobalGoals targets and Indicators, and an actual [GRI] Corporate Sustainability Report with Linked Data have?
On Thu, Sep 16, 2021, 11:35 Chris Adams @.***> wrote:
Thanks for this folks!
I didn't know there was a spec for Verifiable Credentials- thanks for sharing the link to it.
One of the original ideas for carbon.txt was to make it human readable as well as machine readable - a bit like how robots.txt or security.txt can still be read by mere mortals.
I'm working with another provider to prototype some of this, based on this gist from a while back.
It's written in TOML, for a few reasons:
- it avoid some of the more common problems with YAML
- also allows for comments
- TOML has lots of language support, while still being comparatively rich and readable
https://gist.github.com/mrchrisadams/5ac8bdbd1d1904d3fa3bbc16ea2905dd
And you can see an example here we were trying out, for an organisation that uses multiple domains and brands:
https://www.bergfreunde.it/carbon.txt
I've also pasted the content below:
[upstream]providers = [ { domain = 'syseleven.com', doctype = 'sustainability-page', url = 'https://www.syseleven.de/en/about-us/our-data-centers/' }, { domain = 'akamai.com' , doctype = 'sustainability-page', url = 'https://www.akamai.com/company/corporate-responsibility/sustainability' } ]
[org]credentials = [ { domain = 'www.bergfreunde.de', doctype = 'sustainability-page', url = 'https://www.bergfreunde.de/klimaneutral/' }, { domain = 'www.bergfreunde.de', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'alpinetrek.co.uk', doctype = 'sustainability-page', url = 'https://www.alpinetrek.co.uk/climate-neutral/' }, { domain = 'alpinetrek.co.uk', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.nl', doctype = 'sustainability-page', url = 'https://www.bergfreunde.nl/klimaatneutraliteit/' }, { domain = 'bergfreunde.nl', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'alpiniste.fr', doctype = 'sustainability-page', url = 'https://www.alpiniste.fr/carbone-neutre/' }, { domain = 'alpiniste.fr', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.eu', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' }, { domain = 'bergfreunde.eu', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'berg-freunde.at', doctype = 'sustainability-page', url = 'https://www.berg-freunde.at/klimaneutral/' }, { domain = 'berg-freunde.at', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'berg-freunde.ch', doctype = 'sustainability-page', url = 'https://www.berg-freunde.ch/klimaneutral/' }, { domain = 'berg-freunde.ch', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.dk', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' }, { domain = 'bergfreunde.dk', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.se', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' }, { domain = 'bergfreunde.se', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.no', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' }, { domain = 'bergfreunde.no', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.fi', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' }, { domain = 'bergfreunde.fi', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.it', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' }, { domain = 'bergfreunde.it', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bergfreunde.es', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' }, { domain = 'bergfreunde.es', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
{ domain = 'bfgcdn.com', doctype = 'sustainability-page', url = 'https://www.bergfreunde.eu/climate-neutral/' }, { domain = 'bfgcdn.com', doctype = 'carbon-compensation', url = 'https://fpm.climatepartner.com/tracking/13467-1912-1001/en' },
]
One thing in these examples is this notion of different 'document types', which are referred to as doctypes here.
The idea here is that these are extendable, so support other kinds of claims you'd point to (for example, the carbon-compensation claim could be replaced with a different kind of validated claim in future)
I'm going to have a bash at implementing a parser for some existing content to use for our own green web foundation checker, as much to learn about the process as anything, and I'll share back here what I pick up along the way.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/thegreenwebfoundation/carbon.txt/issues/3#issuecomment-921010134, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMNS6D2UYZPDIME3XE2PLUCIFDBANCNFSM4HRCZWSQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Because the page seems to currently advocate using something in the root directory, it'd be good to start using .well-known
earlier rather than later, so that you don't have a transition issue. You can register as provisionally before it's a standard.
thanks @mnot - I've updated this accordingly. I didn't know you could register provisionally like that, thank you.
We have loads of prior work to look to for establishing convention for this.
The .wellknown convention has been around for ages, and stops us polluting the root namespace
Google uses DNS Text records as a way to tie information to a domain as well.
Amazon and others use the conventions for email address to check SSL certificates, by sending an email to confirm information ought to be associated with a domain. This page outlines how it works
What would this look like?