CBOR Representation

There were a number of explicit and implicit questions that went
unanswered during the "At Risk" portion of the call today due to time
constraints. I'm making an attempt at answering them here in case that's
useful to those that had the same questions.

First, Christopher's concrete questions:

1. What is the relationship with other organizations (having to register
CBOR tags with IETF)?

If we need to register new CBOR tags at IANA:

https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

... then we'll need to consider the time it takes to register those
things and get a review on the new tags into our timeline. The number
and type of new tags will affect the complexity and time and it takes to
complete that process.

2. What is the relationship with how much we have to do with a method,
vs. what needs to be done in the DID spec.

It depends -- but, ideally, DID Method specifications won't have to do
anything because the CBOR representation would be standard across all
DID Methods.

One of the dangers of not specifying a CBOR representation is that
ad-hoc CBOR representations pop up.

> For example, if i can take any conformant JSON-LD doc and
> convert it to CBOR, do i even care if the DID spec allows for
> CBOR?

You could do a 1-to-1 translation. It wouldn't give you most of the
benefits of CBOR, but you can do it in a loss-less way today.

> Did we say we may have to  conform with protocols labs
> things? they are neither a standards organization nor a
> standards implementation organization

There are sections in the specification that loosely refer to DagCBOR,
which is an IPLD mechanism that requires no tags be used other than IPLD
content identifiers. It's not clear when one would use DagCBOR vs.
regular CBOR.

> jonathan_holt: if i were to have a second implementation,
> e.g. i fork indy and i add CBOR, is that sufficient?

This would not be sufficient because the W3C Process requires that
implementations come from two independent implementers, ideally reading
only the specification and implementing to the specification. The reason
this requirement exists is to ensure that two people reading the same
specification would implement the normative parts of a particular
feature in a way that is interoperable (by only reading the
specification). We do this to try and drive out any tribal knowledge and
ensure that this is all written down in a way that people outside of the
tribe can understand.

More specifically, Jonathan, that no one has engaged on the CBOR stuff
is a data point. It probably means that people are too busy to give it
their time right now, which means that you're the only one with your eye
on the ball, which means that the feature isn't meeting the requirement
of wide review (to make sure you didn't miss anything).

Additionally, of concern is that the COSE part of the specification at
present forbids at least a few key optimizations that we'd get from
using a CBOR representation. For example: The current spec text
asserting that "Map keys MUST be strings" ensures that semantic
compression (CBOR-LD uses this) will not be possible for DID
Documents... we'll be stuck with a CBOR representation that eschews one
of the driving reasons behind CBOR (more compact representations). That
is, we'll not be able to compress "publicKeyBase58" to a 2-5 byte value
(resulting in something that is 300% the size it should be).

That last item, and the items that Christopher raises are, I expect,
just the tip of the iceberg. I wouldn't underestimate how much work it
will be for the group to get to consensus on a CBOR representation that
will work for the pure JSON/CBOR, IPFS, CBOR-LD, etc. communities... and
then write the test suite tests that test all of the normative CBOR
statements in the specification.

Hope that helps provide some additional context around the CBOR
Representation and the at-risk concern.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Tuesday, 30 June 2020 18:11:03 UTC