[DG-BSC] Ann Vroom Followup toBSC telecon Thursday August 25 2016
james.g.hazard at gmail.com
Fri Aug 26 19:23:05 CDT 2016
Sure, a visualization is very helpful. The steps are meant to correspond
to those in your diagram.
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.
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
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?
On Fri, Aug 26, 2016 at 5:35 PM, M AV <av_m at hotmail.com> 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 at gmail.com> wrote:
> 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.
> On Thu, Aug 25, 2016 at 4:14 PM, M AV <av_m at hotmail.com> wrote:
>> It’s one .jpeg you should be able to cut and paste from the email …
>> *From:* James Hazard [mailto:james.g.hazard at gmail.com]
>> *Sent:* Thursday, August 25, 2016 4:13 PM
>> *To:* M AV <av_m at hotmail.com>
>> *Cc:* Eve Maler <eve.maler at forgerock.com>; dg-bsc at 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 <av_m at hotmail.com> 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 at kantarainitiative.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 57216 bytes
Desc: not available
More information about the DG-BSC