August 2016 - DG-BSC - mailman.kantarainitiative.org

Agenda for BSC telecon Tuesday, August 30 (shortly -- sorry for the late note!)
by Eve Maler 01 Nov '16

01 Nov '16

http://kantarainitiative.org/confluence/display/BSC/2016-08+%28August+2016%… We meet *Tuesdays* for 30 minutes at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options <https://www.turbobridge.com/international.html>, web interface <https://panel.turbobridge.com/webcall/>, more info <https://www.turbobridge.com/join.html>, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar <http://kantarainitiative.org/confluence/display/BSC/Calendar> for our full meeting schedule. Previous meeting minutes are here: July <http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29…> . Agenda: - Confirm timeline, scope, and approach, or revise in specific - Assign action items for report next steps *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits and UnSummits* are coming to <http://summits.forgerock.com/> *London and Paris!*

5 11

From John Moehrke
by John Wunderlich 01 Sep '16

01 Sep '16

John got this bounced on the list, so I'm posting on his behalf: ---- I have a potential new use of Blockchain and Smart-Contracts. I have written it up using the template, but don't yet have rights on the Kantara system. I have published what I have developed with a friend of mine (Health Informaticist and Researcher) onto my Blog. I am happy to submit it fully to the Kantara DG-BSC efforts if the community is interested. The use-case is Evidence Notebooks (aka Lab Notebooks, or Patent Notebooks). https://healthcaresecprivacy.blogspot.com/2016/08/blockchain -and-smart-contracts-applied.html John Moehrke ---- Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

2 1

Notes from BSC telecon Tuesday, August 30
by Eve Maler 30 Aug '16

30 Aug '16

http://kantarainitiative.org/confluence/display/BSC/2016-08+%28August+2016%… Agenda: - Confirm timeline, scope, and approach, or revise in specific - Assign action items for report next steps Attending: Scott S, Thomas, Jeff S, Ann V, Mattisse, Scott D, Thorsten, Jim H, Luk V, Marc, Kathleen, John M, Eve Congrats to Thomas (and his students) and Adrian on their awards! In Italy, law has a general structure and then specific cases separately. Ethereum's recent fork required recalculating to a point before the hack (this was in July). Is this a problem for us? Jim comments: DAO demonstrates a number of things - that you need legal framing and that even decentralized protocols depend on communities. Eve notes that many of today's technologies and techniques seem to undermine DLTs and similar in that they centralize to protect them: TTPs, trust frameworks, permissioning, etc. Scott D thinks undermining isn't necessary: e.g., a dairy coop or a partnership could overcome the need for the "poison of centralization" (Eve phrase). Since any realistic IAM system injects this poison today, and any sufficiently "wide-ecosystem" (cross-domain) distributed use case will likely need some element of IAM and/or governance to achieve its goals, can the circle be squared? What are the techniques that temper the need for centralization-style governance? Can Matisse and Scott D discuss this on the list? We can add them to the report. Do we need to write several reports? There are several themes here. One is about specific technologies being missing, e.g. (as Jeff S notes) a query language and specific techniques missing (as noted above), and one is about the central tension here. Alternatively, Eve suggests our six-month goal is to write the first broad report about the central tension given the many use cases that want to achieve empowerment. Thomas, Eric, and Scott D have already been writing a paper called Computational Sovereignty. They can distribute it – there's definitely interest! There's some support for one report with recommendations for the breakdown of several reports/maybe specs in future. Jim suggests adding analysis to break down "smart contracts" vs. generic blockchain. And there's support for putting a stake in terminology generally. AI: Eve: Ensure Ann's list contributions get into the minutes more properly. *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits and UnSummits* are coming to <http://summits.forgerock.com/> *London and Paris!*

1 0

Re: [DG-BSC] Ann Vroom Followup toBSC telecon Thursday August 25 2016
by James Hazard 30 Aug '16

30 Aug '16

