crJSON di C2PA 2.4: Kenapa JSON-LD Muncul di Dunia Provenance

Seorang developer membuka hasil validasi C2PA lalu bilang:

“Akhirnya JSON. Jadi sekarang C2PA pindah ke JSON-LD ya?”

Temannya yang sudah membaca spesifikasi menjawab:

“Enggak. Ini justru bagian yang gampang salah paham.”

C2PA 2.4 memang memperkenalkan Content Credentials JSON, disingkat crJSON. Format ini menggunakan JSON-LD dan membuat data hasil ekstraksi serta validasi Content Credentials lebih mudah dipertukarkan dalam ekosistem yang sangat familiar dengan JSON.

Tetapi crJSON bukan pengganti C2PA Manifest.

Ia bukan format authoring utama.

Ia bukan sumber kebenaran kriptografis yang berdiri sendiri.

Dan ia tidak independen diverifikasi.

Spesifikasi crJSON 2.4 menyebutnya secara tegas sebagai derived view atas C2PA data yang berguna untuk profile evaluation, interoperability testing, dan validation reporting.

Jadi kalau kita ingin memahami kenapa JSON-LD masuk, jangan mulai dari pertanyaan:

“Apakah C2PA sekarang jadi Schema.org?”

Tidak.

Mulai dari pertanyaan:

“Bagaimana membuat output provenance lebih mudah dipakai software lain setelah asset divalidasi?”

Di situlah crJSON masuk.

Masalah C2PA Bukan Kekurangan Struktur

C2PA dari awal sudah sangat terstruktur.

Ada Manifest Store.

Ada Manifest.

Ada assertions.

Ada claim.

Ada signature.

Ada cryptographic binding.

Strukturnya bukan free-form metadata.

Justru struktur internalnya dibuat untuk verifiability, integrity, dan interoperability.

Tetapi struktur kriptografis itu tidak selalu nyaman bagi semua consumer.

Bayangkan tim compliance ingin menampilkan report.

Tim observability ingin menyimpan validation result.

QA ingin membandingkan output validator.

Dashboard ingin menampilkan manifest chain.

Developer web ingin membaca object tanpa harus memahami seluruh detail JUMBF, CBOR, dan COSE.

Di sini representation berbasis JSON menjadi practical.

crJSON adalah jembatan setelah extraction dan validation.

Pipeline dalam spesifikasi digambarkan kira-kira:

C2PA asset atau manifest store,
manifest extraction,
validation,
crJSON transformation.

Urutan itu penting.

crJSON bukan titik awal.

Ia hasil turunan.

Kenapa JSON-LD?

JSON biasa bagus untuk data struktur.

JSON-LD menambah vocabulary dan context.

Di crJSON ada `@context`.

Ini memungkinkan istilah memiliki namespace dan meaning yang lebih eksplisit, termasuk custom terms untuk workflow tertentu.

Dalam ekosistem provenance, ini berguna karena banyak pihak bisa menambahkan data atau extension.

Nama field yang sama tidak harus berarti hal berbeda secara ambigu jika namespace dikelola dengan benar.

Secara konsep, JSON-LD membantu data menjadi self-describing dan mengurangi konflik istilah.

Tetapi sekali lagi, jangan melompat ke kesimpulan:

JSON-LD = Schema.org.

Schema.org memang menggunakan JSON-LD secara luas di web.

Namun JSON-LD adalah teknologi general.

crJSON memakai vocabulary dan context sendiri.

Sama seperti dua aplikasi sama-sama memakai JSON tetapi tidak berarti mereka memakai schema yang sama.

crJSON Bukan Structured Data SEO

Karena melihat `@context`, orang SEO bisa langsung excited.

“Bisa ditaruh di halaman buat AI?”

Stop.

crJSON tidak dibuat sebagai markup SEO.

Spesifikasi mengatakan format ini bukan general-purpose machine-readable Content Credentials format dan bukan input format untuk C2PA data.

Tujuannya spesifik:

export,
profile evaluation,
interoperability testing,
validation reporting.

Jadi jangan menjadikan crJSON sebagai “schema baru untuk GEO” hanya karena berbasis JSON-LD.

Kalau search platform suatu hari mendokumentasikan dukungan khusus terhadap crJSON, itu cerita lain.

Sampai ada source platform, jangan membuat ranking claim.

Protocol harus dibaca dari use case yang ditentukan spec, bukan dari kebiasaan industri marketing.

Apa yang Ada di Root crJSON?

Dokumen crJSON memiliki beberapa property utama.

`@context`.

`manifests`.

`jsonGenerator`.

