search

thegreenwebfoundation / carbon.txt

A proposed convention for making it possible demonstrate that your infrastucture uses green power
Apache License 2.0
74 stars 5 forks source link

Work out how to make it discoverable - `well-known`, TXT records or root domains #3

Open mrchrisadams opened 5 years ago

mrchrisadams commented 5 years ago

We have loads of prior work to look to for establishing convention for this.

What would this look like?

fknet commented 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.

mrchrisadams commented 5 years ago

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?

arendjantetteroo commented 5 years ago

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.

fknet commented 5 years ago

@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.

mrchrisadams commented 5 years ago

@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.

npdoty commented 3 years ago

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.

westurner commented 2 years ago

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

westurner commented 2 years ago

@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"?)

westurner commented 2 years ago

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)?

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)

msporny commented 2 years ago

@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?

westurner commented 2 years ago

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?

mrchrisadams commented 2 years ago

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.

westurner commented 2 years ago

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

https://github.com/blockchain-certificates/cert-verifier-js/blob/master/docs/verification-process.md#issuer-identity :

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 .

https://cryptoclimate.org/

https://cryptoclimate.org/

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.

mnot commented 2 years ago

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.

mrchrisadams commented 2 years ago

thanks @mnot - I've updated this accordingly. I didn't know you could register provisionally like that, thank you.