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

+1

On 27/04/2020 08:08, Leonard Rosenthol wrote:
>
> 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
>

Received on Sunday, 26 April 2020 21:56:44 UTC