Decouple OCA "v" attribute from CESR versioning to preserve modular architecture

[pknowl]

I'd like to address the following concern with the "v" attribute in the OCA Bundle:

CESR should not be a dependency of OCA. I'm keen to ensure that OCA (object domain only) isn't bound to a specific event encoding format, such as CESR. OCA should only be concerned with the textual representation and interpretive context of an object—not the encoding, transmission, or tracking of events. To maintain interoperability and architectural clarity, OCA must remain agnostic to provenance frameworks.

For OCA to remain a pure architecture, it must not ...

(i.) Be bound to any specific serialization format (e.g., CBOR (for efficiency), CESR (for verifiability), JSON (for readability), Protobuf (for performance)).

(ii.) Depend on a specific provenance system (e.g., KERI (for authenticity), Git (for versioning), PROV-O (for explanation)).

(iii.) Impose event-model assumptions onto object-based schemas.

Provenance captures the lifecycle of digital objects by tracing the sequence of events that define their structure and state over time. It establishes a trusted record of how, when, and by whom data was created, modified, or transferred—supporting authenticity, accountability, and traceability. Provenance operates across two key dimensions: stemmas, which represent the derivation history of objects (textual lineage), and DAGs (Directed Acyclic Graphs), which track the chronological chain of events affecting those objects (tractual lineage). Together, these structures provide a comprehensive map of both what changed and how it changed, offering a critical foundation for data governance, reproducibility, and trust modeling.

Provenance Marks are the embedded signals or indicators that record specific points within this lifecycle—anchoring the relationship between authenticated agents, object versions, and event sequences. They serve as verifiable signposts within the provenance framework, linking structural evolution (via stemmas) and event history (via DAGs). Unlike mechanical integrity checks or permission-based governance, provenance marks are concerned with who acted, what changed, and in what order, forming a tractual narrative of data lineage. They enable systems to reconstruct the path of agency and transformation, making provenance a living, inspectable trail rather than a static record.

Check out the latest video explainer on Provenance Marks from Blockchain Commons: https://www.youtube.com/watch?v=vKAK6j4mqgE

Modular construction means that OCA remains a structural semantic core—a pure, passive definition layer for objects—while surrounding components such as serialization, provenance, and governance function as pluggable modules rather than embedded dependencies. This separation of concerns ensures that OCA objects can move fluidly across ecosystems, maintaining both structural and semantic integrity regardless of the context in which they are used.

Forcing OCA to conform to CESR’s constraints just to “slot in” to an event stream is a violation of modular design.

OCA bundles SHOULD NOT reference event encoding formats. Instead, encoded events MAY reference OCA bundles.

[mitfik]

OCA does not depend on any of it, as architecture concept it is beyond that, for implementation purposes we needed to pick something for identifier system to being able to have clear implementation path way, we picked SAID, which is linked with CESR encoding. Currently only OCA Bundle requries v field which is encoded according to the CESR standard for the sake of consistency with other components which we are building.

I would close that issue since OCA as architecture is fulfilling all what you have described above. Only on implementation side at certain point we needed to pick specific technology which in our case is SAID to assure about integrity. The v field in OCA bundle is required so tooling can understand how to process it, so v field in OCA Bundle is mandatory anyway, the only concern which I hear is it's format, which conform with CESR format, we cannot decouple CESR from OCA because we need SAID which depends on CESR and SAID is used as decentralized identifier to for all OCA objects.

[pknowl]

I agree that SAIDs are a strong identifier choice, and we clearly value them. However, SAID is still one identifier solution among many. From an architectural standpoint, OCA should not depend on any specific external primitive.

OCA was intentionally designed as a pillar protocol. As such, it should remain identifier-agnostic at the technical specification level. While particular implementations may choose SAIDs (and CESR) to guarantee integrity and determinism, the OCA specification itself should not mandate that choice.

I fully understand why SAID/CESR is required for current tooling consistency; my point is strictly about where that requirement lives.

Concretely, this means using MAY rather than SHOULD when referring to identifier mechanisms. If we say MAY, then we also cannot dictate that the v field must conform to a specific CESR encoding format in the core specification.

SAID (and CESR) fit very naturally as a normative example or as part of an implementation guide, where concrete technology choices belong. That allows OCA to stay technically pure and future-proof, while still fully supporting SAID-based implementations today.

[blelump]

I must agree that SAID's explicit dependency on CESR and CESR's weirdness with respect to implementation specifics for SAID aren't particularly helpful for OCA implementers. It's like a car manual referring to a combine harvester manual about rear wheels.

It's highly unlikely any OCA ecosystem will ever reach the scale where collision resistance becomes problematic (compare with the Git example using SHA1), and thus, it's unlikely any OCA ecosystem would ever need a construct such as SAID (which enables achieving crypto agility).

The only exception to go Z instead of Y is compliance. Thus, some sense of agility is essential to have tech compliance across many governance, but it can be achieved with simpler constructs than SAIDs. Even with the magic byte in OCA itself.