Re: [Multiformats] Multiformats Considered Harmful

[Melvin Carvalho <[e-mail]>]

čt 7. 9. 2023 v 22:16 odesílatel Richard Barnes <[e-mail]> napsal:

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

For context, the predominant deployment within the blockchain realm employs
the bech32 serialization for hashed keys, notable for its efficient error
correction and the exclusion of certain characters. However, I observed
that this isn't encompassed in the multiformats specification. Although
termed "universal", the specification appears to selectively include
certain serializations while omitting others.


>
> --Richard
>
> On Wed, Sep 6, 2023 at 3:53 PM Michael Jones <[e-mail]>
> 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 <[e-mail]>
>> *Sent:* Wednesday, September 6, 2023 12:47 PM
>> *To:* Carsten Bormann <[e-mail]>
>> *Cc:* Michael Jones <[e-mail]>; [e-mail];
>> Murray Kucherawy <[e-mail]>; Barry Leiba <
>> [e-mail]>; Francesca Palombini <
>> [e-mail]>; Roman Danyliw <[e-mail]>; Paul
>> Wouters <[e-mail]>; Russ Housley <[e-mail]>;
>> Henk Birkholz <[e-mail]>; Richard Barnes <
>> [e-mail]>
>> *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 <[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/>
>>
> --
> Multiformats mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multiformats
>