New HIPE consent receipt

[JanLin]

Hi,
I have created a new HIPE on the topic of consent receipt. There has been a lot of discussion on the subject and this is an initial proposal to help document what is needed to be supported in Indy and how it will work practice with use cases. Hope the draft is clear but if any further clarification that is needed before being accepted let me know. Eventually a sequence diagram and demo will be created to further support the draft.
Thanks,
Jan Lindquist

[dhh1128]

You may need to refer to the concept of "freshness" in a proof request. Talk to @jovfer (github) / @sergey.minaev (rocket.chat) to get more details.

[JanLin]

I will ask Sergey for more details before making the update to make sure that the terms are aligned. If not what needs to be changed. Will keep change request open.

[dhh1128]

Based on a discussion in our last indy-agent call, it appears that we are going to have to modify crypto and some additional logic in libindy before this HIPE can be implemented. The reason is that as described here, the issued credential could be used by either an issuer or a holder to prove things. Today, that is not the case--issuance is an asymmetric operation where only the holder's link secret is embedded in a credential, and only the issuer has the right to revoke.

The idea of a 2-way contract, modeled as a credential, but conferring holder status on both parties, could maybe be addressed as follows (credit to @lovesh for the idea):

1. Assume a contract credential with 2 participants and 3 attributes and we are using Coconut threshold credentials. Here both participants will act as issuers and both will act as holders too
2. The schema will have 3 attributes a1, a2 and a3. 
3. Both participants p1 and p2 have a master secret, m1 and m2 respectively
4. Each of them creates a cred def with 5 fields (3 attributes + 2 link secrets).  
5. Each of them creates a verifiable encryption (Elgamal) of their link secret with a proof of encryption.
6. Each of them shares the ciphertext and the proof with another. Ciphertext of m1 is c1 and ciphertext of m2 is c2. 
(Both c1 and c2 are 2 group elements each like Elgamal ciphertext. Each element can be represented by its compressed point, c1=>(c1', c1''), c2=>(c2', c2''))
7. Each of them verifies the proof given by another.
8. They jointly arrive at a credential that contains the 3 attributes and 2 ciphertexts. This is how:
    a. p1 creates credential, X1 with attributes (a1, a2, a3, c1, c2), signs it and shares with p2.
    b. p2 creates credential, X2 with attributes (a1, a2, a3, c1, c2), signs it and shares with p1.
    c. Both p1 and p2 can independently combine the 2 credentials X1 and X2.
9. Now when p1 can act as a holder it proves knowledge of plaintext behind c1 (m1). Similarly for p2.

A drawback of this approach is that it doesn't preserve privacy in quite the same way that our normal ZKP behaviors do. However, perhaps 2-way contracts should not have the same privacy guarantees?

[kdenhartog]

I'm commenting to offer my -1 for issuers being able to prove things with the credential. This could become an incentive to issuers to only use this method which at best allows for this new functionality, but at worst allows a large system to be undermined. Is there a way we can achieve consent receipts without having to give issuers the ability to prove as well? As an extension question, can we make it possible where the issuer get's consent, but gets no access to the data even?

[JanLin]

I would like to point out that there are two different consent receipts, between a private individual and an institution and between two different institutions. The 2nd example, two different institutions, would benefit from the 2-way contract. So the issue of privacy guarantee may not necessarily be negative. Agree that in some circumstances it is important to have privacy guarantee. In the call last week there was discussion of having a 2nd credential between private individual and institution, the roles in this case become reversed. Isn't this an alternative for full privacy?

I will add as part of the HIPE the proposal with the 2-way contract. I may have other comments as I make the update.

[lovesh]

To clarify last comment from @dhh1128 the privacy guarantee we lose is that multiple presentations to the same verifier can be linked.

[dhh1128]

@JanLin This PR has languished for a long time. We just updated the process that this repo uses to accept PRs, and it would now be easy to merge if you still want to. However, I think it fits better now into the aries-rfcs repo. I would be happy to help you move it there if you like. See https://docs.google.com/document/d/1BKLR6lmjuwmHrYldNELijddJYi43IJByBXSMQgIHSYM/edit.

What is your preference?

[JanLin]

Good suggestion. Agree that is may fit better with the aries-rfcs repo as my hipe has a broader topic. I will plan to move it to Aries with an updated contribution. If I run into problems I will get back. Thanks

…

On 20 Jun 2019, at 07:29, Daniel Hardman ***@***.***> wrote: @JanLin <https://github.com/JanLin> This PR has languished for a long time. We just updated the process that this repo uses to accept PRs, and it would now be easy to merge if you still want to. However, I think it fits better now into the aries-rfcs repo. I would be happy to help you move it there if you like. See https://docs.google.com/document/d/1BKLR6lmjuwmHrYldNELijddJYi43IJByBXSMQgIHSYM/edit <https://docs.google.com/document/d/1BKLR6lmjuwmHrYldNELijddJYi43IJByBXSMQgIHSYM/edit>. What is your preference? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55?email_source=notifications&email_token=AB2RHL4R5VDPCENXQJ3VJODP3MIR3A5CNFSM4GCUIR72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYEJYKY#issuecomment-503880747>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB2RHL4F7ZXKUOTF5P5HPULP3MIR3ANCNFSM4GCUIR7Q>.

[dhh1128]

This is now superseded by Aries RFC 0167