Re: [Multiformats] Multiformats Considered Harmful

[Orie Steele <[e-mail]>]

I'm sorry if the connection point to W3C work is tough to follow, here are
the points of overlap:

> The outputs from this Working Group are currently being used by various
groups, including the *W3C Verifiable Credentials Working Group*, *W3C
Decentralized Identifiers Working Group*, Conexxus Age Verification Working
Group, *W3C Dataset Canonicalization and Hashing Working Group*, *GS1
Verifiable Credentials*, and online communities such as the *W3C
Credentials Community Group* and Interplanetary File System developer
community.

-
https://github.com/msporny/charter-ietf-multiformats/blob/main/README.md?plain=1#L33

However, as you pointed out... the current proposed charter scope covers
multibase and multihash, not the *multicodec* (which extends multihash) and
includes key format representations...

- https://github.com/multiformats/multicodec/blob/master/table.csv#L9
- https://github.com/multiformats/multicodec/blob/master/table.csv#L97

... and yet some of the W3C TRs cited in the charter are using multicodec
not just multibase and multihash.

-
https://github.com/search?q=repo%3Aw3c%2Fvc-data-model%20publicKeyMultibase&type=code
(Verifiable
Credentials Data Model v2.0)
-
 https://github.com/search?q=repo%3Aw3c%2Fvc-data-integrity%20publicKeyMultibase&type=code
<https://github.com/search?q=repo%3Aw3c%2Fvc-data-integrity%20publicKeyMultibase&type=code>
(Verifiable
Credential Data Integrity 1.0
-
https://github.com/search?q=repo%3Aw3c%2Fdid-core%20publicKeyMultibase&type=code
(W3C
Decentralized Identifier Specification v1.0)

Additionally this community group draft:

https://w3c-ccg.github.io/did-method-key which is not a W3C TR, but which
defines public keys exactly the same way as publicKeyMultibase does, and
was cited as a candidate for standardization in the latest proposed W3C
DIDWG charter, which caused formal objections:
https://github.com/w3c/did-wg-charter/pull/27

My take on what W3C would use from multiformats after a few chartered
working groups (assuming what I have heard people say they want to do is
true) is as follows:

1. W3C Decentralized Identifiers will use multiformats for expressing
public key material, hash links
https://datatracker.ietf.org/doc/draft-sporny-hashlink, and data integrity
proofs securing DID Documents.
2. W3C Verifiable Credentials will use multformats for expressing public
key material, data integrity proofs, digests of JSON-LD context files, and
digests of svg files https://w3c-ccg.github.io/vc-render-method

IPFS and IPLD will continue to use multiformats for CIDs, and perhaps CIDs
will be standardized somewhere eventually (maybe at IETF?)

Cloudflare hosts an IPFS gateway btw:
https://developers.cloudflare.com/web3/ipfs-gateway

I've used IPFS for several things, and I generally enjoy the experience of
CIDs.

I *really* don't enjoy seeing the other experimental multicodec stuff
injected into every specification at W3C that needs to represent binary in
JSON-LD and is related to identity or credentials, because I don't think
JSON-LD really benefits from `@type`, `https://w3id.org/security#multibase`
(
https://github.com/w3c/vc-data-integrity/blob/main/contexts/data-integrity/v2#L68)
over
`https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#hexBinary`....

As a broader point, I question the general value of JSON-LD, over say CBOR
or ProtocolBuffers, in modern security oriented data models and protocols,
and the coordination between multiformats and JSON-LD raises my suspicions
about the soundness of W3C security specifications... Obviously you don't
need to use JSON-LD to use multiformats, but I doubt anyone reading W3C
specs would come to that conclusion based on what is in the documents
linked above.... The documents make it appear that multiformats are
mandatory to support, when they are not.

As I have said before, I don't think it's a great experience to have to
implement several different base encodings, when one binary text encoding
would have sufficed for protocol interoperability.

Regards,

OS


On Thu, Sep 7, 2023 at 10:44 PM bumblefudge von CASA <
[e-mail]> wrote:

> 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 STEELE Chief Technology Officer www.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
> --
> Multiformats mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multiformats
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>