Notes from BSC DG telecon on July 12
http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+... Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W The May 23-24 event at MIT, variously called *Digital Contracts, Identities, and Blockchain* and *Digital Identities, Contracts, and Blockchain*, had some notes as output. Here are relevant links: - Technical and Future Infrastructure track notes <https://docs.google.com/a/forgerock.com/document/d/14KD-KA-XPKKvuSfNx4E5B2ZfLjF2mMVKrg3zMzYNHrg/edit?usp=sharing> - Business track notes <https://docs.google.com/document/d/1fNjd25h_Ne4HUedn-vKkfNP73TKZAG-PM_K7Qf6uLAA/edit?usp=sharing> - Healthcare use cases track notes <https://docs.google.com/document/d/1nGTZHq7Q_51tu46jcivLLlS-1vTKXr9z_JcyntBYvOk/edit?usp=sharing> - IBM Open Blockchain white paper <https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md> - Article <https://medium.com/enspiral-tales/bootstrapping-a-bossless-organisation-in-3-easy-steps-afc653e8f5e6#.wt0y8twwf> on bootstrapping a bosses organization - Screenshot <https://slack-files.com/T02DW4GQE-F1BEJRL2G-7421d194f1> from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) - CommonAccord intro presentation <https://docs.google.com/presentation/d/1LqdDjo41PlXBUj3l84gUVQI4H8GH04mvavHj0OslIVQ/edit?usp=sharing> - CommonAccord site <http://www.commonaccord.org/> - CommonAccord Slack team invitation <https://cmacc-slack-add.herokuapp.com/> For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form <http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/Demo/Roberta_Robinson_US> in CommonAccord. There's capacity for it to be signed. Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec. Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands. *AI:* John to share research consent templates with Jim/the group. On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect. *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!*
On the theme of Patient Consents, I put one of the documents that John suggested into modular format. The organization of the document follows the original, with meaningful names for the various sections based on my hunches. The names for roles are not yet meaningful, just placeholders. Click "Document" http://source.commonaccord.org/index.php?action=source&file=Wx/ca/ocrebonline/Templates/COG-OCREB_Consent/v2015-Jun-29/0.md On Tue, Jul 12, 2016 at 11:23 AM, Eve Maler <eve.maler@forgerock.com> wrote:
http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+...
Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W
The May 23-24 event at MIT, variously called *Digital Contracts, Identities, and Blockchain* and *Digital Identities, Contracts, and Blockchain*, had some notes as output. Here are relevant links:
- Technical and Future Infrastructure track notes <https://docs.google.com/a/forgerock.com/document/d/14KD-KA-XPKKvuSfNx4E5B2ZfLjF2mMVKrg3zMzYNHrg/edit?usp=sharing> - Business track notes <https://docs.google.com/document/d/1fNjd25h_Ne4HUedn-vKkfNP73TKZAG-PM_K7Qf6uLAA/edit?usp=sharing> - Healthcare use cases track notes <https://docs.google.com/document/d/1nGTZHq7Q_51tu46jcivLLlS-1vTKXr9z_JcyntBYvOk/edit?usp=sharing> - IBM Open Blockchain white paper <https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md> - Article <https://medium.com/enspiral-tales/bootstrapping-a-bossless-organisation-in-3-easy-steps-afc653e8f5e6#.wt0y8twwf> on bootstrapping a bosses organization - Screenshot <https://slack-files.com/T02DW4GQE-F1BEJRL2G-7421d194f1> from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) - CommonAccord intro presentation <https://docs.google.com/presentation/d/1LqdDjo41PlXBUj3l84gUVQI4H8GH04mvavHj0OslIVQ/edit?usp=sharing> - CommonAccord site <http://www.commonaccord.org/> - CommonAccord Slack team invitation <https://cmacc-slack-add.herokuapp.com/>
For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form <http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/Demo/Roberta_Robinson_US> in CommonAccord. There's capacity for it to be signed.
Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec.
Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands.
*AI:* John to share research consent templates with Jim/the group.
On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect.
*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@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
-- @commonaccord
I am concerned that there may be an important misunderstanding about the power of blockchain in a large scale deployment with regards to query capability. It is easy to add transactions of all kinds to the blockchain. It is harder to query the blockchain efficiently to get information out. The blockchain does store data, but it is not a database. It does not directly support indexed fields that make queries efficient and scalable. With crypto-currencies such as Bitcoin, all transactions are for anonymous, fungible, virtual assets (e.g., Bitcoins). But once the transactions become explicit, unique, assets (e.g., various identity attributes or consent receipts unique to particular websites or transactions), it becomes necessary to find individual needles in the haystack. And the latency for such searches degrades rapidly as the blockchain grows larger. Because scalability and performance are merely assumed and not explicitly specified in our discussions, I wanted to point out that just because something can be added to a blockchain does not imply that it will be scalable and provide adequate performance. To assume this could lead to a lot of churn. Thank you. Jeff --------------------------------- Jeff Stollman stollman.j@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, Jul 13, 2016 at 6:50 PM, James Hazard <james.g.hazard@gmail.com> wrote:
On the theme of Patient Consents, I put one of the documents that John suggested into modular format. The organization of the document follows the original, with meaningful names for the various sections based on my hunches. The names for roles are not yet meaningful, just placeholders.
Click "Document"
On Tue, Jul 12, 2016 at 11:23 AM, Eve Maler <eve.maler@forgerock.com> wrote:
http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+...
Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W
The May 23-24 event at MIT, variously called *Digital Contracts, Identities, and Blockchain* and *Digital Identities, Contracts, and Blockchain*, had some notes as output. Here are relevant links:
- Technical and Future Infrastructure track notes <https://docs.google.com/a/forgerock.com/document/d/14KD-KA-XPKKvuSfNx4E5B2ZfLjF2mMVKrg3zMzYNHrg/edit?usp=sharing> - Business track notes <https://docs.google.com/document/d/1fNjd25h_Ne4HUedn-vKkfNP73TKZAG-PM_K7Qf6uLAA/edit?usp=sharing> - Healthcare use cases track notes <https://docs.google.com/document/d/1nGTZHq7Q_51tu46jcivLLlS-1vTKXr9z_JcyntBYvOk/edit?usp=sharing> - IBM Open Blockchain white paper <https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md> - Article <https://medium.com/enspiral-tales/bootstrapping-a-bossless-organisation-in-3-easy-steps-afc653e8f5e6#.wt0y8twwf> on bootstrapping a bosses organization - Screenshot <https://slack-files.com/T02DW4GQE-F1BEJRL2G-7421d194f1> from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) - CommonAccord intro presentation <https://docs.google.com/presentation/d/1LqdDjo41PlXBUj3l84gUVQI4H8GH04mvavHj0OslIVQ/edit?usp=sharing> - CommonAccord site <http://www.commonaccord.org/> - CommonAccord Slack team invitation <https://cmacc-slack-add.herokuapp.com/>
For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form <http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/Demo/Roberta_Robinson_US> in CommonAccord. There's capacity for it to be signed.
Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec.
Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands.
*AI:* John to share research consent templates with Jim/the group.
On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect.
*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@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
-- @commonaccord
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
Jeff, Thanks and agreed. I am not the most technical of the people on this list (and seek to be corrected), so here is how it looks: 1. Blockchain is an inappropriate platform for many uses. Blockchains are, as you say, slow, redundant, and not privacy-preserving. Other databases are more appropriate for most transacting. If there is a non-technical basis for trust, which is the case in most interpersonal transacting, then you don't need a blockchain. 2. Git, IPFS, Interledger, Corda (not intended as a complete list, but what has caught my eye) seem well-positioned to provide crypto-based notarization and synchronization of records. 3. Within an organization, records will be stored in conventional databases or modern equivalents such as graph databases. Those records will originate from multiple sources. There needs to be proof that the internal record is the same as the original. Some see a future of IPFS as the canonical format for storage, with operational or analytic work being done in graph databases. 4. Blockchains appear to be a good solution, perhaps the only solution, to the worst case - where there isn't a basis for trust. In the IoT, this worst case will become very widespread - when your thermostat (door clicker or pacemaker) tells the furnace to turn on, the furnace needs to authenticate the thermostat and receive tokens that will allow the furnace to order more fuel. The internet connection might be down and the house working on battery backup, so they need to sort this out themselves. Once telecoms are reestablished, the record of their interaction will want to be integrated into and validated by the homeowner's off-site canonical image of themselves, and then destroyed. 5. This worst-case, blockchain-based scenario must inform the design of the platform, but most social interactions will be done without blockchains. Eager for correction. Jim On Thu, Jul 14, 2016 at 6:27 AM, j stollman <stollman.j@gmail.com> wrote:
I am concerned that there may be an important misunderstanding about the power of blockchain in a large scale deployment with regards to query capability.
It is easy to add transactions of all kinds to the blockchain. It is harder to query the blockchain efficiently to get information out. The blockchain does store data, but it is not a database. It does not directly support indexed fields that make queries efficient and scalable. With crypto-currencies such as Bitcoin, all transactions are for anonymous, fungible, virtual assets (e.g., Bitcoins). But once the transactions become explicit, unique, assets (e.g., various identity attributes or consent receipts unique to particular websites or transactions), it becomes necessary to find individual needles in the haystack. And the latency for such searches degrades rapidly as the blockchain grows larger.
Because scalability and performance are merely assumed and not explicitly specified in our discussions, I wanted to point out that just because something can be added to a blockchain does not imply that it will be scalable and provide adequate performance. To assume this could lead to a lot of churn.
Thank you.
Jeff
--------------------------------- Jeff Stollman stollman.j@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, Jul 13, 2016 at 6:50 PM, James Hazard <james.g.hazard@gmail.com> wrote:
On the theme of Patient Consents, I put one of the documents that John suggested into modular format. The organization of the document follows the original, with meaningful names for the various sections based on my hunches. The names for roles are not yet meaningful, just placeholders.
Click "Document"
On Tue, Jul 12, 2016 at 11:23 AM, Eve Maler <eve.maler@forgerock.com> wrote:
http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+...
Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W
The May 23-24 event at MIT, variously called *Digital Contracts, Identities, and Blockchain* and *Digital Identities, Contracts, and Blockchain*, had some notes as output. Here are relevant links:
- Technical and Future Infrastructure track notes <https://docs.google.com/a/forgerock.com/document/d/14KD-KA-XPKKvuSfNx4E5B2ZfLjF2mMVKrg3zMzYNHrg/edit?usp=sharing> - Business track notes <https://docs.google.com/document/d/1fNjd25h_Ne4HUedn-vKkfNP73TKZAG-PM_K7Qf6uLAA/edit?usp=sharing> - Healthcare use cases track notes <https://docs.google.com/document/d/1nGTZHq7Q_51tu46jcivLLlS-1vTKXr9z_JcyntBYvOk/edit?usp=sharing> - IBM Open Blockchain white paper <https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md> - Article <https://medium.com/enspiral-tales/bootstrapping-a-bossless-organisation-in-3-easy-steps-afc653e8f5e6#.wt0y8twwf> on bootstrapping a bosses organization - Screenshot <https://slack-files.com/T02DW4GQE-F1BEJRL2G-7421d194f1> from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) - CommonAccord intro presentation <https://docs.google.com/presentation/d/1LqdDjo41PlXBUj3l84gUVQI4H8GH04mvavHj0OslIVQ/edit?usp=sharing> - CommonAccord site <http://www.commonaccord.org/> - CommonAccord Slack team invitation <https://cmacc-slack-add.herokuapp.com/>
For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form <http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/Demo/Roberta_Robinson_US> in CommonAccord. There's capacity for it to be signed.
Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec.
Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands.
*AI:* John to share research consent templates with Jim/the group.
On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect.
*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@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
-- @commonaccord
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
-- @commonaccord
Hi James, Native block chains have little in the way of security. Boiled down, they are a set of transaction records bound together by PKI in a chain of trust. The provenance of the actors interacting with the chain depends upon a Proof of Work, which requires significant computational power to do. As with any database, access control is essential for the business use of any block chain, for reasons of compliance and risk management. This normally needs to be federated and high assurance, if it is supporting the sharing of sensitive information across organisations. Block chain requirements for federated high assurance AAA (Authentication, Authorisation and Accountability) are emerging. PKI federation per ISO 29115 is the norm for high assurance federated identity management, signature and encryption - all of these functions are required to support privacy and commercial sensitivities too. The potential exists to leverage PKI federation to support the block chain itself, the access control, privacy, smart contracts, secure payments and more. It could potentially replace the proof of work. It also has the potential to support interoperability across/between compliant block chains. This could be vital to support scalability, as the computing power to support a block chain can grow exponentially as the chain grows. Use cases and products in the financial sector are expanding fast, with many banks indicating that they will enter the market later this year. Some governments are experimenting/piloting too. However, perhaps more interesting, is the number of non-financial block chain initiatives that are starting up in different industry sectors. Your point about IoT and domestic sensors is interesting. Many organisations are hovering around this area, particularly telcos, promising announcements in 2017. Much to discuss, I am sure. As I said to Colin Wallis, do we want to attract some of the telcos and BC start ups into this group and, if so, what is the value prop? My tuppence for the moment. Patrick Patrick Curry Director British Business Federation Authority - BBFA Ltd M: +44 786 024 9074 T: +44 1980 620606 patrick.curry@bbfa.info www.bbfa.info – a not-for-profit, self-regulating body On 14 Jul 2016, at 13:30, James Hazard <james.g.hazard@gmail.com> wrote: Jeff, Thanks and agreed. I am not the most technical of the people on this list (and seek to be corrected), so here is how it looks: 1. Blockchain is an inappropriate platform for many uses. Blockchains are, as you say, slow, redundant, and not privacy-preserving. Other databases are more appropriate for most transacting. If there is a non-technical basis for trust, which is the case in most interpersonal transacting, then you don't need a blockchain. 2. Git, IPFS, Interledger, Corda (not intended as a complete list, but what has caught my eye) seem well-positioned to provide crypto-based notarization and synchronization of records. 3. Within an organization, records will be stored in conventional databases or modern equivalents such as graph databases. Those records will originate from multiple sources. There needs to be proof that the internal record is the same as the original. Some see a future of IPFS as the canonical format for storage, with operational or analytic work being done in graph databases. 4. Blockchains appear to be a good solution, perhaps the only solution, to the worst case - where there isn't a basis for trust. In the IoT, this worst case will become very widespread - when your thermostat (door clicker or pacemaker) tells the furnace to turn on, the furnace needs to authenticate the thermostat and receive tokens that will allow the furnace to order more fuel. The internet connection might be down and the house working on battery backup, so they need to sort this out themselves. Once telecoms are reestablished, the record of their interaction will want to be integrated into and validated by the homeowner's off-site canonical image of themselves, and then destroyed. 5. This worst-case, blockchain-based scenario must inform the design of the platform, but most social interactions will be done without blockchains. Eager for correction. Jim On Thu, Jul 14, 2016 at 6:27 AM, j stollman <stollman.j@gmail.com <mailto:stollman.j@gmail.com>> wrote: I am concerned that there may be an important misunderstanding about the power of blockchain in a large scale deployment with regards to query capability. It is easy to add transactions of all kinds to the blockchain. It is harder to query the blockchain efficiently to get information out. The blockchain does store data, but it is not a database. It does not directly support indexed fields that make queries efficient and scalable. With crypto-currencies such as Bitcoin, all transactions are for anonymous, fungible, virtual assets (e.g., Bitcoins). But once the transactions become explicit, unique, assets (e.g., various identity attributes or consent receipts unique to particular websites or transactions), it becomes necessary to find individual needles in the haystack. And the latency for such searches degrades rapidly as the blockchain grows larger. Because scalability and performance are merely assumed and not explicitly specified in our discussions, I wanted to point out that just because something can be added to a blockchain does not imply that it will be scalable and provide adequate performance. To assume this could lead to a lot of churn. Thank you. Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com <mailto:stollman.j@gmail.com> 1 202.683.8699 <tel:1%20202.683.8699> Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Wed, Jul 13, 2016 at 6:50 PM, James Hazard <james.g.hazard@gmail.com <mailto:james.g.hazard@gmail.com>> wrote: On the theme of Patient Consents, I put one of the documents that John suggested into modular format. The organization of the document follows the original, with meaningful names for the various sections based on my hunches. The names for roles are not yet meaningful, just placeholders. Click "Document" http://source.commonaccord.org/index.php?action=source&file=Wx/ca/ocrebonline/Templates/COG-OCREB_Consent/v2015-Jun-29/0.md <http://source.commonaccord.org/index.php?action=source&file=Wx/ca/ocrebonline/Templates/COG-OCREB_Consent/v2015-Jun-29/0.md> On Tue, Jul 12, 2016 at 11:23 AM, Eve Maler <eve.maler@forgerock.com <mailto:eve.maler@forgerock.com>> wrote: http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+... <http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+Meetings#id-2016-07(July2016)Meetings-TuesdayJuly12> Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W The May 23-24 event at MIT, variously called Digital Contracts, Identities, and Blockchain and Digital Identities, Contracts, and Blockchain, had some notes as output. Here are relevant links: Technical and Future Infrastructure track notes <https://docs.google.com/a/forgerock.com/document/d/14KD-KA-XPKKvuSfNx4E5B2ZfLjF2mMVKrg3zMzYNHrg/edit?usp=sharing> Business track notes <https://docs.google.com/document/d/1fNjd25h_Ne4HUedn-vKkfNP73TKZAG-PM_K7Qf6uLAA/edit?usp=sharing> Healthcare use cases track notes <https://docs.google.com/document/d/1nGTZHq7Q_51tu46jcivLLlS-1vTKXr9z_JcyntBYvOk/edit?usp=sharing> IBM Open Blockchain white paper <https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md> Article <https://medium.com/enspiral-tales/bootstrapping-a-bossless-organisation-in-3-easy-steps-afc653e8f5e6#.wt0y8twwf> on bootstrapping a bosses organization Screenshot <https://slack-files.com/T02DW4GQE-F1BEJRL2G-7421d194f1> from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) CommonAccord intro presentation <https://docs.google.com/presentation/d/1LqdDjo41PlXBUj3l84gUVQI4H8GH04mvavHj0OslIVQ/edit?usp=sharing> CommonAccord site <http://www.commonaccord.org/> CommonAccord Slack team invitation <https://cmacc-slack-add.herokuapp.com/> For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form <http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/Demo/Roberta_Robinson_US> in CommonAccord. There's capacity for it to be signed. Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec. Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands. AI: John to share research consent templates with Jim/the group. On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect. Eve Maler ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 <tel:%2B1%20425.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@kantarainitiative.org <mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc <http://kantarainitiative.org/mailman/listinfo/dg-bsc> -- @commonaccord _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org <mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc <http://kantarainitiative.org/mailman/listinfo/dg-bsc> -- @commonaccord _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
I regret that other commitments have so far prevented me from participating in this group, for which I apologise. I concur with Jeff’s comment and offer 2 more: Block chain 2.0 technologies are emerging that are much more efficient and better optimised for specific use cases. It is putting a lot more tools in the toolbox. So it may be that some of these (particularly those looking to leverage cloud toolkits and modules, such as in AWS) will have the apparently native ability to support search fairly well. However, that is not yet the situation. Many DB companies are looking to provide a relational (or other) database technology over the top of a block chain. The chain provides the distributed ledger technology across partners. The DB maintains an ingested clone (of sorts) of the chain data and provides the necessary search capability. The results can be validated directly on the chain. regards, Patrick Patrick Curry Director British Business Federation Authority - BBFA Ltd M: +44 786 024 9074 T: +44 1980 620606 patrick.curry@bbfa.info www.bbfa.info – a not-for-profit, self-regulating body On 14 Jul 2016, at 12:27, j stollman <stollman.j@gmail.com> wrote: I am concerned that there may be an important misunderstanding about the power of blockchain in a large scale deployment with regards to query capability. It is easy to add transactions of all kinds to the blockchain. It is harder to query the blockchain efficiently to get information out. The blockchain does store data, but it is not a database. It does not directly support indexed fields that make queries efficient and scalable. With crypto-currencies such as Bitcoin, all transactions are for anonymous, fungible, virtual assets (e.g., Bitcoins). But once the transactions become explicit, unique, assets (e.g., various identity attributes or consent receipts unique to particular websites or transactions), it becomes necessary to find individual needles in the haystack. And the latency for such searches degrades rapidly as the blockchain grows larger. Because scalability and performance are merely assumed and not explicitly specified in our discussions, I wanted to point out that just because something can be added to a blockchain does not imply that it will be scalable and provide adequate performance. To assume this could lead to a lot of churn. Thank you. Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com <mailto:stollman.j@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, Jul 13, 2016 at 6:50 PM, James Hazard <james.g.hazard@gmail.com <mailto:james.g.hazard@gmail.com>> wrote: On the theme of Patient Consents, I put one of the documents that John suggested into modular format. The organization of the document follows the original, with meaningful names for the various sections based on my hunches. The names for roles are not yet meaningful, just placeholders. Click "Document" http://source.commonaccord.org/index.php?action=source&file=Wx/ca/ocrebonline/Templates/COG-OCREB_Consent/v2015-Jun-29/0.md <http://source.commonaccord.org/index.php?action=source&file=Wx/ca/ocrebonline/Templates/COG-OCREB_Consent/v2015-Jun-29/0.md> On Tue, Jul 12, 2016 at 11:23 AM, Eve Maler <eve.maler@forgerock.com <mailto:eve.maler@forgerock.com>> wrote: http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+... <http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+Meetings#id-2016-07(July2016)Meetings-TuesdayJuly12> Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W The May 23-24 event at MIT, variously called Digital Contracts, Identities, and Blockchain and Digital Identities, Contracts, and Blockchain, had some notes as output. Here are relevant links: Technical and Future Infrastructure track notes <https://docs.google.com/a/forgerock.com/document/d/14KD-KA-XPKKvuSfNx4E5B2ZfLjF2mMVKrg3zMzYNHrg/edit?usp=sharing> Business track notes <https://docs.google.com/document/d/1fNjd25h_Ne4HUedn-vKkfNP73TKZAG-PM_K7Qf6uLAA/edit?usp=sharing> Healthcare use cases track notes <https://docs.google.com/document/d/1nGTZHq7Q_51tu46jcivLLlS-1vTKXr9z_JcyntBYvOk/edit?usp=sharing> IBM Open Blockchain white paper <https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md> Article <https://medium.com/enspiral-tales/bootstrapping-a-bossless-organisation-in-3-easy-steps-afc653e8f5e6#.wt0y8twwf> on bootstrapping a bosses organization Screenshot <https://slack-files.com/T02DW4GQE-F1BEJRL2G-7421d194f1> from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) CommonAccord intro presentation <https://docs.google.com/presentation/d/1LqdDjo41PlXBUj3l84gUVQI4H8GH04mvavHj0OslIVQ/edit?usp=sharing> CommonAccord site <http://www.commonaccord.org/> CommonAccord Slack team invitation <https://cmacc-slack-add.herokuapp.com/> For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form <http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/Demo/Roberta_Robinson_US> in CommonAccord. There's capacity for it to be signed. Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec. Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands. AI: John to share research consent templates with Jim/the group. On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect. Eve Maler ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 <tel:%2B1%20425.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@kantarainitiative.org <mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc <http://kantarainitiative.org/mailman/listinfo/dg-bsc> -- @commonaccord _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org <mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc <http://kantarainitiative.org/mailman/listinfo/dg-bsc> _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
I agree with Patrick on DB companies and recent initiatives that seek to provide relational or other database technology for block chains. The BigchainDB, for example, is a decentralised and scalable database (see https://www.bigchaindb.com). It addresses some issues highlighted by Jeff such as performance and query efficency. Regards Youakim -------------------------------------------------------- Youakim Badr, Ph.D - Associate Professor LIRIS Lab. / University of Lyon National Institute of Applied Sciences (INSA-Lyon) F-69621 Villeurbanne, FRANCE On 14 Jul 2016, at 13:34, Patrick Curry <patrick.curry@bbfa.info> wrote:
I regret that other commitments have so far prevented me from participating in this group, for which I apologise.
I concur with Jeff’s comment and offer 2 more: Block chain 2.0 technologies are emerging that are much more efficient and better optimised for specific use cases. It is putting a lot more tools in the toolbox. So it may be that some of these (particularly those looking to leverage cloud toolkits and modules, such as in AWS) will have the apparently native ability to support search fairly well. However, that is not yet the situation. Many DB companies are looking to provide a relational (or other) database technology over the top of a block chain. The chain provides the distributed ledger technology across partners. The DB maintains an ingested clone (of sorts) of the chain data and provides the necessary search capability. The results can be validated directly on the chain.
regards,
Patrick
Patrick Curry Director
British Business Federation Authority - BBFA Ltd M: +44 786 024 9074 T: +44 1980 620606 patrick.curry@bbfa.info www.bbfa.info – a not-for-profit, self-regulating body
On 14 Jul 2016, at 12:27, j stollman <stollman.j@gmail.com> wrote:
I am concerned that there may be an important misunderstanding about the power of blockchain in a large scale deployment with regards to query capability.
It is easy to add transactions of all kinds to the blockchain. It is harder to query the blockchain efficiently to get information out. The blockchain does store data, but it is not a database. It does not directly support indexed fields that make queries efficient and scalable. With crypto-currencies such as Bitcoin, all transactions are for anonymous, fungible, virtual assets (e.g., Bitcoins). But once the transactions become explicit, unique, assets (e.g., various identity attributes or consent receipts unique to particular websites or transactions), it becomes necessary to find individual needles in the haystack. And the latency for such searches degrades rapidly as the blockchain grows larger.
Because scalability and performance are merely assumed and not explicitly specified in our discussions, I wanted to point out that just because something can be added to a blockchain does not imply that it will be scalable and provide adequate performance. To assume this could lead to a lot of churn.
Thank you.
Jeff
--------------------------------- Jeff Stollman stollman.j@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, Jul 13, 2016 at 6:50 PM, James Hazard <james.g.hazard@gmail.com> wrote: On the theme of Patient Consents, I put one of the documents that John suggested into modular format. The organization of the document follows the original, with meaningful names for the various sections based on my hunches. The names for roles are not yet meaningful, just placeholders.
Click "Document"
On Tue, Jul 12, 2016 at 11:23 AM, Eve Maler <eve.maler@forgerock.com> wrote: http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+...
Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W
The May 23-24 event at MIT, variously called Digital Contracts, Identities, and Blockchain and Digital Identities, Contracts, and Blockchain, had some notes as output. Here are relevant links:
Technical and Future Infrastructure track notes Business track notes Healthcare use cases track notes IBM Open Blockchain white paper Article on bootstrapping a bosses organization Screenshot from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) CommonAccord intro presentation CommonAccord site CommonAccord Slack team invitation For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form in CommonAccord. There's capacity for it to be signed.
Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec.
Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands.
AI: John to share research consent templates with Jim/the group.
On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect.
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 Sydney, London, and Paris!
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
-- @commonaccord
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
Agreeing. Patrick - I think there is indeed a fit with telcos and BC startups. The fits include: 1. An object model for relationships and transactions (aka legal), expressed in text objects. The privacy/data security perspective is, I think, an essential starting point for many reasons. Those solutions will ripple through the chain of relationships. 2. AAA and smart contracts that shape and are supported by the object model and text. These, too, will ripple through the chain. (Code is law and law can be code.) On Thu, Jul 14, 2016 at 8:30 AM, Youakim Badr <youakim@gmail.com> wrote:
I agree with Patrick on DB companies and recent initiatives that seek to provide relational or other database technology for block chains.
The BigchainDB, for example, is a decentralised and scalable database (see https://www.bigchaindb.com). It addresses some issues highlighted by Jeff such as performance and query efficency.
Regards Youakim
-------------------------------------------------------- Youakim Badr, Ph.D - Associate Professor LIRIS Lab. / University of Lyon National Institute of Applied Sciences (INSA-Lyon) F-69621 Villeurbanne, FRANCE
On 14 Jul 2016, at 13:34, Patrick Curry <patrick.curry@bbfa.info> wrote:
I regret that other commitments have so far prevented me from participating in this group, for which I apologise.
I concur with Jeff’s comment and offer 2 more:
- Block chain 2.0 technologies are emerging that are much more efficient and better optimised for specific use cases. It is putting a lot more tools in the toolbox. So it may be that some of these (particularly those looking to leverage cloud toolkits and modules, such as in AWS) will have the apparently native ability to support search fairly well. - However, that is not yet the situation. Many DB companies are looking to provide a relational (or other) database technology over the top of a block chain. The chain provides the distributed ledger technology across partners. The DB maintains an ingested clone (of sorts) of the chain data and provides the necessary search capability. The results can be validated directly on the chain.
regards,
Patrick
Patrick Curry Director
British Business Federation Authority - BBFA Ltd M: +44 786 024 9074 T: +44 1980 620606 patrick.curry@bbfa.info www.bbfa.info – a not-for-profit, self-regulating body
On 14 Jul 2016, at 12:27, j stollman <stollman.j@gmail.com> wrote:
I am concerned that there may be an important misunderstanding about the power of blockchain in a large scale deployment with regards to query capability.
It is easy to add transactions of all kinds to the blockchain. It is harder to query the blockchain efficiently to get information out. The blockchain does store data, but it is not a database. It does not directly support indexed fields that make queries efficient and scalable. With crypto-currencies such as Bitcoin, all transactions are for anonymous, fungible, virtual assets (e.g., Bitcoins). But once the transactions become explicit, unique, assets (e.g., various identity attributes or consent receipts unique to particular websites or transactions), it becomes necessary to find individual needles in the haystack. And the latency for such searches degrades rapidly as the blockchain grows larger.
Because scalability and performance are merely assumed and not explicitly specified in our discussions, I wanted to point out that just because something can be added to a blockchain does not imply that it will be scalable and provide adequate performance. To assume this could lead to a lot of churn.
Thank you.
Jeff
--------------------------------- Jeff Stollman stollman.j@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, Jul 13, 2016 at 6:50 PM, James Hazard <james.g.hazard@gmail.com> wrote:
On the theme of Patient Consents, I put one of the documents that John suggested into modular format. The organization of the document follows the original, with meaningful names for the various sections based on my hunches. The names for roles are not yet meaningful, just placeholders.
Click "Document"
On Tue, Jul 12, 2016 at 11:23 AM, Eve Maler <eve.maler@forgerock.com> wrote:
http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+...
Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W
The May 23-24 event at MIT, variously called *Digital Contracts, Identities, and Blockchain* and *Digital Identities, Contracts, and Blockchain*, had some notes as output. Here are relevant links:
- Technical and Future Infrastructure track notes <https://docs.google.com/a/forgerock.com/document/d/14KD-KA-XPKKvuSfNx4E5B2ZfLjF2mMVKrg3zMzYNHrg/edit?usp=sharing> - Business track notes <https://docs.google.com/document/d/1fNjd25h_Ne4HUedn-vKkfNP73TKZAG-PM_K7Qf6uLAA/edit?usp=sharing> - Healthcare use cases track notes <https://docs.google.com/document/d/1nGTZHq7Q_51tu46jcivLLlS-1vTKXr9z_JcyntBYvOk/edit?usp=sharing> - IBM Open Blockchain white paper <https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md> - Article <https://medium.com/enspiral-tales/bootstrapping-a-bossless-organisation-in-3-easy-steps-afc653e8f5e6#.wt0y8twwf> on bootstrapping a bosses organization - Screenshot <https://slack-files.com/T02DW4GQE-F1BEJRL2G-7421d194f1> from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) - CommonAccord intro presentation <https://docs.google.com/presentation/d/1LqdDjo41PlXBUj3l84gUVQI4H8GH04mvavHj0OslIVQ/edit?usp=sharing> - CommonAccord site <http://www.commonaccord.org/> - CommonAccord Slack team invitation <https://cmacc-slack-add.herokuapp.com/>
For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form <http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/Demo/Roberta_Robinson_US> in CommonAccord. There's capacity for it to be signed.
Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec.
Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands.
*AI:* John to share research consent templates with Jim/the group.
On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect.
*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@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
-- @commonaccord
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
-- @commonaccord
Jeff, Excellent point, absolutely agree. It's like we're in the mid 1980s, we had the IP protocol but TCP/UDP was still being defined and there was no standard protocol for the dumb VT100 monochrome terminals to talk to the network. Is this a topic of interest of folks here? /thomas/ _________________________________ On Jul 14, 2016, at 06:27, j stollman <stollman.j@gmail.com<mailto:stollman.j@gmail.com>> wrote: I am concerned that there may be an important misunderstanding about the power of blockchain in a large scale deployment with regards to query capability. It is easy to add transactions of all kinds to the blockchain. It is harder to query the blockchain efficiently to get information out. The blockchain does store data, but it is not a database. It does not directly support indexed fields that make queries efficient and scalable. With crypto-currencies such as Bitcoin, all transactions are for anonymous, fungible, virtual assets (e.g., Bitcoins). But once the transactions become explicit, unique, assets (e.g., various identity attributes or consent receipts unique to particular websites or transactions), it becomes necessary to find individual needles in the haystack. And the latency for such searches degrades rapidly as the blockchain grows larger. Because scalability and performance are merely assumed and not explicitly specified in our discussions, I wanted to point out that just because something can be added to a blockchain does not imply that it will be scalable and provide adequate performance. To assume this could lead to a lot of churn. Thank you. Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com<mailto:stollman.j@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, Jul 13, 2016 at 6:50 PM, James Hazard <james.g.hazard@gmail.com<mailto:james.g.hazard@gmail.com>> wrote: On the theme of Patient Consents, I put one of the documents that John suggested into modular format. The organization of the document follows the original, with meaningful names for the various sections based on my hunches. The names for roles are not yet meaningful, just placeholders. Click "Document" http://source.commonaccord.org/index.php?action=source&file=Wx/ca/ocrebonline/Templates/COG-OCREB_Consent/v2015-Jun-29/0.md On Tue, Jul 12, 2016 at 11:23 AM, Eve Maler <eve.maler@forgerock.com<mailto:eve.maler@forgerock.com>> wrote: http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+... Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W The May 23-24 event at MIT, variously called Digital Contracts, Identities, and Blockchain and Digital Identities, Contracts, and Blockchain, had some notes as output. Here are relevant links: * Technical and Future Infrastructure track notes<https://docs.google.com/a/forgerock.com/document/d/14KD-KA-XPKKvuSfNx4E5B2ZfLjF2mMVKrg3zMzYNHrg/edit?usp=sharing> * Business track notes<https://docs.google.com/document/d/1fNjd25h_Ne4HUedn-vKkfNP73TKZAG-PM_K7Qf6uLAA/edit?usp=sharing> * Healthcare use cases track notes<https://docs.google.com/document/d/1nGTZHq7Q_51tu46jcivLLlS-1vTKXr9z_JcyntBYvOk/edit?usp=sharing> * IBM Open Blockchain white paper<https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md> * Article<https://medium.com/enspiral-tales/bootstrapping-a-bossless-organisation-in-3-easy-steps-afc653e8f5e6#.wt0y8twwf> on bootstrapping a bosses organization * Screenshot<https://slack-files.com/T02DW4GQE-F1BEJRL2G-7421d194f1> from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) * CommonAccord intro presentation<https://docs.google.com/presentation/d/1LqdDjo41PlXBUj3l84gUVQI4H8GH04mvavHj0OslIVQ/edit?usp=sharing> * CommonAccord site<http://www.commonaccord.org/> * CommonAccord Slack team invitation<https://cmacc-slack-add.herokuapp.com/> For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form<http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/Demo/Roberta_Robinson_US> in CommonAccord. There's capacity for it to be signed. Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec. Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands. AI: John to share research consent templates with Jim/the group. On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect. Eve Maler ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756<tel:%2B1%20425.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@kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc -- @commonaccord _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc
participants (6)
-
Eve Maler -
j stollman -
James Hazard -
Patrick Curry -
Thomas Hardjono -
Youakim Badr