- From: Bob Wyman <bob@wyman.us>
- Date: Mon, 13 Dec 2021 14:37:30 -0500
- To: "Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net>
- Cc: Mike Prorock <mprorock@mesur.io>, "sam@prosapien.com" <sam@prosapien.com>, "public-credentials (public-credentials@w3.org)" <public-credentials@w3.org>
- Message-ID: <CAA1s49UhtkXstx1uT+QJeDcat=fxA7enPL=DCjw6YGg89yk1fw@mail.gmail.com>
> > ...are you assuming a classic checksum could be stored in the same way on > a VDR? In the abstract, a signature doesn't tell you anything other than that the checksum was encrypted using the private key paired with the public key. Thus, in the absence of the private key, or some way to cause it to be used in a verification process, the signature doesn't really add any useful information that isn't provided by the unsigned checksum. Given this, it would seem reasonable to store checksums in a Verifiable Data Registry (VDR) rather than going through the hassle of processing signatures. Storing the checksum in the VDR would shift the burden of proof to whatever methods the VDR used to assert the correctness of its content. But, if you had a public key that was accompanied by claims, such as those in a certificate issued by a key pair provider, which stated that it had issued a key pair containing the public key, then you could verify the virtual presence of the private key by interacting with the provider of the certificate. In this case, it would be irrelevant if the private key was still accessible. Of course, the most you could know was that the relevant key pair had been issued by the provider, but, you wouldn't be able to know, or discover, who had used the private key. bob wyman On Mon, Dec 13, 2021 at 12:15 PM Michael Herman (Trusted Digital Web) < mwherman@parallelspace.net> wrote: > A checksum doesn't amount to a signature/proof. > > With a checksum approach, anybody is free to change the VC's claims, > metadata (aka packing list), and/or the inner/outer id's and simply > recompute the checksum. > > If you want to call what I'm proposing single-use key-pair based > "checksums" that might be an interesting but confusing term. > > What I'm proposing are not checksums in the classic sense. There is a > stated assumption that the public key of the SUKP is stored on a VDR for > verification purposes. > > ...are you assuming a classic checksum could be stored in the same way on > a VDR? > > Get Outlook for Android <https://aka.ms/AAb9ysg> > ------------------------------ > *From:* Mike Prorock <mprorock@mesur.io> > *Sent:* Monday, December 13, 2021 10:03:05 AM > *To:* Bob Wyman <bob@wyman.us> > *Cc:* Michael Herman (Trusted Digital Web) <mwherman@parallelspace.net>; > sam@prosapien.com <sam@prosapien.com>; public-credentials ( > public-credentials@w3.org) <public-credentials@w3.org> > *Subject:* Re: Single Use Key Pairs: Disposable Private Keys? > > +1 Bob > > Mike Prorock > mesur.io > > On Mon, Dec 13, 2021, 11:45 Bob Wyman <bob@wyman.us> wrote: > > I think I'm missing something in the scenario you describe. If the private > key has been discarded, how can a signature generated with that private key > serve as anything more than a checksum? If a checksum is all you need, why > not just provide a checksum? Why bother with the signature? > > bob wyman > > > On Sat, Dec 11, 2021 at 11:50 PM Michael Herman (Trusted Digital Web) < > mwherman@parallelspace.net> wrote: > > If an NFT (for a photo, a calf, or a kiss, etc.) or a unique one-of-a-kind > business document (a specific purchase order, invoice, waybill, delivery > confirmation, etc.) is represented as a (signed) verifiable credential, > once the proof is generated for the VC, is it necessary to persist the > private key used to sign the VC? > ...can't the private key be thrown away if it is no longer needed to sign > anything further? > ...that is, only the public key needs to be persisted and keyed to the > VC's outer id and stored in the corresponding DID document? > ... inspired by the early part of Sam's KERI ssimeetup talk. > > Michael Herman > Founder > Trusted Digital Web > Get Outlook for Android <https://aka.ms/AAb9ysg> > >
Received on Monday, 13 December 2021 19:37:55 UTC