{"action":"opened","issue":{"url":"https://api.github.com/repos/ethereum/solidity/issues/1546","repository_url":"https://api.github.com/repos/ethereum/solidity","labels_url":"https://api.github.com/repos/ethereum/solidity/issues/1546/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/solidity/issues/1546/comments","events_url":"https://api.github.com/repos/ethereum/solidity/issues/1546/events","html_url":"https://github.com/ethereum/solidity/issues/1546","id":198913476,"number":1546,"title":"Designing a smart contract for real world use case(s)","user":{"login":"varunagarwal315","id":12291579,"avatar_url":"https://avatars.githubusercontent.com/u/12291579?v=3","gravatar_id":"","url":"https://api.github.com/users/varunagarwal315","html_url":"https://github.com/varunagarwal315","followers_url":"https://api.github.com/users/varunagarwal315/followers","following_url":"https://api.github.com/users/varunagarwal315/following{/other_user}","gists_url":"https://api.github.com/users/varunagarwal315/gists{/gist_id}","starred_url":"https://api.github.com/users/varunagarwal315/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/varunagarwal315/subscriptions","organizations_url":"https://api.github.com/users/varunagarwal315/orgs","repos_url":"https://api.github.com/users/varunagarwal315/repos","events_url":"https://api.github.com/users/varunagarwal315/events{/privacy}","received_events_url":"https://api.github.com/users/varunagarwal315/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-01-05T09:42:24Z","updated_at":"2017-01-05T09:42:24Z","closed_at":null,"body":"I would like to refer to [this][1] documentation of list of possible use-cases for smart contracts written by people part of the hyperledger team. I have deployed some basic smart contracts of my own on a testnet with basic permissioning as well and want to tackle a much more advance, real-world use case.\r\n\r\nThe problem statement is \r\n\r\n\r\n>    Jane is opening an account at MidBank in Finland. As part of that process, the bank asks her to provide two from a variety of possible sources to confirm her identity - a so called \"Know Your Customer\" check. She selects government-supplied verifiable claims that confirm she receives postal mail at a certain address and that she has a national ID card. Confirming these allows the bank to open her account and be confident in her identity when she conducts transactions.\r\n    Now that the account is open, Jane is issued a digitally signed credential for her checking account at MidBank. This credential verifies that Jane has an account at MidBank and has access to her associated checking account. Since MidBank (and all banks in Finland) are required to perform \"Know Your Customer\" checks on accounts, this credential can also be used as sufficient verification by other financial institutions. This can help Jane assure destination banks that she is verified, thereby allaying concerns about misdirected transactions and money laundering.\r\n\r\n\r\nI have one `people` contract which is called every time a new person like Jane is added to the system.\r\n Multiple identities can be used. Now if in the future, apart from Social Security number or address, say a mobile bill is accepted, then in that case it is better to have separate contracts for them and link it to each `people` contract as contracts cannot be upgraded. Each identity contract can either hold information for one unique person or can be used a registry and contain all data related to one document type (passport etc.) for each of the `people` contracts deployed.\r\n\r\nI wanted to have an open discussion on how contracts such as these can be structured keeping in mind that the system should be upgradable, in the sense that, if a new government document is made acceptable, the system should be able to account for it without causing hindrance \r\n\r\n\r\nIf the system has 100k people then keeping one `identity contract` to handle each document type and use it as a registry would be good, or deploying 100k + (100k * number of docs) be a more viable option as each person would then have his own `person contract` and separate contracts linked to it for each document type that he would upload.\r\n\r\nWould love to hear community thoughts on this.\r\n1]: https://opencreds.github.io/vc-use-cases/#finance"}}
{"actor":{"display_login":"varunagarwal315"}}