Remove multibase requirement from proofValue type

[OR13]

Including this requirement forces implementers to bundle multibase which is not yet a standard.

it also forces them to bundle multformats which is not a standard.

Bundling base58btc and base64url and others...

I suggest leaving proofType a regular string, that is understood in the context of its associated cryptosuite.

In the future, when multibase becomes a standard, it seems wise to follow the "sorta convention" established by "did core", and call the multibase version of proof;

proofMultibase - https://www.w3.org/TR/did-core/#dfn-publickeymultibase

[mprorock]

Approved, let's avoid down refs wherever possible

[msporny]

-1 for the following reasons:

• The feature does not require "bundling multiformats", as @OR13 suggests.
• The feature does not require downrefs to Multibase or Multiformats, as @mprorock suggests.
• Removing this feature is actively harmful to auto-encoders, such as CBOR-LD, which relies on the multibase tag to convert the base-encoded text value to a binary value to save space (up to 33% for base64).
• Removing this would be actively harmful for a variety of implementations that Digital Bazaar is doing for customers.
• The Multibase work is currently in the process of being either 1) adopted at IETF via a mini-WG, or 2) going the ISE route (at which point we can provide a normative link).

[dlongley]

-1 for the same reasons noted by @msporny above.

[msporny]

@OR13, given the discussion on the call yesterday, are you going to still pursue this PR, or are you comfortable now that what you were concerned about was not the intent of the spec text? If so, please close the PR. If not, please provide guidance on how the spec could change to convey what we discussed yesterday (ideally, by raising another PR).

[OR13]

I'd like to see reference to base64url in the spec, here: https://w3c.github.io/vc-data-integrity/#multikey

As we discussed on the call, u +

examples for both keys and signatures.

[msporny]

I'd like to see reference to base64url in the spec, here: https://w3c.github.io/vc-data-integrity/#multikey

As we discussed on the call, u +

examples for both keys and signatures.

The normative requirements and the concrete examples for both keys and signatures happen in the cryptosuites:

https://w3c.github.io/vc-di-eddsa/#data-model

I expect the u Multibase value to be used in the vc-di-bbs cryptosuite.

Once they're in each cryptosuite, we might want to also mention them in https://w3c.github.io/vc-data-integrity/ ... but we might want to do that just before, or during CR. It could be argued to be an Editorial change since we're just moving normative content between a family of specifications.

My preference would be to have Multikey defined in the VC Data Integrity specification, but have been holding off on doing that until we have more people requesting that we consolidate the normative definitions.

If we can get more support from the WG to put just 'z' and 'u' Multibase definitions in VC Data Integrity, as well as the Multikey definitions in VC Data Integrity and just have the other specs refer to the core spec (but allow other cryptosuite definitions to extend/use different base and key formats, if they have good reason to do so), then that would be a good sign to consolidate.

In the very least, we need to know that people aren't going to object if we start defining that stuff more generally/normatively in VC Data Integrity.

[OR13]

I'm going to close this, given the working group seems to have resolved to support multikey, and we are allowed to use both base58btc and base64url.

See the minutes related to #93