-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New HIPE consent receipt #55
Conversation
|
||
**Storage limitation**: PII data should not be stored indefinitely and need to have a clear storage limitation. Storage limitation as defined by GDPR limits how long PII data is kept to fulfill the legitimate reasons for providing a service. | ||
|
||
**Processing TTL**: Indy currently supports proof only limited to a specific point in time. For companies that collect data over time to check for proof every minute is not a viable solution. The **processing Time To Live (TTL)** gives allowances for data ingestion to be done for an extended period without requiring performing new proof request. Further down examples will be given that explain the usage of the term. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
… that Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
…eferences Signed-off-by: Stephen Curran <swcurran@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: mhailstone <matthew.hailstone@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com> Signed-off-by: JanL <jan.lindquist@dativa.com>
Creating initial draft. Signed-off-by: JanL <jan.lindquist@dativa.com>
initial draft Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: JanL <jan.lindquist@dativa.com>
moved to new folder Signed-off-by: JanL <jan.lindquist@dativa.com>
Following changes were made. - based on comments added new reference to SSI article on Medium. (comment from dhh1128) - added reference to Customer Commons initiative under references and also prior art. (comment from dhh1128) - added further clarification to Introduction of edge and cloud agents. (comment from dhh1128) Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: JanL <jan.lindquist@dativa.com>
Added explanation regarding usage of wallets that they may not be required for data subjects. Signed-off-by: JanL <jan.lindquist@dativa.com>
- Added a brief puml for the README - Updated list of open questions - Added link to sequence diagram and also schemas Signed-off-by: JanL <jan.lindquist@dativa.com>
- Updated all powerpoint diagrams with latest terms. Signed-off-by: JanL <jan.lindquist@dativa.com>
- Renamed file name Signed-off-by: JanL <jan.lindquist@dativa.com>
Signed-off-by: JanL <jan.lindquist@dativa.com>
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):
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? |
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? |
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. |
To clarify last comment from @dhh1128 the privacy guarantee we lose is that multiple presentations to the same verifier can be linked. |
@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? |
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>.
|
This is now superseded by Aries RFC 0167 |
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