Re: [Multiformats] Multiformats Considered Harmful

[Orie Steele <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multiformats
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>