Hi, John and I discussed this a bit off channel (some issue re the mailing list), and I suggested that all use cases need to be accommodated. The one that Ann posed makes sense in many contexts (for instance, I think it is like the use case for the GA4GH's ADAM consents - but giving Alice a direct role). So I did a start on John's use case - of Alice offering the same materials - and present a base for negotiation of the conditions of the use, which can then take place as an exchange of records between Alice and Researcher B. http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/… Maybe John can correct or round this out. Jim On Fri, Aug 26, 2016 at 8:33 AM, John Moehrke <johnmoehrke(a)gmail.com> wrote: > I don't think this flow is realistic. he second researcher (B) would not > likely be added to the existing consent, but rather build a new consent. > > An alternative flow : > > 1. Alice publishing her 'preferences' first, likely advertising > specific health attributes to help researchers select. (blockchain > publication, likely using Pseudonym) > 2. The researcher discovering Alice, and determines preferences meet > the research terms. (possibly using smart-contracts) > 3. The researcher approaches Alice with the offer. (blockchain > messaging) > 4. Note at this point, as JohnW diagram shows, there is usually some > form of 'negotiation'. This might be simply Alice making selections (web > form), or might be an interactive session using technology (Oauth/UMA), > human interaction, or smart-contracts. This negotiation phase is to > optimize the terms of the consent (possibly through smart-contract). > 5. The terms of the interaction are fixed (likely published on > blockchain) - possibly in smart-contract) > 6. The researcher accesses the data (with authorization from > blockchain evidence, or other such as UMA) > > > In this flow, what you have diagrammed as a new researcher (B) is really a > new opportunity -- starting at step 2. This would certainly be a new > consent. > > I realize I might be bias, as this is the scenario that I diagrammed on my > blog in May. But I still think it holds up, and would love to see it > developed under kantara > https://healthcaresecprivacy.blogspot.com/2016/05/healthcare- > blockchain-big-data.html > > John > > John Moehrke > Principal Engineering Architect: Standards - Interoperability, Privacy, > and Security > CyberPrivacy – Enabling authorized communications while respecting Privacy > M +1 920-564-2067 > JohnMoehrke(a)gmail.com > https://www.linkedin.com/in/johnmoehrke > https://healthcaresecprivacy.blogspot.com > "Quis custodiet ipsos custodes?" ("Who watches the watchers?") > > On Thu, Aug 25, 2016 at 6:27 PM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > >> Hi, >> >> Here is a first, rough sketch. There are five steps in the transaction. >> It is structured to anticipate additional requests and grants. >> 05-AliceGrants, is the last link in the chain and gives an overview of the >> steps. You could click on it, then on "Document". Note that a few nuances >> have been captured, such as the request being more limited in scope than >> the full data. >> >> The general principle is that each step in a transaction that needs to be >> persisted is documented as a record. The record states particulars and >> references its context, including the prior step. >> >> In a production system, each record can be stored under a friendly name, >> like this, or under a hash. Records can be stored in a file system >> versioned with git, like this, or in a database such as IPFS or a >> blockchain, as needed. >> >> http://www.commonaccord.org/index.php?action=list&file=GH/Ka >> ntaraInitiative/DG-BSC/Consent/Use1/ >> >> >> On Thu, Aug 25, 2016 at 4:14 PM, M AV <av_m(a)hotmail.com> wrote: >> >>> It’s one .jpeg you should be able to cut and paste from the email … >>> >>> >>> >>> *From:* James Hazard [mailto:james.g.hazard@gmail.com] >>> *Sent:* Thursday, August 25, 2016 4:13 PM >>> *To:* M AV <av_m(a)hotmail.com> >>> *Cc:* Eve Maler <eve.maler(a)forgerock.com>; dg-bsc(a)kantarainitiative.org >>> *Subject:* Re: [DG-BSC] Ann Vroom Followup toBSC telecon Thursday >>> August 25 2016 >>> >>> >>> >>> Excellent! I'll do a minimal sketch of this flow. >>> >>> >>> >>> On Thu, Aug 25, 2016 at 4:02 PM, M AV <av_m(a)hotmail.com> wrote: >>> >>> Hi – in reference to this afternoon’s conf call, here’s my >>> super-simplified version of the flow I described: >>> >>> >>> _______________________________________________ >>> DG-BSC mailing list >>> DG-BSC(a)kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>> >>> >>> >>> >>> >>> -- >>> >>> @commonaccord >>> >> >> >> >> -- >> @commonaccord >> >> _______________________________________________ >> DG-BSC mailing list >> DG-BSC(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/dg-bsc >> >> > -- @commonaccord

7 9

Re: [DG-BSC] FYI
by Colin Wallis 30 Aug '16

30 Aug '16

Thanks John M, John W, James, Patrick et al I think we are all in agreement we could do with more input from the broader BC and SC communities. And of course that is most welcomed, moreso if they bring their own communities with them and join Kantara which helps pay for the platform on which the DG rests:-). I'm also sensitive to the LC Chair Andrew's motivation to bring DG discussions to a conclusion at frequent intervals (typically 6 months) in order to get onto the work of addressing the issues that the DG use cases and deliberations raise. These two things are not mutually exclusive. We can have a WG working on solutions arising from a DG output, while at the same time having a DG continue to draw in more use cases and discussion. The Charters need to be directed and focussed accordingly and the timelines clear. John W's estimates are about right. We started this DG in May, so we need to have it concluded November latest. Take off a month of writing and there is 2 months left. It is really tempting to slip the timeline to allow more discussion in a DG, as a preface to WG work. But past experience has shown us that that often comes at the expense of focussing the resulting WG on nailing the solutions to the problems raised, to a logical formal end deliverable in a community-valuable timeframe. There is so much to do in this space. Biting it off in a continual process of digestible chunks is absolutely OK. Cheers Colin ________________________________ From: John Moehrke <johnmoehrke(a)gmail.com> Sent: 29 August 2016 13:42 To: James Hazard Cc: Colin Wallis; dg-bsc(a)kantarainitiative.org Subject: Re: [DG-BSC] FYI I have a potential new use of Blockchain and Smart-Contracts. I have written it up using the template, but don't yet have rights on the Kantara system. I have published what I have developed with a friend of mine (Health Informaticist and Researcher) onto my Blog. I am happy to submit it fully to the Kantara DG-BSC efforts if the community is interested. The use-case is Evidence Notebooks (aka Lab Notebooks, or Patent Notebooks). https://healthcaresecprivacy.blogspot.com/2016/08/blockchain-and-smart-cont… Healthcare CyberPrivacy: Blockchain and Smart-Contracts applied to Evidence Notebook <https://healthcaresecprivacy.blogspot.com/2016/08/blockchain-and-smart-cont…> healthcaresecprivacy.blogspot.com John John Moehrke Principal Engineering Architect: Standards - Interoperability, Privacy, and Security CyberPrivacy – Enabling authorized communications while respecting Privacy M +1 920-564-2067 JohnMoehrke(a)gmail.com<mailto:JohnMoehrke@gmail.com> https://www.linkedin.com/in/johnmoehrke https://healthcaresecprivacy.blogspot.com "Quis custodiet ipsos custodes?" ("Who watches the watchers?") On Mon, Aug 29, 2016 at 7:26 AM, James Hazard <james.g.hazard(a)gmail.com<mailto:james.g.hazard@gmail.com>> wrote: Hi Colin, I think it might be helpful to have wider representation of the blockchain community on the thread. I mention the DG-BSC when I am in conversation with them. On deliverables, I think we have spent good time well on discussing what blockchains and smart contracts are and aren't, and could do more on how they fit into a broader picture of automation, institutions, privacy and security. (Elements of the blockchain community, IMHO, sometimes think they don't need to think about institutions, since ridding the world of institutions is the goal of decentralization.) I suggest that we could: Describe a general "smart contract" paradigm on the lines of: i) events - (Barclay's and R3's "parameters") ii) text objects ("prose," actors, things, places, etc.) iii) Smart Contract Description Language iv) code We could describe the relationship between this "smart contract" record of relationships and transactions, on the one hand, and various databases on the other. We could describe some uses cases where blockchain databases were useful. This would not exclude developing use-case verticals. The consent to use of genetic information use case seems potent. On Mon, Aug 29, 2016 at 4:57 AM, Colin Wallis <colin_wallis(a)hotmail.com<mailto:colin_wallis@hotmail.com>> wrote: Thanks All Interesting thoughts and discussion. Indeed we could invite some other folks not engaged here to add their use cases. But it would need to be pretty soon. We are more than half way through the 6 month period for collecting use cases, allowing some time for the report to be written up with recommendations on what work we might take forward to a WG to deliver a specific useful tangible output. There is plenty of talk in this domain. But Kantara value proposition that it is about 'doing', and the community will be the better for a useful deliverable as a result. Let's not divert from that goal. That said, there is nothing to stop another DG, or a re-charter of this DG, working on a another suite of use cases perhaps for a particular context. Cheers Colin ________________________________ From: dg-bsc-bounces(a)kantarainitiative.org<mailto:dg-bsc-bounces@kantarainitiative.org> <dg-bsc-bounces(a)kantarainitiative.org<mailto:dg-bsc-bounces@kantarainitiative.org>> on behalf of Patrick Curry <patrick.curry(a)bbfa.info<mailto:patrick.curry@bbfa.info>> Sent: 28 August 2016 22:15 To: James Hazard Cc: dg-bsc(a)kantarainitiative.org<mailto:dg-bsc@kantarainitiative.org> Subject: Re: [DG-BSC] FYI The devil is in the detail and also in the minds of innovators and start ups. Back end transactions of smart contracts differ from the smart contracts in BCs with their transparency property. My colleagues see a difference and it is giving rise to new user cases. One involves the ability of all parties in a police incident to be able to validate that the legally permitted individual policeman is assigned to a specific task for that incident in real time based on his skills, training, authority etc. The rules are being executed in a distributed fashion with distributed inputs, all assured. This particular example is in the concept stage. However, there is another international logistic example. leveraging an existing pilot, that is expected to move into implementation soon. I’ll speak to Colin. We could be inviting some of the more forward BC companies to engage in the KI discussion. regards, Patrick Patrick Curry Director British Business Federation Authority - BBFA Ltd M: +44 786 024 9074<tel:%2B44%20786%20024%209074> T: +44 1980 620606<tel:%2B44%201980%20620606> patrick.curry(a)bbfa.info<mailto:patrick.curry@bbfa.info> www.bbfa.info<http://www.bbfa.info> – a not-for-profit, self-regulating body On 28 Aug 2016, at 20:07, James Hazard <james.g.hazard(a)gmail.com<mailto:james.g.hazard@gmail.com>> wrote: Yes, IPFS is a very useful resource. The chain of consent to use of information seems to unify many use cases. A few links in the chain from prior threads in the discussion: Patient consent from our discussion earlier this week: http://www.commonaccord.org/index.php?action=doc&file=/GH/KantaraInitiative… Data transfer agreements on the EU "Model Clauses": http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/europa/eur-lex/… (Available in 20+ languages, about six of which are in the demo). On Sun, Aug 28, 2016 at 10:36 AM, Thomas Hardjono <hardjono(a)mit.edu<mailto:hardjono@mit.edu>> wrote: Jim, With regards to legal contracts for data-sharing, this could be (should be) a good use-case for BSC. /thomas/ ________________________________________ From: Jim Willeke [jim(a)willeke.com<mailto:jim@willeke.com>] Sent: Sunday, August 28, 2016 9:56 AM To: John Wunderlich Cc: Thomas Hardjono; dg-bsc(a)kantarainitiative.org<mailto:dg-bsc@kantarainitiative.org> Subject: Re: [DG-BSC] FYI I agree with /thomas/. There is no reason smart contracts could not be done via a protocol with the back-end system be unknown. IPFS could be used as an example. JLINC<http://www.jlinclabs.com/protocol/> is one such idea. -- -jim Jim Willeke On Sun, Aug 28, 2016 at 5:24 AM, John Wunderlich <john(a)wunderlich.ca<mailto:john@wunderlich.ca><mailto:john@wunderlich.ca<mailto:john@wunderlich.ca>>> wrote: Blockchains of adherence? If smart contracts are published on well known URI’s, then agreeing to them by signing the contract and putting the MAC on the blockchain provides some level of assurance. This becomes even more powerful when the smart contract can accept or negotiate terms and what gets recorded on the blockchain memorialized the terms freely negotiated by both parties bots. ??? Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749<tel:%2B1%20%28647%29%20669-4749><tel:%2B1%20%28647%29%20669-4749> eMail: john(a)wunderlich.ca<mailto:john@wunderlich.ca><mailto:john@wunderlich.ca<mailto:john@wunderlich.ca>> On 28 August 2016 at 08:20, Thomas Hardjono <hardjono(a)mit.edu<mailto:hardjono@mit.edu><mailto:hardjono@mit.edu<mailto:hardjono@mit.edu>>> wrote: Thanks John, Good piece. I think there is still a lot of confusion about the promise of smart-contracts executing collectively on a syntax-rich set of nodes, vs the very limited Bitcoin-blockchain of today. Maybe BSC-DG could come up with our own new terms or language to describe the possible features of smart contracts. /thomas/ ___________________________________ On Aug 27, 2016, at 11:48 PM, John Wunderlich <john(a)wunderlich.ca<mailto:john@wunderlich.ca><mailto:john@wunderlich.ca<mailto:john@wunderlich.ca>>> wrote: https://theconversation.com/blockchain-really-only-does-one-thing-well-62668 Thanks, John 4giv spellin errurz from mobile devize This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ DG-BSC mailing list DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org><mailto:DG-BSC@kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org>> http://kantarainitiative.org/mailman/listinfo/dg-bsc This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ DG-BSC mailing list DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org><mailto:DG-BSC@kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org>> http://kantarainitiative.org/mailman/listinfo/dg-bsc _______________________________________________ DG-BSC mailing list DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc -- @commonaccord _______________________________________________ DG-BSC mailing list DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc -- @commonaccord _______________________________________________ DG-BSC mailing list DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc

8 11

Re: [DG-BSC] FYI
by John Moehrke 29 Aug '16

29 Aug '16

Note in the USA the HHS/ONC has recognized submissions to their blockchain in healthcare competition https://www.hhs.gov/about/news/2016/08/29/onc-announces-blockchain-challeng… John On Aug 29, 2016 6:01 PM, "Eve Maler" <eve.maler(a)forgerock.com> wrote: Based on our round-robin inputs, the group did reach consensus on a use case universe, so to speak, which may address this question in part (as recorded on our wiki <http://kantarainitiative.org/confluence/display/BSC/Home>): "[The DG] plans to deliver a report at the end of [the six months] that offers recommendations and observations to Kantara regarding solving use cases for empowering traditionally disempowered parties (such as individuals) to "contract and transact" e.g. with parties that traditionally hold greater power (such as companies and large countries), given the new landscape of decentralization and distributed technologies and techniques and their mixture with identity." One good reason to open up decisions previously made for reconsideration would be that we have new information on the table. One good reason to try and keep the time-boxing is that this technology world and the insights being gleaned about it (one could say the "hype cycle") are rapidly maturing, so those with requirements and use cases will want to influence the builders. Why don't we take up all of these meta-questions in tomorrow's call and try to drive towards "why we're here" once again, being *extremely concrete*? In other words, please be prepared to argue for specific scope wording that differs from (e.g., broadens or tightens) the statement above in whatever dimensions if you think it's not suitable in its current form. *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits and UnSummits* are coming to <http://summits.forgerock.com/> *London and Paris!* On Mon, Aug 29, 2016 at 3:27 PM, Thorsten H. Niebuhr [WedaCon GmbH] < tniebuhr(a)wedacon.net> wrote: > Which (for me) translates into the (open) question (and I really dont > wanna be the advocatis diaboli): > > Should we split and discuss SmartContracts independently from BlockChain > /DLT (here: in respect to identity management) ? > > SmartContracts are discussed and worked on already in the consensus field > (esp. CommonAccord) with great results/findings. > > Thesis: SmartContracts are just a usecase for DLT/Blockchain (and I have > used the order on purpose here) > > > But its late for me, and I might be totally wrong... > > > reg, > > T. > > On 30.08.2016 00:02, j stollman wrote: > > I agree with Colin and Andrew's sentiments about trying to achieve a > consensus on what the DG report should look like and what we could do as a > next step in a WG. But I don't believe that there is a natural consensus > on this broad topic at this point. Like the blind men describing the > elephant, we are looking at blockchain and smart contracts from multiple > perspectives -- none of which are wrong. > > I personally sense that there is some high-level agreement to focus on a > couple broad solution areas as targets for a report (e.g., healthcare > research consents). But I also sense that there is a lot of talking past > each other when we start drilling down to the direction people want to go. > Unlike other DGs, we have taken on two very broad topic areas in this DG > (blockchain and smart contracts) just to try to get our heads wrapped > around the subject. I don't know that we have accomplished this basic > goal. We are still "storming" and nowhere near "norming". This makes it > hard to come to any kind of agreement. And, perhaps forcing ourselves into > a lukewarm consensus just to meet a self-imposed deadline will keep us from > discovering some significant value added topics that would benefit from the > combined wisdom of the highly intelligent participants in this group. > > Perhaps, rather than a single report, we made need to consider multiple > reports and/or multiple targets for a new WG or set of WGs. I don't claim > that this is the answer. I just don't sense that we are close enough to > any consensus yet to create a report with significant value. > > Jeff > > > > --------------------------------- > Jeff Stollman > stollman.j(a)gmail.com > +1 202.683.8699 > > > Truth never triumphs — its opponents just die out. > Science advances one funeral at a time. > Max Planck > > On Mon, Aug 29, 2016 at 12:18 PM, M AV <av_m(a)hotmail.com> wrote: > >> Ditto on the keep-it-simple sentiment – except that I wouldn’t >> characterize it as “not beg[ing] the question of technology” so much as not >> getting into the weeds with details, the distinction being that I do think >> we need to keep cycling back to the basic question of what the smart >> contract/authenticated ledger technology especially enables in the proo0sed >> use cases, e.g. empowerment of smart contract parties, authenticated chain >> of asset states, etc. >> >> >> >> J ann vroom >> >> >> >> >> >> *From:* dg-bsc-bounces(a)kantarainitiative.org [mailto: >> dg-bsc-bounces(a)kantarainitiative.org] *On Behalf Of *Eve Maler >> *Sent:* Monday, August 29, 2016 12:08 PM >> *To:* Andrew Hughes <andrewhughes3000(a)gmail.com> >> >> *Cc:* dg-bsc(a)kantarainitiative.org >> *Subject:* Re: [DG-BSC] FYI >> >> >> >> Hi folks-- Now that I'm back from my vacation with self-imposed lack of >> connectivity... >> >> >> >> It's fine for us to get more experts at our table, but this should in no >> way impede our development and completion of use cases. I do think we can >> easily over-rotate on use case writing, and we probably are doing so. They >> should be short and crisp, and -- most importantly from my perspective -- *should >> not beg the question of technology* by including requirements for >> technology in them. If there's a requirement for, say, not trusting a >> central authority, say why plainly and move on. If it turns out that this >> is in tension with a requirement for limiting access by some parties for >> some purpose (e.g., the best way today for ensuring "permissioning" of some >> portion of a solution stack is to use identity/access federation frameworks >> with a TTP in them), so be it; we're here to describe the use cases and >> then those tensions in the use-case technology/technique SWOTs, not write >> specs. >> >> >> >> That said, we can be very dynamic in writing our materials given online >> docs and hyperlinking and such, and thus we can get internal and external >> review as we go along. So if we're disciplined, we don't have to >> write-write-write now and then only get review in month 6. >> >> >> >> My preference would be for use cases to be relatively text-sparse and to >> include use case diagrams as appropriate. Not sure how realistic this is, >> though. >> >> >> >> *Eve Maler *ForgeRock Office of the CTO | VP Innovation & Emerging >> Technology >> Cell +1 425.345.6756 <%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: >> @xmlgrrl >> *ForgeRock Summits and UnSummits* are coming to >> <http://summits.forgerock.com/> *London and Paris!* >> >> >> >> On Mon, Aug 29, 2016 at 8:15 AM, Andrew Hughes < >> andrewhughes3000(a)gmail.com> wrote: >> >> John W. - that is one very good candidate - it would, of course, need >> more detail at this stage to spur the need for a WG. >> >> >> >> One way to view a WG is through questions like: >> >> - Which technical or policy audience needs a consensus standard, guidance >> or tool? >> >> - Is there a state of practice or new regulation/legislation that is >> ready for compliance and conformance development and even certification? >> >> - Is there a consensus position or opinion that needs to be articulated >> in order to rally the industry and inform a specific audience? >> >> - Is there a group of related activities or initiatives that would >> benefit from an umbrella document to knit the parts together and bring >> cohesion to the disparate work? >> >> >> >> The mission of a WG is to create useful artifacts for a well-scoped, >> well-defined audience through consensus-based collaboration. This mission >> is easy to execute when participants with a strong interest in the >> outcome/output are engaged (otherwise WGs drift). >> >> >> >> andrew. >> >> >> *Andrew Hughes *CISM CISSP >> Independent Consultant >> *In Turn Information Management Consulting* >> >> o +1 650.209.7542 <%2B1%20650.209.7542> >> m +1 250.888.9474 <%2B1%20250.888.9474> >> 1249 Palmer Road, >> Victoria, BC V8P 2H8 >> AndrewHughes3000(a)gmail.com >> ca.linkedin.com/pub/andrew-hughes/a/58/682/ >> *Identity Management | IT Governance | Information Security * >> >> >> >> On Mon, Aug 29, 2016 at 8:03 AM, John Wunderlich <john(a)wunderlich.ca> >> wrote: >> >> Colin; >> >> >> >> Given the constraints/opportunities it occurs to me that the DG report >> should seek to articulate the Terms of Reference for a Kantara WG whose >> goal would be to define and work to create a Proof Of Concent instantiation >> of a Blockchain and/or SmartContract ecosystem that will move the user >> centred identity concept closer to fruition, if that makes sense? >> >> >> >> >> Sincerely, >> John Wunderlich >> @PrivacyCDN >> >> Call: +1 (647) 669-4749 <%2B1%20%28647%29%20669-4749> >> eMail: john(a)wunderlich.ca >> >> >> >> On 29 August 2016 at 10:34, Colin Wallis <colin_wallis(a)hotmail.com> >> wrote: >> >> Thanks John M, John W, James, Patrick et al >> >> >> >> I think we are all in agreement we could do with more input from the >> broader BC and SC communities. >> >> And of course that is most welcomed, moreso if they bring their own >> communities with them and join Kantara which helps pay for the platform on >> which the DG rests:-). >> >> >> >> I'm also sensitive to the LC Chair Andrew's motivation to bring DG >> discussions to a conclusion at frequent intervals (typically 6 months) in >> order to get onto the work of addressing the issues that the DG use cases >> and deliberations raise. >> >> >> >> These two things are not mutually exclusive. We can have a WG working on >> solutions arising from a DG output, while at the same time having a DG >> continue to draw in more use cases and discussion. The Charters need to be >> directed and focussed accordingly and the timelines clear. >> >> >> >> John W's estimates are about right. We started this DG in May, so we need >> to have it concluded November latest. Take off a month of writing and there >> is 2 months left. >> >> >> >> It is really tempting to slip the timeline to allow more discussion in a >> DG, as a preface to WG work. >> >> But past experience has shown us that that often comes at the expense of >> focussing the resulting WG on nailing the solutions to the problems raised, >> to a logical formal end deliverable in a community-valuable timeframe. >> >> There is so much to do in this space. >> >> Biting it off in a continual process of digestible chunks is absolutely >> OK. >> >> >> >> Cheers >> >> Colin >> >> >> >> >> >> >> ------------------------------ >> >> *From:* John Moehrke <johnmoehrke(a)gmail.com> >> *Sent:* 29 August 2016 13:42 >> *To:* James Hazard >> *Cc:* Colin Wallis; dg-bsc(a)kantarainitiative.org >> *Subject:* Re: [DG-BSC] FYI >> >> >> >> I have a potential new use of Blockchain and Smart-Contracts. I have >> written it up using the template, but don't yet have rights on the Kantara >> system. I have published what I have developed with a friend of mine >> (Health Informaticist and Researcher) onto my Blog. I am happy to submit it >> fully to the Kantara DG-BSC efforts if the community is interested. >> >> >> >> The use-case is Evidence Notebooks (aka Lab Notebooks, or Patent >> Notebooks). >> >> >> >> https://healthcaresecprivacy.blogspot.com/2016/08/blockchain >> -and-smart-contracts-applied.html >> >> Healthcare CyberPrivacy: Blockchain and Smart-Contracts applied to >> Evidence Notebook >> <https://healthcaresecprivacy.blogspot.com/2016/08/blockchain-and-smart-cont…> >> >> healthcaresecprivacy.blogspot.com >> >> >> >> >> >> John >> >> >> John Moehrke >> Principal Engineering Architect: Standards - Interoperability, Privacy, >> and Security >> CyberPrivacy – Enabling authorized communications while respecting Privacy >> M +1 920-564-2067 >> JohnMoehrke(a)gmail.com >> https://www.linkedin.com/in/johnmoehrke >> https://healthcaresecprivacy.blogspot.com >> "Quis custodiet ipsos custodes?" ("Who watches the watchers?") >> >> >> >> On Mon, Aug 29, 2016 at 7:26 AM, James Hazard <james.g.hazard(a)gmail.com> >> wrote: >> >> Hi Colin, >> >> >> >> I think it might be helpful to have wider representation of the >> blockchain community on the thread. I mention the DG-BSC when I am in >> conversation with them. >> >> >> >> On deliverables, I think we have spent good time well on discussing what >> blockchains and smart contracts are and aren't, and could do more on how >> they fit into a broader picture of automation, institutions, privacy and >> security. (Elements of the blockchain community, IMHO, sometimes think >> they don't need to think about institutions, since ridding the world of >> institutions is the goal of decentralization.) >> >> >> >> I suggest that we could: >> >> >> >> Describe a general "smart contract" paradigm on the lines of: >> >> >> >> i) events - (Barclay's and R3's "parameters") >> >> ii) text objects ("prose," actors, things, places, etc.) >> >> iii) Smart Contract Description Language >> >> iv) code >> >> >> >> We could describe the relationship between this "smart contract" record >> of relationships and transactions, on the one hand, and various databases >> on the other. >> >> >> >> We could describe some uses cases where blockchain databases were useful. >> >> >> >> This would not exclude developing use-case verticals. The consent to use >> of genetic information use case seems potent. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Aug 29, 2016 at 4:57 AM, Colin Wallis <colin_wallis(a)hotmail.com> >> wrote: >> >> Thanks All >> >> Interesting thoughts and discussion. >> >> Indeed we could invite some other folks not engaged here to add their use >> cases. >> >> But it would need to be pretty soon. >> >> We are more than half way through the 6 month period for collecting use >> cases, allowing some time for the report to be written up with >> recommendations on what work we might take forward to a WG to deliver a >> specific useful tangible output. >> >> There is plenty of talk in this domain. But Kantara value proposition >> that it is about 'doing', and the community will be the better for a useful >> deliverable as a result. Let's not divert from that goal. >> >> That said, there is nothing to stop another DG, or a re-charter of this >> DG, working on a another suite of use cases perhaps for a particular >> context. >> >> Cheers >> >> Colin >> >> >> >> >> ------------------------------ >> >> *From:* dg-bsc-bounces(a)kantarainitiative.org < >> dg-bsc-bounces(a)kantarainitiative.org> on behalf of Patrick Curry < >> patrick.curry(a)bbfa.info> >> *Sent:* 28 August 2016 22:15 >> *To:* James Hazard >> *Cc:* dg-bsc(a)kantarainitiative.org >> *Subject:* Re: [DG-BSC] FYI >> >> >> >> The devil is in the detail and also in the minds of innovators and start >> ups. >> >> >> >> Back end transactions of smart contracts differ from the smart contracts >> in BCs with their transparency property. My colleagues see a difference >> and it is giving rise to new user cases. One involves the ability of all >> parties in a police incident to be able to validate that the legally >> permitted individual policeman is assigned to a specific task for that >> incident in real time based on his skills, training, authority etc. The >> rules are being executed in a distributed fashion with distributed inputs, >> all assured. This particular example is in the concept stage. However, >> there is another international logistic example. leveraging an existing >> pilot, that is expected to move into implementation soon. >> >> >> >> I’ll speak to Colin. We could be inviting some of the more forward BC >> companies to engage in the KI discussion. >> >> >> regards, >> >> >> >> Patrick >> >> Patrick Curry >> Director >> >> British Business Federation Authority - BBFA Ltd >> M: +44 786 024 9074 >> T: +44 1980 620606 >> patrick.curry(a)bbfa.info >> www.bbfa.info – a not-for-profit, self-regulating body >> >> >> >> On 28 Aug 2016, at 20:07, James Hazard <james.g.hazard(a)gmail.com> wrote: >> >> >> >> Yes, IPFS is a very useful resource. >> >> >> >> The chain of consent to use of information seems to unify many use >> cases. A few links in the chain from prior threads in the discussion: >> >> >> >> Patient consent from our discussion earlier this week: >> >> http://www.commonaccord.org/index.php?action=doc&file=/GH/Ka >> ntaraInitiative/DG-BSC/Consent/Use1/05-AliceGrants.md >> >> >> >> Data transfer agreements on the EU "Model Clauses": >> >> http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/ >> europa/eur-lex/Privacy/ModelClauses/EN/Demo/0.md >> >> (Available in 20+ languages, about six of which are in the demo). >> >> >> >> >> >> >> >> >> >> On Sun, Aug 28, 2016 at 10:36 AM, Thomas Hardjono <hardjono(a)mit.edu> >> wrote: >> >> >> Jim, >> >> With regards to legal contracts for data-sharing, this could be (should >> be) a good use-case for BSC. >> >> /thomas/ >> >> >> >> ________________________________________ >> From: Jim Willeke [jim(a)willeke.com] >> Sent: Sunday, August 28, 2016 9:56 AM >> To: John Wunderlich >> Cc: Thomas Hardjono; dg-bsc(a)kantarainitiative.org >> Subject: Re: [DG-BSC] FYI >> >> I agree with /thomas/. There is no reason smart contracts could not be >> done via a protocol with the back-end system be unknown. >> >> IPFS could be used as an example. >> >> JLINC<http://www.jlinclabs.com/protocol/> >> >> _______________________________________________ DG-BSC mailing list DG-BSC(a)kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc ...

2 1

Enjoy
by john＠wunderlich.ca 29 Aug '16

29 Aug '16

FYI For some reason this resonates Unicode Source: http://xkcd.com/1726/ (via Mr. Reader) Thanks, John Wunderlich @PrivacyCDN Pleez 4give speling errurs, sent from a mobile device. -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Re: [DG-BSC] FYI
by Thomas Hardjono 29 Aug '16

29 Aug '16

Jim, With regards to legal contracts for data-sharing, this could be (should be) a good use-case for BSC. /thomas/ ________________________________________ From: Jim Willeke [jim(a)willeke.com] Sent: Sunday, August 28, 2016 9:56 AM To: John Wunderlich Cc: Thomas Hardjono; dg-bsc(a)kantarainitiative.org Subject: Re: [DG-BSC] FYI I agree with /thomas/. There is no reason smart contracts could not be done via a protocol with the back-end system be unknown. IPFS could be used as an example. JLINC<http://www.jlinclabs.com/protocol/> is one such idea. -- -jim Jim Willeke On Sun, Aug 28, 2016 at 5:24 AM, John Wunderlich <john(a)wunderlich.ca<mailto:john@wunderlich.ca>> wrote: Blockchains of adherence? If smart contracts are published on well known URI’s, then agreeing to them by signing the contract and putting the MAC on the blockchain provides some level of assurance. This becomes even more powerful when the smart contract can accept or negotiate terms and what gets recorded on the blockchain memorialized the terms freely negotiated by both parties bots. ??? Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749<tel:%2B1%20%28647%29%20669-4749> eMail: john(a)wunderlich.ca<mailto:john@wunderlich.ca> On 28 August 2016 at 08:20, Thomas Hardjono <hardjono(a)mit.edu<mailto:hardjono@mit.edu>> wrote: Thanks John, Good piece. I think there is still a lot of confusion about the promise of smart-contracts executing collectively on a syntax-rich set of nodes, vs the very limited Bitcoin-blockchain of today. Maybe BSC-DG could come up with our own new terms or language to describe the possible features of smart contracts. /thomas/ ___________________________________ On Aug 27, 2016, at 11:48 PM, John Wunderlich <john(a)wunderlich.ca<mailto:john@wunderlich.ca>> wrote: https://theconversation.com/blockchain-really-only-does-one-thing-well-62668 Thanks, John 4giv spellin errurz from mobile devize This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ DG-BSC mailing list DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ DG-BSC mailing list DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc

5 5

FYI
by John Wunderlich 28 Aug '16

28 Aug '16

https://theconversation.com/blockchain-really-only-does-one-thing-well-62668 Thanks, John 4giv spellin errurz from mobile devize -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

2 2

Re: [DG-BSC] Ann Vroom Followup toBSC telecon Thursday August 25 2016
by M AV 26 Aug '16

26 Aug '16

Hi – in reference to this afternoon’s conf call, here’s my super-simplified version of the flow I described: [cid:image001.jpg@01D1FEE9.F8D02280]

2 5

Re: [DG-BSC] Ann Vroom Followup toBSC telecon Thursday August 25 2016
by James Hazard 26 Aug '16

26 Aug '16

I'm happy to do another flow. I believe all flows can be accommodated, and the system must be extensible to accommodate all flows (or you never get harmony). This one reflects what I understand to be a common flow in some kinds of research. The researcher collects the information and makes known to other researchers. It is, I understand, common to give ResearcherA general authority to respond to requests by other Researchers (within the scope). The flow demo-ed gives Alice a direct role. This kind of flow is common (and should be much more common) in other settings, such as NDAs or use of credentials. Should I do a second flow? On Fri, Aug 26, 2016 at 8:33 AM, John Moehrke <johnmoehrke(a)gmail.com> wrote: > I don't think this flow is realistic. he second researcher (B) would not > likely be added to the existing consent, but rather build a new consent. > > An alternative flow : > > 1. Alice publishing her 'preferences' first, likely advertising > specific health attributes to help researchers select. (blockchain > publication, likely using Pseudonym) > 2. The researcher discovering Alice, and determines preferences meet > the research terms. (possibly using smart-contracts) > 3. The researcher approaches Alice with the offer. (blockchain > messaging) > 4. Note at this point, as JohnW diagram shows, there is usually some > form of 'negotiation'. This might be simply Alice making selections (web > form), or might be an interactive session using technology (Oauth/UMA), > human interaction, or smart-contracts. This negotiation phase is to > optimize the terms of the consent (possibly through smart-contract). > 5. The terms of the interaction are fixed (likely published on > blockchain) - possibly in smart-contract) > 6. The researcher accesses the data (with authorization from > blockchain evidence, or other such as UMA) > > > In this flow, what you have diagrammed as a new researcher (B) is really a > new opportunity -- starting at step 2. This would certainly be a new > consent. > > I realize I might be bias, as this is the scenario that I diagrammed on my > blog in May. But I still think it holds up, and would love to see it > developed under kantara > https://healthcaresecprivacy.blogspot.com/2016/05/healthcare- > blockchain-big-data.html > > John > > John Moehrke > Principal Engineering Architect: Standards - Interoperability, Privacy, > and Security > CyberPrivacy – Enabling authorized communications while respecting Privacy > M +1 920-564-2067 > JohnMoehrke(a)gmail.com > https://www.linkedin.com/in/johnmoehrke > https://healthcaresecprivacy.blogspot.com > "Quis custodiet ipsos custodes?" ("Who watches the watchers?") > > On Thu, Aug 25, 2016 at 6:27 PM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > >> Hi, >> >> Here is a first, rough sketch. There are five steps in the transaction. >> It is structured to anticipate additional requests and grants. >> 05-AliceGrants, is the last link in the chain and gives an overview of the >> steps. You could click on it, then on "Document". Note that a few nuances >> have been captured, such as the request being more limited in scope than >> the full data. >> >> The general principle is that each step in a transaction that needs to be >> persisted is documented as a record. The record states particulars and >> references its context, including the prior step. >> >> In a production system, each record can be stored under a friendly name, >> like this, or under a hash. Records can be stored in a file system >> versioned with git, like this, or in a database such as IPFS or a >> blockchain, as needed. >> >> http://www.commonaccord.org/index.php?action=list&file=GH/Ka >> ntaraInitiative/DG-BSC/Consent/Use1/ >> >> >> On Thu, Aug 25, 2016 at 4:14 PM, M AV <av_m(a)hotmail.com> wrote: >> >>> It’s one .jpeg you should be able to cut and paste from the email … >>> >>> >>> >>> *From:* James Hazard [mailto:james.g.hazard@gmail.com] >>> *Sent:* Thursday, August 25, 2016 4:13 PM >>> *To:* M AV <av_m(a)hotmail.com> >>> *Cc:* Eve Maler <eve.maler(a)forgerock.com>; dg-bsc(a)kantarainitiative.org >>> *Subject:* Re: [DG-BSC] Ann Vroom Followup toBSC telecon Thursday >>> August 25 2016 >>> >>> >>> >>> Excellent! I'll do a minimal sketch of this flow. >>> >>> >>> >>> On Thu, Aug 25, 2016 at 4:02 PM, M AV <av_m(a)hotmail.com> wrote: >>> >>> Hi – in reference to this afternoon’s conf call, here’s my >>> super-simplified version of the flow I described: >>> >>> >>> _______________________________________________ >>> DG-BSC mailing list >>> DG-BSC(a)kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>> >>> >>> >>> >>> >>> -- >>> >>> @commonaccord >>> >> >> >> >> -- >> @commonaccord >> >> _______________________________________________ >> DG-BSC mailing list >> DG-BSC(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/dg-bsc >> >> > -- @commonaccord

