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 10:42 AM, j stollman <stollman.j@gmail.com> wrote:
James,

I am not certain what you mean by "first-class copy", but I think it might be wiser to to leave the record in situ wherever it was generated and merely provide the user with a "permanent" pointer to the record.  

For example, if the claim is that Alice is creditworthy because she paid BobCorp on time for a widget shipped in advance BobCorp might hold the transaction in its CRM system.  But if Alice could have some permanent link  to (or ID for) that claim that she could pass on to Claire to obtain credit to buy a wazzit from her, that is all she really needs.  In fact, if when Claire exercises the link she is made aware that the claim is located on BobCorp's site, it should enhance the perceived integrity of the claim.

The link/ID that Alice provides to Claire might need to include not only the transaction ID but some signature from Alice proving that Alice authorized Claire to view the claim.

Claire's claim transaction would require that BobCorp provide an interface for Claire to input Alice's link to view the claim.  In the interest of privacy it might also limit the claim to a TRUE of FALSE acknowledgement of an assertion by Alice:  i.e., On 5 OCT 2015 Alice purchased a product or service from BobCorp valued at $US123 on credit and timely paid for it.  This would prevent 

Alternately, the claim could be stored in a blockchain which would provide a permanent storage of the claim (in case BobCorp goes out of business) and a single interface to all such claims.  It would also require that both Alice and BobCorp consent to storing their transactions on the blockchain.  This is not a small assumption, but VISA pulled off something of similar scale forty years ago, so it is not inconceivable.  One big difference is that VISA data is closely held.  The blockchain is presumed to be a decentralized system without ownership.  This makes it even harder to implement.

Jeff




---------------------------------
Jeff Stollman
+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 12:41 PM, 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-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. 


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 | Skype: xmlgrrl | Twitter: @xmlgrrl
The ForgeRock Identity Summit is coming to Paris in November!


On Tue, Aug 30, 2016 at 2:06 PM, Adrian Gropper <agropper@healthurl.com> wrote:
We should also consider the place of protocols that support decentralization without neccessarily being either blockchain or smart contracts. For example, W3C Verifiable Claims https://w3c.github.io/webpayments-ig/VCTF/use-cases/ seems to solve a major privacy and centralization problem by enabling triple-blind interactions.

Adrian


On Tuesday, August 30, 2016, Scott L. David <sldavid@uw.edu> wrote:
Jeff - I heartily agree with all the points you raise.

Kind regards,
Scott

Scott L. David

Director of Policy
Center for Information Assurance and Cybersecurity
University of Washington - Applied Physics Laboratory

Principal Consulting Analyst
TechVision Research

w- 206-897-1466
m- 206-715-0859
Tw - @ScottLDavid

From: j stollman <stollman.j@gmail.com>
Sent: Tuesday, August 30, 2016 10:15:27 AM
To: Scott L. David
Cc: Eve Maler; dg-bsc@kantarainitiative.org
Subject: Re: [DG-BSC] Agenda for BSC telecon Tuesday, August 30 (shortly -- sorry for the late note!)
 
Scott,

Excellent survey.

I would like to further emphasize one of the corollary points you raise:  Perhaps we shouldn't be looking for a distributed organizational "structure" at all.  Instead, we might consider what organizational "processes" would serve the interests involved, and then allow the organizational structure to reveal itself based on the observation and reification of the patterns that emerge from those processes.

In my observations people move rapidly from trying to describe a new solution to using their description to prescribe its use.  Over two years of focus on blockchain technology, I have noticed that it is common for people to recognize that a particular instance of blockchain solves a particular problem and to then falsely conclude that the features of that instantiation are necessary to achieve the same end in other contexts.  For example, we give a lot of lip service to the fact that popular blockchain instances use a distributed model in which the blockchain itself is replicated in numerous locations and the block verification process is also distributed among a large group of "miners."  This has been followed by the conclusion that all blockchains are necessarily distributed for both data integrity and verification integrity.  (In fact many people now refer to blockchain technology as "Distributed Ledger Technology" (DLT)).   I suggest that this causes an unnecessary narrowing of our thinking by casting out other alternatives before they are even considered.

In the example, I would suggest that distributed data does provide higher levels of information assurance by removing a single point of failure that a nefarious hacker could modify.  And this is likely true for any instantiation of a data structure -- whether or not it is a blockchain -- as long as the consensus mechanism for determining which data set is the correct one when discrepancies are found is robust.  But, depending on the risk of such hacks, it may not be cost-effective to use this information assurance technique.  As long as the underlying data structure uses blockchain encryption, I would still consider it a blockchain application.

I also agree that distributed miners afford some ability to reduce collusion in systems where there is an incentive to collude.  But not all transaction systems have such an incentive.  And I don't think that mining whether using proof of work or proof of stake is either cost-effective or necessary.  

We all agree that standardization can create great benefits.  But standardizing too early can stifle innovation or raise the cost of better solutions to the point of making them no longer viable.

In view of the many directions that our blockchain DG discussions continue to splinter off, I hope that this comment offers some value.

Jeff


---------------------------------
Jeff Stollman
+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-Tuesday,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, web interface, more info, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar for our full meeting schedule. Previous meeting minutes are here: July.

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

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





--
@commonaccord