Re: [Multiformats] Multiformats Considered Harmful

For the benefit of those added to the thread, you can read my original message that this is response to at https://self-issued.info/?p=2408.

                                                       -- Mike

From: Orie Steele <orie@transmute.industries>
Sent: Wednesday, September 6, 2023 12:47 PM
To: Carsten Bormann <cabo@tzi.org>
Cc: Michael Jones <michael_b_jones@hotmail.com>; multiformats@ietf.org; Murray Kucherawy <superuser@gmail.com>; Barry Leiba <barryleiba@computer.org>; Francesca Palombini <francesca.palombini@ericsson.com>; Roman Danyliw <rdd@cert.org>; Paul Wouters <paul.wouters@aiven.io>; Russ Housley <housley@vigilsec.com>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; Richard Barnes <rlb@ipv.sx>
Subject: Re: [Multiformats] Multiformats Considered Harmful

I'll comment in the context of the experience working with multicodec and multibase at W3C.

And include a few folks I spoke with regarding this topic at the last IETF.

We implemented support for publicKeyMultibase, and helped register the NIST curves in order to be able to do "key translation" required to use Decentralized Identifiers or Verifiable Credentials.

https://github.com/multiformats/multicodec/pull/190

We've also used multibase encoded "proofValue" in JSON-LD / RDF to encode various kinds of Data Integrity Proofs:

https://github.com/w3c/vc-data-integrity

The 2 primary points of connection to W3C for this work are "encoding key representations" and "encoding signature / proof values"... not just encoding hashes as strings, although that is also commented on https://github.com/search?q=repo%3Aw3c%2Fvc-data-integrity%20digestMultibase&type=code ...

I'd add that digestMultibase is positioned as competing with digestSRI, and the W3C working group has no consensus on if it's worth not being compatible with SRI... In very much the same way the working group can't agree to recommend using publicKeyMultibase over publicKeyJwk... It's possible that might change in the current verifiable credentials working group, if it does not, that would also prove my general point regarding helpfulness.

W3C specifications do not require, prefer or recommend multibase.

Data Integrity - https://github.com/w3c/vc-data-integrity which is on track to become a technical recommendation is, afaik, the sole exception to this, `proofValue` MUST be encoded as multibase... This is a part of what is motivating the need to move multibase to an organization that can be referenced normatively by W3C, without producing their version of a downref.

Some members of W3C want to position multibase keys and signatures as recommendations, and there seems to be a good amount of overlap with folks wanting to position data integrity proofs, which are similar to xml digital signatures, as the recommended way to encode verifiable credentials with security.

Everything these folks are recommending can be solved for with standards that are available today, many of which have lots of off the shelf implementations and are widely adopted in protocols for moving JSON based data models (JOSE, OAuth, OIDC).

Having spent a lot of time implementing support for multibase in the context of DIDs and VCs our conclusion is that they are not "worth the switching cost" relative to JOSE... COSE support is worth the switching cost, but it's not compatible with the W3C Data Model approach which is based on JSON-LD and RDF.

The primary point I want to make is this:

Adding many ways to do the same thing, with very little benefit over the existing ways is not helpful.

Adding new ways to do old things that are not an improvement worth paying to upgrade too, is also not helpful.

It creates a fertile garden bed of bugs and consulting opportunities, which can reduce security and drive up costs for regulators and commercial markets needing to implement standards, without benefiting end users, who we are here to serve.

To be clear, there is nothing wrong with preferring base58btc over base64url, or uvarint prefixing over cbor tagging... But there is a lot wrong with forcing verifiers and relying parties to support "every binary encoding format multiplied by every registered public key or hash type"... it's better to not publish a standard, than it is to do this.

I don't see how multiformats does not leave the verifier or relying party holding this bag, along with all the other burdens they are required to carry already (JOSE, COSE, etc...), and if they can't handle it, or they handle only part of it, the consumer / end user does not get the benefit.

I don't think the work should be done... If it is done, or continues to be done (since it's happening at W3C regardless of progress in IETF), I think it will continue to cause harm to the use cases that it's supposedly being done to support.

Specifically ensuring end users can control their own identifiers and credentials, and that verifiers (governments, organizations, hardware systems and other users) can automate compliance requirements built on digital trust ecosystems.

I have a lot of respect for the people involved with the work, in particular Protocol Labs & Digital Bazaar, even if I don't think this particular approach should become an IETF standard.

Regards,

OS

On Wed, Sep 6, 2023 at 3:45 AM Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>> wrote:
RFC 6256, which was used in the bundle protocol v6, before they switched to CBOR for v7
Sent from mobile, sorry for terse

On 6. Sep 2023, at 10:09, Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>> wrote:
Leb128 (not sure that the drafts call it by its common name) is the little endian variant of sdnv, which we do have as an rfc (please look that up for me…)
--
Multiformats mailing list
Multiformats@ietf.org<mailto:Multiformats@ietf.org>
https://www.ietf.org/mailman/listinfo/multiformats

--

ORIE STEELE
Chief Technology Officer
www.transmute.industries<http://www.transmute.industries/>

[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>