Re: Identity Hubs and Agents

Let me offer a bit of history to contextualize my encouragement that we
understand the Aries terms carefully before we invent new terms.

For the first year or so that we worked on this topic, we were categorizing
agents in many different ways -- by trust, by location, by target platform,
by intended scope of features, by delegation style. Sometimes we used a
term as a label for a location category when it was actually a trust
category, and vice versa. We experienced many subtle misunderstandings
about use cases, UX, and privacy/security expectations due to this
imprecision.

The current Aries terminology may be too narrow for what this community
ultimately needs--but it reflects a lot of battle scars. It has the virtue
of forcing clear discussion about the axis on which we are making
distinctions. Knowing that there are multiple axes, not just one, is a key
insight that I don't want to re-derive from scratch. It took us a year
before.

On Wed, Aug 14, 2019 at 8:42 AM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

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