Re: Secure Data Hubs specification released

On 7/3/19 2:03 AM, Carlos Bruguera 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").

Yes, agreed. I think we're very aligned on that.

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

Yep, and there is already work going on in that space... did:peer: ...
we also have something that we've been intending to release for some
time that would probably drop into this category.

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

Maybe... I'd like for that to be true, but the details matter here and
in order for us to talk about the details, we need to have a spec (or
specs) that we're comparing contrasting... otherwise, we don't really
know if we're really aligned or not. That's what the whole
standardization process is about... finding common ground and then
documenting that in excruciating detail so that we eventually get to
interop.

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

That sounds intriguing... but vague. :) -- Do you mean methods like
did:web? Or were you thinking something else? I'd certainly appreciate
you going into more detail about this on a CCG call where we discuss how
we can align on these approaches.

-- 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 Sunday, 7 July 2019 19:43:13 UTC