**Session Date/Time:** 31 May 2023 14:00

# [CBOR](../wg/cbor.html)

## Summary

The CBOR Working Group discussed the Deterministic CBOR (DCBOR) Internet Draft, focusing on its proposed numerical reduction for supporting weakly-typed languages and ensuring deterministic encoding. Key discussions revolved around disentangling the document's normative, API, and tutorial components. Additionally, the proposal for standardizing a set of CBOR tags for generic graph data structures (Gordian Envelope) was presented, with a suggestion to coordinate with the SCITT working group. Action items were identified for advancing the DCBOR document and exploring the graph data tags with relevant communities.

## Key Discussion Points

### Deterministic CBOR (DCBOR)

*   **Document Update**: Christopher Allen provided an update on the latest DCBOR Internet Draft. API recommendations have been de-emphasized and moved to a different section, and the numerical reduction section was expanded.
*   **Working Group Adoption**: The chairs sought group consensus on officially adopting the DCBOR proposal as a working group item. Carsten Bormann expressed reservations due to the document containing disparate elements (normative encoding, API recommendations, tutorial content) that need to be disentangled before adoption.
*   **API Recommendations**: Christopher Allen explained his motivation for including API recommendations, stating that determinism requires support from how codecs are used, not just the normative protocol. He clarified that these are not normative in the current draft.
*   **Numerical Reduction**:
    *   **Rationale**: Christopher highlighted that numerical reduction primarily benefits languages without a strong hierarchy of numerical types (e.g., JavaScript, Ruby), where a generic "number" type makes it problematic to work with fixed-size types. The goal is to allow engineers to present a numerical value and have it deterministically encoded without loss of precision (e.g., 3.0 as integer 3), reducing cognitive burden. It also streamlines handling in strongly-typed languages.
    *   **Carsten's Concerns**: Carsten questioned why the integer/float boundary was chosen for this reduction, contrasting it with the established distinction between text strings and byte strings in CBOR. He recalled that CBOR's founding principle was to clarify such distinctions, and 8949 specifically moved to separate integers and floating-point numbers due reversing earlier thinking (circa 7049). He expressed surprise at moving this numerical mapping into CBOR's deterministic encoding, as implementers in constrained and high-performance systems preferred keeping floating-point and integer data separate.
    *   **Christopher's Response**: Christopher reiterated that the need for deterministic encoding of numbers is driven by implementers at Blockchain Commons working with signed data at rest across diverse and constrained devices (e.g., MicroPython). The numerical reduction is seen as generically useful and should be pushed down to the CBOR layer.
    *   **Layering Suggestion**: Carsten suggested that DCBOR could be framed as defining a *new information model* on top of the generic CBOR information model, where all numeric types are equivalent, with precise rules for encoding into CBOR. This might help clarify the layering.

### CBOR Tags for Graph Data (Gordian Envelope)

*   **Problem Statement**: Christopher Allen introduced a proposal for CBOR tags to support generic graph data structures (Gordian Envelope), aimed at addressing IETF RFCs 6973 (privacy) and 8280 (human rights) regarding data minimization for data at rest.
*   **Proposal**: The proposal involves standardizing a set of seven (reusing one existing) CBOR tags to enable sophisticated triple stores and provide options for hash-based data minimization. This would support various graph data forms (e.g., W3C Linked Data graphs) in CBOR.
*   **Coordination with SCITT**: Carsten Bormann suggested engaging with the SCITT (Supply Chain Transparency) working group, which is addressing similar requirements for transparency registries, privacy, and Merkle trees.
*   **Scope and Layering**: Christopher acknowledged SCITT's work but expressed concern that Gordian Envelope is a more generic, fundamental building block for graph data in CBOR, not just an application-specific solution. He highlighted issues with current approaches (e.g., JSON-LD, JWT) often involving tangled layers and schema complexity, and aimed for cleaner layering with separate documents for CBOR, DCBOR, and graph structures.
*   **Signing Data at Rest**: A brief discussion revisited the trade-offs between signing data in flight (favored by Cozy) and signing data at rest (needed by Gordian Envelope), acknowledging that some applications genuinely require data at rest signing despite its complexities (e.g., JWT's issues with canonicalization, multi-signatures, and database integration).

## Decisions and Action Items

*   **DCBOR Document Refinement**: Christopher Allen, Wolf, and Carsten Bormann will collaborate to refine the DCBOR Internet Draft. This involves splitting or reorganizing the document to clearly separate normative encoding components from API recommendations and tutorial elements.
*   **Gordian Envelope Outreach**: Christopher Allen will initiate offline discussions with key drivers in the SCITT working group to explore potential synergies and contributions of the Gordian Envelope format.

## Next Steps

*   The discussion on DCBOR document restructuring and the Gordian Envelope proposal will continue on the mailing list.
*   The next CBOR Working Group call (in two weeks) will focus on preparing the agenda for the IETF July session.