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 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 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 | 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 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 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-blockchain-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 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 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 | 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 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 >> *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 >> 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 structures >>> developed under various legal and cultural regimes) can provide insight >>> into at least prior forms of "organic" stakeholder-responsive governance >>> that can potentially help to reveal governance techniques that might be >>> borrowed for our current discussions and effort. >>> >>> >>> I am guessing (projecting) that organizational surveys might >>> suggest that we consider separating the analysis of stakeholder involvement >>> into at least three sub-categories of governance activity, along the lines >>> to which Jeff S. was alluding in the call. >>> >>> >>> Specifically, we might benefit from separating out stakeholder >>> involvement in the separate activities of 1. rule making, 2. system >>> operation, and 3. enforcement, as helpful in mitigating the >>> conflict-of-interest/power accumulation/etc. issues that are inherent in >>> the centralized models (and their too-often-tempting-abuses of gatekeeping >>> function). For example, in 2007 when NASD (National Association of >>> Securities Dealers) converted to FINRA (FInancial Industry Regulatory >>> Authority, Inc.) they formed separate subsidiaries to separate these three >>> functions for the SRO (self-regulatory organization) responsible for broker >>> dealer activities (at least for purposes of optics!). For current >>> purposes, the important point is that they chose to separate the rule >>> making, operation and enforcement purposes to at least reduce the >>> appearances of conflict among the decision making in those separate spheres. >>> >>> >>> Of course, these 3 "system governance" elements are in addition to >>> stakeholder role as system "users," which is not a "governance" role, per >>> se. However, in co-op and similar forms participation as a "user" is a >>> form of quasi-governance since the use of the system by a >>> stakeholder reveals problems and value propositions that helps the >>> stakeholders to set the agenda for further refinement of the system in the >>> "1. rule making" role of stakeholders alluded to above. >>> >>> >>> The current global information network organizational structure >>> that we are looking for does not yet have a name, but that novelty should >>> not be discouraging. ALL forms of human organization (governance, >>> language, belief systems, etc.) are responses to shared challenges, and all >>> of them permit stakeholders (both institutional or individual) to do >>> things (mitigate risks and enhance rewards) that they cannot do (or cannot >>> do as well) unilaterally. Many of the shared challenges that are currently >>> faced by individuals are unprecedented, requiring groups such as ours to >>> search the history of human organization for clues as to what might be >>> effective in this context. >>> >>> >>> One last thought (at least for now!). 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 (as "Lagrangian Coherent Structures" for you fluid >>> mechanics geeks out there). Our first question might be "What are the sets >>> of processes that MUST be standardized, normalized in order for the value >>> propositions of block chain and/or smart contracts to be effective in >>> mitigating risk and/or leveraging value?" After we catalog those >>> processes, we might be in a position to assign that catalog a name. >>> >>> >>> An article "Self Regulation as Policy Process" by Porter and Ronit >>> (2006) suggests that among hundreds of "self-regulatory" organizations, a >>> familiar 5 stage pattern emerges for a governance feed-back loop among >>> stakeholders (agenda setting-problem identification-decision-implementation-review). >>> The emergence of this similar archetype pattern in myriad disparate >>> settings may be suggesting that there is a natural feedback process through >>> which separate elements of human organization can be joined together to >>> create larger forms in "information" space, where decreased Shannon entropy >>> (in whatever context or domain) is the ultimate test of fitness (based on >>> the primacy of information risk and information leverage in current >>> discussions). >>> >>> >>> This latter suggestion may be confirmed by considering how many >>> current human institutions and organizations can be accurately described by >>> reference to their information flows and processes, variously constrained >>> by their intended application. Human organizations that demonstrate their >>> usefulness "achieve" longevity (in fact human stakeholders have >>> endowed governments, and corporations with "perpetual life," by mutual >>> agreement, in an effort to project an external sovereignty toward these >>> organizational forms that are relied upon to create a "solid" foundation of >>> most (not all) human endeavor). However, all governments and corporations >>> are collective hallucinations of the stakeholders that recognize, and >>> depend upon, their presence. >>> >>> >>> But I digress. . . >>> >>> >>> 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:* dg-bsc-bounces@kantarainitiative.org < >>> dg-bsc-bounces@kantarainitiative.org> on behalf of Eve Maler < >>> eve.maler@forgerock.com> >>> *Sent:* Tuesday, August 30, 2016 6:50 AM >>> *To:* dg-bsc@kantarainitiative.org >>> *Subject:* [DG-BSC] Agenda for BSC telecon Tuesday, August 30 >>> (shortly -- sorry for the late note!) >>> >>> http://kantarainitiative.org/confluence/display/BSC/2016-08+ >>> %28August+2016%29+Meetings#id-2016-08(August2016)Meetings-Tu >>> esday,August30 >>> >>> 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!* >>> >>> _______________________________________________ >>> DG-BSC mailing list >>> DG-BSC@kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>> >>> >> > > -- > > 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/ > > > _______________________________________________ > DG-BSC mailing list > DG-BSC@kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/dg-bsc > >

--

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/

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

-- @commonaccord

--

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/

--

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/

-- @commonaccord

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 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 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 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 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 | 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

...

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 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-blockchain-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 > 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 | 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 >>> 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 >>>> *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 >>>> 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 structures >>>>> developed under various legal and cultural regimes) can provide insight >>>>> into at least prior forms of "organic" stakeholder-responsive governance >>>>> that can potentially help to reveal governance techniques that might be >>>>> borrowed for our current discussions and effort. >>>>> >>>>> >>>>> I am guessing (projecting) that organizational surveys might >>>>> suggest that we consider separating the analysis of stakeholder involvement >>>>> into at least three sub-categories of governance activity, along the lines >>>>> to which Jeff S. was alluding in the call. >>>>> >>>>> >>>>> Specifically, we might benefit from separating out stakeholder >>>>> involvement in the separate activities of 1. rule making, 2. system >>>>> operation, and 3. enforcement, as helpful in mitigating the >>>>> conflict-of-interest/power accumulation/etc. issues that are inherent in >>>>> the centralized models (and their too-often-tempting-abuses of gatekeeping >>>>> function). For example, in 2007 when NASD (National Association of >>>>> Securities Dealers) converted to FINRA (FInancial Industry Regulatory >>>>> Authority, Inc.) they formed separate subsidiaries to separate these three >>>>> functions for the SRO (self-regulatory organization) responsible for broker >>>>> dealer activities (at least for purposes of optics!). For current >>>>> purposes, the important point is that they chose to separate the rule >>>>> making, operation and enforcement purposes to at least reduce the >>>>> appearances of conflict among the decision making in those separate spheres. >>>>> >>>>> >>>>> Of course, these 3 "system governance" elements are in addition >>>>> to stakeholder role as system "users," which is not a "governance" role, >>>>> per se. However, in co-op and similar forms participation as a "user" is a >>>>> form of quasi-governance since the use of the system by a >>>>> stakeholder reveals problems and value propositions that helps the >>>>> stakeholders to set the agenda for further refinement of the system in the >>>>> "1. rule making" role of stakeholders alluded to above. >>>>> >>>>> >>>>> The current global information network organizational structure >>>>> that we are looking for does not yet have a name, but that novelty should >>>>> not be discouraging. ALL forms of human organization (governance, >>>>> language, belief systems, etc.) are responses to shared challenges, and all >>>>> of them permit stakeholders (both institutional or individual) to do >>>>> things (mitigate risks and enhance rewards) that they cannot do (or cannot >>>>> do as well) unilaterally. Many of the shared challenges that are currently >>>>> faced by individuals are unprecedented, requiring groups such as ours to >>>>> search the history of human organization for clues as to what might be >>>>> effective in this context. >>>>> >>>>> >>>>> One last thought (at least for now!). 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 (as "Lagrangian Coherent Structures" for you fluid >>>>> mechanics geeks out there). Our first question might be "What are the sets >>>>> of processes that MUST be standardized, normalized in order for the value >>>>> propositions of block chain and/or smart contracts to be effective in >>>>> mitigating risk and/or leveraging value?" After we catalog those >>>>> processes, we might be in a position to assign that catalog a name. >>>>> >>>>> >>>>> An article "Self Regulation as Policy Process" by Porter and >>>>> Ronit (2006) suggests that among hundreds of "self-regulatory" >>>>> organizations, a familiar 5 stage pattern emerges for a governance >>>>> feed-back loop among stakeholders (agenda setting-problem >>>>> identification-decision-implementation-review). The emergence >>>>> of this similar archetype pattern in myriad disparate settings may be >>>>> suggesting that there is a natural feedback process through which separate >>>>> elements of human organization can be joined together to create larger >>>>> forms in "information" space, where decreased Shannon entropy (in whatever >>>>> context or domain) is the ultimate test of fitness (based on the primacy of >>>>> information risk and information leverage in current discussions). >>>>> >>>>> >>>>> This latter suggestion may be confirmed by considering how many >>>>> current human institutions and organizations can be accurately described by >>>>> reference to their information flows and processes, variously constrained >>>>> by their intended application. Human organizations that demonstrate their >>>>> usefulness "achieve" longevity (in fact human stakeholders have >>>>> endowed governments, and corporations with "perpetual life," by mutual >>>>> agreement, in an effort to project an external sovereignty toward these >>>>> organizational forms that are relied upon to create a "solid" foundation of >>>>> most (not all) human endeavor). However, all governments and corporations >>>>> are collective hallucinations of the stakeholders that recognize, and >>>>> depend upon, their presence. >>>>> >>>>> >>>>> But I digress. . . >>>>> >>>>> >>>>> 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:* dg-bsc-bounces@kantarainitiative.org < >>>>> dg-bsc-bounces@kantarainitiative.org> on behalf of Eve Maler < >>>>> eve.maler@forgerock.com> >>>>> *Sent:* Tuesday, August 30, 2016 6:50 AM >>>>> *To:* dg-bsc@kantarainitiative.org >>>>> *Subject:* [DG-BSC] Agenda for BSC telecon Tuesday, August 30 >>>>> (shortly -- sorry for the late note!) >>>>> >>>>> http://kantarainitiative.org/confluence/display/BSC/2016-08+ >>>>> %28August+2016%29+Meetings#id-2016-08(August2016)Meetings-Tu >>>>> esday,August30 >>>>> >>>>> 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!* >>>>> >>>>> _______________________________________________ >>>>> DG-BSC mailing list >>>>> DG-BSC@kantarainitiative.org >>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>> >>>>> >>>> >>> >>> -- >>> >>> 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/ >>> >>> >>> _______________________________________________ >>> DG-BSC mailing list >>> DG-BSC@kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>> >>> >> > > -- > > 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/ > > > _______________________________________________ > DG-BSC mailing list > DG-BSC@kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/dg-bsc > >

