Re: Secure Data Hubs specification released

There is some impedance between Manu/Dave's thinking and that of DIF
hubs/Hyperledger Aries agents. The "Secure Data Hubs" spec in its current
form reads as web-centric; each API that it lists comes with HTTP status
codes and a swagger-ish view of how the API call's parameters and response
are communicated. This is only natural, since the proposed home of the work
is the W3C, which is web-centric in its core DNA.

DIF Hubs and Hyperledger Aries agents started out as web-centric, too, but
eventually concluded that this was too narrow. We needed to support
functionality over other transports such as Bluetooth, NFC, a pull model
for mobile push notifications, AMQP, ZMQ, SMTP, a file system, proprietary
comm layers on IoT devices, and so forth. The need to share data is broader
than the web, though HTTP is by far the most significant individual
transport. By introducing these additional transports, we also found that
we had to abandon the convenient assumption that interactions were
synchronous and duplex; many transports lack either or both of those
features. And we needed to support complex routing scenarios
<https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0046-mediators-and-relays/README.md>,
not just direct hub access. The umbrella answer is DIDComm
<https://github.com/hyperledger/aries-rfcs/blob/93a3258b05ee47c1d0801fe95c0777bbd2fc1640/concepts/0005-didcomm/README.md>
+ protocols
<https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md>,
which support HTTP but also many other ways to move bytes.

If a goal of this effort is to produce meaningful interoperability instead
of providing a competing standard that undercuts many person-decades of
standardization and implementation work, I suggest that we recast the spec
as one aligned with DIDComm. This would not eliminate HTTP; it would simply
require us to describe HTTP as one of many alternatives, and it would
replace/supplement things like the discovery mechanism in section 5.1 with
a DID Doc-based service endpoint for the hub. The JWE-based encryption
shown in example 3 could easily be updated to use DIDComm's encryption
envelope
<https://github.com/hyperledger/aries-rfcs/blob/master/features/0019-encryption-envelope/README.md>,
which is also JWE-based but which allows multiplexed encryption so the same
package can be decrypted by multiple parties. We might also consider
whether the W3C is really the appropriate home for this work, if the
charter is broader than just the web.



On Tue, Jul 2, 2019 at 12:32 AM Carlos Bruguera <cbruguera@gmail.com> wrote:

> Great initiative! My assumption is that this specs attempt to
> "standardize" all these separate lines of work for secure identity data
> storage? Are DIF Hubs, for example, expected to stay compliant with these
> specs (or are the specs already being considered to be compatible with the
> ongoing work on DIF Hubs)?
>
> I cite the DIF Hubs specific example because I already perceived it it as
> an initiative to reach some sort of "common ground" for agent
> interoperability among different identity platforms (if I my understanding
> is correct)... On this note, A particular feature of DIF Hubs is that they
> intend to implement a protocol for data replication among different agents:
> is this being considered for Secure Data Hubs, or would that be left
> outside this scope?
>
> Any feedback appreciated. Thanks in advance.
>
> On Tue, Jul 2, 2019 at 11:10 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> Hi all,
>>
>> For a number of years, a handful of us in the community have been
>> grappling with the problem of personal data storage. How do we store
>> application data, such as Verifiable Credentials, in a way that is
>> controlled and administered by us, encrypted by default from parties
>> that may not have our best interests in mind, and most importantly in a
>> standards-compliant manner?
>>
>> There is similar work going on at Hyperledger Aries, DIF's Identity
>> Hubs, at Solid/Inrupt, and elsewhere in the world. We tried to study
>> each system and provide a fundamental low-level layer for answering the
>> question above... we're calling the technology:
>>
>> Secure Data Hubs
>>
>> ... and here's the Abstract:
>>
>> We store a significant amount of sensitive data online such as
>> personally identifying information, trade secrets, family pictures, and
>> customer information. The data that we store should be encrypted in
>> transit and at rest but is often not protected in an appropriate manner.
>> This specification describes a privacy-respecting mechanism for storing,
>> indexing, and retrieving encrypted data at a storage provider. It is
>> often useful when an individual or organization wants to protect data in
>> a way that the storage provider cannot view, analyze, aggregate, or
>> resell the data. This approach also ensures that application data is
>> portable and protected from storage provider data breaches.
>>
>> This is a very rough draft and we hope to incubate the work in the W3C
>> CCG and eventually gain support for it across various communities and
>> take it through the standardization process at W3C:
>>
>> https://msporny.github.io/data-hubs/
>>
>> If there is interest in collaborating on the specification, we'll
>> contribute it to the W3C CCG and request that it become a formal work
>> item in the group. For now, take a look at the spec and let us know what
>> you think about it. Happy to answer any questions on this mailing list
>> and on a future CCG call if the Chairs deem this a good topic to cover.
>>
>> -- manu
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: Veres One Decentralized Identifier Blockchain Launches
>> https://tinyurl.com/veres-one-launches
>>
>>
>>