Notes from BSC telecon Julyl 14
(Apologies for any confusion; I put incorrect Thursday times in the meeting notes page! All correct now. Sigh. We finally have a process in place, and correct data...) http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+... Thursday July 14 Attending: Eve, Jim, Scott, Thomas, Thorsten, Colin Thanks to Scott we have a new Use Cases <http://kantarainitiative.org/confluence/display/BSC/Use+Cases> page! Eve speaks in favor of having champions and recording stakeholders, where possible. Scott will add. Here's the template <http://kantarainitiative.org/confluence/display/BSC/Use+Case+Template>. Adding web sequence diagrams <https://www.websequencediagrams.com/> is a very nice touch. Thorsten's email about IRM liaison opportunities probably doesn't contain use cases as such, but their work on "IRM in the wild" may bubble up use cases, which we can capture here. Okay, returning to discussing our current use case: Jeff S stated in email the concern that getting proofs that something happened *out of* a blockchain is not going to be as scalable or performant as we might be assuming. For example, we're talking about consent receipts. If an individual argues they didn't consent, and the service operator argues they did, and it's two years later, and it's hard to find that needle in the haystack, what good is a blockchain? Does IPFS help? Certificate transparency (see the RFC and the Chrome implementation) is a model where the CAs publicly attest to the certificate so that you don't have to "trust the CA". Does this help the problem we're discussing, where it's hard to get "recorded truth" out of the ledger? J-LINC Labs uses Stellar <https://www.stellar.org/papers/stellar-consensus-protocol.pdf> as a lightweight consensus protocol. Interledger was also mentioned; Jim has looked at it and likes it. Jim's take is that blockchain is really a notarization service – just validating a record. He believes Bitcoin doesn't need all that strength; you could use a (central) trust provider instead. In most social transacting, you probably don't need all the blockchain infrastructure. On the other hand, it's the best solution for the worst case: It's for the wide ecosystem. It's for the Internet (or disconnected) use cases where there's a lot of loose coupling. Given that blockchain is therefore a social mechanism, and consensus is social, and blockchain seems best suited for "lack of centralized trust" use cases, Eve shares her concern about relying on lightweight consensus mechanisms if they open the way to vulnerabilities of a social/sociological/business sort (vs. a purely technical sort). Let's look at our current candidate use case, and others, with an eye towards the wide ecosystem implications. *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!*
participants (1)
-
Eve Maler