-- @commonaccord

--

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/

--

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/

-- @commonaccord

-- @commonaccord

-- 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/

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 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

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 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 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 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

...

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 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 | 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 > 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 >>> 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 | 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 >>>>> 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 >>>>>> *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 structures >>>>>>> developed under various legal and cultural regimes) can provide insight >>>>>>> into at least prior forms of "organic" stakeholder-responsive governance >>>>>>> that can potentially help to reveal governance techniques that might be >>>>>>> borrowed for our current discussions and effort. >>>>>>> >>>>>>> >>>>>>> I am guessing (projecting) that organizational surveys might >>>>>>> suggest that we consider separating the analysis of stakeholder involvement >>>>>>> into at least three sub-categories of governance activity, along the lines >>>>>>> to which Jeff S. was alluding in the call. >>>>>>> >>>>>>> >>>>>>> Specifically, we might benefit from separating out stakeholder >>>>>>> involvement in the separate activities of 1. rule making, 2. system >>>>>>> operation, and 3. enforcement, as helpful in mitigating the >>>>>>> conflict-of-interest/power accumulation/etc. issues that are inherent in >>>>>>> the centralized models (and their too-often-tempting-abuses of gatekeeping >>>>>>> function). For example, in 2007 when NASD (National Association of >>>>>>> Securities Dealers) converted to FINRA (FInancial Industry Regulatory >>>>>>> Authority, Inc.) they formed separate subsidiaries to separate these three >>>>>>> functions for the SRO (self-regulatory organization) responsible for broker >>>>>>> dealer activities (at least for purposes of optics!). For current >>>>>>> purposes, the important point is that they chose to separate the rule >>>>>>> making, operation and enforcement purposes to at least reduce the >>>>>>> appearances of conflict among the decision making in those separate spheres. >>>>>>> >>>>>>> >>>>>>> Of course, these 3 "system governance" elements are in >>>>>>> addition to stakeholder role as system "users," which is not a "governance" >>>>>>> role, per se. However, in co-op and similar forms participation as a >>>>>>> "user" is a form of quasi-governance since the use of the system by a >>>>>>> stakeholder reveals problems and value propositions that helps the >>>>>>> stakeholders to set the agenda for further refinement of the system in the >>>>>>> "1. rule making" role of stakeholders alluded to above. >>>>>>> >>>>>>> >>>>>>> The current global information network organizational structure >>>>>>> that we are looking for does not yet have a name, but that novelty should >>>>>>> not be discouraging. ALL forms of human organization (governance, >>>>>>> language, belief systems, etc.) are responses to shared challenges, and all >>>>>>> of them permit stakeholders (both institutional or individual) to do >>>>>>> things (mitigate risks and enhance rewards) that they cannot do (or cannot >>>>>>> do as well) unilaterally. Many of the shared challenges that are currently >>>>>>> faced by individuals are unprecedented, requiring groups such as ours to >>>>>>> search the history of human organization for clues as to what might be >>>>>>> effective in this context. >>>>>>> >>>>>>> >>>>>>> One last thought (at least for now!). 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 (as "Lagrangian Coherent Structures" for you fluid >>>>>>> mechanics geeks out there). Our first question might be "What are the sets >>>>>>> of processes that MUST be standardized, normalized in order for the value >>>>>>> propositions of block chain and/or smart contracts to be effective in >>>>>>> mitigating risk and/or leveraging value?" After we catalog those >>>>>>> processes, we might be in a position to assign that catalog a name. >>>>>>> >>>>>>> >>>>>>> An article "Self Regulation as Policy Process" by Porter and >>>>>>> Ronit (2006) suggests that among hundreds of "self-regulatory" >>>>>>> organizations, a familiar 5 stage pattern emerges for a governance >>>>>>> feed-back loop among stakeholders (agenda setting-problem >>>>>>> identification-decision-implementation-review). The >>>>>>> emergence of this similar archetype pattern in myriad disparate settings >>>>>>> may be suggesting that there is a natural feedback process through which >>>>>>> separate elements of human organization can be joined together to create >>>>>>> larger forms in "information" space, where decreased Shannon entropy (in >>>>>>> whatever context or domain) is the ultimate test of fitness (based on the >>>>>>> primacy of information risk and information leverage in current >>>>>>> discussions). >>>>>>> >>>>>>> >>>>>>> This latter suggestion may be confirmed by considering how >>>>>>> many current human institutions and organizations can be accurately >>>>>>> described by reference to their information flows and processes, variously >>>>>>> constrained by their intended application. Human organizations that >>>>>>> demonstrate their usefulness "achieve" longevity (in fact human >>>>>>> stakeholders have endowed governments, and corporations with "perpetual >>>>>>> life," by mutual agreement, in an effort to project an external sovereignty >>>>>>> toward these organizational forms that are relied upon to create a >>>>>>> "solid" foundation of most (not all) human endeavor). However, all >>>>>>> governments and corporations are collective hallucinations of the >>>>>>> stakeholders that recognize, and depend upon, their presence. >>>>>>> >>>>>>> >>>>>>> But I digress. . . >>>>>>> >>>>>>> >>>>>>> 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:* dg-bsc-bounces@kantarainitiative.org < >>>>>>> dg-bsc-bounces@kantarainitiative.org> on behalf of Eve Maler < >>>>>>> eve.maler@forgerock.com> >>>>>>> *Sent:* Tuesday, August 30, 2016 6:50 AM >>>>>>> *To:* dg-bsc@kantarainitiative.org >>>>>>> *Subject:* [DG-BSC] Agenda for BSC telecon Tuesday, August 30 >>>>>>> (shortly -- sorry for the late note!) >>>>>>> >>>>>>> http://kantarainitiative.org/confluence/display/BSC/2016-08+ >>>>>>> %28August+2016%29+Meetings#id-2016-08(August2016)Meetings-Tu >>>>>>> esday,August30 >>>>>>> >>>>>>> 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!* >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DG-BSC mailing list >>>>>>> DG-BSC@kantarainitiative.org >>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> 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/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> DG-BSC mailing list >>>>> DG-BSC@kantarainitiative.org >>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>> >>>>> >>>> >>> >>> -- >>> >>> 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/ >>> >>> >>> _______________________________________________ >>> DG-BSC mailing list >>> DG-BSC@kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>> >>> >> >> >> -- >> @commonaccord >> > > > -- > > 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/ > >