`manifests` berisi representasi manifest yang ditemukan di Manifest Store.

Active manifest ditempatkan di depan.

Di dalam manifest ada label, assertions, claim atau `claim.v2`, signature details, validation result, dan optional ingredient deltas sesuai struktur.

`jsonGenerator` menyatakan tool yang menghasilkan dokumen crJSON, termasuk name dan version.

Perhatikan detailnya.

Tool yang menghasilkan crJSON bukan otomatis sama dengan tool yang menciptakan asset atau claim generator asli.

Ini representasi hasil transformasi.

Kalau dashboard mencampur dua identity itu, provenance story bisa jadi salah.

Derived View Harus Dianggap Derived

Misalnya validator membaca sebuah image dengan Content Credentials.

Validator memeriksa manifest.

Lalu menghasilkan crJSON.

Seseorang copy file JSON tersebut dan mengubah field:

`humanOversightLevel` dari `fully_autonomous` menjadi `human_validated`.

Apakah crJSON itu masih “valid C2PA”?

Sebagai JSON file, mungkin syntax-nya valid.

Tetapi ia bukan sumber cryptographic truth.

Perubahan di crJSON tidak otomatis mengubah manifest asli.

Karena crJSON tidak independently verifiable.

Kalau consumer perlu assurance, ia harus merujuk kembali ke C2PA asset/manifest dan validation process, bukan percaya pada file JSON hasil export yang berdiri sendiri.

Ini point paling penting untuk security.

Jangan menjadikan derived report sebagai credential.

Validation Result Juga Punya Context

crJSON dapat membawa associated validation results.

Itu useful.

Dashboard bisa menunjukkan apakah manifest valid, assertion bermasalah, signature issue, atau status lain sesuai validator.

Tetapi validation result sendiri juga harus dibaca dengan konteks validator.

Tool apa yang menghasilkan.

Version berapa.

Trust configuration apa.

Environment apa.

Inilah alasan `jsonGenerator` penting.

Di dunia enterprise, dua validator dengan trust store atau configuration berbeda bisa menghasilkan interpretation berbeda pada bagian tertentu.

Provenance pipeline perlu menyimpan alat dan versi.

Bukan cuma hasil akhir.

JSON-LD Mempermudah Interoperability Testing

Bayangkan dua implementation C2PA.

Keduanya membaca asset yang sama.

Bagaimana kita membandingkan output?

Membandingkan binary structure secara langsung lebih sulit untuk tooling umum.

Representation JSON-LD dapat memudahkan test harness.

Expected manifest.
Expected assertion.
Expected validation code.

Tool A menghasilkan crJSON.

Tool B menghasilkan crJSON.

QA dapat membandingkan representation pada level yang relevan.

Itulah use case engineering yang masuk akal.

Bukan keyword baru untuk content marketer.

crJSON juga Berguna untuk Validation Reporting

Organisasi besar bisa memproses jutaan asset.

Mereka tidak ingin manusia membuka validator UI satu per satu.

Pipeline dapat:

ingest asset,
validate,
hasilkan crJSON,
extract status,
simpan ke observability system,
trigger review bila problem.

Contoh:

signature validation gagal.
AI disclosure tidak sesuai policy internal.
Manifest missing pada asset type tertentu.
Ingredient chain bermasalah.

crJSON mempermudah hasil validator masuk ke pipeline data biasa.

Python.
JavaScript.
Data warehouse.
SIEM.
Compliance dashboard.

JSON adalah lingua franca software modern.

Itu salah satu alasan format seperti ini powerful.

Tetapi power-nya datang dari integration convenience, bukan karena ia menggantikan cryptography.

Hubungan crJSON dan AI Disclosure

C2PA 2.4 memperkenalkan dua hal yang bisa saling bertemu.

AI Disclosure berada dalam Manifest sebagai assertion `c2pa.ai-disclosure`.

crJSON dapat merepresentasikan assertion yang telah diekstrak dari manifest dalam view JSON-LD.

Jadi developer downstream dapat membaca:

modelType,
modelName bila ada,
modelIdentifier bila ada,
humanOversightLevel bila ada,
scientificDomain bila ada.

Ini mempermudah policy automation.

Misalnya:

Jika human oversight fully autonomous dan asset masuk kategori high-risk, route ke reviewer.

Tetapi system perlu mempertahankan chain:

field ini berasal dari crJSON yang dihasilkan setelah validasi terhadap manifest tertentu.

Jangan copy field ke database lalu kehilangan provenance bahwa ia berasal dari assertion siapa dan asset versi apa.

Serialization Tidak Sama dengan Semantics

JSON-LD membuat serialization lebih familiar.

