Re: CBOR Representation

On Tue, Jun 30, 2020 at 11:12 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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.
>

We (Blockchain Commons) is making great progress with alignment with a
number of cryptocurrency wallet vendors working together on standards for
interoperability, with a focus on QR scenarios. Still a lot to do (this
week, fountain codes for QRs) but making progress.
https://github.com/BlockchainCommons/Research

In particular, the self-describing conciseness of CBOR is powerful. This
enables us to do some useful tricks for to make very compact QRs and
readable over phone mnemonics:

   - Hex Shamir secret : d901355576220220b86ab8636212aab84200a070975a641972


   - As Bytewords (basically a mnemonic replacement for hex encoding, with
   a VERY carefully selected wordlist):

tuna acid epic gyro keno cusp also crux redo item

redo idea iced brag peck redo flew able numb judo

miss heat idle chef jump fern navy kite luau


   - As a UR (QR-compressible, URL-safe, double-clickable conversion of
   mnemonics to 2-letter hex equivs)
   ur:crypto-sskr/taadecgokocpaocxroimroiaidbgpkrofwaenbjomshtiecfjpfnnykelu


   - Annotated Byteword (basically breaking out the mnemonics as CBOR):

tuna acid epic gyro -- identifies that this is an SSKR share and the length
of the data that follows

keno cusp -- same for every share in split

also crux -- same for every share in group

redo item redo idea iced brag peck redo flew able numb judo miss heat idle
chef jump

fern navy kite luau -- checksum


   - We also have some "brutal" tricks where we leave out some common CBOR
   information if you can infer it from the protocol context. The checksums
   are the same, so you have to re-insert the CBOR stuff, but it can decrease
   size significantly in QRs. I've heard that Digital Bazaar may have some
   other CBOR compressions tricks.

It could be that we should add a QR scenario to the DID use cases document.
We are using it with cryptocurrencies for airgap between devices to
mitigate a number of security issues. I plan to use QRs and mnemonics for
my trustless DIDs implementations as well, not just for basic crypto
(seeds, master keys, derived keys, signatures, VCs, directed capabilities,
social secret recovery, social authorization recovery) but also for DID/VC
requests, authentication and authorization flows.

On Tue, Jun 30, 2020 at 11:12 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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).
>

This worries me. Things like account descriptors and partially signed
transaction requests are full of cryptographic primitives, and we need them
to be as concise as possible to work with QRs.


> On Tue, Jun 30, 2020 at 11:12 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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.
>

Let me raise one that I voiced but I don't think was well enough described
to be heard.

How little can we enable CBOR in the DID spec such that it can be used in a
more complete form by methods?

I was also very confused by the language CBOR-only (the "-only" part), as
that meant to me that it was like JSON-only's relationship/compatibility
with JOSE, and thus meant to me was explicitly COSE, i.e. JSON-only but
doesn't break LD but doesn't support it either. It sounds like no one is
working on that.

But Jonathan's CBOR proposal not only isn't COSE either but instead
includes stuff that makes it not quite a CBOR-LD either, as it is full of
IPLD stuff from Protocol Labs. It could be that I could support that, but
it feels like it may add yet more not only technical complexity but
standards process complexity (i.e. how do we get IP assignments from all
the contributors to IPFS specs?).

— Christopher Allen