--

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/

-- @commonaccord

-- @commonaccord

--

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/

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

-- 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/

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 mailto: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 mailto:stollman.j@gmail.com +1 202.683.8699 tel:%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 mailto: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 mailto: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 mailto: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 mailto: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 mailto: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 tel:%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 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 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-blockchain-91d98b8a3a65#.... https://medium.com/@justmoon/the-subtle-tyranny-of-blockchain-91d98b8a3a65#....)

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 wrote:

You might find the FAQ useful.

https://w3c.github.io/webpayments-ig/VCTF/charter/faq.html https://w3c.github.io/webpayments-ig/VCTF/charter/faq.html

Adrian

On Tuesday, November 1, 2016, Eve Maler 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 tel:%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 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/ 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 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 tel:206-897-1466 m- 206-715-0859 tel:206-715-0859 Tw - @ScottLDavid

------------------------------------------------------------------------ *From:* j stollman *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 tel:%2B1%20202.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 wrote:

Hi folks - This wiki page provides a pretty nice overview of cooperatives.

https://en.wikipedia.org/wiki/Cooperative 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 structures developed under various legal and cultural regimes) can provide insight into at least prior forms of "organic" stakeholder-responsive governance that can potentially help to reveal governance techniques that might be borrowed for our current discussions and effort.

I am guessing (projecting) that organizational surveys might suggest that we consider separating the analysis of stakeholder involvement into at least three sub-categories of governance activity, along the lines to which Jeff S. was alluding in the call.

Specifically, we might benefit from separating out stakeholder involvement in the separate activities of 1. rule making, 2. system operation, and 3. enforcement, as helpful in mitigating the conflict-of-interest/power accumulation/etc. issues that are inherent in the centralized models (and their too-often-tempting-abuses of gatekeeping function). For example, in 2007 when NASD (National Association of Securities Dealers) converted to FINRA (FInancial Industry Regulatory Authority, Inc.) they formed separate subsidiaries to separate these three functions for the SRO (self-regulatory organization) responsible for broker dealer activities (at least for purposes of optics!). For current purposes, the important point is that they chose to separate the rule making, operation and enforcement purposes to at least reduce the appearances of conflict among the decision making in those separate spheres.

Of course, these 3 "system governance" elements are in addition to stakeholder role as system "users," which is not a "governance" role, per se. However, in co-op and similar forms participation as a "user" is a form of quasi-governance since the use of the system by a stakeholder reveals problems and value propositions that helps the stakeholders to set the agenda for further refinement of the system in the "1. rule making" role of stakeholders alluded to above.

The current global information network organizational structure that we are looking for does not yet have a name, but that novelty should not be discouraging. ALL forms of human organization (governance, language, belief systems, etc.) are responses to shared challenges, and all of them permit stakeholders (both institutional or individual) to do things (mitigate risks and enhance rewards) that they cannot do (or cannot do as well) unilaterally. Many of the shared challenges that are currently faced by individuals are unprecedented, requiring groups such as ours to search the history of human organization for clues as to what might be effective in this context.

One last thought (at least for now!). 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 (as "Lagrangian Coherent Structures" for you fluid mechanics geeks out there). Our first question might be "What are the sets of processes that MUST be standardized, normalized in order for the value propositions of block chain and/or smart contracts to be effective in mitigating risk and/or leveraging value?" After we catalog those processes, we might be in a position to assign that catalog a name.

An article "Self Regulation as Policy Process" by Porter and Ronit (2006) suggests that among hundreds of "self-regulatory" organizations, a familiar 5 stage pattern emerges for a governance feed-back loop among stakeholders (agenda setting-problem identification-decision-implementation-review). The emergence of this similar archetype pattern in myriad disparate settings may be suggesting that there is a natural feedback process through which separate elements of human organization can be joined together to create larger forms in "information" space, where decreased Shannon entropy (in whatever context or domain) is the ultimate test of fitness (based on the primacy of information risk and information leverage in current discussions).

This latter suggestion may be confirmed by considering how many current human institutions and organizations can be accurately described by reference to their information flows and processes, variously constrained by their intended application. Human organizations that demonstrate their usefulness "achieve" longevity (in fact human stakeholders have endowed governments, and corporations with "perpetual life," by mutual agreement, in an effort to project an external sovereignty toward these organizational forms that are relied upon to create a "solid" foundation of most (not all) human endeavor). However, all governments and corporations are collective hallucinations of the stakeholders that recognize, and depend upon, their presence.

But I digress. . .

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 tel:206-897-1466

m- 206-715-0859 tel:206-715-0859

Tw - @ScottLDavid

------------------------------------------------------------------------ *From:* dg-bsc-bounces@kantarainitiative.org on behalf of Eve Maler *Sent:* Tuesday, August 30, 2016 6:50 AM *To:* dg-bsc@kantarainitiative.org *Subject:* [DG-BSC] Agenda for BSC telecon Tuesday, August 30 (shortly -- sorry for the late note!)

http://kantarainitiative.org/confluence/display/BSC/2016-08+%28August+2016%2... http://kantarainitiative.org/confluence/display/BSC/2016-08+%28August+2016%2...

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 tel:%2B1-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 tel:%2B1%20425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits and UnSummits* are coming to http://summits.forgerock.com/ *London and Paris!*

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc http://kantarainitiative.org/mailman/listinfo/dg-bsc

--

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/ http://patientprivacyrights.org/donate-2/

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc http://kantarainitiative.org/mailman/listinfo/dg-bsc

--

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/ http://patientprivacyrights.org/donate-2/

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc http://kantarainitiative.org/mailman/listinfo/dg-bsc

-- @commonaccord

--

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/ http://patientprivacyrights.org/donate-2/

--

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/ http://patientprivacyrights.org/donate-2/

-- @commonaccord

-- @commonaccord

--

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/ http://patientprivacyrights.org/donate-2/

_______________________________________________ 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

--

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/

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

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 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 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 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 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 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 > 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 >>>>> 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 >>>>>>> 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 >>>>>>>> *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/

Yes you do need overall standards in the system. That's exactly what Rebooting Web of Trust is doing by standardizing DID and DDO. Adrian On Friday, November 4, 2016, Susan wrote:

So the minute you agree hard forks can happen in a permissionless system, think DAO, what kind of mechanism exists to keep the actors in check? You need overall standards for the system.

Susan

SheTechPower 914.924.1994

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail, delete and then destroy all copies of the original message.

On Nov 4, 2016, at 10:00 AM, j stollman javascript:_e(%7B%7D,'cvml','stollman.j@gmail.com');> wrote:

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 javascript:_e(%7B%7D,'cvml','stollman.j@gmail.com'); +1 202.683.8699 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 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 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

...

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 >> 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 >>>>>>>> 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 >>>>>>>>> *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/

My two cents on centralization: A blockchain is "centralizing." The innovation is that it disperses control of the center. And even though the center is replicated. It is more centralizing than a P2P model, where only the direct parties have a copy of their transactions. The participants in a P2P system can rely on any form of validation that they deem adequate. That might include conventional systems, such as that they know one another, and can cajole, shame or sue one another. It might include having a "trust provider" - some one whose stake in their reputation is greater than their stake (even indirect) in the transaction. That could be a mutual friend, a congregation (e.g. marriage vows), a trustee, a bank, bank regulator, land recording office, the WayBack machine, Github, or a blockchain. There does not need to be a universal system that everyone trusts, and perhaps the system would be more robust if there is not a universal system. A patchwork of trust relationships may be better. There are already some quasi-universal systems of second-hand trust - notably via governments and via banks. The academic, scientific and business communities also have domain-specific quasi-universal systems. On Fri, Nov 4, 2016 at 7:35 AM, Eve Maler wrote:

Awesome thread. I am going to try to net out some assertions and potential conclusions in this thread that we could mark as observations *For The Report* / *Needs More Discussion* (preparatory to including in the report). I would like us all to be thinking in these terms from now on in this DG's lifespan. If you take issue with a For The Report suggestion, we can turn it into a Needs More Discussion agenda item. (I recommend we time-box each one.)

By the way, I can't make the next two weeks' worth of meetings (!), so please stay tuned regarding any impacts on meeting schedule. Thomas and I are coordinating.

