Re: Secure Data Hubs specification released

>
> > This topic is being raised 18-24 months after serious
> > standardization work began in other channels, and the scope of the
> > spec draft is a step backward. This isn't a recipe for alignment
> > around interop.
>
> My understanding was that Aries and DIF were not standards setting
> organizations? They are implementation organizations. W3C, IETF, Oasis,
> ISO... those are the standards setting organizations.
>

I want to challenge your mental model a bit.

First of all, can we agree that there is no such thing as a "standard
setting" organization? There are Standards Development Orgs (SDOs) that
*develop* standards, but whether they are set as relevant standards in the
mind of the world is something that comes about through market forces,
world consensus, and history--not through the actions of any org. SDOs
often wish they could "set" standards, but the "D" in their acronym is
actually more accurate. Two of the ISO standards I worked on in the 90s
enjoyed brief surges of relevance but have long since been ignored. The
world set a different standard from the SDO.

Secondly, implementation communities have different degrees of formality to
what they do. By making the strong contrast between implementation and SDO,
it sounds like you are assuming that implementation is pretty different
from developing standards, and has very little formality insofar as
consensus specs are concerned--the formality all begins when an SDO gets
involved.

DIF does style itself as a an "implementation" org, IIRC. However,
Hyperledger Aries doesn't use that term. It calls itself an open source
"project" with a mandate/scope that includes developing an implementation
but also globally relevant specs that drive it. This is quite far away from
the loose approach to implementation that best fits your dichotomy. There
are approximately 50 Aries RFCs
<https://github.com/hyperledger/aries-rfcs/blob/master/index.md>--each of
which is a formal specification that has a vetting process, a status, and a
lifecycle. Many of them have multiple reference implementations in
codebases from independent orgs. There are test suites, corpuses of bugs
and improvements, PRs against the specs, and community meetings where those
specs get debated and refined. Aries doesn't consider itself an SDO, but it
also doesn't consider itself just a loose confederation of coders who might
produce semi-cohesive stuff. Is incumbent on an SDO that picks up the
thread of such work to cite prior art in detail, and to grapple with
it--not just mention it in passing as "implementation" while proposing a
work item that starts over. This is especially the case when the corpus of
prior art is substantial, formal, directly related to the problem at hand,
and highly interlinked and conceptually cohesive.