---
# System prepended metadata

title: Provenance / Attestation Standards

---

# Provenance / Attestation

- systems
- standards
- services
- tools
- examples
- stakeholders
- users
- use-cases
 
## List (to classify)

- C2PA https://c2pa.org/ - Adobe/BBC/Intel/MS/Sony
  - https://contentcredentials.org/
  - Adobe announcement - https://blog.adobe.com/en/publish/2022/01/26/cp2a-1spec-adobeblogv1
  - overview: https://contentauthenticity.org/blog/exploring-the-open-standard-for-content-provenance-the-c2pa-draft-specification-and-the-path-to-adoption
  - Project Origin https://www.originproject.info/
- Starling pipeline (list the formats/components/svcs/networks used)
- Authenticated Attributes: https://github.com/starlinglab/authenticated-attributes
- HoPRS
- Verify (2023) - Fox Corp on Polygon w/ Lit protocol - https://techinsiders.substack.com/p/the-future-of-verified-content
- W3C Web Annotations (2017) - https://en.wikipedia.org/wiki/Web_annotation
  - Hypothes.is announcement https://web.hypothes.is/blog/annotation-is-now-a-web-standard/ 
- W3C Prov (2013) - https://en.m.wikipedia.org/wiki/PROV_(Provenance)
  - Specs https://www.w3.org/TR/prov-overview/
- Ethereum Attestation Service (EAS) https://attest.sh/
- Numbers
- Operad.ai (Alan, Filecoin Green)
  - provenance wrapper [gdoc](https://docs.google.com/document/d/1eyIgeYzu5Aldb89Iux3SKtztgA6ix0AFvuYDllsSqb4/edit)
- Liccium
  - https://docs.liccium.app/features
- ISCC codes
  - https://iscc.codes/
- VC
  - eg https://www.w3.org/TR/vc-use-cases/
- Veramo
  - https://veramo.io/
  - https://medium.com/uport/introducing-veramo-5a960bf2a5fe
- ACDC
  - https://www.ietf.org/archive/id/draft-ssmith-acdc-02.html
- HTML+
  - https://geometry.xyz/notebook/internet-lit-up
  - https://dawn.mirror.xyz/UCa63fgxdeeduhSt9jQSxz1VKw_QbCgGOXOTUAzpEmQ
  - https://discourse.verifiedinternet.com/t/design-of-html/12
  - https://hackmd.io/@walpo/SyL1jh_Ah
- Gozala/w3s content claims
  - https://hackmd.io/@gozala/content-claims
  - https://github.com/web3-storage/content-claims
  - (more notes below)
- https://www.w3.org/groups/wg/rch/

## Related/Context

- https://fireproof.storage/posts/accountability-for-ai-copilots/
- https://www.hackerfactor.com/blog/index.php?/archives/1010-C2PAs-Butterfly-Effect.html

## Tools?

- web app and/or cli for trying them out?
- swiss army knife for the various key combos
- would need multi-node topology, prob need a backend
- web app for viewing the json/metadata/manifests for a given example

## Communications ideas

- blog post just doing a review of what's out there or coming
- deep dives into each
  - a series
  - curated by someone
  - written by each project?
  - with architecture and hello world examples
- visual diagram/matrix comparing them
- information on where it came from and why
- who's using each, in the wild

## W3S Content Claims

- https://hackmd.io/@gozala/content-claims
- https://github.com/web3-storage/content-claims

> we have been putting together a different approach which perhaps could be synthesized somehow. We have this notion of content claims

> Which is attempt to create and index over IPFS. General idea is that anyone can submit a claim about the content to some aggregators that can verify and propagate those claims by signing over them. You can then form trust hubs and query them

> It also allows you to layer a reputation system on top, because all claims are signed UCAN chains you effectively have a provenance of accountability and can weed out bad actors. It also assigns roles to actors nearest to content been indexed. Specifically (this work is in progress) clients uploading data make their own claims and submit them with uploaded data to web3.storage. web3.storage holds those claims and lazily verifies them when relevant requests are received signing and propagating valid claims and invalidating incorrect ones. There is ongoing effort to feed our signed claims on IPNI. Separately we expose graphql interface so than any one could query claims our system is aware of

> domain specific claims can be published and we may not even know what they mean, but we could make those queryable and apps can use them for their domain specific things

> they won’t be signed by us, but they could be signed by some trusted authority that does some sort of verification

> In fact we are rethinking some of our architecture so we when you upload some bytes we just expose those as raw cid. But if you want to expose block level access you publish a claim for those blocks

> but it does not has to be cid based addressing either you could just claim that 2755d3c..slice is byte range 127…567  within the ff3e785..hash