1 0

Re: [DG-BSC] Layers - templates, smart contracts, blockchains
by James Hazard 23 Aug '16

23 Aug '16

Hi John, Agreed. The current workflows of consent handling can be respected while also getting the benefits of templating, standards formation and machine readability. Regarding "smart contracts," it may be helpful to think of them as independent of the database (blockchain). In this view, "smart contracts" are functions executed in code. They can schedule an access, transfer a ledger entry, provide a notice mechanism, etc. The code needs to be abstracted from any particular computer language (Thomas's Smart Contract Definition Language) and from any particular database. In some instances, it will make sense to use a blockchain as the database and execution platform, but in most, a more conventional database will be appropriate. For uses where confidentiality or ability to delete information is important, a blockchain will be inappropriate. In any event, the "smart contracts" must be independent of the form of database because a person (including and institution) must be able to have a database representation of all of their interactions. Best, Jim On Tue, Aug 23, 2016 at 1:05 PM, John Moehrke <johnmoehrke(a)gmail.com> wrote: > James, > > In healthcare this is current best-practice, when a consent needs to be > known by multiple parties. Most consents only need to be known by the > data-holder to enable them to release data that the consent authorizes. > When multiple parties need to know, we use a system like you have > described. The dominant form of this comes from a profiling organization -- > Integrating the Healthcare Enterprise (IHE) -- a very similar organization > to Kantara for the healthcare domain. This is profiled in "Basic Patient > Privacy Consents (BPPC)". > > There is also the work of Kantara on Consent Receipts.... > > This kind of evidence could be defined in pseudonym space and of YES/NO > basis, thus reasonable to put on blockchain. If done, the smart-contract > could be simple enough. This is the essence of a blog article I posted in > May. > https://healthcaresecprivacy.blogspot.com/2016/05/ > healthcare-blockchain-big-data.html > > > This supports consents without exceptions or conditions or obligations. > Which covers some space. Healthcare is moving to the next step, being able > to encode some of the rules (vectors) that are commonly needed by Patients. > Again within IHE there is an effort focused on a Document Sharing system, > also from IHE. This is profiled as "Advance Patient Privacy Consent" > (APPC), which is a profile of XACML policy-set. It leverages BPPC to manage > the documentation, just using XACML for the exceptions to the base policy. > > SImilar is being done in HL7 FHIR in a RESTful resource -- Consent > Resource. .... > > somewhat related is the work of HEART. -- rather than focus on capturing > consent rules in standardized documentation, they focus on standardizing > access control decisions using UMA..... > > I am working on a series of blog articles to explain this. Just published > yesterday a top-level view > https://healthcaresecprivacy.blogspot.com/2016/08/controlling-big- > data-feeding-frenzy.html > > when the rules get more complex, I think the system must use a more > comprehensive access control system, smart-contracts will not be > sufficient. It is possible that the smart-contract could leverage a access > control service using one of the above. But question as to why it would be > helpful to put a smart-contract onto blockchain that does nothing but > return the results of service call... Hence why I am not convinced that > the authorization to access healthcare data should be implemented in > smart-contract. This doesn't diminish the discussion, it is just my current > perspective. > > John > > > John Moehrke > Principal Engineering Architect: Standards - Interoperability, Privacy, > and Security > CyberPrivacy – Enabling authorized communications while respecting Privacy > M +1 920-564-2067 > JohnMoehrke(a)gmail.com > https://www.linkedin.com/in/johnmoehrke > https://healthcaresecprivacy.blogspot.com > "Quis custodiet ipsos custodes?" ("Who watches the watchers?") > > On Tue, Aug 23, 2016 at 11:12 AM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > >> Very good call today. I was very interested in the discussion of >> templated consents. This seems very productive. If the consents are >> authored from templates and have GUIDs, then they can be made machine >> readable even if all the machine can read is the GUID (for instance in >> scanned PDFs, which I'm told are common). The GUID also provides a basis >> for notifications and permissions. >> >> Here is a bit of old work that I did (Primavera did the diagrams) for the >> Global Alliance for Genomics and Health. >> http://www.commonaccord.org/index.php?action=list&file=Wx/or >> g/genomicsandhealth/REWG/Demo/ The complexity of the example reflects >> (some of) the complexity of the relationships. >> >> >> >> >> >> -- >> @commonaccord >> >> _______________________________________________ >> DG-BSC mailing list >> DG-BSC(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/dg-bsc >> >> > -- @commonaccord

1 0

Layers - templates, smart contracts, blockchains
by James Hazard 23 Aug '16

23 Aug '16

Very good call today. I was very interested in the discussion of templated consents. This seems very productive. If the consents are authored from templates and have GUIDs, then they can be made machine readable even if all the machine can read is the GUID (for instance in scanned PDFs, which I'm told are common). The GUID also provides a basis for notifications and permissions. Here is a bit of old work that I did (Primavera did the diagrams) for the Global Alliance for Genomics and Health. http://www.commonaccord.org/index.php?action=list&file=Wx/org/genomicsandhe… The complexity of the example reflects (some of) the complexity of the relationships. -- @commonaccord

2 1

Re: [DG-BSC] WEF Report
by Koen Vingerhoets 22 Aug '16

22 Aug '16

Hi Luk, How would vendors be able to mix that? (I don’t understand your remark). There is no need to disclose an identity, we’re simply building one. If 3 banks and a telco accept and validate your “proof of address” and “approve” the hash of that document on the ledger, it’s up to you to use it for a 4th bank. But if you do, your KYC should go faster (de lege ferenda – at the moment it’ll merely indicate you already used the document). As we’re doing KYC anyway, returning the result to the user just seems to be the best thing to do. Keeping identity secured is interesting from a personal point of view, for the collective it’s way more interesting to know who is where. But that seems to be an entirely different discussion. Best regards, Koen Van: Luk Vervenne [mailto:luk.vervenne@synergetics.be] Verzonden: vrijdag 19 augustus 2016 0:20 Aan: Koen Vingerhoets <koen.vingerhoets(a)telenet.be> CC: James Hazard <james.g.hazard(a)gmail.com>; Luk Vervenne <luk.vervenne(a)synergetics.be>; dg-bsc(a)kantarainitiative.org Onderwerp: Re: [DG-BSC] WEF Report Hmm, that would allow vendors to mix identification, authenticaiton and authorization. I would be favour to cleanly separate those three elements. In fact I would like individuals be known - after identification - through "pairwise persistent pseudonyms”. By default. Identity disclosure is a prerogative of the user. So it can’t be google/facebook either. Federated networks of IdM providers (Martins suggestion) is focused but also limited in what it does. Luk On 19 Aug 2016, at 00:00, Koen Vingerhoets <koen.vingerhoets(a)telenet.be <mailto:koen.vingerhoets@telenet.be> > wrote: Hi, I’m working on a blockchain use case where banks use the KYC procedure to construct an identity fort heir customer. Based on (re)validation of hashes of re(used) documents, banks can confirm an identity. By extending to telco (and other utilities), the “digital identity” gains extra value. Basically a <http://onename.com/> onename.com with banks/large corporates validating instead of github, twitter, facebook. Banks are no hosts – what benefit would that bring in the short or medium term? They’re investing a lot to ensure they can still add value in a peer 2 peer (or human 2 human) world. Best regards, KOen Van: <mailto:dg-bsc-bounces@kantarainitiative.org> dg-bsc-bounces(a)kantarainitiative.org [ <mailto:dg-bsc-bounces@kantarainitiative.org> mailto:dg-bsc-bounces@kantarainitiative.org] Namens James Hazard Verzonden: donderdag 18 augustus 2016 15:48 Aan: Luk Vervenne < <mailto:luk.vervenne@synergetics.be> luk.vervenne(a)synergetics.be> CC: <mailto:dg-bsc@kantarainitiative.org> dg-bsc(a)kantarainitiative.org Onderwerp: Re: [DG-BSC] WEF Report Thanks Luk. I would think that real P2P would not have central governance (not even central "mining"). It would be polycentric. Anyone or any group could fork their own and cooperate or interoperate as they found convenient. Of course there are very strong reasons to interoperate, and standards are important (e.g., our discussion on a Kantara thread). Regarding decentralized law (document templates) we think that participants will want local, national, industry and global standards processes, under distinct, "local", even competing managements. Hence a "Center for Decentralized Law." On Thu, Aug 18, 2016 at 9:05 AM, Luk Vervenne < <mailto:luk.vervenne@synergetics.be> luk.vervenne(a)synergetics.be> wrote: OK James. But there is a difference between who’s is running the federated IdM, and who is governing it. A data center, Telco’s or even a bank might actually do it, but an independent "separation of concern” governance should manage it. If we really want to make the individual a genuine stakeholder… it starts there and then. By ethically industrialising personal data management (which is more than IdM, we need to end this fight for personal data, by setting up a new digital utility as the very basis from which individuals can become genuine stakeholders. To name one ...Local Gov. should take up its (partial) responsibility. Luk On 18 Aug 2016, at 14:46, James Hazard < <mailto:james.g.hazard@gmail.com> james.g.hazard(a)gmail.com> wrote: This is an interesting discussion. I have no dog in this fight, and am not trying to take sides. I notice, however, that telcos are i) more digital, ii) in more direct contact with the customer via mobile phones iii) more agile iv) bigger (in subscriber bases). In addition to the advantages of banks mentioned in the report, banks are more numerous and many are more local than telcos. They might pose less of monopoly threat and perhaps less monoculture threat. In this view, telcos are natural conduits for a P2P solution and banks are natural hosts. This of course does not make banks the exclusive hosts, not even for a single individual. In a P2P solution, individuals can host-their-own or host with an alternative supplier, and there is a very low barrier to switching. On Thu, Aug 18, 2016 at 8:14 AM, Luk Vervenne < <mailto:luk.vervenne@synergetics.be> luk.vervenne(a)synergetics.be> wrote: Adding to Martin’s, here’s another one : Even in an digital world, most of the economic value of an individual is spend ...local. So federated IdM - and in fact the Digital Utility supporting Personal Data Ecosystems - need to be locally based in a Europe of Regions. Luk On 18 Aug 2016, at 14:04, Martin Kuppinger < <mailto:mk@kuppingercole.com> mk(a)kuppingercole.com> wrote: Hi, yes, unfortunately they neither act that way nor are they as trusted for that role as most believe. We did research even a couple of years ago on that and it has been verified repeatedly that Telcos including mobile operators are in a better position. They are trusted. And they have far bigger ecosystems than most banks have. Furthermore, I believe that many people still want to keep identity and their own financials somewhat separate. Otherwise, PayPal might be the best home for identity management: Global, large scale,… At least we finally might see an evolution towards an ecosystem of trusted identity providers with sufficient interoperability, particularly for the interactions and transactions that really need trust. Most governments failed in providing such infrastructure. Others, including many startups, tried to fill that gap – and commonly failed. Now, others (and I bet more on telcos than the finance industry), based on new technical options, might succeed. Regards, Martin Von: <mailto:dg-bsc-bounces@kantarainitiative.org> dg-bsc-bounces(a)kantarainitiative.org [ <mailto:dg-bsc-bounces@kantarainitiative.org> mailto:dg-bsc-bounces@kantarainitiative.org] Im Auftrag von James Hazard Gesendet: Donnerstag, 18. August 2016 13:58 An: John Wunderlich < <mailto:john@wunderlich.ca> john(a)wunderlich.ca> Cc: <mailto:dg-bsc@kantarainitiative.org> dg-bsc(a)kantarainitiative.org Betreff: Re: [DG-BSC] WEF Report This report of the World Economic Forum, done by Deloitte, has a consistent thesis - that banks (financial institutions) are the natural home for identity management. It makes the point in great depth. <http://www3.weforum.org/docs/WEF_A_Blueprint_for_Digital_Identity.pdf> http://www3.weforum.org/docs/WEF_A_Blueprint_for_Digital_Identity.pdf On Wed, Aug 17, 2016 at 5:02 PM, James Hazard < <mailto:james.g.hazard@gmail.com> james.g.hazard(a)gmail.com> wrote: A couple of thoughts: These "blockchain" analyses tend to minimize the role of related technologies, such as identity management and access control, and of knock-on effects resulting from, for instance, harmonization of the record format, of the functions and of the legal text. If we recontextualize "blockchain," it is busting down the proprietary door to banking and finance software, and all the other technologies can follow. "Financial technology" becomes simply "technology," technology that is open source. Borrowing from the Barclays' smart templates vocabulary and Thomas's use case, the layers seem to be: 1. Records, which can be: 1.1. parameters (transaction particulars and paradigms) 1.2. prose (framing - legal, descriptive and other human-readable text) 1.3. code (functions - "smart contracts" - text that computers like to read) 2. synchronization of records 3. execution of code 4. management of collections of records (notably access control) 5. validation of the veracity of collections of records. "Blockchains," in the technical sense provide advantages primarily in layer 5, but "blockchains" in the movement sense highlight the advantages of using common approaches to the other layers. Blockchains in the technical sense are suboptimal (or even unusable) in some of the other layers, notably in management of records. It is hard to see how blockchains can be reconciled with, for instance, the privacy requirements of the GDPR. <http://kantarainitiative.org/confluence/display/BSC/Privacy-Preserving+Data…> http://kantarainitiative.org/confluence/display/BSC/Privacy-Preserving+Data… Banking is a particularly important use case, that we might wish to consider. The EU Payment Services Directive mandates banking APIs. Banks are, I am told, extremely concerned about data security and fraud, as well as worried about the competitive effects. To demonstrate a vision of "open sourced" financial services in a format that is compatible with blockchains but not dependent on them, I improved on a "bank chain" demo I did in France. This demo is very dense - (not the first time that that can be said of my work) - but it shows a flow of drafting, signature and validation of a payment instrument (check), and has stubs for specifying consequences that need to be implemented in code (a kind of loose-text SCDL - smart contract definition language). This is neither legal nor coding advice, and is certainly wrong in all particulars, but it may help convey the general idea - that open source (blockchain in context) can permit the financial sector and its customers (most of us) to be treated as a decentralized file system, nodes in a "graph." <http://www.commonaccord.org/index.php?action=doc&file=bqc/fr/bnpp/a5we/Acco…> http://www.commonaccord.org/index.php?action=doc&file=bqc/fr/bnpp/a5we/Acco… On Wed, Aug 17, 2016 at 4:14 PM, John Wunderlich < <mailto:john@wunderlich.ca> john(a)wunderlich.ca> wrote: If I were to pick at that nit, I would suggest "mistrust somewhere in the chain of transactions" Thanks, John 4giv spellin errurz from mobile devize _____________________________ From: j stollman < <mailto:stollman.j@gmail.com> stollman.j(a)gmail.com> Sent: Wednesday, August 17, 2016 12:30 PM Subject: Re: [DG-BSC] WEF Report To: John Wunderlich < <mailto:john@wunderlich.ca> john(a)wunderlich.ca> Cc: Thomas Hardjono < <mailto:hardjono@mit.edu> hardjono(a)mit.edu>, < <mailto:dg-bsc@kantarainitiative.org> dg-bsc(a)kantarainitiative.org> John, This list provides some valuable insight. The only thing I would change is the Item 3: Minimal Trust. My correction is nitpicky, but I would change "mistrust between entities: to "mistrust among entities." Often the two parties transacting trust each other. The trust breakdown is further up or down the transaction chain. "Among" captures this more accurately than "between." Jeff --------------------------------- Jeff Stollman <mailto:stollman.j@gmail.com> stollman.j(a)gmail.com <tel:%2B1%20202.683.8699> +1 202.683.8699 Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Wed, Aug 17, 2016 at 6:27 AM, John Wunderlich < <mailto:john@wunderlich.ca> john(a)wunderlich.ca> wrote: Here's the page that leapt out at me - characteristics of high potential use cases <image001.jpg> John Wunderlich, Sent frum a mobile device, Pleez 4give speling erurz "...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin On Wed, Aug 17, 2016 at 5:13 AM -0400, "Thomas Hardjono" < <mailto:hardjono@mit.edu> hardjono(a)mit.edu> wrote: This might help us in some of our use cases: <http://www3.weforum.org/docs/WEF_The_future_of_financial_infrastructure.pdf> http://www3.weforum.org/docs/WEF_The_future_of_financial_infrastructure.pdf… mailing list <mailto:DG-BSC@kantarainitiative.org> DG-BSC(a)kantarainitiative.org <http://kantarainitiative.org/mailman/listinfo/dg-bsc> http://kantarainitiative.org/mailman/listinfo/dg-bsc This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ DG-BSC mailing list <mailto:DG-BSC@kantarainitiative.org> DG-BSC(a)kantarainitiative.org <http://kantarainitiative.org/mailman/listinfo/dg-bsc> http://kantarainitiative.org/mailman/listinfo/dg-bsc This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ DG-BSC mailing list <mailto:DG-BSC@kantarainitiative.org> DG-BSC(a)kantarainitiative.org <http://kantarainitiative.org/mailman/listinfo/dg-bsc> http://kantarainitiative.org/mailman/listinfo/dg-bsc -- @commonaccord -- @commonaccord _______________________________________________ DG-BSC mailing list <mailto:DG-BSC@kantarainitiative.org> DG-BSC(a)kantarainitiative.org <http://kantarainitiative.org/mailman/listinfo/dg-bsc> http://kantarainitiative.org/mailman/listinfo/dg-bsc -- @commonaccord -- @commonaccord

