Thorsten, Regarding your comment: Given the assumption, that a BSC/DLT System for Identities needs to be 'public', it leaves Permissioned or permissionless on the table. Permissionless needs a mechanism to make sure the 'bad guys' do not overrule the good guys, which (currently?) is done by mining mechanism (inefficient). I would suggest that a Permissioned system also "needs a mechanism to make sure the 'bad guys' do not overrule the good guys." Who is doing the permissioning? Can we trust this party to be unbiased. The reason for mining is to avoid handing over control to any single party who may be/become corrupt. Permissioned systems make a lot of sense for private blockchains where the blockchain serves the goals of the party who grants permission, because this party has little incentive to corrupt its own system. But in a public blockchain, what party is sufficiently above suspicion that everyone using the system can trust them? Given the cultural diversity of the world, I don't know that there can be agreement on that. In some countries, banks are trusted. In others, governments. But I don't think there is likely to be an entity that can be trusted across the board. Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com> Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Fri, Nov 4, 2016 at 6:53 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Identity, unlike payment, is a "read mostly" activity relative to a broadcast mechanism like Bitcoin. Therefore, inefficiency is hardly an issue. When it comes to identity, the principal difference between permissioned and permissionless seems to be how they handle attributes. What seems to be happening is a happy coexistence by defining identifiers in a way that allows many different methods to resolve an attribute linked to an identifier.
Adrian
On Friday, November 4, 2016, Thorsten H. Niebuhr [WedaCon GmbH] < tniebuhr@wedacon.net> wrote:
I think you mean this one:
Given the assumption, that a BSC/DLT System for Identities needs to be 'public', it leaves Permissioned or permissionless on the table. Permissionless needs a mechanism to make sure the 'bad guys' do not overrule the good guys, which (currently?) is done by mining mechanism (inefficent).
Which would indicate that it should be a 'permissioned' one.
On 01.11.2016 22:05, Adrian Gropper wrote:
Jeff makes a very important point. At the Verifiable Claims F2F, Drummond Reed put up a nice 2x2 table (that I have no link to) that showed: Permissioned / Permissionless on one axis and Public / Private on the other. Sovrin is an example of a permissioned blockchain that is public (anyone can use it). Bitcoin and Ethereum are permissionless and public. Private blockchains are just "old fashioned" technology from this perspective. Valuable, and may benefit from standardization, but unlikely to disrupt as far as I can tell.
Adrian
On Tue, Nov 1, 2016 at 4:28 PM, j stollman <stollman.j@gmail.com> wrote:
I would make a slight correction to the applicability of DLT.
From my perspective, Distributed Ledger Technology has two broad areas of applicability.
1. It supports Information Integrity by raising the bar for attackers seeking to compromise the data store by compelling them to modify a majority of copies of the data store to achieve consensus on the modified records. 2. It distributes the governance role of "trusted authority" when members of the community are unwilling to trust any of their fellows to be the keeper of the system of record.
But I do not equate DLT with Blockchain Technology. When DLT uses blockchain encryption in the datastore, I would consider it to be a Blockchain Technology application. This may be the current case for most currently envisioned DLT applications.
Alternatively, Blockchain Technology (i.e., blockchain encryption) may be applied to datastores that are not distributed. I can envision private blockchains that are run by trusted parties that intentionally hold data close to avoid compromising private or confidential data. The blockchain encryption may be applied to help ensure data integrity.
Jeff
--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <%2B1%20202.683.8699>
Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck
On Tue, Nov 1, 2016 at 3:18 PM, Adrian Gropper <agropper@healthurl.com> wrote:
I agree as well.
DLT is useful for: - maintaining reputation (such as control of an identifier) - timestamping, ordering of transactions, and related audit support - avoiding replay or double-spend
Mostly, DLT makes identity federations much less important if not actually irrelevant.
Adrian
On Tue, Nov 1, 2016 at 2:33 PM, James Hazard <james.g.hazard@gmail.com> wrote:
Agree with Eve that DLT seems usually to be the wrong platform when there are participants who can be contacted.
My impression is that DLT/blockchain is useful, perhaps necessary, when there is the possibility that nodes will have to act but will have no contact with a trust provider. E.g., the thermostat must be able to be authenticated vis-à-vis the furnace, and must be able to demonstrate ability to pay, even when the internet connection is down. (One can imagine much more compelling situations.)
The records of those transactions, however, should be synced to trusted nodes (e.g. AliceNode) as soon as they can be, and the history should be purged and just the balances carried forward.
Again, this is beyond my scope, but helps the ecosystem for codified legal.
On Tue, Nov 1, 2016 at 11:26 AM, James Hazard < james.g.hazard@gmail.com> wrote:
Tagging this on to the newly named thread (ignore my other):
I think we are in agreement, but imagining slightly different scenarios.
If Alice paid BobCo, there would be a record of the payment, originating at AliceNode and synced to BobCoNode (by push or pull).
BobCo could then issue a certificate of prompt payment to Alice, which would originate at BobCoNode and be synced to AliceNode. Kind of like an Uber/Lyft/Airbnb rating.
When Alice wanted to demonstrate creditworthiness to Claire, she would create a record in AliceNode and sync it to ClaireNode which authorized ClaireNode to access a permalink at BobCoNode. Whether AliceNode would also sync this authorization directly with BobCoNode is a technical matter beyond my scope, and perhaps could be done either way.
When ClaireNode actually accessed the record at BobCoNode, BobCo could create a receipt that originated in BobCoNode and was synced to AliceNode and ClaireNode, as desired.
The difference between this and the scenario you describe is mostly that Alice has a record of equal value to the one that BobCo has of her payment, and of BobCo's statement that it was on time. This maps more or less to email.
A blockchain as sole database seems problematic because of data security, performance constraints and interoperability. But blockchains might be very useful for keeping a tally of threads of transactions, proof-of-existence validation, etc.
The permalink could be done by hashing, like in IPFS.
In any event, peer-based transacting would not be based on word processing, and therefore would free the legal profession and system to use standards-based data formats.
On Adrian's point about PDS, I can imagine that the term carries freight. I use it merely to mean a database of records created by or synced to a participant. The git term might be something like a repo, or perhaps a branch, to reflect the fact that the records are understood to be part of something bigger.
On Tue, Nov 1, 2016 at 11:19 AM, Adrian Gropper < agropper@healthurl.com> wrote:
> There are two ways to get trusted information: > (1) verify a signed claim associated with an identity > (2) present a secure (UMA) token to a resource server you trust > > Adrian > > On Tuesday, November 1, 2016, Eve Maler <eve.maler@forgerock.com> > wrote: > >> I changed the subject line so as not to be misleading. Hopefully >> that starts a "new thread" in most everybody's email systems. >> >> I'm still not getting what about "blockchain the technology" helps >> any of this. Lots of information that is important to an individual -- e.g. >> credit information, as pointed out below -- must be third-party-asserted to >> be valuable. We can argue about whether this is/constitutes/contributes to >> "identity" information or not (in this case, it can be used to help "proof" >> a digital identity and so on). But the conventional wisdom seems to be >> hardening around the notions that: >> >> - It's inefficient, inappropriate, and insecure to store such >> information by means of DLTs. >> - It's quite often inefficient, inappropriate, and insecure to >> aggregate such information in a single place away from whoever is >> authoritative for it. See all the schemes -- federated identity and >> federated authorization both -- for getting this info fresh by means of >> attribute transfer and API calls and such. You have to tamper-proof college >> e-transcripts, income tax forms, identity attributes, etc. that have to >> pass through intermediary services if you can't arrange for them to be >> shared directly. >> >> UMA at least tries to let an individual authorize access to data >> that is asserted by others about them. (That role at the technical level is >> called "resource owner" after OAuth, but as I always say, I never liked >> that phrase, property being a bundle of sticks... :-) ) >> >> >> *Eve Maler *ForgeRock Office of the CTO | VP Innovation & Emerging >> Technology >> Cell +1 425.345.6756 <%2B1%20425.345.6756> | Skype: xmlgrrl | >> Twitter: @xmlgrrl >> *The ForgeRock Identity Summit* is coming to >> <http://summits.forgerock.com/> *Paris in November!* >> >> On Tue, Nov 1, 2016 at 10:46 AM, Adrian Gropper < >> agropper@healthurl.com> wrote: >> >>> I share Jim's perspective about incremental semantic standards and >>> I'm seeing coherent identity standardization efforts at every >>> level with: >>> >>> 1 - Authentication credentials corresponding to a decentralized >>> identifier (DID), point to >>> 2 - Secure decentralized identity data objects (DDO), that point to >>> 3 - Identity Containers that issue (W3C) verifiable claims and >>> (UMA) authorization tokens to use >>> 4 - on other resources with my personal data on the Web that are >>> only partially under my control. >>> >>> Levels 1-3 can be self-sovereign without any federated IDPs. >>> >>> However, there is absolutely no mention of PDS in any of the >>> forums. The term may be too vague and overloaded to be useful. I hope we >>> can abandon it soon. Identity containers may not be a much better term but >>> at least it allows for a personal authorization server as a component. >>> >>> Adrian >>> >>> On Tuesday, November 1, 2016, James Hazard < >>> james.g.hazard@gmail.com> wrote: >>> >>>> Sorry, I missed the call, again. On the west coast for a bit. >>>> >>>> I agree with the direction of the conversation. >>>> >>>> The essence of a peer-based system is the PDS notion. Each >>>> participant has a first-class copy of the records that touch them. >>>> >>>> Those records must be in formats that have common semantics. >>>> >>>> Because the world is big and varied (and more top-down is >>>> dangerous), the semantics need to be extensible by the participants. The >>>> commonality of the semantics does not need to be system-wide, it only needs >>>> to be shared as far as the records they relate to. This makes it possible >>>> to do "standards" incrementally. (Open source software iterates from >>>> personal project to standard this way.) >>>> >>>> Blockchain permits each participant to have a first-class copy, >>>> but has major draw backs, particularly that every participant gets a copy >>>> of all the records (reason that Corda is not a blockchain) and blockchains >>>> have the rigidities of "shared state." ( >>>> https://medium.com/@justmoon/the-subtle-tyranny-of-blockch >>>> ain-91d98b8a3a65#.oupo603xl) >>>> >>>> Ideally, each record would be only in the PDSs of the >>>> participants that the record directly touches. >>>> >>>> To run a "DRY" system, with very little need to have duplicate >>>> information about participants, the PDS must be available to respond to >>>> appropriate queries. >>>> >>>> The records in the PDS could come all via a single protocol, but >>>> they could instead come via a variety of protocols. The participants do >>>> need a way to prove records as against one another. There are a variety of >>>> ways to do this, and they don't need to depend on the protocol. >>>> >>>> From this perspective, the goal is PDSs with shared record >>>> semantics, unlimited extensibility, and a secure method of querying. >>>> Unlimited extensibility is what the "prototype inheritance" model of >>>> CommonAccord appears to enable. >>>> >>>> That in turn will create an ecosystem for codified legal, which >>>> is the goal of CommonAccord. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Nov 1, 2016 at 8:52 AM, Adrian Gropper < >>>> agropper@healthurl.com> wrote: >>>> >>>>> You might find the FAQ useful. >>>>> >>>>> https://w3c.github.io/webpayments-ig/VCTF/charter/faq.html >>>>> >>>>> Adrian >>>>> >>>>> On Tuesday, November 1, 2016, Eve Maler <eve.maler@forgerock.com> >>>>> wrote: >>>>> >>>>>> Adrian-- I'm sorry, it appears you already did send this link >>>>>> to the group! Thanks; action item completed. >>>>>> >>>>>> >>>>>> *Eve Maler *ForgeRock Office of the CTO | VP Innovation & >>>>>> Emerging Technology >>>>>> Cell +1 425.345.6756 <%2B1%20425.345.6756> | Skype: xmlgrrl | >>>>>> Twitter: @xmlgrrl >>>>>> *The ForgeRock Identity Summit* is coming to >>>>>> <http://summits.forgerock.com/> *Paris in November!* >>>>>> >>>>>> On Tue, Aug 30, 2016 at 2:06 PM, Adrian Gropper < >>>>>> agropper@healthurl.com> wrote: >>>>>> >>>>>>> We should also consider the place of protocols that support >>>>>>> decentralization without neccessarily being either blockchain or smart >>>>>>> contracts. For example, W3C Verifiable Claims >>>>>>> https://w3c.github.io/webpayments-ig/VCTF/use-cases/ seems to >>>>>>> solve a major privacy and centralization problem by enabling triple-blind >>>>>>> interactions. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> On Tuesday, August 30, 2016, Scott L. David <sldavid@uw.edu> >>>>>>> wrote: >>>>>>> >>>>>>>> Jeff - I heartily agree with all the points you raise. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Scott >>>>>>>> >>>>>>>> Scott L. David >>>>>>>> >>>>>>>> Director of Policy >>>>>>>> Center for Information Assurance and Cybersecurity >>>>>>>> University of Washington - Applied Physics Laboratory >>>>>>>> >>>>>>>> Principal Consulting Analyst >>>>>>>> TechVision Research >>>>>>>> >>>>>>>> w- 206-897-1466 >>>>>>>> m- 206-715-0859 >>>>>>>> Tw - @ScottLDavid >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* j stollman <stollman.j@gmail.com> >>>>>>>> *Sent:* Tuesday, August 30, 2016 10:15:27 AM >>>>>>>> *To:* Scott L. David >>>>>>>> *Cc:* Eve Maler; dg-bsc@kantarainitiative.org >>>>>>>> *Subject:* Re: [DG-BSC] Agenda for BSC telecon Tuesday, >>>>>>>> August 30 (shortly -- sorry for the late note!) >>>>>>>> >>>>>>>> Scott, >>>>>>>> >>>>>>>> Excellent survey. >>>>>>>> >>>>>>>> I would like to further emphasize one of the corollary points >>>>>>>> you raise: *Perhaps we shouldn't be looking for a >>>>>>>> distributed organizational "structure" at all. Instead, we might consider >>>>>>>> what organizational "processes" would serve the interests involved, and >>>>>>>> then allow the organizational structure to reveal itself based on the >>>>>>>> observation and reification of the patterns that emerge from those >>>>>>>> processes.* >>>>>>>> >>>>>>>> In my observations people move rapidly from trying to >>>>>>>> describe a new solution to using their description to prescribe its use. >>>>>>>> Over two years of focus on blockchain technology, I have noticed that it is >>>>>>>> common for people to recognize that a particular instance of blockchain >>>>>>>> solves a particular problem and to then falsely conclude that the features >>>>>>>> of that instantiation are necessary to achieve the same end in other >>>>>>>> contexts. For example, we give a lot of lip service to the fact that >>>>>>>> popular blockchain instances use a distributed model in which the >>>>>>>> blockchain itself is replicated in numerous locations and the block >>>>>>>> verification process is also distributed among a large group of "miners." >>>>>>>> This has been followed by the conclusion that all blockchains are >>>>>>>> necessarily distributed for both data integrity and verification integrity. >>>>>>>> (In fact many people now refer to blockchain technology as "Distributed >>>>>>>> Ledger Technology" (DLT)). I suggest that this causes an unnecessary >>>>>>>> narrowing of our thinking by casting out other alternatives before they are >>>>>>>> even considered. >>>>>>>> >>>>>>>> In the example, I would suggest that distributed data does >>>>>>>> provide higher levels of information assurance by removing a single point >>>>>>>> of failure that a nefarious hacker could modify. And this is likely true >>>>>>>> for any instantiation of a data structure -- whether or not it is a >>>>>>>> blockchain -- as long as the consensus mechanism for determining which data >>>>>>>> set is the correct one when discrepancies are found is robust. But, >>>>>>>> depending on the risk of such hacks, it may not be cost-effective to use >>>>>>>> this information assurance technique. As long as the underlying data >>>>>>>> structure uses blockchain encryption, I would still consider it a >>>>>>>> blockchain application. >>>>>>>> >>>>>>>> I also agree that distributed miners afford some ability to >>>>>>>> reduce collusion in systems where there is an incentive to collude. But >>>>>>>> not all transaction systems have such an incentive. And I don't think that >>>>>>>> mining whether using proof of work or proof of stake is either >>>>>>>> cost-effective or necessary. >>>>>>>> >>>>>>>> We all agree that standardization can create great benefits. >>>>>>>> But standardizing too early can stifle innovation or raise the cost of >>>>>>>> better solutions to the point of making them no longer viable. >>>>>>>> >>>>>>>> In view of the many directions that our blockchain DG >>>>>>>> discussions continue to splinter off, I hope that this comment offers some >>>>>>>> value. >>>>>>>> >>>>>>>> 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 Tue, Aug 30, 2016 at 12:09 PM, Scott L. David < >>>>>>>> sldavid@uw.edu> wrote: >>>>>>>> >>>>>>>>> Hi folks - This wiki page provides a pretty nice overview of >>>>>>>>> cooperatives. >>>>>>>>> >>>>>>>>> >>>>>>>>> https://en.wikipedia.org/wiki/Cooperative >>>>>>>>> >>>>>>>>> I am NOT suggesting that we confine ourselves to these >>>>>>>>> historical structures, since they are all institutions configured to >>>>>>>>> address various prior governance/organizational challenges, none of which >>>>>>>>> will perfectly match current challenges in character and scope. >>>>>>>>> >>>>>>>>> >>>>>>>>> However, exploration of the co-op form (and similar stru >>>>>>>>> >>>>>>>>
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
