http://kantarainitiative.org/confluence/display/BSC/2016-10+%28October+2016%... Agenda: - Report <http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockchain+and+Smart+Contracts+Discussion+Group> writing Attending: Eve, Scott S, Adrian, Kathleen, Matisse, Colin, Marco?, John W? Matisse has suggested the blood diamond example as a case study to analyze for this properties of enforcing ethics at a technology level. Here's a YouTube video <https://youtu.be/4sm5LNqL5j0> on it. This could be extended to several provenance use cases. Scott notes everledger.io <http://www.everledger.io/> as a company offering blockchain-based fraud detection services for insurance purposes, where the generic use case is fraud detection and the specific case study involves ethics of blood diamond provenance. The ivory trade could be another ethics use case. See also this article <http://www.coindesk.com/kimberley-process-continue-work-blood-diamond-blockchain/>. The current process is Kimberley Process certificates. Apparently the Kimberley Process is looking at blockchain <https://www.kimberleyprocess.com/en/system/files/documents/kimberley_process_mid-term_report.pdf> now. Would Matisse be willing to take on the assignment to write up the blood diamond case study? Scott S is interesting in this too. Matisse is only free after her PhD thesis is done in a month's time, and would like a structure. How about this for case study structures? - Deficits and benefits of how the problem space was/is being solved - Proposed benefits of the new solution space – crystalize this (e.g., fraud, not "user empowerment"?) - Different approaches being taken (e.g., whitelist? blacklist? other?) in the new solution space - Strengths, weaknesses, risks, and open issues being seen in practice - Cross-references to the appropriate other technology, case study, and use case sections - Since our Report process is time-boxed, go into only as much depth as you can in a short period of time *AI:* Scott S: Attempt to turn the draft case study structure into a questionnaire and see if we can reach out to everledger.io to try it out so we can begin to fill out a case study section with the results. We always reserve the right to massage any answers we get back, to do more research, and publish information in our own words. Note that it's possible to put diagrams in the final report. We will make sure of it. All report authors should feel free to submit diagrams and graphics. Discussing the language Scott has contributed to the Certificate Transparency <http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockchain+and+Smart+Contracts+Discussion+Group#ReportfromtheBlockchainandSmartContractsDiscussionGroup-CertificateTransparency> section of the report: We suggest adding a bit of discussion about the weaknesses of PKI, and the optimistic assumption of much blockchain technology about PKI and how identity can just use a clean global PKI system. Also, how much of blockchain node participation is anonymous, how much of the time? The notion behind Certificate Transparency is to force, at a technical level, knowledge of what you've got. The section could contain cross-references to the other technology sections. *AI:* Eve: Find for Scott S the "Let's fix HTTPS" presentation that explains why browsers are never going to get better at cert management. Thomas reports that he is working on his IPFS section. Kathleen is working on her HL7 section. Eve's thoughts for her UMA section run in this direction: UMA's primary goal is empowerment for a particular type of transaction, which is sharing of digital resources. In the course of coming up with an architecture for that, UMA invented an interestingly powerful service (the AS), which is, however, a centralized entity that must be trusted. (Adrian's "pure" form requires this to be chosen by the individual, akin to a public blockchain that is completely decentralized, whereas most initial deployments are expected to be akin to a permissioned blockchain that we could consider less "pure".) The work on UMA Legal attempts to mitigate the risk of having central services matching up to distributed APIs. More brainstorming on UMA section ideas: Adrian's formulation of requirements sent to the list: Trust and personal data - identifying the patient that is the subject of the data, - identifying the user requesting patient data, - recording and auditing the authorization to release the patient data, - establishing the authenticity of the data that is being released, - paying for the service that delivered the patient data, - controlling and auditing that the shared data was used as expected. Eve's revision: ??? - Identifying the resource subject - Identifying claims about the user requesting access - (something about authorization itself??) - Recording and auditing the authorization to access the resource - Establishing the authenticity of the resource that was accessed - Paying for the service that delivered the resource - Controlling and auditing that the resource was used as expected We made a few changes in the report itself as well. *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits* are coming to <http://summits.forgerock.com/> *London and Paris!*