2 3

Re: [DG-BSC] WEF Report
by James Hazard 18 Aug '16

18 Aug '16

Thanks Luk. I would think that real P2P would not have central governance (not even central "mining"). It would be polycentric. Anyone or any group could fork their own and cooperate or interoperate as they found convenient. Of course there are very strong reasons to interoperate, and standards are important (e.g., our discussion on a Kantara thread). Regarding decentralized law (document templates) we think that participants will want local, national, industry and global standards processes, under distinct, "local", even competing managements. Hence a "Center for Decentralized Law." On Thu, Aug 18, 2016 at 9:05 AM, Luk Vervenne <luk.vervenne(a)synergetics.be> wrote: > OK James. > But there is a difference between who’s is running the federated IdM, and > who is governing it. > A data center, Telco’s or even a bank might actually do it, but an > independent "separation of concern” governance should manage it. > > If we* really* want to make the individual a genuine stakeholder… it > starts there and then. > By *ethically industrialising personal data management* (which is more > than IdM, we need to end this *fight for personal data,* by setting up a *new > digital utility* as the very basis from which individuals can become > genuine stakeholders. > To name one ...Local Gov. should take up its (partial) responsibility. > > Luk > > On 18 Aug 2016, at 14:46, James Hazard <james.g.hazard(a)gmail.com> wrote: > > This is an interesting discussion. > > I have no dog in this fight, and am not trying to take sides. I notice, > however, that telcos are i) more digital, ii) in more direct contact with > the customer via mobile phones iii) more agile iv) bigger (in subscriber > bases). > > In addition to the advantages of banks mentioned in the report, banks are > more numerous and many are more local than telcos. They might pose less of > monopoly threat and perhaps less monoculture threat. > > In this view, telcos are natural conduits for a P2P solution and banks are > natural hosts. This of course does not make banks the exclusive hosts, not > even for a single individual. In a P2P solution, individuals can > host-their-own or host with an alternative supplier, and there is a very > low barrier to switching. > > > > > On Thu, Aug 18, 2016 at 8:14 AM, Luk Vervenne <luk.vervenne(a)synergetics.be > > wrote: > >> Adding to Martin’s, here’s another one : >> >> Even in an digital world, most of the economic value of an individual is >> spend ...local. >> So federated IdM - and in fact the Digital Utility supporting Personal >> Data Ecosystems - need to be locally based in a Europe of Regions. >> >> Luk >> >> >> On 18 Aug 2016, at 14:04, Martin Kuppinger <mk(a)kuppingercole.com> wrote: >> >> Hi, >> >> yes, unfortunately they neither act that way nor are they as trusted for >> that role as most believe. >> We did research even a couple of years ago on that and it has been >> verified repeatedly that Telcos including mobile operators are in a better >> position. They are trusted. And they have far bigger ecosystems than most >> banks have. Furthermore, I believe that many people still want to keep >> identity and their own financials somewhat separate. Otherwise, PayPal >> might be the best home for identity management: Global, large scale,… >> At least we finally might see an evolution towards an ecosystem of >> trusted identity providers with sufficient interoperability, particularly >> for the interactions and transactions that really need trust. Most >> governments failed in providing such infrastructure. Others, including many >> startups, tried to fill that gap – and commonly failed. Now, others (and I >> bet more on telcos than the finance industry), based on new technical >> options, might succeed. >> >> Regards, >> Martin >> >> *Von:* dg-bsc-bounces(a)kantarainitiative.org [mailto:dg-bsc- >> bounces(a)kantarainitiative.org <dg-bsc-bounces(a)kantarainitiative.org>] *Im >> Auftrag von *James Hazard >> *Gesendet:* Donnerstag, 18. August 2016 13:58 >> *An:* John Wunderlich <john(a)wunderlich.ca> >> *Cc:* dg-bsc(a)kantarainitiative.org >> *Betreff:* Re: [DG-BSC] WEF Report >> >> This report of the World Economic Forum, done by Deloitte, has a >> consistent thesis - that banks (financial institutions) are the natural >> home for identity management. It makes the point in great depth. >> >> http://www3.weforum.org/docs/WEF_A_Blueprint_for_Digital_Identity.pdf >> >> On Wed, Aug 17, 2016 at 5:02 PM, James Hazard <james.g.hazard(a)gmail.com> >> wrote: >> >> A couple of thoughts: >> >> These "blockchain" analyses tend to minimize the role of related >> technologies, such as identity management and access control, and of >> knock-on effects resulting from, for instance, harmonization of the record >> format, of the functions and of the legal text. If we recontextualize >> "blockchain," it is busting down the proprietary door to banking and >> finance software, and all the other technologies can follow. "Financial >> technology" becomes simply "technology," technology that is open source. >> >> Borrowing from the Barclays' smart templates vocabulary and Thomas's use >> case, the layers seem to be: >> >> 1. Records, which can be: >> 1.1. parameters (transaction particulars and paradigms) >> 1.2. prose (framing - legal, descriptive and other human-readable text) >> 1.3. code (functions - "smart contracts" - text that computers like to >> read) >> 2. synchronization of records >> 3. execution of code >> 4. management of collections of records (notably access control) >> 5. validation of the veracity of collections of records. >> >> >> "Blockchains," in the technical sense provide advantages primarily in >> layer 5, but "blockchains" in the movement sense highlight the advantages >> of using common approaches to the other layers. Blockchains in the >> technical sense are suboptimal (or even unusable) in some of the other >> layers, notably in management of records. It is hard to see how >> blockchains can be reconciled with, for instance, the privacy requirements >> of the GDPR. >> >> http://kantarainitiative.org/confluence/display/BSC/Privacy- >> Preserving+Data+Sharing >> >> Banking is a particularly important use case, that we might wish to >> consider. The EU Payment Services Directive mandates banking APIs. Banks >> are, I am told, extremely concerned about data security and fraud, as well >> as worried about the competitive effects. >> >> To demonstrate a vision of "open sourced" financial services in a format >> that is compatible with blockchains but not dependent on them, I improved >> on a "bank chain" demo I did in France. This demo is very dense - (not the >> first time that that can be said of my work) - but it shows a flow of >> drafting, signature and validation of a payment instrument (check), and has >> stubs for specifying consequences that need to be implemented in code (a >> kind of loose-text SCDL - smart contract definition language). >> >> This is neither legal nor coding advice, and is certainly wrong in all >> particulars, but it may help convey the general idea - that open source >> (blockchain in context) can permit the financial sector and its customers >> (most of us) to be treated as a decentralized file system, nodes in a >> "graph." >> >> >> http://www.commonaccord.org/index.php?action=doc&file=bqc/fr >> /bnpp/a5we/Account/Check/00001/06-Accept.md >> >> >> >> On Wed, Aug 17, 2016 at 4:14 PM, John Wunderlich <john(a)wunderlich.ca> >> wrote: >> >> If I were to pick at that nit, I would suggest "mistrust somewhere in the >> chain of transactions" >> Thanks, John >> 4giv spellin errurz from mobile devize >> >> >> _____________________________ >> From: j stollman <stollman.j(a)gmail.com> >> Sent: Wednesday, August 17, 2016 12:30 PM >> Subject: Re: [DG-BSC] WEF Report >> To: John Wunderlich <john(a)wunderlich.ca> >> Cc: Thomas Hardjono <hardjono(a)mit.edu>, <dg-bsc(a)kantarainitiative.org> >> >> John, >> >> This list provides some valuable insight. >> >> The only thing I would change is the Item 3: Minimal Trust. My >> correction is nitpicky, but I would change "mistrust *between* entities: >> to "mistrust *among* entities." Often the two parties transacting trust >> each other. The trust breakdown is further up or down the transaction >> chain. "Among" captures this more accurately than "between." >> >> Jeff >> >> >> --------------------------------- >> Jeff Stollman >> stollman.j(a)gmail.com >> >> +1 202.683.8699 >> >> Truth never triumphs — its opponents just die out. >> Science advances one funeral at a time. >> Max Planck >> >> On Wed, Aug 17, 2016 at 6:27 AM, John Wunderlich <john(a)wunderlich.ca> >> wrote: >> >> Here's the page that leapt out at me - characteristics of high potential >> use cases >> <image001.jpg> >> John Wunderlich, >> >> Sent frum a mobile device, >> Pleez 4give speling erurz >> >> "...a world of near-total surveillance and endless record-keeping is >> likely to be one with less liberty, less experimentation, and certainly far >> less joy..." A. Michael Froomkin >> >> >> >> >> On Wed, Aug 17, 2016 at 5:13 AM -0400, "Thomas Hardjono" < >> hardjono(a)mit.edu> wrote: >> >> This might help us in some of our use cases:http://www3.weforum.org/docs/WEF_The_future_of_financial_infrastructu… mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc >> >> >> >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they are >> addressed. If you have received this email in error please notify the >> system manager. This message contains confidential information and is >> intended only for the individual named. If you are not the named addressee >> you should not disseminate, distribute or copy this e-mail. Please notify >> the sender immediately by e-mail if you have received this e-mail by >> mistake and delete this e-mail from your system. If you are not the >> intended recipient you are notified that disclosing, copying, distributing >> or taking any action in reliance on the contents of this information is >> strictly prohibited. >> >> >> _______________________________________________ >> DG-BSC mailing list >> DG-BSC(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/dg-bsc >> >> >> >> >> >> >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they are >> addressed. If you have received this email in error please notify the >> system manager. This message contains confidential information and is >> intended only for the individual named. If you are not the named addressee >> you should not disseminate, distribute or copy this e-mail. Please notify >> the sender immediately by e-mail if you have received this e-mail by >> mistake and delete this e-mail from your system. If you are not the >> intended recipient you are notified that disclosing, copying, distributing >> or taking any action in reliance on the contents of this information is >> strictly prohibited. >> >> >> _______________________________________________ >> DG-BSC mailing list >> DG-BSC(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/dg-bsc >> >> >> >> >> -- >> @commonaccord >> >> >> >> >> -- >> @commonaccord >> _______________________________________________ >> DG-BSC mailing list >> DG-BSC(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/dg-bsc >> >> >> > > > -- > @commonaccord > > > -- @commonaccord

