CBOR Object Type Extension (COTX)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 June 2023.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

This specification introduces a method for augmenting data expressed in the CBOR [RFC8949] notation, with a text based type identifier mechanism.¶

The primary purpose is to enable developers defining application specific type identifiers without necessarily having to go through an external registration process. Using URLs [URL] should due to their ubiquity be a candidate for CBOR based applications. See also Appendix A.¶

This specification is also intended to provide a path for ISO using CBOR as a possible alternative to XML by supporting their current URN [RFC8141] based identifier naming scheme. See also Appendix B.¶

By applying the typing scheme to top level CBOR objects, additional functionality is enabled including:¶

• Support for embedding an object in other CBOR and non-CBOR constructs, as well as storage in databases, without being forced adding information about the object.¶
• Remove the need for application specific media types. In most cases "application/cbor" suffice.¶

2. Specification

This specification builds on the CBOR [RFC8949] tag feature (major type 6), by defining a fixed tag with the preliminary decimal value of 1010. See also Section 3.¶

This tag MUST in turn enclose a CBOR array (major type 4) with two elements, where the first element is assumed to contain an object type identifier in textual format, while the second element holds the actual object (instance) data. The type identifier MUST be a valid CBOR text string (major type 3), while the only constraint on the targeted object is that it MUST be a valid CBOR object.¶

The syntax expressed in CBOR diagnostic notation (section 8 of [RFC8949]) would read as:¶

    1010([Object Identifier, Object Data])¶

Note that real-world usages will typically impose constraints like requiring object identifiers to be expressed as HTTPS URLs etc.¶

1010(["https://example.com/myobject", {
  1: "data",
  2: "more data"
}])

D9 03F2                             # tag(1010)
   82                               # array(2)
      78 1C                         # text(28)
         68747470733A2F2F6578616D706C652E636F6D2F6D796F626A656374
                                    # "https://example.com/myobject"
      A2                            # map(2)
         01                         # unsigned(1)
         64                         # text(4)
            64617461                # "data"
         02                         # unsigned(2)
         69                         # text(9)
            6D6F72652064617461      # "more data"

3. IANA Considerations

In the registry [IANA.cbor-tags], IANA is requested to allocate the tag defined in Table 1.¶

4. Security Considerations

This specification inherits all the security considerations of CBOR [RFC8949].¶

URL-based type identifiers MUST NOT be used for automatically downloading CBOR schema data like CDDL [RFC8610] to CBOR processors, since this introduces potential vulnerabilities.¶

The availability of type information does in no way limit the need for input data validation.¶

For signed CBOR objects, it is RECOMMENDED to include the type identifier extension in the signature calculation as well. The same considerations apply to encryption using AEAD algorithms.¶

Appendix A. URI and URL Identifiers

The primary reason for using URI or URL [URL] based identifiers is for maintaining a single name-space for the entire specification of a system. Note that the referenced URL specification does not distinguish between URIs and URLs.¶

This non-normative section describes different methods for dealing with identifiers expressed as URIs or URLs.¶

Appendix B. URN Identifiers

ISO currently use URN [RFC8141] [RFC5141] based identifiers like "urn:iso:std:iso:20022:tech:xsd:pain.001.001.10" for data definitions using XML schema [XSD]. This method could be applied to CBOR and CDDL [RFC8610] as well.¶

Acknowledgements

People who have contributed with valuable feedback to this specification include Christian Amsüss, Carsten Bormann, and Joe Hildebrand.¶

Document History

[[ This section to be removed by the RFC Editor before publication as an RFC ]]¶

Version 00:¶

• Initial publication.¶

Version 01:¶

• IANA reference update.¶

Version 02:¶

• Made type identifier a CBOR text string.¶
• Wordsmithing.¶

Author's Address