Hi, Here is a first, rough sketch. There are five steps in the transaction. It is structured to anticipate additional requests and grants. 05-AliceGrants, is the last link in the chain and gives an overview of the steps. You could click on it, then on "Document". Note that a few nuances have been captured, such as the request being more limited in scope than the full data. The general principle is that each step in a transaction that needs to be persisted is documented as a record. The record states particulars and references its context, including the prior step. In a production system, each record can be stored under a friendly name, like this, or under a hash. Records can be stored in a file system versioned with git, like this, or in a database such as IPFS or a blockchain, as needed. http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/DG-BSC/Consent/Use1/ On Thu, Aug 25, 2016 at 4:14 PM, M AV wrote:

It’s one .jpeg you should be able to cut and paste from the email …

*From:* James Hazard [mailto:james.g.hazard@gmail.com] *Sent:* Thursday, August 25, 2016 4:13 PM *To:* M AV *Cc:* Eve Maler ; dg-bsc@kantarainitiative.org *Subject:* Re: [DG-BSC] Ann Vroom Followup toBSC telecon Thursday August 25 2016

Excellent! I'll do a minimal sketch of this flow.

On Thu, Aug 25, 2016 at 4:02 PM, M AV wrote:

Hi – in reference to this afternoon’s conf call, here’s my super-simplified version of the flow I described:

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

--

@commonaccord

-- @commonaccord

Hi Ann, Sure, a visualization is very helpful. The steps are meant to correspond to those in your diagram. Jeff, Agreed, the records are independent of the database in which they are stored, and from the "punctuation" (Eve's word) - e.g. this plain text version, JSON, XML or whatever representation of the key/values. I expect that they would usually be used with a conventional database and not a blockchain. In most settings, a blockchain would be unneeded and would create issues of data privacy similar to those that made R3 chose a non-blockchain model for Corda. Jim _________

From Jeff

All, It's been said that when you are keeping you head and everyone around you is losing theirs, maybe you don't understand the situation. So I'll allow that, perhaps, I am guilty of missing something important here. I see this consent as an excellent demonstration of an UMA application, but I fail to understand the benefits of using blockchain. Any database could track the consents. And an SQL database could perform queries much faster and cheaper. The only justification I can imagine for using blockchain would be if you could not find a trustworthy owner for the database. In this instance, using a public blockchain would remove the fear that the database owner might be unscrupulous and try to modify the data to some advantage. Other than that, I don't know why it would be beneficial to engage a blockchain network to perform this simple record keeping. So what am I missing? Thank you. Jeff On Fri, Aug 26, 2016 at 5:35 PM, M AV wrote:

Hi James! Looks like you've done a major translation of my little flow cartoon such that, to be honest, I can't quite wrap my head around all the nuanced layering of your schema -

... but maybe the two together is an approach of pitching the use case scenario - the cartoon kind of thing for dunces like me so as to be able to keep in view a fundamental mental model of the process Lego blocks - and then the detailed build schema for folks like yourself that can do the deep details dives ...

Best! Ann vroom

Get Outlook for Android https://aka.ms/ghei36

On Thu, Aug 25, 2016 at 7:27 PM -0400, "James Hazard" < james.g.hazard@gmail.com> wrote:

Hi,

Here is a first, rough sketch. There are five steps in the transaction. It is structured to anticipate additional requests and grants. 05-AliceGrants, is the last link in the chain and gives an overview of the steps. You could click on it, then on "Document". Note that a few nuances have been captured, such as the request being more limited in scope than the full data.

The general principle is that each step in a transaction that needs to be persisted is documented as a record. The record states particulars and references its context, including the prior step.

In a production system, each record can be stored under a friendly name, like this, or under a hash. Records can be stored in a file system versioned with git, like this, or in a database such as IPFS or a blockchain, as needed.

http://www.commonaccord.org/index.php?action=list&file=GH/Ka ntaraInitiative/DG-BSC/Consent/Use1/

On Thu, Aug 25, 2016 at 4:14 PM, M AV wrote:

...

It’s one .jpeg you should be able to cut and paste from the email …

*From:* James Hazard [mailto:james.g.hazard@gmail.com] *Sent:* Thursday, August 25, 2016 4:13 PM *To:* M AV *Cc:* Eve Maler ; dg-bsc@kantarainitiative.org *Subject:* Re: [DG-BSC] Ann Vroom Followup toBSC telecon Thursday August 25 2016

Excellent! I'll do a minimal sketch of this flow.

On Thu, Aug 25, 2016 at 4:02 PM, M AV wrote:

Hi – in reference to this afternoon’s conf call, here’s my super-simplified version of the flow I described:

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

--

@commonaccord

-- @commonaccord

-- @commonaccord