W3C home > Mailing lists > Public > public-credentials@w3.org > April 2020

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

From: yancy ribbens <yancy.ribbens@gmail.com>
Date: Sun, 26 Apr 2020 14:37:09 -0500
Message-ID: <CAOLy5tZLYedREZwK561bTUAJ4AngYsXqSXo8JTp0UVWg6LVhpg@mail.gmail.com>
To: David Chadwick <D.W.Chadwick@kent.ac.uk>
Cc: public-credentials@w3.org
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) 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.

Cheers,
-Yancy

On Sun, Apr 26, 2020 at 2:12 PM David Chadwick <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
>
>
>
Received on Sunday, 26 April 2020 19:37:34 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:58 UTC