Re: Identity Hubs and Agents

Two separate things. First a taxonomy for agent protocols that extends
Kim's strawmen. Then, a response to Danel H's verifiable credentials
sharing model.

Agent Protocol Use Cases / Strawmen

Define an agent as: A service where a requesting party other than the data
subject may present access credentials.

1 - Mobile-to-Online: Alice owns both agents. e.g. Alice’s biometrically
protected mobile wallet delegates to Alice’s online agent service based on
Intel SGX.

2 - Online-to-Online: Alice owns both agents. e.g. Alice’s online agent
delegates to another agent that Alice also owns for pairwise-pseudonymity
privacy reasons.

3 - Online-to-Data Processor: Alice’s agent is the GDPR data controller and
delegates to a GDPR data processor that is a separate entity. e.g. Alice
gets a blood test at a national lab. The lab does not process or act on the
basis of requesting party credentials. (except law enforcement).

3a - Online-to-Alice-owned Data Processor: This is the case where Alice
owns both the controller and the processor. This case does not require a
standardized protocol between the controller and processor but could
benefit from it in some cases where the services are provided to Alice by
separate hosts. e.g. Alice chooses Apple for her controller and Microsoft
for her processor.

4 - Online-to-Data Broker: Alice’s agent is the data controller and
delegates to another data controller that is a separate entity. e.g. Alice
gets a blood test at a national lab and posts a link to the lab to a dating
service directory. The dating service decides if Bob can access the data
pointing to the lab.


*Re: Verifiable Credentials Sharing - *From a privacy engineering
perspective, I'm not sure it matters whether a data processor is acting as
a DID holder or an attribute store. In both cases the entity is just an
access policy execution point and not a controller. The situation is made
more confusing by streaming direct from the issuer, encrypted credentials
(e.g. a letter of recommendation that the subject is not allowed to see),
verifiable presentations, zero-knowledge proofs, searchable attributes,
etc... but I would maintain that the five strawmen above are all
independent of the VC vs. private attribute distinction.


Adrian



On Tue, Aug 13, 2019 at 4:20 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> The concept that some agents are more authorized than others is and always
> has been fundamental to the mental model for agents. Note that the core
> definition of an agent assumes delegated authority via keys, and that not
> all delegation authority needs to be uniform. We originally chose the terms
> "edge agent" and "cloud agent" for the two categories Bill proposed, and we
> still do use those terms. However, we realized after a while that the most
> important distinction between these two agent types wasn't location (edge
> vs. cloud), but rather the amount of trust they hold. We then introduced
> the terms "trustable agent" and "semi-trustable agent" instead. Please see
> https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents#by-trust.
> Let's use these terms, since they are already normative in an Aries RFC.
>
> Aries agent codebases contemplate all agent types, so we don't need a new
> Hyperledger project for the cloud agent type.
>
> I do agree with Bill's suggestion that use cases where agents interact
> directly (instead of indirectly, via data distribution mechanisms) are
> important. I think it's a mistake to promote a mental model where we think
> of self-sovereign identities primarily as data sources/sinks--data is one,
> but only one, important aspect of how they manifest.
>
> Regarding Adrian's privacy design diagram: I do not believe that
> credentials should be thought of as ordinary data. Yes, they contain
> data--but I don't think we want the world peering into our wallets or data
> repositories to look at credentials in the same way we might be willing to
> let the world peer into dropbox to view our cat photos. Credentials have
> the special characteristic that they ratchet up trust--and I think
> fiduciaries, not data distribution mechanisms, need to be involved whenever
> that goal is on the table; I don't want to ratchet up trust with party X
> without knowing I'm doing it. I also think that privacy has a much better
> outcome when fiduciaries are at the heart of credential presentation.
>
> I am under the impression that this latter opinion makes me a minority in
> the CCG, where I hear a lot of assumptions that people should fetch others'
> credentials as data. I'm not trying to argue the rightness of my
> perspective here--just noting the existence of a view that doesn't believe
> hubs--whether DIF Identity Hubs or Secure Data Hubs--should be serving
> credentials at all.
>
> On Tue, Aug 13, 2019 at 11:24 AM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> Further to Bill's call for consistent terminology, I have tried to
>> capture the essence of the various protocol designs from a privacy
>> engineering perspective.
>> [image: Agent to Hubs Protocols.png]
>> The terms in this diagram are just a starting point meant to be agnostic
>> to any of the proposed designs. You can clone it or edit it at:
>>
>> https://www.websequencediagrams.com/#invite=KJKVCyJ03X&from=agropper%40gmail.com&name=Public
>>
>> Adrian
>>
>> On Tue, Aug 13, 2019 at 12:24 PM Bill Barnhill <w.a.barnhill@gmail.com>
>> wrote:
>>
>>> I went through the Identity Hubs presentation, and the Medium article.
>>>
>>> Though I'm not as versed in Identity Hubs as many of you, I want to
>>> comment on a couple of things.
>>>
>>> First,  I proposed we talk about two types of agents when we talk
>>> about identity agents. The first type are the first-class agents that
>>> act as fiduciaries for their user, have wallet root keys, etc. The
>>> second type are offline proxy agents, that act on behalf of the user
>>> when the user is offline, but have more limited privileges. These can
>>> automatically provide collections managed by a user when that user is
>>> not online, verify claims on behalf of the user, etc.  This second
>>> type is distinct enough it might warrant a second Hyperledger project,
>>> but the Hyperledger folks would be a better judge of that than me. If
>>> so, perhaps a suitable name might be Gemini (i.e., the offline digital
>>> twin agent).
>>>
>>> Second, I agree Identity Hub use is a useful set of use cases, but I'd
>>> also like to see a pure agent-based set of use cases allowed. Instead
>>> of an Identity Hub managing a user's information for offline retrieval
>>> you could have a proxy agent run by an agent host (think a Digital
>>> Ocean Aries Agent droplet, for example).  We should support the people
>>> who want to use the simplest solution and might gravitate to using an
>>> Identity Hub, but I also think we should support the people that want
>>> full decentralization via interacting agents (i.e., a digital
>>> community as a collection of people and the the digital mesh of their
>>> agents acting together).
>>>
>>>
>>
>> --
>>
>> 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/
>>
>

-- 

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/