- Blockchain vs. DLT: Do we intend to distinguish "blockchain encryption" vs. the aggregation of distributed ledger technology that is typically associated with "blockchain"? To date we've done the latter (and this is what's in the report now, with extensive language), while Jeff is suggesting the former. *Needs More "Discussion"*, but I suggest we should actually take a vote or similar and not spend time arguing. - Netting out Jim's comments about Alice and Bob transactions: Saving transaction records (or pointers to them) on this type of ledger are valuable when preserving *reciprocality* between/among parties in a transaction is desired, and this has salutary effects on evening out the empowerment situation among them. I suggest this is *For The Report*. - Jeff's point that "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." I suggest this is usable as is *For The Report*. - This technology generally is known to have security, privacy, and inefficiency (both at rest = bloat and in motion = mining) concerns generally, which is why we're seeing a design pattern in many cases emerge of storing information in other types of repositories and pointers/hashes on the ledger. Classic identity profile information, however, is written less frequently and read more frequently, as Adrian pointed out. Nonetheless, we still see this design pattern being used (e.g. in Sovrin). I suggest this is *For The Report*. - Jeff's point that "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." Our ongoing conversation about governance models and permissionless/permissioned seems to complicate this a bit, so I suspect that it *Needs More Discussion* to add color. E.g., are controls being added back at technical layers? business layers? both? - (Co-chair's privilege: :-) ) For me, the million-dollar question is: When permissioning of any kind is added back, most often, it comes in a *re-centralizing* form. In what use cases does this harm the original point of the exercise? *Needs More Discussion*.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *The ForgeRock Identity Summit* is coming to http://summits.forgerock.com/ *Paris in November!*

On Fri, Nov 4, 2016 at 7:15 AM, Adrian Gropper wrote:

...

Yes you do need overall standards in the system. That's exactly what Rebooting Web of Trust is doing by standardizing DID and DDO.

Adrian

On Friday, November 4, 2016, Susan wrote:

...

So the minute you agree hard forks can happen in a permissionless system, think DAO, what kind of mechanism exists to keep the actors in check? You need overall standards for the system.

Susan

SheTechPower 914.924.1994

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail, delete and then destroy all copies of the original message.

On Nov 4, 2016, at 10:00 AM, j stollman wrote:

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

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 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 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 >>>> 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 >>>>>>>>>> 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 >>>>>>>>>>> *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/

_______________________________________________ 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

Your second point is really critical. Yes, we have contracts of adhesion and I would add with minimal penalties. The individual should be able to negotiate the relationship terms. But on the other side, the information service provider has to know the individual asserting the control has done that in a way that provides trustable information as the identity trail evolves via reputation or other factors. On Fri, Nov 4, 2016 at 1:14 PM, John Wunderlich wrote:

James et al;

If I assume that one of the design goals of Kantara supported initiative is to empower individuals (i.e. natural persons), that generates a couple of corollaries:

1. An individual should be free to assert control over their own information assets. This may be accomplished by them running their own systems or by delegating that control to a third party to operate on their behalf; which implies that, 2. An individual should be free to negotiate the terms of their relationships with information service providers.

It is clearly not usually the case that the collection of personal information or other data exchanges between individuals and corporate entities is a negotiation between equals as witnessed by the terms of use and contracts of adhesion that govern most Alice to Bob(company) data exchanges. In the context of single sided dictates of terms P2P systems are not systems of equitable power and control no matter what the form of validation is used.

I like James' characterization of 'dispersed control of the centre'. That is because it does seem to be the case that any audit, monitoring or governance system over multiparty data exchanges has to provide some central reference point (what happened when and in what order). Where the each of n participants in a system has approximately 1/n portion of control, that is as reasonably equitable as can be expected.

Sincerely, John Wunderlich @PrivacyCDN https://twitter.com/PrivacyCDN

Call: +1 (647) 669-4749 eMail: john@wunderlich.ca

On 4 November 2016 at 12:15, James Hazard wrote:

...

My two cents on centralization:

A blockchain is "centralizing." The innovation is that it disperses control of the center. And even though the center is replicated. It is more centralizing than a P2P model, where only the direct parties have a copy of their transactions.

The participants in a P2P system can rely on any form of validation that they deem adequate. That might include conventional systems, such as that they know one another, and can cajole, shame or sue one another. It might include having a "trust provider" - some one whose stake in their reputation is greater than their stake (even indirect) in the transaction. That could be a mutual friend, a congregation (e.g. marriage vows), a trustee, a bank, bank regulator, land recording office, the WayBack machine, Github, or a blockchain.

There does not need to be a universal system that everyone trusts, and perhaps the system would be more robust if there is not a universal system. A patchwork of trust relationships may be better.

There are already some quasi-universal systems of second-hand trust - notably via governments and via banks. The academic, scientific and business communities also have domain-specific quasi-universal systems.

On Fri, Nov 4, 2016 at 7:35 AM, Eve Maler wrote:

...

Awesome thread. I am going to try to net out some assertions and potential conclusions in this thread that we could mark as observations *For The Report* / *Needs More Discussion* (preparatory to including in the report). I would like us all to be thinking in these terms from now on in this DG's lifespan. If you take issue with a For The Report suggestion, we can turn it into a Needs More Discussion agenda item. (I recommend we time-box each one.)

By the way, I can't make the next two weeks' worth of meetings (!), so please stay tuned regarding any impacts on meeting schedule. Thomas and I are coordinating.

- Blockchain vs. DLT: Do we intend to distinguish "blockchain encryption" vs. the aggregation of distributed ledger technology that is typically associated with "blockchain"? To date we've done the latter (and this is what's in the report now, with extensive language), while Jeff is suggesting the former. *Needs More "Discussion"*, but I suggest we should actually take a vote or similar and not spend time arguing. - Netting out Jim's comments about Alice and Bob transactions: Saving transaction records (or pointers to them) on this type of ledger are valuable when preserving *reciprocality* between/among parties in a transaction is desired, and this has salutary effects on evening out the empowerment situation among them. I suggest this is *For The Report*. - Jeff's point that "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." I suggest this is usable as is *For The Report*. - This technology generally is known to have security, privacy, and inefficiency (both at rest = bloat and in motion = mining) concerns generally, which is why we're seeing a design pattern in many cases emerge of storing information in other types of repositories and pointers/hashes on the ledger. Classic identity profile information, however, is written less frequently and read more frequently, as Adrian pointed out. Nonetheless, we still see this design pattern being used (e.g. in Sovrin). I suggest this is *For The Report*. - Jeff's point that "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." Our ongoing conversation about governance models and permissionless/permissioned seems to complicate this a bit, so I suspect that it *Needs More Discussion* to add color. E.g., are controls being added back at technical layers? business layers? both? - (Co-chair's privilege: :-) ) For me, the million-dollar question is: When permissioning of any kind is added back, most often, it comes in a *re-centralizing* form. In what use cases does this harm the original point of the exercise? *Needs More Discussion*.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *The ForgeRock Identity Summit* is coming to http://summits.forgerock.com/ *Paris in November!*

On Fri, Nov 4, 2016 at 7:15 AM, Adrian Gropper wrote:

...

Yes you do need overall standards in the system. That's exactly what Rebooting Web of Trust is doing by standardizing DID and DDO.

Adrian

On Friday, November 4, 2016, Susan wrote:

...

So the minute you agree hard forks can happen in a permissionless system, think DAO, what kind of mechanism exists to keep the actors in check? You need overall standards for the system.

Susan

SheTechPower 914.924.1994

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail, delete and then destroy all copies of the original message.

On Nov 4, 2016, at 10:00 AM, j stollman wrote:

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

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

...

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 > 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 >>>>>>>>>>>>> *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/

_______________________________________________ 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

_______________________________________________ DG-BSC mailing list 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@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

James, I am pleased with your point about centralization: succinct and well stated! 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 Fri, Nov 4, 2016 at 12:15 PM, James Hazard wrote:

My two cents on centralization:

A blockchain is "centralizing." The innovation is that it disperses control of the center. And even though the center is replicated. It is more centralizing than a P2P model, where only the direct parties have a copy of their transactions.

The participants in a P2P system can rely on any form of validation that they deem adequate. That might include conventional systems, such as that they know one another, and can cajole, shame or sue one another. It might include having a "trust provider" - some one whose stake in their reputation is greater than their stake (even indirect) in the transaction. That could be a mutual friend, a congregation (e.g. marriage vows), a trustee, a bank, bank regulator, land recording office, the WayBack machine, Github, or a blockchain.

There does not need to be a universal system that everyone trusts, and perhaps the system would be more robust if there is not a universal system. A patchwork of trust relationships may be better.

There are already some quasi-universal systems of second-hand trust - notably via governments and via banks. The academic, scientific and business communities also have domain-specific quasi-universal systems.

On Fri, Nov 4, 2016 at 7:35 AM, Eve Maler wrote:

...

Awesome thread. I am going to try to net out some assertions and potential conclusions in this thread that we could mark as observations *For The Report* / *Needs More Discussion* (preparatory to including in the report). I would like us all to be thinking in these terms from now on in this DG's lifespan. If you take issue with a For The Report suggestion, we can turn it into a Needs More Discussion agenda item. (I recommend we time-box each one.)

By the way, I can't make the next two weeks' worth of meetings (!), so please stay tuned regarding any impacts on meeting schedule. Thomas and I are coordinating.

- Blockchain vs. DLT: Do we intend to distinguish "blockchain encryption" vs. the aggregation of distributed ledger technology that is typically associated with "blockchain"? To date we've done the latter (and this is what's in the report now, with extensive language), while Jeff is suggesting the former. *Needs More "Discussion"*, but I suggest we should actually take a vote or similar and not spend time arguing. - Netting out Jim's comments about Alice and Bob transactions: Saving transaction records (or pointers to them) on this type of ledger are valuable when preserving *reciprocality* between/among parties in a transaction is desired, and this has salutary effects on evening out the empowerment situation among them. I suggest this is *For The Report*. - Jeff's point that "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." I suggest this is usable as is *For The Report* . - This technology generally is known to have security, privacy, and inefficiency (both at rest = bloat and in motion = mining) concerns generally, which is why we're seeing a design pattern in many cases emerge of storing information in other types of repositories and pointers/hashes on the ledger. Classic identity profile information, however, is written less frequently and read more frequently, as Adrian pointed out. Nonetheless, we still see this design pattern being used (e.g. in Sovrin). I suggest this is *For The Report*. - Jeff's point that "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." Our ongoing conversation about governance models and permissionless/permissioned seems to complicate this a bit, so I suspect that it *Needs More Discussion* to add color. E.g., are controls being added back at technical layers? business layers? both? - (Co-chair's privilege: :-) ) For me, the million-dollar question is: When permissioning of any kind is added back, most often, it comes in a *re-centralizing* form. In what use cases does this harm the original point of the exercise? *Needs More Discussion*.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *The ForgeRock Identity Summit* is coming to http://summits.forgerock.com/ *Paris in November!*

On Fri, Nov 4, 2016 at 7:15 AM, Adrian Gropper wrote:

...

Yes you do need overall standards in the system. That's exactly what Rebooting Web of Trust is doing by standardizing DID and DDO.

Adrian

On Friday, November 4, 2016, Susan wrote:

...

So the minute you agree hard forks can happen in a permissionless system, think DAO, what kind of mechanism exists to keep the actors in check? You need overall standards for the system.

Susan

SheTechPower 914.924.1994

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail, delete and then destroy all copies of the original message.

On Nov 4, 2016, at 10:00 AM, j stollman wrote:

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

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 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 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 >>>>> 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 >>>>>>>>>>>> *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/

_______________________________________________ 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

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

While I am on a tear, I will try to address Eve's issue regarding "distributed control of the center." The issue that we are struggling with is governance: who makes the rules? Some approaches to governance include: 1. single owner/king 2. group ownership/republic 3. communal ownership/democracy Bitcoin opted for this last option. What Bitcoin attempts to do was to create a system in which self-interest was sufficient to govern a global system. The elegance of this approach, in theory, is that there is no single party or small group of parties to be seduced by potential individual gain to act against the best interests of the community. In the case of Bitcoin, the community might be defined as humankind. And the Bitcoin implementation included rewards to those with decision-making capability (miners) to induce them to play within the imagined rules. But Bitcoin blocks are not voted on by the entire community. Rather we have representative democracy similar to the governance of the US. Rather then being elected, the ruling elite invest in technology in order to gain a seat at the table. So far, so good. But over time, there is likelihood that the cost of the specialized expertise required for mining may reduce the number of miners to a number small enough that it will become easy to form a consortium with enough computing power to control the Bitcoin blockchain. This doesn't immediately imply that they will then compromise the system. They may be content just to earn more revenue as miners. But the possibility will be there for them to exploit their power to further enrich themselves beyond their revenue as miners. They may inadvertently get caught up in their power and kill the goose that lays their golden eggs. 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 Fri, Nov 4, 2016 at 3:32 PM, Eve Maler wrote:

I must be missing something about this "distributed control of the center" concept. 1/nth portion of control of something all the stakeholders care about sounds precisely like the definition of decentralization vs. centralization. I just looked it up.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *The ForgeRock Identity Summit* is coming to http://summits.forgerock.com/ *Paris in November!*

On Fri, Nov 4, 2016 at 11:50 AM, j stollman wrote:

...

James,

I am pleased with your point about centralization: succinct and well stated!

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 Fri, Nov 4, 2016 at 12:15 PM, James Hazard wrote:

...

My two cents on centralization:

A blockchain is "centralizing." The innovation is that it disperses control of the center. And even though the center is replicated. It is more centralizing than a P2P model, where only the direct parties have a copy of their transactions.

The participants in a P2P system can rely on any form of validation that they deem adequate. That might include conventional systems, such as that they know one another, and can cajole, shame or sue one another. It might include having a "trust provider" - some one whose stake in their reputation is greater than their stake (even indirect) in the transaction. That could be a mutual friend, a congregation (e.g. marriage vows), a trustee, a bank, bank regulator, land recording office, the WayBack machine, Github, or a blockchain.

There does not need to be a universal system that everyone trusts, and perhaps the system would be more robust if there is not a universal system. A patchwork of trust relationships may be better.

There are already some quasi-universal systems of second-hand trust - notably via governments and via banks. The academic, scientific and business communities also have domain-specific quasi-universal systems.

On Fri, Nov 4, 2016 at 7:35 AM, Eve Maler wrote:

...

Awesome thread. I am going to try to net out some assertions and potential conclusions in this thread that we could mark as observations *For The Report* / *Needs More Discussion* (preparatory to including in the report). I would like us all to be thinking in these terms from now on in this DG's lifespan. If you take issue with a For The Report suggestion, we can turn it into a Needs More Discussion agenda item. (I recommend we time-box each one.)

By the way, I can't make the next two weeks' worth of meetings (!), so please stay tuned regarding any impacts on meeting schedule. Thomas and I are coordinating.

- Blockchain vs. DLT: Do we intend to distinguish "blockchain encryption" vs. the aggregation of distributed ledger technology that is typically associated with "blockchain"? To date we've done the latter (and this is what's in the report now, with extensive language), while Jeff is suggesting the former. *Needs More "Discussion"*, but I suggest we should actually take a vote or similar and not spend time arguing. - Netting out Jim's comments about Alice and Bob transactions: Saving transaction records (or pointers to them) on this type of ledger are valuable when preserving *reciprocality* between/among parties in a transaction is desired, and this has salutary effects on evening out the empowerment situation among them. I suggest this is *For The Report* . - Jeff's point that "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." I suggest this is usable as is *For The Report*. - This technology generally is known to have security, privacy, and inefficiency (both at rest = bloat and in motion = mining) concerns generally, which is why we're seeing a design pattern in many cases emerge of storing information in other types of repositories and pointers/hashes on the ledger. Classic identity profile information, however, is written less frequently and read more frequently, as Adrian pointed out. Nonetheless, we still see this design pattern being used (e.g. in Sovrin). I suggest this is *For The Report*. - Jeff's point that "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." Our ongoing conversation about governance models and permissionless/permissioned seems to complicate this a bit, so I suspect that it *Needs More Discussion* to add color. E.g., are controls being added back at technical layers? business layers? both? - (Co-chair's privilege: :-) ) For me, the million-dollar question is: When permissioning of any kind is added back, most often, it comes in a *re-centralizing* form. In what use cases does this harm the original point of the exercise? *Needs More Discussion*.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *The ForgeRock Identity Summit* is coming to http://summits.forgerock.com/ *Paris in November!*

On Fri, Nov 4, 2016 at 7:15 AM, Adrian Gropper wrote:

...

Yes you do need overall standards in the system. That's exactly what Rebooting Web of Trust is doing by standardizing DID and DDO.

Adrian

On Friday, November 4, 2016, Susan wrote:

...

So the minute you agree hard forks can happen in a permissionless system, think DAO, what kind of mechanism exists to keep the actors in check? You need overall standards for the system.

Susan

SheTechPower 914.924.1994

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail, delete and then destroy all copies of the original message.

On Nov 4, 2016, at 10:00 AM, j stollman wrote:

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

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 >> 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 >>>>>>>>>>>>>> *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/

_______________________________________________ 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

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

To Jeff's 3 legs tear, we don't have to do everything at once, but we should take advantage of new technology as we plan for the future. 1 - OAuth2 is a new technology that has seen broad adoption and is one leg of the stool. UMA doesn't need to offer different granularity to the resources in order to be immensely valuable as an agent. All we need to do is to allow those RSs that choose to respect my choice of AS to have a standard they can use. This is particularly clear when it comes to IoT where having to deal with a separate portal for each Thing in my life is clearly unsustainable. My willingness to install apps, other than for one-time configuration of a new Thing, is more limited than ever. If I'm going to add a Thing to my life, it better not ask me for more than my WiFi password and my UMA AS. Come to think of it, if it would just ask for my UMA AS, maybe it wouldn't need my WiFi password. 2 - Decentralized Identifiers (DID) are a new technology that solves a problem that identity federations clearly have been unable to solve. Combined with widely available biometrics on my phone, tablet, and now my laptop, they offer passwordless login (like ApplePay), improved security, and privacy. I suspect that the cost of managing identity this way is also less since one strong credential, like a driver's license, is better than a dozen weak ones. (Home Depot is perfectly happy for me to leave their credit card at home and simply show them a driver's license to charge my purchases. And they give me a discount to-boot.) It would be irresponsible for UMA to favor federation at the expense of DID. 3 - The third leg is probably Client and RqP interactions. Leg 1 is about gaining agency relative to my RS and their incentives. Leg 2 is about identity and a big improvement for RS, RO, and RqP once it catches on. Leg 3 means that Clients can negotiate access with my UMA AS instead of the RS. This is not a cost to the RS. It may be a cost to the Client because it means that they may be subject to policies that are not entirely uniform for each RS. As we deal with Jeff's point about who bears the cost of introducing UMA, it seems that Clients are the ones we need to help. A client that invests in UMA can compete on the basis of improved privacy and security. To the extent we have leverage as customers, it's a good thing. The next app or thing that hopes I'll install it better start thinking of how they will get UMA to take off. Adrian On Fri, Nov 4, 2016 at 4:05 PM, James Hazard wrote:

By the 1/n definition, representative democracy is decentralized. But of course it is not.

We could all commonly vote on what to have for dinner and then collectively cook it. We could instead do a group potluck. Or we could each pair off and share with a few others. Or we could each bring a lunch box.

Some decision must be common, some are needlessly common. P2P tech could reduce the technical advantages of hubs, reducing needless centralization.

On Fri, Nov 4, 2016 at 12:32 PM, Eve Maler wrote:

...

I must be missing something about this "distributed control of the center" concept. 1/nth portion of control of something all the stakeholders care about sounds precisely like the definition of decentralization vs. centralization. I just looked it up.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *The ForgeRock Identity Summit* is coming to http://summits.forgerock.com/ *Paris in November!*

On Fri, Nov 4, 2016 at 11:50 AM, j stollman wrote:

...

James,

I am pleased with your point about centralization: succinct and well stated!

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 Fri, Nov 4, 2016 at 12:15 PM, James Hazard wrote:

...

My two cents on centralization:

A blockchain is "centralizing." The innovation is that it disperses control of the center. And even though the center is replicated. It is more centralizing than a P2P model, where only the direct parties have a copy of their transactions.

The participants in a P2P system can rely on any form of validation that they deem adequate. That might include conventional systems, such as that they know one another, and can cajole, shame or sue one another. It might include having a "trust provider" - some one whose stake in their reputation is greater than their stake (even indirect) in the transaction. That could be a mutual friend, a congregation (e.g. marriage vows), a trustee, a bank, bank regulator, land recording office, the WayBack machine, Github, or a blockchain.

There does not need to be a universal system that everyone trusts, and perhaps the system would be more robust if there is not a universal system. A patchwork of trust relationships may be better.

There are already some quasi-universal systems of second-hand trust - notably via governments and via banks. The academic, scientific and business communities also have domain-specific quasi-universal systems.

On Fri, Nov 4, 2016 at 7:35 AM, Eve Maler wrote:

...

Awesome thread. I am going to try to net out some assertions and potential conclusions in this thread that we could mark as observations *For The Report* / *Needs More Discussion* (preparatory to including in the report). I would like us all to be thinking in these terms from now on in this DG's lifespan. If you take issue with a For The Report suggestion, we can turn it into a Needs More Discussion agenda item. (I recommend we time-box each one.)

By the way, I can't make the next two weeks' worth of meetings (!), so please stay tuned regarding any impacts on meeting schedule. Thomas and I are coordinating.

- Blockchain vs. DLT: Do we intend to distinguish "blockchain encryption" vs. the aggregation of distributed ledger technology that is typically associated with "blockchain"? To date we've done the latter (and this is what's in the report now, with extensive language), while Jeff is suggesting the former. *Needs More "Discussion"*, but I suggest we should actually take a vote or similar and not spend time arguing. - Netting out Jim's comments about Alice and Bob transactions: Saving transaction records (or pointers to them) on this type of ledger are valuable when preserving *reciprocality* between/among parties in a transaction is desired, and this has salutary effects on evening out the empowerment situation among them. I suggest this is *For The Report*. - Jeff's point that "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." I suggest this is usable as is *For The Report*. - This technology generally is known to have security, privacy, and inefficiency (both at rest = bloat and in motion = mining) concerns generally, which is why we're seeing a design pattern in many cases emerge of storing information in other types of repositories and pointers/hashes on the ledger. Classic identity profile information, however, is written less frequently and read more frequently, as Adrian pointed out. Nonetheless, we still see this design pattern being used (e.g. in Sovrin). I suggest this is *For The Report*. - Jeff's point that "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." Our ongoing conversation about governance models and permissionless/permissioned seems to complicate this a bit, so I suspect that it *Needs More Discussion* to add color. E.g., are controls being added back at technical layers? business layers? both? - (Co-chair's privilege: :-) ) For me, the million-dollar question is: When permissioning of any kind is added back, most often, it comes in a *re-centralizing* form. In what use cases does this harm the original point of the exercise? *Needs More Discussion*.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *The ForgeRock Identity Summit* is coming to http://summits.forgerock.com/ *Paris in November!*

On Fri, Nov 4, 2016 at 7:15 AM, Adrian Gropper

...

wrote:

...

Yes you do need overall standards in the system. That's exactly what Rebooting Web of Trust is doing by standardizing DID and DDO.

Adrian

On Friday, November 4, 2016, Susan wrote:

> So the minute you agree hard forks can happen in a permissionless > system, think DAO, what kind of mechanism exists to keep the actors in > check? You need overall standards for the system. > > Susan > > SheTechPower > 914.924.1994 > > > > This e-mail message, including any attachments, is for the sole use > of the intended recipient(s) and may contain confidential and privileged > information. Any unauthorized review; use, disclosure or distribution is > prohibited. If you are not the intended recipient, please contact the > sender by reply e-mail, delete and then destroy all copies of the original > message. > > On Nov 4, 2016, at 10:00 AM, j stollman > wrote: > > 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 > > > 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 >>> 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/webpayme >>>>>>>>>>>> nts-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 >>>>>>>>>>>>>>> *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/

_______________________________________________ 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

_______________________________________________ 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

-- 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/

A slightly different perspective on John's two points: 1. An individual should be free to assert control over their own information assets. This may be accomplished by them running their own systems or by delegating that control to a third party to operate on their behalf; which implies that, 2. An individual should be free to negotiate the terms of their relationships with information service providers. I appreciate the goal of giving individual consumer better negotiating power. And I am pleased to support technical solutions that can support that end. But I don't see that we are dealing with the entire problem. Rather, we are focused on one aspect of it: the lack of an interface that affords us the granularity to define our own terms, rather than merely accept contracts of adhesion. But this is a systems problem. And solving one leg of the stool is insufficient on its own to support the stool. We create various solutions for this - federation, UMA, etc. - but the Relying Paties (RPs) who we want to accept our custom terms don't show up. And we act surprised. Why aren't they flocking to us. It isn't that they have zero regard for their customers. It is because we have failed to solve the other elements of the systems problem. To the RPs, negotiating with each customer individually would create an operational (and legal) nightmare for them. Just because we can immutably capture the custom terms in a blockchain as a reference doesn't mean that the RPs can deliver what we request. Many can't afford to negotiate separately with each of their millions of customers -- much less to deliver millions of customized offerings. They don't have the manpower. It would cost so much that it would put them out of business. Many business have considered these costs. And their reply to our attempts at negotiation is "take it or leave it" because there is no one else offering anything better to prompt them to change. Eventually enough people coalesce around certain values to become a viable market. This has happened with organic food. Enough people are willing to pay the premium for produce that is "organic." But others, just as desirous of the higher quality food, just can't afford the higher prices. Have we considered the cost impacts of obtaining the customization of BobCo's services that we seem to be seeking? This doesn't mean that a tool such as UMA can't be viable today for a particular subset of interactions in which Alice sets unique terms for the use of her content. In this case, Alice is the RP dictating terms of use of her proprietary information. (Of course, if her information is her credit card transactions, it is not her "property." It's "ownership" is shared with the shop she dealt and with her credit card issuer (at a minimum).) But my ISP provides me and millions of my peers with a wide range of services. They currently lack the infrastructure to customize these services beyond a fixed menu of choices. Slowly, they are becoming more granular. They offer me a choice of packages. But the packages are fixed. Printers now offer "custom" t-shirts with anything we want printed on them. But the selection of t-shirts is still of their choosing. The problem we are trying to solve is similar to the labor issues that arose in the wake of the industrial revolution. Working conditions were dictated by the "bosses." You had a "take it or leave it" choice. But there were lots of people who were upset. In response, the labor union movement evolved. This gave labor enough power to be recognized -- enough power to be able to get a seat at the negotiating table. And conditions improved. But even labor unions could only gain "one-size-fits-all" improvements. And some laborers are frustrated by the dues they pay to their unions because they don't feel that they are getting the particular working conditions they desire. Technology may gradually give us low-cost ways to allow enterprises (commercial and governmental) to address the myriad permutations we desire. But we aren't there yet. 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 Fri, Nov 4, 2016 at 2:50 PM, j stollman wrote:

James,

I am pleased with your point about centralization: succinct and well stated!

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 Fri, Nov 4, 2016 at 12:15 PM, James Hazard wrote:

...

My two cents on centralization:

A blockchain is "centralizing." The innovation is that it disperses control of the center. And even though the center is replicated. It is more centralizing than a P2P model, where only the direct parties have a copy of their transactions.

The participants in a P2P system can rely on any form of validation that they deem adequate. That might include conventional systems, such as that they know one another, and can cajole, shame or sue one another. It might include having a "trust provider" - some one whose stake in their reputation is greater than their stake (even indirect) in the transaction. That could be a mutual friend, a congregation (e.g. marriage vows), a trustee, a bank, bank regulator, land recording office, the WayBack machine, Github, or a blockchain.

There does not need to be a universal system that everyone trusts, and perhaps the system would be more robust if there is not a universal system. A patchwork of trust relationships may be better.

There are already some quasi-universal systems of second-hand trust - notably via governments and via banks. The academic, scientific and business communities also have domain-specific quasi-universal systems.

On Fri, Nov 4, 2016 at 7:35 AM, Eve Maler wrote:

...

Awesome thread. I am going to try to net out some assertions and potential conclusions in this thread that we could mark as observations *For The Report* / *Needs More Discussion* (preparatory to including in the report). I would like us all to be thinking in these terms from now on in this DG's lifespan. If you take issue with a For The Report suggestion, we can turn it into a Needs More Discussion agenda item. (I recommend we time-box each one.)

By the way, I can't make the next two weeks' worth of meetings (!), so please stay tuned regarding any impacts on meeting schedule. Thomas and I are coordinating.

- Blockchain vs. DLT: Do we intend to distinguish "blockchain encryption" vs. the aggregation of distributed ledger technology that is typically associated with "blockchain"? To date we've done the latter (and this is what's in the report now, with extensive language), while Jeff is suggesting the former. *Needs More "Discussion"*, but I suggest we should actually take a vote or similar and not spend time arguing. - Netting out Jim's comments about Alice and Bob transactions: Saving transaction records (or pointers to them) on this type of ledger are valuable when preserving *reciprocality* between/among parties in a transaction is desired, and this has salutary effects on evening out the empowerment situation among them. I suggest this is *For The Report*. - Jeff's point that "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." I suggest this is usable as is *For The Report*. - This technology generally is known to have security, privacy, and inefficiency (both at rest = bloat and in motion = mining) concerns generally, which is why we're seeing a design pattern in many cases emerge of storing information in other types of repositories and pointers/hashes on the ledger. Classic identity profile information, however, is written less frequently and read more frequently, as Adrian pointed out. Nonetheless, we still see this design pattern being used (e.g. in Sovrin). I suggest this is *For The Report*. - Jeff's point that "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." Our ongoing conversation about governance models and permissionless/permissioned seems to complicate this a bit, so I suspect that it *Needs More Discussion* to add color. E.g., are controls being added back at technical layers? business layers? both? - (Co-chair's privilege: :-) ) For me, the million-dollar question is: When permissioning of any kind is added back, most often, it comes in a *re-centralizing* form. In what use cases does this harm the original point of the exercise? *Needs More Discussion*.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *The ForgeRock Identity Summit* is coming to http://summits.forgerock.com/ *Paris in November!*

On Fri, Nov 4, 2016 at 7:15 AM, Adrian Gropper wrote:

...

Yes you do need overall standards in the system. That's exactly what Rebooting Web of Trust is doing by standardizing DID and DDO.

Adrian

On Friday, November 4, 2016, Susan wrote:

...

So the minute you agree hard forks can happen in a permissionless system, think DAO, what kind of mechanism exists to keep the actors in check? You need overall standards for the system.

Susan

SheTechPower 914.924.1994

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail, delete and then destroy all copies of the original message.

On Nov 4, 2016, at 10:00 AM, j stollman wrote:

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

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

...

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 > 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 >>>>>>>>>>>>> *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/

_______________________________________________ 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

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

My take on slicing and dicing is that it can be controlled by allowing Alice to move the data elsewhere and forbid the sharing of data by the RS beyond that. To the extent Alice has the ability to move the data to where there are better slicing and dicing tools, then the RS has some incentive to support the tools itself. It's a pretty binary thing, either Alice can move all the data and shut off other sharing or not. Is this an example of a User Submitted Term? If so, we should give it a name because it's special compared to other terms. Adrian On Monday, November 7, 2016, John Wunderlich wrote:

Jeff;

re: "The problem we are trying to solve is similar to the labor issues that arose in the wake of the industrial revolution. Working conditions were dictated by the "bosses." You had a "take it or leave it" choice. But there were lots of people who were upset. In response, the labor union movement evolved. This gave labor enough power to be recognized -- enough power to be able to get a seat at the negotiating table. And conditions improved. But even labor unions could only gain "one-size-fits-all" improvements. And some laborers are frustrated by the dues they pay to their unions because they don't feel that they are getting the particular working conditions they desire.

Technology may gradually give us low-cost ways to allow enterprises (commercial and governmental) to address the myriad permutations we desire. But we aren't there yet."

The network effect that tends to a leading provider in any given category is similar to the consolidation and reduction of competition that happens in markets. It's also apt that the workers were not customers, but a source of value, where the cost of acquisition and maintenance 'needs' to be minimised. This begs the question, however, of what would be the equivalent organisation to a union organising drive to push back against imposed conditions? It seems that User Submitted Terms might be a potential for that role.

On the question of myriad permutations, that seems to be a red herring, as it is the case that customer or employee data is already sliced and diced in many ways, contingent to attributes assigned to the data. The issue isn't the slicing and dicing, but rather who has the power/authority to determine what attributes will be used for filtering and processing. This flows back to the question of governance. You articulated a tripartite model of governance based on ownership, but it makes more sense to me to use "authority" rather than "ownership" for governance. The key question is "Who, or what role, has the authority to make a decision (or write to the blockchain)".

If we use 'authority', Bob can maintain ownership of records, but can enter into negotiations with Alice about what to delegate/assign authority for Alice to assert control over data relating to her. This may create a fourth category for governance - pairwise authority. But I note that this articulation is not a meaningful one in the absence of either a market or regulatory answer to the network affect that reduces Alice's choice of provider.

This is the background and context for the contribution that I'm writing for the report on User Submitted Terms and Consent Receipts.

JW.

Sincerely, John Wunderlich @PrivacyCDN https://twitter.com/PrivacyCDN

Call: +1 (647) 669-4749 eMail: john@wunderlich.ca javascript:_e(%7B%7D,'cvml','john@wunderlich.ca');

On 4 November 2016 at 15:44, j stollman wrote:

A slightly different perspective on John's two points:

1. An individual should be free to assert control over their own information assets. This may be accomplished by them running their own systems or by delegating that control to a third party to operate on their behalf; which implies that, 2. An individual should be free to negotiate the terms of their relationships with information service providers.

I appreciate the goal of giving individual consumer better negotiating power. And I am pleased to support technical solutions that can support that end. But I don't see that we are dealing with the entire problem. Rather, we are focused on one aspect of it: the lack of an interface that affords us the granularity to define our own terms, rather than merely accept contracts of adhesion.

But this is a systems problem. And solving one leg of the stool is insufficient on its own to support the stool. We create various solutions for this - federation, UMA, etc. - but the Relying Paties (RPs) who we want to accept our custom terms don't show up. And we act surprised. Why aren't they flocking to us. It isn't that they have zero regard for their customers. It is because we have failed to solve the other elements of the systems problem. To the RPs, negotiating with each customer individually would create an operational (and legal) nightmare for them. Just because we can immutably capture the custom terms in a blockchain as a reference doesn't mean that the RPs can deliver what we request. Many can't afford to negotiate separately with each of their millions of customers -- much less to deliver millions of customized offerings. They don't have the manpower. It would cost so much that it would put them out of business.

Many business have considered these costs. And their reply to our attempts at negotiation is "take it or leave it" because there is no one else offering anything better to prompt them to change. Eventually enough people coalesce around certain values to become a viable market. This has happened with organic food. Enough people are willing to pay the premium for produce that is "organic." But others, just as desirous of the higher quality food, just can't afford the higher prices. Have we considered the cost impacts of obtaining the customization of BobCo's services that we seem to be seeking?

This doesn't mean that a tool such as UMA can't be viable today for a particular subset of interactions in which Alice sets unique terms for the use of her content. In this case, Alice is the RP dictating terms of use of her proprietary information. (Of course, if her information is her credit card transactions, it is not her "property." It's "ownership" is shared with the shop she dealt and with her credit card issuer (at a minimum).) But my ISP provides me and millions of my peers with a wide range of services. They currently lack the infrastructure to customize these services beyond a fixed menu of choices. Slowly, they are becoming more granular. They offer me a choice of packages. But the packages are fixed. Printers now offer "custom" t-shirts with anything we want printed on them. But the selection of t-shirts is still of their choosing.

The problem we are trying to solve is similar to the labor issues that arose in the wake of the industrial revolution. Working conditions were dictated by the "bosses." You had a "take it or leave it" choice. But there were lots of people who were upset. In response, the labor union movement evolved. This gave labor enough power to be recognized -- enough power to be able to get a seat at the negotiating table. And conditions improved. But even labor unions could only gain "one-size-fits-all" improvements. And some laborers are frustrated by the dues they pay to their unions because they don't feel that they are getting the particular working conditions they desire.

Technology may gradually give us low-cost ways to allow enterprises (commercial and governmental) to address the myriad permutations we desire. But we aren't there yet.

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 Fri, Nov 4, 2016 at 2:50 PM, j stollman wrote:

James,

I am pleased with your point about centralization: succinct and well stated!

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 Fri, Nov 4, 2016 at 12:15 PM, James Hazard wrote:

My two cents on centralization:

A blockchain is "centralizing." The innovation is that it disperses control of the center. And even though the center is replicated. It is more centralizing than a P2P model, where only the direct parties have a copy of their transactions.

The participants in a P2P system can rely on any form of validation that they deem adequate. That might include conventional systems, such as that they know one another, and can cajole, shame or sue one another. It might include having a "trust provider" - some one whose stake in their reputation is greater than their stake (even indirect) in the transaction. That could be a mutual friend, a congregation (e.g. marriage vows), a trustee, a bank, bank regulator, land recording office, the WayBack machine, Github, or a blockchain.

There does not need to be a universal system that everyone trusts, and perhaps the system would be more robust if there is not a universal system. A patchwork of trust relationships may be better.

There are already some quasi-universal systems of second-hand trust - notably via governments and via banks. The academic, scientific and business communities also have domain-specific quasi-universal systems.

On Fri, Nov 4, 2016 at 7:35 AM, Eve Maler wrote:

Awesome thread. I am going to try to net out some assertions and potential conclusions in this thread that we could mark as observations *For The Report* / *Needs More Discussion* (preparatory to including in the report). I would like us all to be thinking in these terms from now on in this DG's lifespan. If you take issue with a For The Report suggestion, we can turn it into a Needs More Discussion agenda item. (I recommend we time-box each one.)

By the way, I can't make the next two weeks' worth of meetings (!), so please stay tuned regarding any impacts on meeting schedule. Thomas and I are coordinating.

- Blockchain vs. DLT: Do we intend to distinguish "blockchain encryption" vs. the aggregation of distributed ledger technology that is typically associated with "blockchain"? To date we've done the latter (and this is what's in the report now, with extensive language), while Jeff is suggesting the former. *Needs More "Discussion"*, but I suggest we should actually take a vote or similar and not spend time arguing. - Netting out Jim's comments about Alice and Bob transactions: Saving transaction records (or pointers to them) on this type of ledger are valuable when preserving *reciprocality* between/among parties in a transaction is desired, and this has salutary effects on evening out the empowerment situation among them. I suggest this is *For The Report*. - Jeff's point that "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." I suggest this is usable as is *For The Report*. - This technology generally is known to have security, privacy, and inefficiency (both at rest = bloat and in motion = mining) concerns generally, which is why we're seeing a design pattern in many cases emerge of storing information in other types of repositories and pointers/hashes on the ledger. Classic identity profile information, however, is written less frequently and read more frequently, as Adrian pointed out. Nonetheless, we still see this design pattern being used (e.g. in Sovrin). I suggest this is *For The Report*. - Jeff's point that "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." Our ongoing conversation about governance models and permissionless/permissioned seems to complicate this a bit, so I suspect that it *Needs More Discussion* to add color. E.g., are controls being added back at technical layers? business layers? both? - (Co-chair's privilege: :-) ) For me, the million-dollar question is: When permissioning of any kind is added back, most often, it comes in a *re-centralizing* form. In what use cases does this harm the original point of the exercise? *Needs More Discussion*.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *The ForgeRock Identity Summit* is coming to http://summits.forgerock.com/ *Paris in November!*

On Fri, Nov 4, 2016 at 7:15 AM, Adrian Gropper wrote:

Yes you do need overall standards in the system. That's exactly what Rebooting Web of Trust is doing by standardizing DID and DDO.

Adrian

On Friday, November 4, 2016, Susan wrote:

So the minute you agree hard forks can happen in a permissionless system, think DAO, what kind of mechanism exists to keep the actors in check? You need overall standards for the system.

Susan

SheTechPower 914.924.1994

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail, delete and then destroy all copies of the original message.

On Nov 4, 2016, at 10:00 AM, j stollman wrote:

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

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 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 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

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 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 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 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 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 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 | 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 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 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-blockchain-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 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 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 | 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 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 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 *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

-- 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/

Thank you so much for that DID link to what may be the longest Wikipedia page I have ever visited. As a physician, I am now concerned that my suggestion of DID in our workgroup is merely, as they explain, iatrogenic. The article also points out a rather poor prognosis for DID. A On Friday, November 4, 2016, Thorsten H. Niebuhr [WedaCon GmbH] < tniebuhr@wedacon.net> wrote:

Yes, it comes down again to 'who to trust'. Ultimately, the only one someone trusts by 100% is 'me, myself, and I', given I am not suffering from 'Dissociate Identity Disorder'[1] while realizing that I am. Complicated, especially as this is also abbreviated with 'DID'.....

Anyway, the question is : who/what can be trusted to be in charge of controlling the ledger (give permissions to write)? A pre-requisite could be that 'no one owns it' and there is no 'commercial' benefit, which could be solved by non-profit organizations (the same way the 'internet' is managed).

The model Sovrin has chosen for that is an example.

T.

[1] https://en.wikipedia.org/wiki/Dissociative_identity_disorder

On 04.11.2016 15:15, Adrian Gropper wrote:

Yes you do need overall standards in the system. That's exactly what Rebooting Web of Trust is doing by standardizing DID and DDO.

Adrian

On Friday, November 4, 2016, Susan javascript:_e(%7B%7D,'cvml','susan.joseph1786@gmail.com');> wrote:

...

So the minute you agree hard forks can happen in a permissionless system, think DAO, what kind of mechanism exists to keep the actors in check? You need overall standards for the system.

Susan

SheTechPower 914.924.1994

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review; use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail, delete and then destroy all copies of the original message.

On Nov 4, 2016, at 10:00 AM, j stollman wrote:

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

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 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 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

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

...

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 >>> 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 >>>>>>>>> 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 >>>>>>>>>> *Sent:* >>>>>>>>>> >>>>>>>>>

-- 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/