Re: Secure Data Hubs specification released

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