Re: Secure Data Hubs specification released

On 7/2/19 8:30 AM, Daniel Hardman wrote:
> 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.

I wouldn't read too much into the focus on HTTP at present... we need to
design for other protocols (as you mention in your email), so I think
there is already alignment there.

We had to write something that "held together" on a first reading and
most of the folks here understand JSON and HTTP... it's a convenient
place to start from when introducing new concepts to a broad audience.

Like the Verifiable Credentials and Decentralized Identifier work, I
expect that we'll end up talking about all of this in layers: the data
model, the syntaxes, and then the protocol. It's a pretty tried and true
way to design systems for the Internet.

I'm upbeat given your response that the impedance mismatch that you are
talking about may be less than you think. I didn't find much in what you
wrote that I disagreed with, so that's a good sign for collaboration.

> 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 is the only concern that I have as it comes across as an ultimatum.
I'm sure you didn't mean it that way. The only hesitation I have is that
DIDComm presumes that you have to use DIDs with the system, and just
like with VCs, it's possible and is the default mode of operation...
it's not the only mode. We're trying to reach folks outside of the DID
ecosystem with the work as that will be important when we take this
stuff standards track. Again, we'd rather cast a wider net than just the
DID ecosystem. Anyone with a public/private key should be able to use
this system to protect their data.

> This would not eliminate HTTP; it would simply require us to describe
> HTTP as one of many alternatives

Yes, our goals are aligned there.

> and it would replace/supplement things like the discovery mechanism 
> in section 5.1 with a DID Doc-based service endpoint for the hub.

Yes, also a goal for the Secure Data Hubs spec.

> The JWE-based encryption shown in example 3 could easily be updated 
> to use DIDComm's encryption envelope 
> <https://github.com/hyperledg...ryption-envelope/README.md>, which
> is also JWE-based but which allows multiplexed encryption so the
> same package can be decrypted by multiple parties.

Yes, we should discuss that as the data model formats feel like they're
very close (and remember, that's because we have read and have tried
very hard to align w/ the parts of the Identity Hubs and Hyperledger
Aries specifications that we agree with).

> We might also consider whether the W3C is really the appropriate home
> for this work, if the charter is broader than just the web.

The Web bits are probably W3C... other bits might be IETF.... but yes,
agreed that this is an ongoing discussion.

Thanks for engaging Daniel, we look forward to working with you on
aligning all of this work.

-- 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

Received on Tuesday, 2 July 2019 13:56:43 UTC