Re: Identity Hubs and Agents

Christopher, Joe, et al:

When I called the spec "existing terminology", I was not trying to prevent
new terms. Of course we can invent new terms and change the mental model as
needed. But I was asserting that we should understand existing mental
models as a starting point. To start over from a blank slate without even
knowing what another community has A) worked on for years; B) formalized;
C) suggested is important to the conversation is not wise or fair. The spac
IS "existing terminology." You may not like it--but it does exist, and it
is terminology. It also seems quite different from the attitude this
community is taking to a brand new spec by one author about Secure Data
Hubs.

Your characterization of "my" spec as being largely my own work (or, in
Joe's case, as the work of Evernym/Sovrin) is an injustice. I am the main
author of the doc, because I did the bulk of the typing. But the 20-30
people who show up to calls each week on agent topics are joint originators
of the mental model we worked out. A spec gets ACCEPTED status when it has
multiple implementations and deep buy-in, and this spec has met that
standard since Feb 2019, when 5 implementations other than Evernym's passed
the test suite. Are independent implementations and test suites not a
standard of the W3C CCG?

Looking at the contributor list isn't a reasonable way to judge momentum on
Aries specs. The implementors list is far more interesting.

One more clarification: I only used the word "normative" in the phrase
"normative in an Aries RFC." In an Aries context, the terms that the RFC
introduces become normative *for Aries* when an RFC is ACCEPTED. I wasn't
claiming the terminology in an Aries RFC are normative to the larger
community. I was suggesting that we use the Aries terms where they applied,
as a starting point of our discussion, because they were normative in the
context where most of the formal work on this topic has happened. I can see
how my sentence might have given the wrong impression, and I apologize for
that.



On Wed, Aug 14, 2019 at 7:06 AM Bill Barnhill <w.a.barnhill@gmail.com>
wrote:

> Thank you all. This thread helped congeal a number of ideas, and I learned
> much.
>
> I read the Aries concept RFC for Agents (
> https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents
> ) and the one for routing agents (
>
> https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0094-cross-domain-messaging/README.md
> ) last night. I think they are a great step toward an agent taxonomy,
> and awesome work.  I can see the point though that they are one
> implementation, though a heavily adopted one, so there may be
> additional ways of partitioning the agent space that aren't in Aries
> concept RFCs.
>
> When folks make a taxonomy some prefer the Barry Smith
> taxonomy/ontology creation approach and a strict hierarchical tree
> taxonomy. Others prefer the John Sowa approach of a lattice taxonomy,
> described at http://www.jfsowa.com/ontology/ (similar to how the REST
> architecture property derivation was described in Roy Fielding's
> thesis
> https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1
> ).
> I've got the start of a Sowa-style taxonomy, based on the info in this
> thread, my thoughts, and the info from the Aries concept RFCs. It's
> similar to the kind of tree in the REST link, except for agents using
> the different ways you can group agents: edge vs cloud, trustable vs
> semi-trustable, aggregator vs actor, user-interacting vs offline,
> payment-handling (and receiving vs sending) vs non-payment handling,
> non-mobile vs mobile (and handheld vs mounted), and the can-of-worms
> of digital-contract-negotiation empowered vs not.  However, I need to
> clean it up a bit before I post it..so probably not until this
> weekend.
>
> Regarding credentials as a different type of data..when I've worked on
> Attribute Based Access Control (ABAC) implementations we've talked
> about three different kinds of data to consider, each with different
> access rights for a process: environment attributes, user/principal
> attributes, and request attributes. Perhaps something similar would
> useful.
>
> I like Dan Thompson-Yvetot's analogy of multiple cooks communicating.
> I do think though that getting a common language defined and
> documented at an early stage is important, as long as we regard that
> document as a living work in progress, updating it as we go forward.
>