# CESR-based OCA Bundle

OCA Bundle, a self-sufficient aggregation of an OCA Capture Base and overlays, was primarily designed to be bundled into a ZIP file. ZIP file format was chosen to keep related OCA objects bounded altogether, potentially with external assets. However, the lack of need to support external assets in the bundle and more importantly, the evolution of protocols[CESR][CESR-proof], where cryptographic material is no longer a part of data model, but rather an attachment to it, influenced a novel format of the Bundle.

## Draft

The canonical form of the Bundle is defined using JSON-representation:

{
  "version": "OCAB10000023_",
  "said": SAID of the bundle,
  "capture_base": {
    "said": SAID of the CB,
    "type": "string",
    "classification":"string",
    "attributes": "Object",
    "flagged_attributes": "Array[String]"
  },
  // overlays, listed in order as depicted on figure in section 
  // https://oca.colossi.network/guide/introduction.html#what-is-decentralised-semantics
  "overlays": {
    "character_encoding": { },
    "format": { },
    "meta": { },
    "label": { },
    "information": { },
    "standard": { },
    "conditional": { },
    "conformance": { },
    "entry_code": { },
    "entry": { },
    ...
  }
}

### Adding authenticity layer

OCA Bundle by design meets the integrity property by having the `d` attribute in the bundle. The integrity property merely assures the data is consistent, but does not prevent from forgery by a malicious user. Thus, to assure non repudiable consistency, we benefit from public-key cryptography characteristics and use digital signatures to sign the Bundle or part of it. Signed OCA Bundle meets the authenticity property.

Different representations were proposed[CESR][VC] of how to combine data payload along with cryptographic material. The approach where data payload is clearly separated from cryptographic material[CESR] supersedes any former representation. This is also clear separation of integrity and authenticity properties.

OCA Bundle given in JSON representation in the text domain[CESR] is defined as follows:

{ oca bundle }
-FAB
E_T2_p83_gRSuAYvGhqV3S0JzYEF2dIa-OCPLbIhBO7Y
-EAB0AAAAAAAAAAAAAAAAAAAAAAB
EwmQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM
-AAB
AA5267UlFg1jHee4Dauht77SzGl8WUC_0oimYG5If3SdIOSzWM8Qs9SFajAilQcozXJVnbkY5stG_K4NbKdNB4AQ

Note the above example involves KERI concepts, identifiers and key event logs. The OCA Bundle is signed with one digital signature `AA5267UlFg1jHee4Dauht77SzGl8WUC_0oimYG5If3SdIOSzWM8Qs9SFajAilQcozXJVnbkY5stG_K4NbKdNB4AQ`, issued by `E_T2_p83_gRSuAYvGhqV3S0JzYEF2dIa-OCPLbIhBO7Y` identifier.

Digital signatures issued by certain identifiers does not only guarantee the data was not tampered with. If furthermore identifiers have a meaning or reputation in given ecosystem, they might impose concrete decisions on the OCA Bundle consumers, ie. assure them about the origin of the Bundle (or part of it).

Consider such example:
- A passport Capture Base is created and signed by ICAO;
- Label overlays are created and issued by governmental authorities

The Bundle is then given as:

{
  version: ...,
  said: ...,
  capture_base: { ... },
  overlays: {
    label: [
      {
        said: "...",
        language: "en",
        ...
      }
    ]
  },
}
-JAC
5AAFAAA-overlays-label-0-said
-FAB
E_T2_p83_gRSuAYvGhqV3S0JzYEF2dIa-OCPLbIhBO7Y
-EAB0AAAAAAAAAAAAAAAAAAAAAAB
EwmQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM
-AAB
AA5267UlFg1jHee4Dauht77SzGl8WUC_0oimYG5If3SdIOSzWM8Qs9SFajAilQcozXJVnbkY5stG_K4NbKdNB4AQ
6AAEAAA-capture_base-said
EQzFVaMasUf4cZZBKA0pUbRc9T8yUXRFLyM1JDASYqAA
-EAB0AAAAAAAAAAAAAAAAAAAAAAB
EymRy7xMwsxUelUauaXtMxTfPAMPAI6FkekwlOjkggt
-AAB
AATD7NDX93ZGTkZBBuSeSGsAQ7u0hngpNTZTK_Um7rUZGnLRNJvo5oOnnC1J2iBQHuxoq8PyjdT3BHS2LiPrs2Cg

Two distinct paths so `-overlays-label-0` and `-capture_base` using `CESR SAD Path Language`[CESR-proof] syntax. In such example two different identifers have signed parts of the Bundle, `capture-base` and `label` overlay for `en` language specifically.

### Refs:

\[CESR\]: https://weboftrust.github.io/ietf-cesr/draft-ssmith-cesr.html
\[CESR-proof\]: https://weboftrust.github.io/ietf-cesr-proof/draft-pfeairheller-cesr-proof.html
\[VC\]: https://www.w3.org/TR/vc-data-model/#proofs-signatures