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