RE: Secure Data Hubs specification released

To reinforce Daniel’s point about the universality of DID identifiers, here’s a brief update about what I’ve been working on this summer here at the ranch…

As a continuation on my work to establish a Universal Distributed Identifier (UDID) standard (https://www.youtube.com/playlist?list=PLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD), I’ve been working to adapt the industry standard BIND DNS server to understand and process UDIDs – both at the client, protocol, and server layers.

[If you need some background on DNS, checkout  https://hyperonomy.com/2019/01/02/dns-domain-name-service-a-detailed-high-level-overview/]

Here’s some conventional as well as UDID-UBIND examples:

  1.  MX record query for microsoft.com (conventional, non-UDID example)
  2.  UDID Document queries (2)

[cid:image001.jpg@01D53DF9.2C38D210]

Here is a preliminary list of UDID-UBIND resource record (RR) types I’ll be submitting to the IETF…

[cid:image002.jpg@01D53DF9.2C38D210]

Best regards,
Michael Herman
Independent Blockchain Futurist, Architect, and Developer

p.s. There’s also a general purpose data platform in the works for managing global datasets indexed and cross-referenced and inter-related entirely using UDIDs.

From: Daniel Hardman <daniel.hardman@evernym.com>
Sent: July 3, 2019 3:59 AM
To: Carlos Bruguera <cbruguera@gmail.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>; Credentials Community Group <public-credentials@w3.org>
Subject: Re: Secure Data Hubs specification released

Yes, new DID methods will take the DID world out of blockchain land. One example of this is the peer DID spec I've been working on with folks from ConsenSys and SecureKey<https://openssi.github.io/peer-did-method-spec>. Another is the work Dave Huseby has done on a github-based DID (I don't have a hyperlink for this handy, but I could track one down if anyone is interested). When such DIDs are easy to use, then asking people outside DID-land to use DIDs should not be a heavy lift with learning curves and dependencies and mysterious crypto. It'll just boil down to key pairs.

On Wed, Jul 3, 2019 at 12:03 AM Carlos Bruguera <cbruguera@gmail.com<mailto:cbruguera@gmail.com>> wrote:
"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."

I see there's a reasonable intent to "cast a wider net" in many aspects of the design and development of all these interrelated standards and initiatives, yet I think if we consider all the pieces and how to fit them together, we can introduce the necessary flexibility in each one without losing concreteness of the whole (i.e. cast the net as "wide" as necessary, but not "wider"). Since DID generic specs definition is still a work in progress and the involved community is already taking into account the necessity to achieve certain levels of flexibility, why don't we work on the basis of DID methods that represent simple identifiers such as public/private keys? I think this possibility has already been discussed before, and in any case we won't be able to avoid the necessity of certain systems to use simple identifiers as DIDs (e.g. ethereum addresses)... So, if we assume that DIDs already cover a wide and extensible space (and there's no way to force it to be otherwise), Secure Data Hubs could be "narrowed down" to assume DIDs as their sole identifier type and DID methods can always be defined to cover any missing cases. Thus existing DID agency models could fit in within the standard (DIDComm may also be adopted) while flexibility is never lost.

In summary, the matter boils down to the question of where do we want to cast the wide net, and it's my opinion that it makes more sense to widen the identifier layer that lies underneath (which is something already happening and probably necessary) than on the components that allow these identifiers to conduct function and interact among each other (agents/hubs/etc.).

Just my 2 cents.
Cheers.

On Tue, Jul 2, 2019 at 9:14 PM Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>> wrote:

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

Sorry. I've been up for chunks of the night with a headache and nausea, and I'm not writing as clearly as I prefer. It wasn't meant at all as an ultimatum, just a bid to consider an idea.

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.

Who is the "we" in this paragraph?

It feels like you're asserting this requirement is a foregone conclusion. I see how it could broaden adoption, but the architectural cost of having a non-DID-based security and communication mechanism is profound. Do other CCG members believe it is a worthwhile tradeoff? The alternative, of course, would be to say that people outside DID-land can use a spec, at the cost of picking up a dependency they aren't familiar with...