Re: Identity Hubs and Agents

Daniel beat me to a reply and articulated what I was going to say, but let
me add some thoughts.

We have to remember that as others put forth ideas that doesn't mean there
hasn't been substantial thinking around it and just because there is only
one contributor in Github, that doesn't mean others were not involved. In
looking at the verifiable credential spec, I collaborated with others in
various parts of it and the thinking behind it, but my name doesn't show up
on many (if any) of the commits. So rather than start down the personal
attack route, be more considerate about an idea before shooting it down. I
know I'm guilty of this and it doesn't help. Considering other points of
view is how we arrive a more acceptable spec.

Daniel's being humble in that he's been the primary author here in that he
helped start this thinking over two years ago and those conversations have
been more and more common. So let's remember that as we consider the
terminology currently used in Aries is being used for a reason. If you
attend the Aries calls there are at least 30-40 people that actively talk
about this from more than just the Sovrin and Evernym teams like uPort and
Spark among others.

My final thoughts here are we should be thanking those that have already
been thinking about these problems before anyone else and appreciate them
putting forth what they have so far and not shoot the messenger. If this
were a paper at RWoT with 30-40 collaborators, it would be quite a paper so
please remember that. Most groups at RWoT don't come close to that size and
I don't think RWoT is the only medium for community thinking. It is a great
place for that but is not limited to it.

On Wed, Aug 14, 2019 at 8:44 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.
>>
>

-- 
Mike Lodder
Security Maven