Re: Identity Hubs and Agents

I'm a huge advocate for SSI and do my best to keep up with what all five of
the principal communities + IIW are doing. My role has been and remains as
invited expert on privacy.

I have asked two related questions about hubs and agents:
July 25:
https://docs.google.com/document/d/11BLUhBCsB_uB_Df7k2kRQT0blHB8YSim4WJeL5F-6FM/edit
August 13:
https://docs.google.com/document/d/1aA9bOF9EndFpapyk4_sXLZt-7_8TGyeM9A-OScc_rdo/edit?usp=sharing

Please HELP ME do this job by responding - privately or publicly - when I
ask a question. I think I can help.

Adrian


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

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

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/