[DG-BSC] Notes from BSC telecon Thursday, October 6

Eve Maler eve.maler at forgerock.com
Thu Oct 6 14:11:04 CDT 2016



   - Report

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
The current process is Kimberley Process certificates. Apparently the
Kimberley Process is looking at blockchain

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

Discussing the language Scott has contributed to the Certificate
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!*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20161006/a8036a4a/attachment.html>

More information about the DG-BSC mailing list