2 1

Agenda for BSC telecon Thursday August 18
by Eve Maler 18 Aug '16

18 Aug '16

http://kantarainitiative.org/confluence/display/BSC/2016-08+%28August+2016%… We meet *Thursdays* for 30 minutes at 11am PT / 2pm ET / 7pm UK / 8pm CET. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options <https://www.turbobridge.com/international.html>, web interface <https://panel.turbobridge.com/webcall/>, more info <https://www.turbobridge.com/join.html>, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar <http://kantarainitiative.org/confluence/display/BSC/Calendar> for our full meeting schedule. Previous meeting minutes are here: July <http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29…> . Agenda: - Blockchain subsection: can we fill in draft text? - Other technology/technique subsections: common approaches? champions? - Approach to mapping use case contents to technology/technique contents? (*Reminder:* Eve regrets for this meeting.) *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits and UnSummits* are coming to <http://summits.forgerock.com/> *London and Paris!*

3 2

WEF Report
by Thomas Hardjono 18 Aug '16

18 Aug '16

This might help us in some of our use cases: http://www3.weforum.org/docs/WEF_The_future_of_financial_infrastructure.pdf /thomas/

6 10

Re: [DG-BSC] WEF Report
by James Hazard 18 Aug '16

18 Aug '16

This is an interesting discussion. I have no dog in this fight, and am not trying to take sides. I notice, however, that telcos are i) more digital, ii) in more direct contact with the customer via mobile phones iii) more agile iv) bigger (in subscriber bases). In addition to the advantages of banks mentioned in the report, banks are more numerous and many are more local than telcos. They might pose less of monopoly threat and perhaps less monoculture threat. In this view, telcos are natural conduits for a P2P solution and banks are natural hosts. This of course does not make banks the exclusive hosts, not even for a single individual. In a P2P solution, individuals can host-their-own or host with an alternative supplier, and there is a very low barrier to switching. On Thu, Aug 18, 2016 at 8:14 AM, Luk Vervenne <luk.vervenne(a)synergetics.be> wrote: > Adding to Martin’s, here’s another one : > > Even in an digital world, most of the economic value of an individual is > spend ...local. > So federated IdM - and in fact the Digital Utility supporting Personal > Data Ecosystems - need to be locally based in a Europe of Regions. > > Luk > > > On 18 Aug 2016, at 14:04, Martin Kuppinger <mk(a)kuppingercole.com> wrote: > > Hi, > > yes, unfortunately they neither act that way nor are they as trusted for > that role as most believe. > We did research even a couple of years ago on that and it has been > verified repeatedly that Telcos including mobile operators are in a better > position. They are trusted. And they have far bigger ecosystems than most > banks have. Furthermore, I believe that many people still want to keep > identity and their own financials somewhat separate. Otherwise, PayPal > might be the best home for identity management: Global, large scale,… > At least we finally might see an evolution towards an ecosystem of trusted > identity providers with sufficient interoperability, particularly for the > interactions and transactions that really need trust. Most governments > failed in providing such infrastructure. Others, including many startups, > tried to fill that gap – and commonly failed. Now, others (and I bet more > on telcos than the finance industry), based on new technical options, might > succeed. > > Regards, > Martin > > *Von:* dg-bsc-bounces(a)kantarainitiative.org [mailto:dg-bsc-bounces@ > kantarainitiative.org <dg-bsc-bounces(a)kantarainitiative.org>] *Im Auftrag > von *James Hazard > *Gesendet:* Donnerstag, 18. August 2016 13:58 > *An:* John Wunderlich <john(a)wunderlich.ca> > *Cc:* dg-bsc(a)kantarainitiative.org > *Betreff:* Re: [DG-BSC] WEF Report > > This report of the World Economic Forum, done by Deloitte, has a > consistent thesis - that banks (financial institutions) are the natural > home for identity management. It makes the point in great depth. > > http://www3.weforum.org/docs/WEF_A_Blueprint_for_Digital_Identity.pdf > > On Wed, Aug 17, 2016 at 5:02 PM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > > A couple of thoughts: > > These "blockchain" analyses tend to minimize the role of related > technologies, such as identity management and access control, and of > knock-on effects resulting from, for instance, harmonization of the record > format, of the functions and of the legal text. If we recontextualize > "blockchain," it is busting down the proprietary door to banking and > finance software, and all the other technologies can follow. "Financial > technology" becomes simply "technology," technology that is open source. > > Borrowing from the Barclays' smart templates vocabulary and Thomas's use > case, the layers seem to be: > > 1. Records, which can be: > 1.1. parameters (transaction particulars and paradigms) > 1.2. prose (framing - legal, descriptive and other human-readable text) > 1.3. code (functions - "smart contracts" - text that computers like to > read) > 2. synchronization of records > 3. execution of code > 4. management of collections of records (notably access control) > 5. validation of the veracity of collections of records. > > > "Blockchains," in the technical sense provide advantages primarily in > layer 5, but "blockchains" in the movement sense highlight the advantages > of using common approaches to the other layers. Blockchains in the > technical sense are suboptimal (or even unusable) in some of the other > layers, notably in management of records. It is hard to see how > blockchains can be reconciled with, for instance, the privacy requirements > of the GDPR. > > http://kantarainitiative.org/confluence/display/BSC/ > Privacy-Preserving+Data+Sharing > > Banking is a particularly important use case, that we might wish to > consider. The EU Payment Services Directive mandates banking APIs. Banks > are, I am told, extremely concerned about data security and fraud, as well > as worried about the competitive effects. > > To demonstrate a vision of "open sourced" financial services in a format > that is compatible with blockchains but not dependent on them, I improved > on a "bank chain" demo I did in France. This demo is very dense - (not the > first time that that can be said of my work) - but it shows a flow of > drafting, signature and validation of a payment instrument (check), and has > stubs for specifying consequences that need to be implemented in code (a > kind of loose-text SCDL - smart contract definition language). > > This is neither legal nor coding advice, and is certainly wrong in all > particulars, but it may help convey the general idea - that open source > (blockchain in context) can permit the financial sector and its customers > (most of us) to be treated as a decentralized file system, nodes in a > "graph." > > > http://www.commonaccord.org/index.php?action=doc&file=bqc/ > fr/bnpp/a5we/Account/Check/00001/06-Accept.md > > > > On Wed, Aug 17, 2016 at 4:14 PM, John Wunderlich <john(a)wunderlich.ca> > wrote: > > If I were to pick at that nit, I would suggest "mistrust somewhere in the > chain of transactions" > Thanks, John > 4giv spellin errurz from mobile devize > > > _____________________________ > From: j stollman <stollman.j(a)gmail.com> > Sent: Wednesday, August 17, 2016 12:30 PM > Subject: Re: [DG-BSC] WEF Report > To: John Wunderlich <john(a)wunderlich.ca> > Cc: Thomas Hardjono <hardjono(a)mit.edu>, <dg-bsc(a)kantarainitiative.org> > > John, > > This list provides some valuable insight. > > The only thing I would change is the Item 3: Minimal Trust. My > correction is nitpicky, but I would change "mistrust *between* entities: > to "mistrust *among* entities." Often the two parties transacting trust > each other. The trust breakdown is further up or down the transaction > chain. "Among" captures this more accurately than "between." > > Jeff > > > --------------------------------- > Jeff Stollman > stollman.j(a)gmail.com > > +1 202.683.8699 > > Truth never triumphs — its opponents just die out. > Science advances one funeral at a time. > Max Planck > > On Wed, Aug 17, 2016 at 6:27 AM, John Wunderlich <john(a)wunderlich.ca> > wrote: > > Here's the page that leapt out at me - characteristics of high potential > use cases > <image001.jpg> > John Wunderlich, > > Sent frum a mobile device, > Pleez 4give speling erurz > > "...a world of near-total surveillance and endless record-keeping is > likely to be one with less liberty, less experimentation, and certainly far > less joy..." A. Michael Froomkin > > > > > On Wed, Aug 17, 2016 at 5:13 AM -0400, "Thomas Hardjono" <hardjono(a)mit.edu> > wrote: > > This might help us in some of our use cases:http://www3.weforum.org/docs/WEF_The_future_of_financial_infrastructu… mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > > > _______________________________________________ > DG-BSC mailing list > DG-BSC(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/dg-bsc > > > > > > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > > > _______________________________________________ > DG-BSC mailing list > DG-BSC(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/dg-bsc > > > > > -- > @commonaccord > > > > > -- > @commonaccord > _______________________________________________ > DG-BSC mailing list > DG-BSC(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/dg-bsc > > > -- @commonaccord