Namun meaning tetap datang dari C2PA specification dan vocabularies yang digunakan.

Developer tidak boleh melihat field lalu menebak.

`signature` misalnya punya meaning dalam context C2PA.

`validationResults` punya semantics tertentu.

`claim.v2` punya struktur spesifik.

Kalau perusahaan membuat extension, `@context` membantu memberitahu vocabulary.

Ini disiplin data engineering.

Format yang mudah dibaca manusia justru bisa membuat orang merasa terlalu percaya diri.

Karena “kelihatan seperti JSON biasa”, developer mungkin melewati spec.

Padahal interoperability bergantung pada semantics.

crJSON Bukan Format Authoring

Ini perlu diulang karena tempting.

Jangan membuat crJSON manual lalu berharap itu menjadi Content Credential.

Spesifikasi tidak menjadikannya input format C2PA.

Alurnya sebaliknya.

C2PA data dulu.

Extract.

Validate.

Transform.

Kalau organisasi ingin membuat manifest, gunakan C2PA SDK atau tooling yang memang mendukung generation sesuai standard.

crJSON adalah output-oriented representation.

Ini mirip report dari compiler.

Mengedit report tidak mengubah source binary yang divalidasi.

Apakah crJSON Bisa Disimpan di Database?

Bisa secara teknis sebagai report atau representation jika sesuai kebutuhan.

Tetapi governance harus jelas.

Simpan juga:

asset ID,
hash atau reference relevan,
manifest identity,
validator version,
timestamp,
trust context bila dibutuhkan.

Jangan hanya satu blob JSON tanpa hubungan ke source.

Karena beberapa bulan kemudian ketika asset berubah, tim perlu tahu crJSON ini milik versi yang mana.

Provenance tentang provenance.

Kedengarannya meta.

Tapi production system memang seperti itu.

crJSON dan Knowledge Graph

Karena JSON-LD sering diasosiasikan dengan graph, pertanyaan berikutnya:

“Apakah crJSON bisa masuk knowledge graph?”

Secara teknis, JSON-LD dapat diproses sebagai linked data.

Tetapi keputusan memasukkan crJSON ke knowledge graph organisasi adalah architecture choice, bukan requirement C2PA.

Kalau dilakukan, jangan campur assertion provenance dengan factual entity graph tanpa label.

Contoh:

AI Disclosure mengatakan claim generator menyatakan model tertentu digunakan.

Knowledge graph jangan mengubahnya menjadi:

“Model X pasti membuat asset ini”

tanpa preserving provenance statement.

Graph perlu represent:
siapa menyatakan apa tentang asset.

Bukan flatten semua assertion menjadi fakta absolut.

Ini praktik knowledge representation yang sehat.

Apa Nilai crJSON untuk Publisher?

Publisher mungkin tidak perlu langsung mengutak-atik crJSON.

Kalau CMS kecil hanya ingin menambahkan Content Credentials ke asset, SDK bisa menangani banyak detail.

Tetapi pada scale tertentu, crJSON menarik untuk:

QA,
validation archive,
audit,
compliance reporting,
asset pipeline monitoring,
interoperability test,
dan internal provenance dashboards.

Engineering team mendapat representation yang lebih natural untuk sistem data modern.

Editorial team tidak harus melihat raw JSON.

User juga tidak perlu.

Layer yang berbeda untuk audience berbeda.

JSON-LD Datang Bukan untuk Mengubah C2PA Menjadi SEO, tetapi untuk Membuka Interoperability

Ini takeaway utama.

C2PA 2.4 membuat satu langkah besar: hasil provenance validation lebih mudah masuk ke ecosystem software yang sudah hidup dengan JSON.

Itu practical.

crJSON punya `@context`.
Punya manifests.
Punya claims.
Punya assertions.
Punya signature representation.
Punya validation results.
Punya generator information.

Tetapi ia tetap derived.

Tidak independen diverifikasi.

Bukan canonical cryptographic truth.

Bukan input authoring format.

Bukan Schema.org.

Bukan ranking markup.

Justru dengan batas yang jelas, kita bisa melihat value sebenarnya.

crJSON membuat provenance tidak berhenti di viewer.

Ia bisa masuk QA pipeline, compliance system, testing framework, observability, dan data infrastructure.

C2PA tetap menjaga core cryptographic representation.

JSON-LD memberi jalan agar hasilnya lebih mudah dibaca sistem lain.

Bukan revolusi SEO.

Lebih penting dari itu:

sebuah layer interoperability untuk provenance yang mulai bergerak dari niche metadata menjadi infrastruktur software yang benar-benar bisa dioperasikan.