Re: [Multiformats] Multiformats Considered Harmful

Not sure why I got added to this thread (I guess because I talked to Orie
:) ), but overall I endorse the objections that Mike and Orie raise.

As I understand it, the reason multiformats exist is basically that the
blockchain community failed to organize itself well enough to agree on an
encoding, so there was a need to shove multiple encodings into a slot and
let the recipient figure it out.  While this seems to be a common pattern
in some W3C spaces (e.g., VC, DID), it is a compatibility nightmare, and is
not something we should build standards around.  Much like DID,
multiformats is a fine hack to multiplex multiple things into a single
slot, but one that should at best be documented for historical purposes
while we build forward to a common thing, not held out as in any sense a
good thing to do.

--Richard

On Wed, Sep 6, 2023 at 3:53 PM Michael Jones <michael_b_jones@hotmail.com>
wrote:

> 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> 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> 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
> https://www.ietf.org/mailman/listinfo/multiformats
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE *Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries/>
>