1 0

Notes from BSC telecon Thursday August 16
by Eve Maler 16 Aug '16

16 Aug '16

http://kantarainitiative.org/confluence/display/BSC/2016-08+%28August+2016%… Agenda: - Technology subsection candidate: describing and analyzing "blockchain" (Jeff and Eve) - Vs. "smart contract"? - Use case content mappings to technology content Attending: Eve, John W, Domenico, Scott S, Thomas, Jeff, Scott D (deeply interested in progress in distributed systems that are reliable), Jim, Andrew, John M, Colin Looking at Eve's candidate definition of blockchain: The second bullet: The value is transparency, is not privacy per se. Or secrecy per se? Transparency isn't necessarily inconsistent with privacy. Data controllers need to be transparent. If many of the risks are controlled for by putting all the nodes in the same cloud or the same organizational domain (where "distributed" is defined in a very special way), it's still a blockchain. There's support for the three bullets at least as a starter definition, along with the "SWOT" subbullets beneath them. Jeff believes that the only requirement for it to be a blockchain is a particular encryption mechanism for the ledger, but we didn't reach (ahem) consensus on that. Let's share the writeups on the list and see if we can form a draft subsection shortly, and then leverage the SWOTs and other analyses to build our understanding of how well the use cases can be served by the technologies and techniques. Eve makes an exhortation for use cases not to *assume* use of technologies, but to *test* them for suitability. *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits and UnSummits* are coming to <http://summits.forgerock.com/> *London and Paris!*

