Re: Agency First

A slight update to Drummond's steps in the process.

Step 1 is the same regardless of whether ZKPs are used or not. By using the
did:peer method (pairwise pseudonymous DIDs), at the
connection/communication layer, there is no need to use a public DID at all
and the DIDs used are not used by any other party.

Likewise in Step 2 and 4, the connections and communications between Alice
and the dating service and Alice and Bob are done with new pairs of
did:peer method DIDs.

It's only when credentials get involved is there any need for a public
DID.  With ZKPs, there is only one public DID involved, and that is for the
Issuer - the HIV Lab. The Dating Service and Bob do not need public DIDs in
this scenario. The Dating Service might for other DIDs they issue, but they
are not used in this scenario.

Another key observation in using pairwise pseudonymous DIDs. Establishing a
connection is not important from an authentication perspective - done
remotely, no trust is accomplished. Some form of verification is needed
beyond that - verifiable credentials. For bootstrapping credentials, other
methods would be used - face-to-face, etc.

On Tue, Jul 2, 2019 at 11:47 PM =Drummond Reed <drummond.reed@evernym.com>
wrote:

> Adrian, while I too support the concept of "Agency First", I just want to
> point out that, if one uses the ZKP format of a verifiable credential and
> the ZKP credential exchange protocol (currently implemented in Hyperledger
> Indy <https://wiki.hyperledger.org/display/indy> and moving to Hyperledger
> Aries <https://wiki.hyperledger.org/display/aries> as one of the
> supported credential exchange protocols), then I believe your scenario can
> be executed far more simply.
>
>    1. Alice forms a peer DID connection (e.g., an exchange of pairwise
>    pseudonymous DIDs) with: a) the HIV lab, and b) the dating service. Note
>    that if Alice uses ZKPs, *she will never needs to share these DIDs
>    with anyone else. *With ZKP credentials, these DIDs are NOT used
>    in credential issuance, only in secure communications. (What is shared is a
>    blinded link secret that, like the pairwise pseudonymous DID, is never
>    shared with any other connection.) So these DIDs can always remain private
>    to those connections.
>    2. Alice does the HIV lab test and gets back a ZKP credential from the
>    lab with her results (let's assume it's negative).
>    3. Alice can now use the ZKP credential to prove to the dating service
>    (as a verifier) that she has an HIV lab result credential *without* disclosing
>    the result. So the dating service can mark her profile as having a current
>    HIV lab result credential.
>    4. When Bob and Alice meet via the dating service and form their own
>    private connection by exchanging pairwise pseudonymous DIDs, Alice can now
>    use the ZKP credential from the HIV lab to prove to Bob that the result is
>    negative *without* having to disclose either her pairwise pseudonymous
>    DID with the HIV lab or her pairwise pseudonymous DID with the dating
>    service. (She can also use proofs of other ZKP credentials to do selective
>    disclosure to Bob of other claims about her, e.g., that she has a job,
>    college degree, mortgage, etc., without disclosing details including DIDs.)
>
> No "authorization tokens" are involved. The proof of the ZKP credential is
> the "token", and because it uses ZKP, preserving privacy gets a whole lot
> simpler.
>
> (BTW, this explanation usually begs the question, "How can Bob know that
> ZKP credential from the HIV lab really belongs to Alice, i.e., couldn't she
> just "borrow" someone else's credential?" It's a great question, and there
> are good answers, but too much for me to go into right now.)
>
> On Tue, Jul 2, 2019 at 6:34 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> This is a fork of the Data Hubs / Aries / DIF Thread asking for a
>> dedicated call in CCG to discuss whether agent endpoints should be
>> specified _before_ data storage endpoints.
>>
>> Here's the use case and logic:
>>
>>    - Alice is on the dating scene and wants an anonymous HIV test.
>>    - Anonymous HIV tests are good public health and often free from
>>    government or non-profits.
>>    - Alice has her choice of where to get the HIV test. Since cost is
>>    not an issue, she will pick the one that is most private.
>>    - Some of the HIV test labs will support Alice's pairwise
>>    pseudonymous DID. She picks that one.
>>    - Alice can pick the dating service too. Other things being equal,
>>    she will pick the one that is most privacy-preserving.
>>    - Alice picks a dating service that supports pairwise pseudonymous
>>    DIDs.
>>    - Alice does not have a personal data store or a credential wallet.
>>    - Alice's test result is available directly from the lab that does
>>    the test to anyone with a suitable access token. The format of the result
>>    is irrelevant as long as the recipient can understand the difference
>>    between Positive and Negative and a Date.
>>    - Alice operates an agent that decides semi-autonomously whether Bob
>>    should see her test result. The agent could be proprietary to the dating
>>    service or self-sovereign to Alice. However it's implemented, the agent
>>    must issue a token that the lab will accept to Bob
>>    - Although Alice has separate DIDs with the lab and the dating
>>    service, she could be correlated if the two DIDs point to the same agent.
>>    This is a concern that would need to be mitigated for an agent or a h.ub or
>>    a personal data store as endpoint in her DIDs.
>>    - From Alice’s agent, Bob's client gets a pointer to the lab and the
>>    DID that Alice used at the lab.
>>    - Bob's client comes to the lab bearing Alice’s DID. The lab points
>>    Bob’s client back to Alice’s agent to get an access token.
>>    - If Bob is evil and leaks Alice’s lab and lab DID to Carol, then
>>    Carol’s client will likely not be able to get an access token from Alice’s
>>    agent so Alice’s HIV status will remain confidential.
>>    - If Bob is evil and leaks Alice’s HIV status, it will not be direct
>>    from the lab and could have been forged by Bob.
>>
>> This use-case is important because:
>>
>>    - It gives Alice market power to choose privacy-preserving service
>>    providers (lab, dating service). This will drive adoption. Any service
>>    provider can decide to accept a DID regardless of any other service
>>    provider as long as the DID resolves to Alice's agent.
>>    - Alice does not have to trust the dating service or a personal data
>>    store intermediary.
>>    - Alice may not need a wallet or Holder at all because no VC is
>>    issued.
>>    - The data model and protocol for presenting the test result is more
>>    or less irrelevant. In practice, it is not totally irrelevant because most
>>    labs and services are multi-purpose and the access token will have to be
>>    scoped and that implies some data model schema shared between the service
>>    provider and the agent.
>>
>> I'm calling this "Agency First" because:
>>
>>    - If Alice does choose to control a personal data store, then she can
>>    choose a personal data store that respects her agent. Again, the market
>>    power is in Alice's hands, or
>>    - If Alice chooses to control a Holder then she needs to find a lab
>>    that's willing to issue a VC and a Verifier that trusts the DID method, VP,
>>    etc...
>>
>> Adrian
>>
>>

-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*