W3C home > Mailing lists > Public > public-credentials@w3.org > August 2019

Re: Datashards and Secure Data Hubs... how to achieve convergence?

From: Steven Rowat <steven_rowat@sunshine.net>
Date: Sat, 17 Aug 2019 10:14:00 -0700
To: Christopher Lemmer Webber <cwebber@dustycloud.org>
Cc: public-credentials@w3.org
Message-ID: <20b620db-eab3-1dc6-4d36-d1260b64f9d4@sunshine.net>
On 2019-08-17 9:07 am, Christopher Lemmer Webber wrote:
> We can then use this as the id of the object, refer to it in other
> documents, like so:
>    {"@context": [
>         "https://www.w3.org/2018/credentials/v1",
>         "https://www.w3.org/2018/credentials/examples/v1"
>        ],
>     "type": "FulfillPrescription",
>     "prescription": "idsc:0p.clfCj_4cJa24pymJDnxE-REJETxTDktJRQAAdLpZr3A.o06THIeG1jUr0S62rVQBH0gsIIcIgaoSRcF5DnPDXnI"}
> There's no VC vs Datashard; they're completely complementary!  (As are
> Datashards and Secure Data Hubs.)  Here's a vision of how they can work
> together:

I think I see the usefulness of Datashards as allowing the content to 
reside anywhere -- usb sticks, whatever -- but you don't include DIDs 
in your example or explanation. Do Datashards take the place of DIDs? 
If not, could you give an example of how they would be included, like 
in the steps you gave below for VCs and Datashards?

>   - Save VCs as Datashards objects.
>   - Upload them to Secure Data Hubs.
>   - Even though the different "chunks"/shards of the Datashards Object
>     can be saved in various places (both archived at the pharmacy and
>     also on your Secure Data Hub).
>   - When you give the pharmacist the idsc: or mdsc: URI, at that point
>     they can read the data.  Until they have that, they might even be
>     able to "hold" the data, but they can't read it or know what it's
>     for.
>   - No matter whether it's being held by the pharmacist's local database
>     or at your Secure Data Hub, there's the convenience that the
>     Datashards URI refers to the same data in both places!

Received on Saturday, 17 August 2019 17:14:36 UTC

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