2 1

Fwd: Brief writeup on blockchain technology
by Eve Maler 16 Aug '16

16 Aug '16

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits and UnSummits* are coming to <http://summits.forgerock.com/> *London and Paris!* ---------- Forwarded message ---------- From: Eve Maler <eve.maler(a)forgerock.com> Date: Mon, Aug 15, 2016 at 1:06 PM Subject: Brief writeup on blockchain technology To: j stollman <stollman.j(a)gmail.com> Tell me what you think of this... I'm sure you will have many corrections! What I was going for was a high-level value-based pocket explanation that would mean a lot to a lot of different audiences. :-) I only recently stuck the few links in there. ==== Following are the key elements of blockchain technology and their value. Other technologies can be blockchain-like if they have some of these elements, but are not considered true blockchains. - A tamper-evident “ledger” (linear, append-only) data structure - Valuable for recording events that definitely happened - Less valuable for recording any information that is uncertain or required to be deleted (such as personal information for which a “right to be forgotten/right to erasure” has been established) - Autonomous, distributed, and possibly even decentralized (no node has higher privileges) storage nodes - Valuable for architectures where trust in a central authority is difficult or undesirable to establish (although trusted third parties do play a role in some blockchain deployments anyway; see third bullet below) - Less valuable for recording sensitive information because of the increased attack surface (every node has a copy of everything) and resulting increased privacy considerations - Less valuable for recording voluminous information because every node has a copy of everything - Mathematically based (algorithmic) consensus for contents of new ledger entries - Valuable for incentivizing cooperative behaviors among node participants about entry contents (“proof of work” as used in Bitcoin is the most famous) - Less valuable if other parts of the “BLT sandwich” (business-legal-technical) are not well controlled for through IAM, trust frameworks, etc. -- e.g., multiple node participants can collude to game the system -- but then decentralization goals can be compromised thereby Blockchain technology is a platform, not a ready-made application. There are “public blockchains” on which applications can be built; two of the most well-known are Bitcoin and Ethereum. (N.B.: A recent (Jul-Aug 2016) hack and fork <https://en.wikipedia.org/wiki/Ethereum#The_DAO_and_the_blockchain_fork> have left the Ethereum blockchain split into two, Ethereum and Ethereum Classic, showing the extreme volatility of this space. See also the Blockchain Graveyard <https://magoo.github.io/Blockchain-Graveyard/> detailing the many startups that have already died due to hacks.) These can be thought of as being something like “public cloud services” for blockchain. There are also open-source implementations of blockchain that can be deployed internally within an organization; depending on how they’re deployed, they can be thought of us being something like “private cloud” blockchains. There are also many blockchain-related tools, SDKs, and app platforms that ride on top of these base layers, much like other development platforms. *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits and UnSummits* are coming to <http://summits.forgerock.com/> *London and Paris!*

