Re: [MINUTES] W3C CCG Credentials CG Call - 2022-03-15

On Wed, Aug 3, 2022 at 4:24 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Tue, Aug 2, 2022 at 6:14 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
> > So perhaps there is some utility in a more generic, multihash:, scheme.
>
> Hey Melvin, a couple of other data points for you:
>
> * I've had a number of discussions with Roberto and Lucas, who are
> working on the HTTP Digest Fields specification in the IETF HTTP WG.
> The last time we chatted, which was many months ago, I was suggesting
> "mh" for the "multihash scheme". There was a general, "Ok, we'll add
> that once it's defined tenor to the call"
>
> * There are a number of us that are going to take some of the
> Multiformats specifications into the IETF, namely Multibase and
> Multihash:
>
> https://www.ietf.org/id/draft-multiformats-multibase-05.html
> https://www.ietf.org/id/draft-multiformats-multihash-04.html
>
> ... and where Multikey is going to be done is a bit up in the air
> right now. We might define it first in VCWG, and then move it over to
> IETF... or start it at IETF, we'll have to see what the VCWG wants to
> do there.
>
> One thing we could do is just define it in the Multihash I-D for now
> and then register it as a provisional scheme w/ IANA:
>
> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
>
> Thoughts?
>

Hi Manu

Thanks for the pointers.

Main motivation is to have something relatively stable so that it's
possible to start implementing without changes later that will be hard to
incorporate.

Some thoughts, in no particular order:

1. mh is registered as a digest value, but not as a URI.  Is there
intention to have mh:// URI too?  I'll not that ni:/// already has 63
entries, so do they have space for another bit, I wonder?

2. on mh: vs multihash:  the latter seems more self descriptive, but mh is
fine too, and would save several bytes, and similar to http etc.  I can
live with mh: if we decide that and dont change it.

3. Will we have mh: or mh:// ?

4. Regarding multihash I think it's trying to be a universal thing, but is
it?  For example open subtitles hash (oshash) is widely used on the
internet, but only check sums the first and last 64k + length.  Could that
get into multihash or would the possibility of altering the file and full
integrity check prevent it?   ie can we say multihash for all hashes, or
will we need a number of URI schemes.

5. The base encoding in multihash seems to be hex.  I seem to remember some
base58 defaults.  It seems that there's a decent network effect around
CIDs, and probably we'd want to do something that can incorporate that
deployment base, but not necessarily be tied to IPFS at the transport
layer.  Multihash or mutlibase could denote many things, including quite a
few DIDs.

6. Maybe we should only make a multibase uri scheme or a multihash uri
scheme.  Though there's much more in multibase than multihash, so more
remove for changes.

Overall, I'm trying to pre guess what such a URI scheme would look like (if
it is desirable).  So mb:// might fit too.

What is your preference?

Best
Melvin


>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>