Re: Question on use of base64 vs base64url in modern specifications

I’ll ask the “elephant in the room” question…

Given that *none* of the options mentioned below (Base58 & its variants, Bech32, multihash, etc.) are standardized by any recognized SDO –  nor are any of them even on an active standards track - why would you use them?

If you goal is to write a new standard – eg. DID – then wouldn’t you want to base it on other pre-existing standards?  If you make it require other not-yet-standards, then you will tie your ability to become a standard to their becoming standards – since you can’t have a normative reference to something that is “behind you” in the standardization process.  (this is true for every SDO I’ve worked with including W3C, ISO, and ETSI).

Leonard

From: yancy ribbens <yancy.ribbens@gmail.com>
Date: Sunday, April 26, 2020 at 3:39 PM
To: David Chadwick <D.W.Chadwick@kent.ac.uk>
Cc: "public-credentials@w3.org" <public-credentials@w3.org>
Subject: Re: Question on use of base64 vs base64url in modern specifications
Resent-From: <public-credentials@w3.org>
Resent-Date: Sunday, April 26, 2020 at 3:37 PM

I'm not sure I understand when a key would be ephemeral.  In DID use cases, there are interactions that could be done machine to machine using QR codes or some other mechanism.  I'm not sure I understand the draw-back of allowing for an encoding that's human readable even if ti's unlikely to be used often or ever.  Base58 and Base58-check are well tested encodings that are fault tolerant and the latter provides error detection.  As was mentioned in a previous email by Christopher, the future will likely be bech32 (see bip32 https://github.com/sipa/bech32/issues/51<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsipa%2Fbech32%2Fissues%2F51&data=02%7C01%7Clrosenth%40adobe.com%7C8ac729de5816494d513308d7ea1979a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637235267454336859&sdata=DPeC%2FjU%2B3E440%2B34PwscVlO9TgsjgBM0hJrJ5aXZjCw%3D&reserved=0>) which provides error correction as well.  However, bech32 is not as well understood as base58 and there are still bugs being corrected: https://github.com/sipa/bech32/issues/51<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsipa%2Fbech32%2Fissues%2F51&data=02%7C01%7Clrosenth%40adobe.com%7C8ac729de5816494d513308d7ea1979a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637235267454336859&sdata=DPeC%2FjU%2B3E440%2B34PwscVlO9TgsjgBM0hJrJ5aXZjCw%3D&reserved=0>.

Cheers,
-Yancy

On Sun, Apr 26, 2020 at 2:12 PM David Chadwick <D.W.Chadwick@kent.ac.uk<mailto:D.W.Chadwick@kent.ac.uk>> wrote:

On 27/04/2020 06:22, Dmitri Zagidulin wrote:
>
>     IMO, saying it's "multicodec / multibase" is about a billion times
>     better than saying "its base64 / base58".
>
>
> Absolutely agree there. Multicodec and multibase are, I think, a must,
> in terms of clarity, future-proofing, and so on.
>
> I do want to say something about the merits of base58 for all key
> representations and anything DID-related. Also, I agree with your 3
> layer approach. Except that to me, 3rd layer is not optional.
>
> > Layer 3 represents why i dislike base58... who cares if "I" and "l"
> look similar...
>
> We care. We *all* care, eventually. Because despite all of our best
> actions to prevent humans from ever dealing with raw key material or
> DIDs (and we *should* do our best to prevent that, it should always be
> mediated by convenient software)... there WILL come a point where
> you're typing in your key or DID or whatever, from backup. You WILL be
> reading that gobbledygook string to your uncle over the phone. Yes,
> those cases will be exceedingly rare. But when they do happen, you
> will be intensely glad that you can tell a lowercase L from an
> uppercase i.

But if the key is ephemeral then it wont even be exceedingly rare, it
will be never. So we dont need human readability for machine-only used
ephemeral keys

Kind regards

David