Remove references to multibase

[selfissued]

proofValue is defined as:

A string value that contains the data necessary to verify the digital proof using the verificationMethod specified. The contents of the value MUST be a [MULTIBASE]-encoded binary value.

Multibase is not a standard and may never become one. Please change the definition of proofValue to utilize a standard encoding. My preference would be for it to use the base64url encoding.

[OR13]

previously discussed in https://github.com/w3c/vc-data-integrity/pull/92

Which later led to:

• https://github.com/w3c/vc-data-model/issues/1261
• https://github.com/w3c/vc-data-model/issues/1175

[BigBlueHat]

Multibase is already normatively referenced in DID-CORE, fwiw.

[OR13]

Can someone answer this gentleman's question here https://github.com/w3c/did-core/issues/405#issuecomment-1719869201

[iherman]

The issue was discussed in a meeting on 2023-09-14

• no resolutions were taken

View the transcript

#### 3.1. Remove normative dependencies on multibase (issue vc-data-integrity#191) _See github issue [vc-data-integrity#191](https://github.com/w3c/vc-data-integrity/issues/191)._ **Michael Jones:** in doing due diligence on IETF standardization on mutlibase I discovered a normative dependence on multibase in DI, even though it's not a standard. we shouldn't be doing that. we shouldn't take normative deps on non-standards. requesting in #191 the definition of proof be changed to not use multibase. > *Dave Longley:* [https://w3c.github.io/vc-data-integrity/#resource-integrity](https://w3c.github.io/vc-data-integrity/#resource-integrity) <-- see "At risk" on what selfissued just said. **Sebastian Crane:** been discussing a lot on how to proceed. one option is to include the definitions inside the specification, since multibase is not a complex format and it is stable. can be in DI itself. � in the future can add an IETF normative dependency. **Dave Longley:** as seabass said, we have a feature at risk in the spec for exactly this reason. don't think it's a pre-CR issue. we can change the current CR to fix this language as necessary. **Manu Sporny:** to Mike - was your objection to the normative reference or the use of multibase at all? it is marked at risk. currently all implementers we have are using multibase. asking them to change their implementations would be problematic. would like to understand your concerns more. **Michael Jones:** I have objections to both. procedurally, normative reference is a stronger argument for the working group since we agreed to not normatively use non standard features - so it has to go. many of you are aware, I wrote a piece 'multiformats are considered harmful' and asked it not be a candidate for IETF standardization. currently being discussed on the mailing list. > *Andres Uribe:* Details in [https://self-issued.info/?p=2408](https://self-issued.info/?p=2408). **Michael Jones:** philosophically against multiformats since it does not make a choice. different impls may make different choices - base10, 32, 58, 64... they won't interoperate. interoperation is facilitated by making a choice, multibase is a failure to make a choice. make a choice! **Brent Zundel:** appreciate that there's a feature at risk tag. is the intention, should multibase not be standardized by the time this moves from CR to REC, would the current link be moved to a non normative reference? **Sebastian Crane:** (responding to Mike) the more choices the more interop you get ... need to facilitate ease of interop. having metadata is useful. would it be acceptable, if in data integrity, we limited which encodings would be used? e.g. saying you must use base64, but encode with the right multibase header. **Manu Sporny:** 3 things. Mike said that WGs can't cite things that are not at the same level of maturity from a standards perspective - not correct. if a WG can demonstrate that a normative dep wont change, then it's fine to cite it. we're doing that with JSON Schema - not an IETF RFC, but we have a specification, went through a lot of discussion at the W3C, has way more dependencies which could be changed. � don't think this is a reason to not have normative dependencies. we use 2 multibase values: z and u, that's it. we could get rid of the normative link, define the headers in our spec to address it, but the normative dep is defensible since those values haven't changed in years and wont change since they're used in other production systems. � as Ivan notes, schema.org is used. allowed to normatively reference it if its not expected to change and this isnt. � you asked for a single base encoding on what we're using, not allow any random base encoding...this is what we do in our suites. a different crypto suite may choose a different encoding. limiting what every cryptosuite can do seems problematic. in this WG we have picked one base encoding format. the basis for your objection is unfounded. � (to Brent) ... can we remove the ref at a later date if it doesn't surface at IETF? yes we can do that, and we can specify the 'z' and 'u' values in our specification. **Michael Jones:** you could remove the reference now and not break uses of b64 encoding if you said the value is the character 'u' + b64 proof value. I could live with that, but think its unnecessary. choosing one is making a choice, then won't need the ref at all. **Manu Sporny:** I am hearing you would not object to us using a header, and pick b64 for everything. the reality for the implementations is not that. implementers have gone another way. we provide a header so people know what the base encoding format is. we could remove the normative ref to multibase and then have a header as a compromise. **Sebastian Crane:** if that satisfies Mike I am happy to make that compromise myself and make it an informative reference. we are waiting for the spec to catch up. **Dmitri Zagidulin:** Is b64url itself an RFC? **Brent Zundel:** answer is yes. � are you and Sebastian as editors ok with addressing this issue? > *Gabe Cohen:* manu/seabass: yes. **Sebastian Crane:** not sure the comparison to b64url ... **Michael Jones:** you can read about it in RFC 7515. **Ivan Herman:** vocab has to change as well, since multibase is in the vocab now. � you don't have to answer now, tell me when you go to change the PR. > *Sebastian Crane:* +1 then. **Manu Sporny:** I will think about you Ivan. > *Ivan Herman:* :-). > *Dave Longley:* +1 to run proposal inclusive of the changes being discussed. **Manu Sporny:** let's run a proposal and then given that...advance to CR. **Sebastian Crane:** (to summarize) - we are going to, in the cryptosuites, to have a specific encoding, for the spec text we are using a format compatible with multibase, so that if it becomes a standard we will use it normatively. we won't publish a normative ref if it's not ready by REC. **Manu Sporny:** yes matches my understanding. > *Benjamin Young:* +1 to seabass's summary.

[msporny]

PR #196 has been raised to address this issue. This issue will be closed once PR #196 is merged.

[msporny]

PR #196 has been merged, closing.