1 0

Agenda for BSC telecon Thursday August 15
by Eve Maler 15 Aug '16

15 Aug '16

http://kantarainitiative.org/confluence/display/BSC/2016-08+%28August+2016%… We meet *Tuesdays* for 30 minutes at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options <https://www.turbobridge.com/international.html>, web interface <https://panel.turbobridge.com/webcall/>, more info <https://www.turbobridge.com/join.html>, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar <http://kantarainitiative.org/confluence/display/BSC/Calendar> for our full meeting schedule. Previous meeting minutes are here: July <http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29…> . Agenda: - Technology subsection candidate: describing and analyzing "blockchain" (Jeff and Eve) - Vs. "smart contract"? - Use case content mappings to technology content *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits and UnSummits* are coming to <http://summits.forgerock.com/> *London and Paris!*

1 0

blockchain solution candidate for study
by j stollman 15 Aug '16

15 Aug '16

I would like to propose that we evaluate voting as a blockchain application possibility. In the same way the blockchain is used in Bitcoin to prevent double spending, it could be used to prevent double voting. There are a few issues which need to be resolved,including: 1. voter registration and credential assignment (at the worst, it could follow the same process used today) 2. supporting voter's recovery of forgotton credentials 3. protecting the re-identification of a voter's identity Jeff --------------------------------- Jeff Stollman stollman.j(a)gmail.com +1 202.683.8699 <stollman.j(a)gmail.com> Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

1 0

Agenda for BSC telecon Thursday August 4
by Eve Maler 11 Aug '16

11 Aug '16

http://kantarainitiative.org/confluence/display/BSC/2016-08+%28August+2016%… We meet *Thursdays* for 30 minutes at 11am PT / 2pm ET / 7pm UK / 8pm CET. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options <https://www.turbobridge.com/international.html>, web interface <https://panel.turbobridge.com/webcall/>, more info <https://www.turbobridge.com/join.html>, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar <http://kantarainitiative.org/confluence/display/BSC/Calendar> for our full meeting schedule. Agenda: - Observation: DG is at the one-month mark - Can we add something like a "technology SWOT analysis" to Alice participates in Bob's Research Study <http://kantarainitiative.org/confluence/display/BSC/Alice+participates+in+B…> as a criterion for approving it as complete? - Plotting and analyzing aspects of blockchain overall, smart contracts, CmA, other related tech – see the report outline <http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockch…> - Do we want to categorize use cases/organize them into a taxonomy? Is this helpful for our report purposes? - What use cases do we want to take up next week? (Scott as chair pro tem on Tuesday) *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits and UnSummits* are coming to <http://summits.forgerock.com/> *Sydney, London, and Paris!*

3 2

Example of scare & snare
by John Wunderlich 09 Aug '16

09 Aug '16

I took a screen shot of this to ensure that you don’t get any drive by links from it, but this is typical of the scare and snare advertising made possible by the relatively abysmal level of security practiced by most health information custodians. Also highlights why auditing, logging and transparency with respect to health data are important issues. Auditing and logging are relatively well understood in IT, but transparency is a new concept - especially for security practitioners. If a public ledger is a transparency tool allowing organizations to prove that they are doing what they say are doing, the question will be how do you provide that transparency will providing appropriate security and privacy safeguards with respect to the underlying personal data/ Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

2 1

From: Ann Vroom RE: of interest, article link re: consent model in UK NHS ...
by M AV 09 Aug '16

09 Aug '16

http://www.theregister.co.uk/2016/08/08/some_benefits_of_digital_health_to_… From: dg-bsc-bounces(a)kantarainitiative.org [mailto:dg-bsc-bounces@kantarainitiative.org] On Behalf Of Scott Shorter Sent: Tuesday, August 9, 2016 9:06 AM To: dg-bsc(a)kantarainitiative.org Subject: [DG-BSC] Agenda for BSC telecon Tuesday August 9 http://kantarainitiative.org/confluence/display/BSC/2016-08+%28August+2016%… We meet Tuesdays for 30 minutes at 10:30am ET. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options<https://www.turbobridge.com/international.html>, web interface<https://panel.turbobridge.com/webcall/>, more info<https://www.turbobridge.com/join.html>, code 4022737) and (today only) http://join.me/findscott for screen sharing. See the DG calendar<http://kantarainitiative.org/confluence/display/BSC/Calendar> for our full meeting schedule. Agenda: · Review Certificate Transparency<http://kantarainitiative.org/confluence/display/BSC/Certificate+Transparency> use case · Discuss potential use cases · Privacy-Preserving Data Sharing on Blockchain P2P Nodes (Thomas) · General Wellness Product (John W) · Others? Thanks! - Scott Scott Shorter - Vice President, Security sshorter(a)kimbleassociates.com<mailto:sshorter@kimbleassociates.com> On Aug 3, 2016, at 10:50 PM, Eve Maler <eve.maler(a)forgerock.com<mailto:eve.maler@forgerock.com>> wrote: http://kantarainitiative.org/confluence/display/BSC/2016-08+%28August+2016%… We meet Thursdays for 30 minutes at 11am PT / 2pm ET / 7pm UK / 8pm CET. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options<https://www.turbobridge.com/international.html>, web interface<https://panel.turbobridge.com/webcall/>, more info<https://www.turbobridge.com/join.html>, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar<http://kantarainitiative.org/confluence/display/BSC/Calendar> for our full meeting schedule. Agenda: * Observation: DG is at the one-month mark * Can we add something like a "technology SWOT analysis" to Alice participates in Bob's Research Study<http://kantarainitiative.org/confluence/display/BSC/Alice+participates+in+B…> as a criterion for approving it as complete? * Plotting and analyzing aspects of blockchain overall, smart contracts, CmA, other related tech – see the report outline<http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockch…> * Do we want to categorize use cases/organize them into a taxonomy? Is this helpful for our report purposes? * What use cases do we want to take up next week? (Scott as chair pro tem on Tuesday) Eve Maler ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl ForgeRock Summits and UnSummits are coming to<http://summits.forgerock.com/> Sydney, London, and Paris! _______________________________________________ DG-BSC mailing list DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc

1 0