Re: Secure Data Hubs specification released

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

I totally agree on the value of having a spec where we can define the
common ground for all of these initiatives. I support the Secure Data Hubs
specs initiative. My reply is mainly presenting a question (and possible
alternative) to the problem of "widening the net" with regard to identifier
types, resorting to the width and extensibility of DIDs (by assuming the
right DID methods, crypto key pairs can still be used as DIDs. Are there
any other known cases where DIDs might be too restrictive for what is
expected from Data Hubs?)... Just trying to reach common ground between
your stated need for flexibility and Daniel's request on aligning with
DIDComm.

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

I didn't refer to any DID method in particular, I'm just questioning the
need to widen the net for data hubs with regard to identifiers when most of
the efforts to develop agent functionality seem to be working on the basis
of DIDs and the DID layer in itself is already "widening" on this regard
(this surely includes ideas like did:web, did:peer and others to come)...
You're completely right in that my input is a bit "vague". I'm not offering
concrete proposals in terms of specs, just trying to get feedback from
those more involved in order to understand where the community is at while
sharing my views if possibly relevant. Regrettably it's a bit inconvenient
for me to attend the calls at the time due to timezone differences (located
in Asia). I will still do my best to keep up-to-date and contribute
whenever possible.

Thanks for the feedback. :)

On Mon, Jul 8, 2019 at 2:42 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

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