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