- From: Bill Barnhill <w.a.barnhill@gmail.com>
- Date: Wed, 14 Aug 2019 09:06:30 -0400
- To: Daniel Thompson-Yvetot <drthompsonsmagickindustries@gmail.com>
- Cc: Joe Andrieu <joe@legreq.com>, Christopher Allen <ChristopherA@lifewithalacrity.com>, Daniel Hardman <daniel.hardman@evernym.com>, Credentials Community Group <public-credentials@w3.org>
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.
Received on Wednesday, 14 August 2019 13:07:04 UTC