35 | This Charter is work in progress. To submit feedback, 36 | please use {TBD:GitHub repository URL} Issues 37 | where Charter is being developed. 38 |
39 |57 | The mission of this group is to establish a standard for creating a universally verifiable proof of any data, file, or series of events, by anchoring data to the blockchain and other sources. This allows anyone to prove the data existed at a point in time and has not been modified. This “chainpoint” can serve as a digital receipt for any purpose. 58 |
59 |63 | {TBD: Describe topics that are in scope. For specifications that the CLA 64 | patent section applies to, it is helpful to describe the scope in a way 65 | that it is clear what types of technologies will be defined in 66 | specifications, as opposed to adoption by reference or underlying 67 | technology not defined in the proposed spec. Key use cases are often 68 | helpful in describing scope. If no specifications will be defined in the 69 | group that the CLA patent section applies to, the charter should clearly 70 | state that. A clear scope is particularly important where patent 71 | licensing obligations may apply.} 72 | 73 |
The Chainpoint group will publish and formalize a digital receipt vocabulary and format as a stable reference specification, create and maintain a test suite to promote interoperability, and collect feedback and use cases for the future evolution for the specification. Each digital receipt, or chainpoint is a JSON-LD document that contains all the information needed to verify the data without relying on a trusted third party. The name chainpoint derives from the addressable location (or anchor point) that the digital receipt occupies in a blockchain, although a chainpoint may be written to any verifiable and persistent data source and does not strictly require a blockchain.
74 | 75 |The initial specification will be based on the Chainpoint v2 specification, which was developed from the v1 specification over the course of a year of active deployment, refinement, and collaboration, and which has been widely adopted by several independent ledger services.
76 | 77 |A future version of the specification may be developed which takes into account additional feedback, use cases, requirements, and real-world experience.
78 | 79 |Maybe add something specific about the primary use cases here?
80 | 81 |The goal is to keep the specification and the chainpoint small, flexible, and easy to use and process.
82 | 83 |87 | This group will not develop any other blockchain technologies. The scope is limited to digital receipts, proof-of-existence, timestamping, and data integrity solutions. 88 |
89 |This specification defines a JSON-LD vocabulary and structure for expressing a verifiable, timestamped, addressable proof-of-existence for the presence of a specific data resource at a particular URL.
100 | 101 |Expected completion: Q2 2017
102 |109 | The group may produce in-scope Community Group Reports supplemental to its specifications, including use cases, requirements, developer documentation, or white papers. 110 |
111 | 112 |116 | The group MAY produce test suites to support the Specifications. Please 117 | see the GitHub LICENSE file (TODO: add LICENSE.md file to repo and link to it here) for test suite contribution licensing 118 | information. 119 |
120 |135 | The group operates under the Community and Business 137 | Group Process. Terms in this Charter that conflict with those of the 138 | Community and Business Group Process are void. 139 |
140 |141 | As with other Community Groups, W3C seeks organizational licensing 142 | commitments under the W3C Community 144 | Contributor License Agreement (CLA). When people request to 145 | participate without representing their organization's legal interests, 146 | W3C will in general approve those requests for this group with the 147 | following understanding: W3C will seek and expect an organizational 148 | commitment under the CLA starting with the individual's first request to 149 | make a contribution to a group Deliverable. 150 | The section on Contribution Mechanics describes 151 | how W3C expects to monitor these contribution requests. 152 |
153 |157 | The group will not publish Specifications on topics other than those 158 | listed under Specifications above. See 159 | below for how to modify the charter. 160 |
161 |165 | Substantive Contributions to Specifications can only be made by Community 166 | Group Participants who have agreed to the W3C Community 168 | Contributor License Agreement (CLA). 169 |
170 |171 | Specifications created in the Community Group must use the 173 | W3C Software and Document License. All other documents produced by 174 | the group should use that License where possible. 175 |
176 |177 | {TBD: if CG doesn't use GitHub replace the remaining paragraphs in this 178 | section with: "All Contributions are made on the groups public mail list 179 | or public contrib list"} 180 |
181 |182 | Community Group participants agree to make all contributions in the 183 | GitHub repo the group is using for the particular document. This may be 184 | in the form of a pull request (preferred), by raising an issue, or by 185 | adding a comment to an existing issue. 186 |
187 |188 | All Github repositories attached to the Community Group must contain a 189 | copy of the CONTRIBUTING 191 | and LICENSE 193 | files. 194 |
195 |199 | The group will conduct all of its technical work in public. If the group 200 | uses GitHub, all technical work will occur in its GitHub repositories 201 | (and not in mailing list discussions). This is to ensure contributions 202 | can be tracked through a software tool. 203 |
204 |205 | Meetings may be restricted to Community Group participants, but a public 206 | summary or minutes must be posted to the group's public mailing list, or 207 | to a GitHub issue if the group uses GitHub. 208 |
209 |213 | This group will seek to make decisions where there is consensus. Groups 214 | are free to decide how to make decisions (e.g. Participants who have 215 | earned Committer status for a history of useful contributions assess 216 | consensus, or the Chair assesses consensus, or where consensus isn't 217 | clear there is a Call for Consensus [CfC] to allow multi-day online 218 | feedback for a proposed course of action). It is expected that 219 | participants can earn Committer status through a history of valuable 220 | contributions as is common in open source projects. After discussion and 221 | due consideration of different opinions, a decision should be publicly 222 | recorded (where GitHub is used as the resolution of an Issue). 223 |
224 |225 | If substantial disagreement remains (e.g. the group is divided) and the 226 | group needs to decide an Issue in order to continue to make progress, the 227 | Committers will choose an alternative that had substantial support (with 228 | a vote of Committers if necessary). Individuals who disagree with the 229 | choice are strongly encouraged to take ownership of their objection by 230 | taking ownership of an alternative fork. This is explicitly allowed (and 231 | preferred to blocking progress) with a goal of letting implementation 232 | experience inform which spec is ultimately chosen by the group to move 233 | ahead with. 234 |
235 |236 | Any decisions reached at any meeting are tentative and should be recorded 237 | in a GitHub Issue for groups that use GitHub and otherwise on the group's 238 | public mail list. Any group participant may object to a decision reached 239 | at an online or in-person meeting within 7 days of publication of the 240 | decision provided that they include clear technical reasons for their 241 | objection. The Chairs will facilitate discussion to try to resolve the 242 | objection according to the decision process. 243 |
244 |245 | It is the Chairs' responsibility to ensure that the decision process is 246 | fair, respects the consensus of the CG, and does not unreasonably favour 247 | or discriminate against any group participant or their employer. 248 |
249 |253 | Participants in this group choose their Chair(s) and can replace their 254 | Chair(s) at any time using whatever means they prefer. However, if 5 255 | participants, no two from the same organisation, call for an election, 256 | the group must use the following process to replace any current Chair(s) 257 | with a new Chair, consulting the Community Development Lead on election 258 | operations (e.g., voting infrastructure and using RFC 2777). 260 |
261 |276 | Participants dissatisfied with the outcome of an election may ask the 277 | Community Development Lead to intervene. The Community Development Lead, 278 | after evaluating the election, may take any action including no action. 279 |
280 |284 | The group can decide to work on a proposed amended charter, editing the 285 | text using the Decision Process described above. 286 | The decision on whether to adopt the amended charter is made by 287 | conducting a 30-day vote on the proposed new charter. The new charter, if 288 | approved, takes effect on either the proposed date in the charter itself, 289 | or 7 days after the result of the election is announced, whichever is 290 | later. A new charter must receive 2/3 of the votes cast in the approval 291 | vote to pass. The group may make simple corrections to the charter such 292 | as deliverable dates by the simpler group decision process rather than 293 | this charter amendment process. The group will use the amendment process 294 | for any substantive changes to the goals, scope, deliverables, decision 295 | process or rules for amending the charter. 296 |
297 | 298 | 299 | -------------------------------------------------------------------------------- /use cases/blockchain_use_cases.md: -------------------------------------------------------------------------------- 1 | Fork from https://github.com/dprophet/blockchain_use_cases 2 | 3 | Erik Anderson 4 | Bloomberg 5 | 6 | For the purpose of this document lets replace Blockchain with DLT (Distributed Ledger Technology). DLT is: 7 | - A ledger that generally runs in a hostile environment like the public internet 8 | - It uses cryptography to try and solve identity and ownership problems in this public environment 9 | - It uses cryptography to try and automate business processes & reduce latency to accelerate the value of money 10 | - Assets are on and managed on the ledger. Off ledger interactions are considered legacy, slow, and inefficient. 11 | - Most real use cases of this technology are theoretical discussions, unimplemented, without a single live use case with enough scalability, security, or appropriate regulatory framework in place. 12 | - Data on the DLT can be permissioned/private but all transactions on this ledger are public and all parties can see those transactions. 13 | - DLT is the technology not the actual asset. The asset is the application utilizing the DLT (Stock trades, payments, swap trade, currencies, bonds & coupons, etc). 14 | - Transactions are absolute, there is no reverting the transaction. Chargebacks/returns are a business process because the ledger cannot be reversed. You must initiate a transaction back to the originating party. 15 | - Current DLT Identity & Data security mechanisms is 'relatively unused' cryptography built for financial services in 1990's. These mathematics has a certain lifetime because computers and distributed calculations are getting faster & more efficient. The current cryptography is not resistive to quantum computer attacks, 5-10yr max additional lifetime, target window 2021-2026. 16 | 17 | Use Case, Direct Financial Services beneficiaries of Blockchain & Distributed Ledger Technology-DLT, Including Identity & Data Security 18 | - Directly lending 19 | - Middle market direct lending 20 | - End consumer direct lending 21 | - Crowd source lending 22 | - Insurance 23 | - Claims: 24 | - Claims will require verifiable assets tied back to identity & proof of purchases 25 | - Personal insurance. Chain of a lifetime. Buying a diamond you had a complete record of the crimes and claims against it? 26 | - Codifying Contracts (ie Smart Contracts) 27 | - Financial Services is expecting Smart Contracts to be a container for the execution of financial business transactions. These containers need stronger security and identity to assure all parties are known, trusted. 28 | - Existing business models can be coded into Smart Contracts to accelerate the value of money. 29 | - Legacy financial services 30 | - Securely embeddable Identity elements in ISO 20022, FpML, FIX, ISO 8583, etc 31 | - Wrap security around these legacy financial services message formats will give you the non-reversible feature of a ledger to solve non-repudiation issues. 32 | - Trades 33 | - Real-time valuation of assets and settlement 34 | - Scoring, ranking, trustworthiness, and other compliant-obligatory algorithms to categorize 'codes of conduct'. This applies to organizations and individuals. 35 | Even if Settlement occurs real-time, collateral still moves at a future date. We still need to score trustworthiness and bind that identities. 36 | - Posting of collateral for OTC trades. The posting of collateral & verified assets needs to be tied back to real world identities. Currently 3rd parties (ie clearing houses) are required as part of this step to validate real world ID and asset ownerships. Without DLT+Identity+VerifiableAssets it will be impossible to construct consensus algorithms to facilitate real-time settlement and measure trustworthiness. 37 | - Verifiable assets placed on a public ledger becomes a utility to servicing of other Instruments 38 | - Assets are on and managed on the ledger. Off ledger interactions are considered legacy, slow, and inefficient. 39 | - Verifiable assets, by themselves, arent as valuable as the channels they create for servicing of other instruments. 40 | - Corporate actions 41 | - Bond coupons 42 | - Dividends 43 | - Corporate Debt 44 | - Syndicated loans 45 | - Private securities 46 | - Asset back instruments 47 | - Many financial instruments are asset backed. The algorithmic version of "hard linking of the verified assets to the instruments/securities" and placing on a DLT will allow automation reconciliation of the accounts and instrument repricing. 48 | - This will add a strong level of operational resiliency to capital markets utilizing asset linking to other instruments. 49 | - Issuing FIGI codes (Financial Instrument Global Identifier) for assets and tying those to identities will create a forensic trail to help prevent the same asset from fraudulently used for multiple different instruments & business deals. 50 | Example: 2x, 3x, 4x... over collateralization of the same asset for multiple business deals. 51 | - A common data encapsulation around which: 52 | - Financial institutions can use to help settle transactions. 53 | - Common data structure for embedding of KYC/AML and other compliance information. 54 | - Financial Institutions are faced with much higher regulatory, compliance costs as well as strict restrictions around capital exposure. These institutions are looking for innovative ways to reduce future regulatory and compliance costs as well as optimally manage their existing capital to generate new revenue streams. 55 | - Data exchange across dissimilar non-interoperable technology. 56 | - Digitization of analog documentation. 57 | - Payments and Remittance 58 | - Transactions can occur directly between two parties on a frictionless P2P basis. The technology application for overseas transactions has the potential to reduce risk, transaction costs and to improve speed, efficiency and transparency. 59 | - By including identity (either tokenized or privacy protection layer) we can allow regulatory controls over the movement of the value. 60 | - Issuance, Ownership and Transfer of Financial Instruments 61 | - A DLT securities market allows traders to buy or sell stocks directly on exchanges or directly to other market participants in a P2P manner without the intermediation services provided by a broker or clearinghouse. 62 | - By including identity (either tokenized or privacy protection layer) we can allow regulatory controls over the movement of the value. 63 | - In financial services, chains of custody of a financial instrument is deeply regulated territory. This chain of custody is a very costly legacy process. The only way to speed this up is to securely & privately embed chains of identity/ownership into the very process. 64 | - Without proper Identity it will be possible for bad actors to continue to create the same chaos thats occurring today. You will need to be securely authenticated with the system and have the proper access controls to the information. 65 | - Massive privacy issues related to publicizing transaction information over a public network/ledger. As a result of this problem the majority of the capital market industry is focused on development of private/permissioned DLT that will never allow an Internet based browser access to these private networks. Access will likely occur via proprietary applications or proprietarty+embedded Webkit technology. 66 | - By linking credentials to individuals, individuals and assets to corporate entities we can create unique cryptographic identification tagging to tradable instruments. Wrapped within a permissioned based privacy friendly security layer it will allow association of people and assets within a hostile environment (such as a public Blockchain running on the internet). This will allow authorized parties to utilize mathematical forensics to trace the chains of ownership yet prevent regulatory snooping. 67 | NOTE: Some will argue that this is a only on-ledger work effort but even ledger work requires on-ramp, off-ramp, data updates, and linked data to off ledger sources. 68 | - Clearing and Settlement 69 | - On the distributed ledger technology (DLT), the entire lifecycle of a trade "including its execution, clearing and settlement" can occur at trade level, lowering post-trade latency and reducing counterparty exposures. 70 | - This can only occur if the transactions themselves are tied back to real world identities yet layered with security mechanisms that protect the privacy yet allow role based regulatory insight into the transactions themselves. Roles could be State Taxes, court auditors, FinCEN. 71 | - Servicing of Instruments 72 | - Through the utilization of smart contracts, financial instruments can be pre-programmed to carry out corporate actions, such as payment of bond coupons or dividends. 73 | - This is only possible by removing the 20 year old security technologies that current Blockchain was built on and layer on Identity with privacy protective mechanisms. 74 | - Reconciliation 75 | - Since DLT is replicated and synchronized database of transactions distributed across a network of users, manual reconciliation become redundant. 76 | - Identity and security layering will be required that trust (ie access to manipulate underlying assets), is granted only to bits of contacts/ledgers that need to interoperate 77 | - Know-your-client and Anti-money Laundering Registries 78 | - the perception of anonymity associated with permissionless DLT like Bitcoin challenges existing know-your-client (KYC) rules and protocols; 79 | - An individual, or an entity's identity can be stored in an Identity Provider and utilized on the blockchain, ensuring secure and rapid ID authentication without the warehousing of sensitive data at third-party repositories. This will allow KYC/AML information to be directly propagated via DLT yet still protect the privacy of the individual 80 | - Regulatory Reporting 81 | - The DLT is fundamentally a record of transaction history, delivering a fully transparent, accessible transactional database for governing bodies. 82 | - By combining Identity & secure privacy layering mechanisms you can grant access to governing bodies without allowing regulatory snooping. 83 | - Reputational Management System 84 | - Reputation systems are in dire need of connectivity to real & merit based identities. This will prevent merit based identities (Ebay profile) from being stolen and used by unauthorized users. 85 | - Dont marginalize or penalize anyone. 86 | - Fines 87 | - Since the 2008 financial crisis, twenty of the world's largest banks including JPMorgan, Citibank and HSBC have paid over US$235 billion in fines. 88 | - Interestingly, the majority of the fines derived from the banking system's inefficiency and failure to keep track of "verifiable assets". Example: sold mortgages, insurance products, collateralized assets, etc 89 | - A lower level standard that addresses verifiable assets, transference of assets, assets chained with other assets, assets with shared ownership, assets with "collateral burdens" will help facilitate creation of a document ledger of assets to reduce the regulatory arbitrage that Financial Services is experiencing. 90 | - Accounting Ledgers & audit chains 91 | - Reduce corporate fraud. Transaction and the record of the transaction are the same thing. 92 | - Trustless audit chains, property title chains, record keeping for sensitive personal, medical and corporate materials, and public accountability mechanisms. 93 | - Internet of things. A ledger of devices and the transactions that happen between them. 94 | - Licensing Ledger 95 | - Empower self-service licensing models like yearly subscriptions, ownership for life of device, ownership for life of the individual. 96 | - Soft linking the license of the content to the ledger. Current approaches are hard license approaches where the licensing is embedded in the content. 97 | - Relicensing of the content without having to reissue the content. 98 | - Direct tracking of licensed content for devices 99 | - Relicensing of 2nd party content to 3rd parties. Example: Electronic music, purchased by a conductor, for Concert and Quire 100 | - Tracking of & direct payment of commissions for 3rd party re-sellers. 101 | - Direct 1x1 coupon issuance to the individual without the need for a 3rd party. 102 | - Dynamic licensing between the electronic format and a license ledger provides us a lot more "self-service" licensing options 103 | - Creation of currently unheard of licensing models like licensing of all content from one particular artist or bulk licensing to a group of individuals. 104 | - Content licensed to a cryptographic biometric identifier 105 | - Usage based licensing like 5 prints of a 3D printing schematic, 3 plays of a movie, 1 free play of a song, 1 passthrough of a electronic sheet music. 106 | - Better persistence of indication of rights (e.g., what happens if company using live data goes out of business?). Ledger persists even after companies are gone. 107 | - Identity 108 | - In Capital Markets, Identity isn't just about "what you know" but also "when you knew it". 109 | - Selective disclosure: You can verify the age but not the individual, Verify first and last name. 110 | - Digital identities will get compromied. Digital Identity should be self-issued but verified attributes or "digital selfies" can be attached to that identity. 111 | - Digital identifier is the Christmas Tree, attributes are the ornaments 112 | - Identity assertions, once extracted out of the Blockchain must be invalid, considered compromised, or at-a-minimum a very short time-to-live. Some data values, such as proofs of a user's identity, must be considered fresh to have any value. 113 | - Identity isnt just about ontology (data structure of user verifiable attributes) but its also about how the environment influences that information. User privacy, court auditors, law enforcement, international laws all apply pressure on the environment and requirements for access to user verifiable attributes. 114 | - At its simplest form, Identity over a hostile environment like the Internet is about combining authentication and secrecy techniques to create a "Privacy Friendly Identity & Data Management". 115 | - Current trends is "Hardware as surrogate for the Identity". Ultimately the assurance of a user's identity will come down to the capabilities or limitations of the user's hardware device. Devices are registered with a ledger to create a trust mechanism. 116 | - Blockchain is certainly NOT the solution to Identity as its too far from the point of origin of the user. However Blockchain uniquely solves 1 problem that has been eluding Financial Services for many decades, non-repudiation. If you use the above W3C specs as a tunnel/entry-point to the Blockchain you can put user assertions & claims on a public ledger yet keep the access controls to that information "In the users pocket". 117 | - Privacy friendly Identity Management: 118 | - Usage of Identity in a hostile environment that is forensically trackable yet private at the same time. It needs to allow: 119 | - Friendly regulatory & legal tracking 120 | - Utilize anti-snooping measures to protect the privacy of the corporations & individual alike. 121 | - Extreme privacy for purchases of pharmaceuticals. 122 | - Empower Government use cases like: 123 | - Government programs like food stamps and Medicare where the government is providing the funding. 124 | - Grants. So how were those funds utilized? 125 | - Empower business use cases like: 126 | - Business processes for a shared role or delegable usage in instances of vacations, 127 | - Incase of death's, willable/transferable assets that were bound to the identity of the deceased. 128 | - Empower individual use cases like: 129 | - willable/transferable assets that were bound to the identity of the deceased. 130 | - Persona's and pure merit based identities and scoring mechanisms for online purchases. In many cases 131 | - Secure yet configurable access to varying levels of sensitive data. 132 | - Usage of secure objects: 133 | - Secure objects allow the access controls for its contents to be integrated with the object. Regardless of where the object is stored the data is secure 134 | - Secure objects have access control mechanisms where in roles can be granted to view various different levels of the objects contents. 135 | - Secure Objects permissioned by an organization chart and employee roles. 136 | - Objects are always secure. Even internal employees go through the same permissioning system as 2nd & 3rd parties. 137 | - There is no back door, only an algorithmic construction for keys to the front door. 138 | - The front door can be permissioned for roles like State Taxes, Auditors, Law Enforcement, various tiers of regulators, compliance officers, etc. 139 | - Algorithms construct dynamic Keys for access through the front door. 140 | - There is a different key for each object. Hacking 1 object only exposes the contents of that singular object: 141 | Example: Hacking the 1 object only exposes one transaction, not an series/history of transactions. 142 | - Voting 143 | - If you combine Identity with the Ledger this will prevent double voting and secure the data against unauthorized access by 3rd parties. You can anonymize various attributes of that data to allow useful statistics without disclosing privacy. 144 | - Regulatory Insight and Oversight 145 | - Regulation, in a nutshell, is about the movement of and insight into information. Regulation and Blockchain is about analytic's and intelligence of content before and after data is written to the ledger. 146 | - Insight: A public ledger, with the appropriate layering of privacy friendly mechanisms, can be used to also allow access to various anonymous statistics that governments uses to measure "economic health". 147 | Example: Demographics, housing, International movement of money, spending habits where consumers switch from 2% milk to powdered milk, etc. 148 | - Oversight: There exists many instances where Regulatory authorities have legal oversight of the movement of value. In these cases, allowing consensus algorithms with regulatory "veto" power over those transactions provides the regulators with the tools they need. 149 | Note: This is a concept I have been pushing to put the "regulations in the code". Regulations can be automated with far less cost and slower human involvement. This will directly reduce the amount of regulatory arbitrage & hand waving those authorities utilize. 150 | - Wallet 151 | - Current trend are toward physical wallets in the form of hardware (e.g. a dongle or mobile phone itself). 152 | - If you combine the hardware key management with a public ledger you can truly create a digital wallet since the contents of the wallet are secure regardless of the mechanics surrounding the wallet storage. Hardware will offer the privacy and access controls to a cloud or Blockchain based wallet. 153 | - Data protection: 154 | - Data is written to DLT. There is no confidentiality as everyone can see it. Even if you encrypt the private metadata how do you allow differential access to a pyramid of sensitive/private information. 155 | - Other data, such as HIPAA, has a 125 year storage requirement and existing data security mechanisms cant achieve this requirement since computer capabilities double every 2 years. 156 | - Data is exposed to a hostile environment (the internet). Any hacker can download the information and attack the data structures directly. This further challenges security measures around data confidentiality half-life. 5 half-lives is an industry acceptable mechanism to measure the time it takes for data, disclosed publically, to be out dated & useless. 157 | - Encrypting data breaks existing tools used to measure economic health & statistics. Example: International movement of money, trade flow, imports/exports, etc. Entire new data analysis tools will need to be developed 158 | - Cryptography, like any technology, gets better and changes over time. Existing Blockchain cryptography is directly soldered/fused into the Blockchain protocols. This will be very costly, require lots of maintenance and developer time. 159 | - Key Management agreements and their dynamic construction is the future most companies are working toward but Tecsec long ago developed. 160 | - Blockchain was built with US 'standard' data encryption but different curves. No foreign nation trusts the other nations encryption and certainly no one trusts encryption the NSA 'helped develop and recommends'. China, UK, Europe, Japan all have their own devastations of that math and refuse to trust other nations recommendations. 161 | - Because of this reason its impossible to get consensus on an international data security algorithm. You must use a 'standard' data security schema that allows choices of which algorithms to use. Call this an international schema that wraps local/domestic requirements. Standard good practice engineering approaches can allow interoperability even when absolute math doesnt. 162 | - This schema also allows new advancements in cryptography to be added to the schema, accounting for advancements in math & technology, without breaking data encrypted through older versions of the schema. 163 | - In essence, the current financial systems reach consensus by reconciliation. This requires a lot of data collection, recording, auditing, processing, and reconciling of vast amounts of information. This process is slow, expensive, and difficult to automate. Existing Blockchain (token based ledger business model) is not a ledger to store enormous amounts of sensitive information with varying privacy, reporting, regulation & access control requirements. 164 | - When it comes to data security and Blockchain .... Its not about what they are doing right, its about what they are doing wrong. 165 | 166 | - WORDS OF WARNING: 167 | - 2015 saw a double increase in hacks targeting financial data 168 | - The very data structures of asset messaging will be targeted by hackers. 169 | - Its inevitable that financial asset information starts to move over the public internet 170 | - As asset information is exchanged it should not be possible to take the information about that asset out of the context for which that information was being exchanged. 171 | Example: I have a Bar of Gold with QR code xxx, verified/signed by Well Fargo as safely secure in their facility, being exchanged as an asset/collateral for a transaction. Assuming a hacker somehow became a man-in-the-middle of the message chorography and has access to the raw signed asset message, he should not be able to separate that signed asset for a different intent. 172 | - Verifiable asset exchange information must be 1x1 bound to the parties and inseparable from its original intent. 173 | - Blockchain is an hyped attempt at a technology leading business solutions. What problem are we trying to solve before we pick a technology. 174 | - Blockchain, as it stands today, is based on yet another procedural programming language with traditional data structures and algorithms. 175 | - Oracle, years ago, tried to codify interactive/behavior information systems into a database with PL/SQL and later followed by embedding Java. This didnt work out the way they intended. Irregardless of cryptography, Blockchain as a procedural database programming language is trying to repeat the history that Oracle went through. 176 | - Blockchain does have a role in financial services but Blockchain ISNT THE ROLE ITSELF. Blockchain role is non-repudiation via final storage of the inputs to a financial agreement, not the code that executes the agreements. 177 | - Blockchain, as a final resting place for the information, and a "dumb contract" who's intent is to help ensure the integrity of the information as its written to the ledger makes perfect sense. Codifying all information flows needed to construct financial agreements flowing to a public ledger? Now add in the integrity of the ledger is maintained by miners running computers in their basement? 178 | 179 | --------------------------------------------------------------------------------