Re: [Multiformats] Multiformats Considered Harmful

[bumblefudge von CASA <[e-mail]>]

Dear Orie:

Thanks for your two emails expanding on Mike's arguments with your experiences implementing at W3C: showing your notes in such detail is generous and helpful. Unfortunately, however, my answers to your version aren't much different than my answers to Mike's. The argument is 80% politics and 20% helpful suggestions for improving the submitted documents.

Most of the politics are W3C politics or otherwise external to IETF. I do not think the IESG should be burdened by what a W3C WG is enabled to do if IETF hardens a version of a widely-deployed protocol used in P2P data systems. Appealing to the IETF leadership's feelings about the DID/VC work or about blockchains smacks of guilt-by-association, since neither DIDs nor key discovery nor blockchains in general nor Filecoin specifically are targeted use-cases or mentioned in the documents under discussion. The insinuation that my volunteer work on DIDs at W3C or my dayjob preaching standardization in the blockchain salt mines "motivates" "[moving] multibase to an organization that can be referenced normatively" is an ad hominem cherry on an off-topic sundae.

The remaining IETF politics relate to a having-cake-and-eating-it-too claim about duplicative protocols. Either multiformats is *entirely* duplicative and redundant, in which case it could be argued to be harmful to the established protocols with which it shares some goals, or it *partially* overlaps with those protocols, in which case it complements them and could enable new combinations if sliced thinly and hardened well. Your two emails go back and forth on this question, both arguing that multiformats is "basically just" a CBOR tagging pattern grafted onto a protobuf trunk AND arguing that the current proposal isn't duplicative in itself, i.e. that the real harm lies many RFCs down the road when it gets profiled in ways that come closer to directly competing with IETF's current headliners. But if these proposed RFCs are just the foundations and those later downstream profiles are the problem, why not block those future RFCs and let other things be built on these foundations? It's a "time machine to kill Hitler" argument, which flatters multiformats in how much harm it imagines multiformats doing.

As for breakage, I already addressed this twofold: I want breakage balanced against costs to legacy production deployments like any other specification-hardening work, and I want work items sequenced so as not to unduly stack the cards against breakage if it proves necessary.

All that said, I thank you for bringing an implementer's perspective on switching costs and protocol abundance-- the burden of proof is on the working group to document better the benefits and complementarity to prior art, and I'm sorry to hear that you are not yet seeing enough of either to support the work.

Warm regards,
__juan

On 06/09/2023 21:46, Orie Steele wrote:

> 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 STEELEChief Technology Officerwww.transmute.industries
>
> https://transmute.industries

---
bumblefudge
janitor [@Chain Agnostic Standards Alliance](https://github.com/chainagnostic/CASA)
contractable via [learningProof UG](https://learningproof.xyz)
mostly berlin-based