- DG-BSC - mailman.kantarainitiative.org

Re: [DG-BSC] BSC and Identity Relationship Management
by James Hazard 18 Jul '16

18 Jul '16

John, Great. The "on paper" part is where we think an object model for text can help. I have only browsed the materials you pointed me to, but I see resemblance to some documents and transaction steps that I sketched for Adrian Gropper. http://www.commonaccord.org/index.php?action=list&file=GHx/KantaraInitiativ… This kind of text framing would let the participants use standards (in the demo, via NY Presbyterian and PPR) and focus on the specifics, which could include granular permissions and interactions. Jim On Mon, Jul 18, 2016 at 11:05 AM, John Moehrke <johnmoehrke(a)gmail.com> wrote: > Hi James, > > We are working on the kind of documentation you are asking for. We have > some of it, just not well organized for an outside reader. There are > examples on that page, mostly fabricated samples. > > There are some examples of consent documents used in healthcare today on > our wiki > http://wiki.hl7.org/index.php?title=Consent_Directive_Examples > > We expect that the actual legal act of consent will be documented in a > classic way on paper; or in some other modern way. The FHIR Consent is not > trying to encode everything, just that which is needed for access control > enforcement. So much of the legal background of the act of consent is not > split out. We provide the "source" element would simply hold the evidence. > So if it is captured on paper, this "source" element might hold a scanned > image of that. If a dispute arose then these source would be used to > address the details of the act of consent. > > John > > John Moehrke > Principal Engineering Architect: Standards - Interoperability, Privacy, > and Security > CyberPrivacy – Enabling authorized communications while respecting Privacy > M +1 920-564-2067 > JohnMoehrke(a)gmail.com > https://www.linkedin.com/in/johnmoehrke > https://healthcaresecprivacy.blogspot.com > "Quis custodiet ipsos custodes?" ("Who watches the watchers?") > > On Mon, Jul 18, 2016 at 9:48 AM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > >> I'm not nearly done digesting, but http://hl7-fhir.github.io/consent.html indeed >> looks very interesting. The rubric of Who, What, When ... seems a helpful >> way to organizing objects. I've experimented with document organization >> that is quite similar. >> >> Would anyone be able to point me to examples of documents used in this >> ecosystem? E.g., consents from patients, agreements between organizations, >> etc., that are the legal support for these. To what extent do they reflect >> the specifics of the assumed consents? The ones I have seen paint very >> broadly. >> >> >> On Sun, Jul 17, 2016 at 4:20 PM, John Moehrke <johnmoehrke(a)gmail.com> >> wrote: >> >>> I hoped so, but waned to assure we were communicating. >>> >>> I am actively working within a Healthcare standards organization (HL7) >>> to develop a standard for capturing the details of a Privacy Consent. >>> http://hl7-fhir.github.io/consent.html >>> >>> I am co-chair of their security workgroup, and one of the leads on this >>> effort. >>> >>> John >>> >>> John Moehrke >>> Principal Engineering Architect: Standards - Interoperability, Privacy, >>> and Security >>> CyberPrivacy – Enabling authorized communications while respecting >>> Privacy >>> M +1 920-564-2067 >>> JohnMoehrke(a)gmail.com >>> https://www.linkedin.com/in/johnmoehrke >>> https://healthcaresecprivacy.blogspot.com >>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?") >>> >>> On Sun, Jul 17, 2016 at 3:03 PM, James Hazard <james.g.hazard(a)gmail.com> >>> wrote: >>> >>>> John, >>>> >>>> Thanks. I took a look at your blog posts and see there is a lot to >>>> this subject area. >>>> >>>> Yes, I understand that the type of record is orthogonal to its >>>> sensitivity. A kind of information can be very sensitive in one >>>> circumstance and not sensitive at all in another. >>>> >>>> I'm trying to tease apart the notion of >>>> things-that-might-be-confidential, operating on the assumption that the >>>> taxonomy must include nearly all kinds of records, conversations, >>>> observations and things. >>>> >>>> I'm approaching this from the perspective of agreements for >>>> non-disclosure, data transfer, services and the like, which can cover a >>>> broad range of subjects. To be really effective, they have to get to the >>>> same level of specificity as the underlying engagements with third-parties, >>>> including data subjects. >>>> >>>> We (lawyers) tend to paint with broad brushes, e.g.: >>>> >>>> >>>> http://source.commonaccord.org/index.php?action=doc&file=Wx/com/cooleygo/US… >>>> or >>>> >>>> http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhea… >>>> >>>> The thought is that overly permissive and overly restrictive practices >>>> could be reduced by shared taxonomies, with a gain in legal certainty and >>>> ability to extend the benefit to the data subjects. >>>> >>>> Eager for more. >>>> >>>> Jim >>>> >>>> >>>> >>>> See my blog article >>>> >>>> On Sun, Jul 17, 2016 at 3:08 PM, John Moehrke <johnmoehrke(a)gmail.com> >>>> wrote: >>>> >>>>> Jim, >>>>> >>>>> Be careful and aware that the way that Healthcare data are organized >>>>> is by medical classification; and has very little to do with how sensitive >>>>> the data are. Meaning the structure and organization is for the benefit of >>>>> the healthcare treatment purpose, where few restrictions exist. This is why >>>>> we have security-tags, so that we can analyze the content of an object >>>>> looking for sensitive topics, from that discovery we tag the data. It is >>>>> this tag that is used in access control and audit logging; not the type of >>>>> data. For any object type it could be determined that the data are not >>>>> sensitive, or are highly sensitive. >>>>> >>>>> The other problem we have is that the data are about people, and those >>>>> people have opinions on what they themselves consider sensitive. >>>>> >>>>> In fact we (security and privacy experts in healthcare) tend to stay >>>>> out of the business of 'determining' how sensitive data are. We prefer to >>>>> leverage a service that does this for us. This service leverages all the >>>>> power of "clinical decision support' -- think about IBM Watson class >>>>> service. This service understands the current state of healthcare >>>>> knowledge, and thus it can better determine that an object that has a >>>>> medication is currently being prescribed for a condition that is currently >>>>> considered sensitive. >>>>> >>>>> See my blog article >>>>> >>>>> https://healthcaresecprivacy.blogspot.com/2014/01/recirculation-ballot-of-h… >>>>> or >>>>> >>>>> https://healthcaresecprivacy.blogspot.com/2015/07/how-to-set-confidentialit… >>>>> >>>>> I do need to write a new article on this topic as I am getting much >>>>> interest. I welcome the interest. >>>>> >>>>> John >>>>> >>>>> John Moehrke >>>>> Principal Engineering Architect: Standards - Interoperability, >>>>> Privacy, and Security >>>>> CyberPrivacy – Enabling authorized communications while respecting >>>>> Privacy >>>>> M +1 920-564-2067 >>>>> JohnMoehrke(a)gmail.com >>>>> https://www.linkedin.com/in/johnmoehrke >>>>> https://healthcaresecprivacy.blogspot.com >>>>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?") >>>>> >>>>> On Sun, Jul 17, 2016 at 1:36 PM, James Hazard < >>>>> james.g.hazard(a)gmail.com> wrote: >>>>> >>>>>> John, >>>>>> >>>>>> Thanks very much. ConfidentialityClassifications maps to what I (we >>>>>> lawyers?) think of as degree-of-care, access, disclosure. From that I >>>>>> found massive list of kinds of records - >>>>>> http://hl7-fhir.github.io/valueset-doc-typecodes.html. This is both >>>>>> i) just the kind of thing I need and ii) overwhelming. A huge itemization, >>>>>> it reflects format and subject matter in a way that I presume corresponds >>>>>> well to how the people involved think about the records, rather than the >>>>>> kind of abstract categories that tend to get including in legal documents. >>>>>> >>>>>> This is terrific. I'll play with the TypeCodes, and think about the >>>>>> ConfidentialityClassifications. >>>>>> >>>>>> Eager for more such. >>>>>> >>>>>> Jim >>>>>> >>>>>> On Sun, Jul 17, 2016 at 2:11 PM, John Moehrke <johnmoehrke(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi James, >>>>>>> >>>>>>> Here is the vocabulary in Healthcare. Some of it is well organized, >>>>>>> most of it is (the sensitivity tags) are a bag of anything people have >>>>>>> found useful as sensitivity topics. >>>>>>> >>>>>>> http://hl7-fhir.github.io/security-labels.html >>>>>>> >>>>>>> The link is to the current specification for HL7 FHIR; a new effort >>>>>>> to leverage general IT http RESTful concept. But the vocabulary is broadly >>>>>>> used in historic protocols as well. >>>>>>> >>>>>>> >>>>>>> John >>>>>>> >>>>>>> John Moehrke >>>>>>> Principal Engineering Architect: Standards - Interoperability, >>>>>>> Privacy, and Security >>>>>>> CyberPrivacy – Enabling authorized communications while respecting >>>>>>> Privacy >>>>>>> M +1 920-564-2067 >>>>>>> JohnMoehrke(a)gmail.com >>>>>>> https://www.linkedin.com/in/johnmoehrke >>>>>>> https://healthcaresecprivacy.blogspot.com >>>>>>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?") >>>>>>> >>>>>>> On Sun, Jul 17, 2016 at 12:03 PM, James Hazard < >>>>>>> james.g.hazard(a)gmail.com> wrote: >>>>>>> >>>>>>>> Very interested in following the discussion on the connections with >>>>>>>> IRM. >>>>>>>> >>>>>>>> Separately, can anyone point me to work on taxonomies of >>>>>>>> confidential information? >>>>>>>> >>>>>>>> Ideally, this taxonomy would be broad - for instance anything that >>>>>>>> might be specified in a non-disclosure agreement. But domain-specific is >>>>>>>> also interesting, e.g. kinds of medical information, kinds of business >>>>>>>> info, kinds of know-how and tech, etc. >>>>>>>> I am working on a taxonomy for "included" or "excluded" >>>>>>>> confidential information under a templated NDA, and it would be nice to be >>>>>>>> more systematic in teasing out the different types than we lawyers usually >>>>>>>> are. This taxonomy will intersect with the patient data taxonomy for a >>>>>>>> model consent. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 14, 2016 at 12:25 PM, Thomas Hardjono <hardjono(a)mit.edu >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> +1 . >>>>>>>>> >>>>>>>>> Thorsten, could we have you describe some of this work at the >>>>>>>>> BSC-DG call (next week, say). >>>>>>>>> >>>>>>>>> /thomas/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ________________________________________ >>>>>>>>> From: dg-bsc-bounces(a)kantarainitiative.org [ >>>>>>>>> dg-bsc-bounces(a)kantarainitiative.org] on behalf of Scott Shorter [ >>>>>>>>> sshorter(a)kimbleassociates.com] >>>>>>>>> Sent: Thursday, July 14, 2016 11:51 AM >>>>>>>>> To: Eve Maler >>>>>>>>> Cc: Thorsten H. Niebuhr [WedaCon GmbH]; >>>>>>>>> dg-bsc(a)kantarainitiative.org >>>>>>>>> Subject: Re: [DG-BSC] BSC and Identity Relationship Management >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> +1 to what Eve said. I’ll feed the contents of the “potential >>>>>>>>> links” column into the “potential use cases” hopper. >>>>>>>>> >>>>>>>>> Thanks Thorsten! >>>>>>>>> - >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> Scott Shorter - Vice President, Security >>>>>>>>> sshorter(a)kimbleassociates.com<mailto:sshorter@kimbleassociates.com >>>>>>>>> > >>>>>>>>> >>>>>>>>> On Jul 12, 2016, at 11:27 AM, Eve Maler <eve.maler(a)forgerock.com >>>>>>>>> <mailto:eve.maler@forgerock.com>> wrote: >>>>>>>>> >>>>>>>>> Hi Thorsten-- Apologies for a belated response to this. I've >>>>>>>>> revised the subject line to be sure it catches people's attention. >>>>>>>>> >>>>>>>>> This is a great analysis. I wonder if, as our use cases shape up, >>>>>>>>> we could seek explicit input/review from your group, and also leverage the >>>>>>>>> analysis in our final deliverable... >>>>>>>>> >>>>>>>>> >>>>>>>>> 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/> Sydney, London, and Paris! >>>>>>>>> >>>>>>>>> On Tue, Jul 12, 2016 at 5:30 AM, Thorsten H. Niebuhr [WedaCon >>>>>>>>> GmbH] <tniebuhr(a)wedacon.net<mailto:tniebuhr@wedacon.net>> wrote: >>>>>>>>> Hi @all >>>>>>>>> >>>>>>>>> dont know if I manage to take part of the call. >>>>>>>>> >>>>>>>>> Anyway: As already mentioned, I joined the DG because of the >>>>>>>>> potential links between the BC/SC Topic and what we currently discuss in >>>>>>>>> the WG-IRM (Identity Relationship Management). Here is a quick summary on >>>>>>>>> the principles we are working on right now in that space and where BC/SC >>>>>>>>> might play a role/ could help (from my pov). >>>>>>>>> >>>>>>>>> For more on the IRM-WG, see < >>>>>>>>> https://kantarainitiative.org/confluence/display/irm/Home> >>>>>>>>> https://kantarainitiative.org/confluence/display/irm/Home >>>>>>>>> >>>>>>>>> Principle Description Potential link into BC/SC >>>>>>>>> Link strength >>>>>>>>> Scalable IRM aware systems must be able to scale into >>>>>>>>> billions (internet of things) BC/SC are not centralized light >>>>>>>>> Actionable A relationship must be able to 'do' something, or >>>>>>>>> better: be able to transport the authorization to do something. could >>>>>>>>> use BC/SC data, but no real benefit here light >>>>>>>>> Immutable A relationship can be immutable (this thing was >>>>>>>>> made by...) This is definitly somehing where BC could help medium >>>>>>>>> Contextual A relationship must allow to be seen in a specific >>>>>>>>> 'context' (time, place, predecessor, post...) >>>>>>>>> >>>>>>>>> could use BC/SC data, but no real benefit here >>>>>>>>> light >>>>>>>>> >>>>>>>>> Transferable A relationship can be transfered, permanently or >>>>>>>>> temporary >>>>>>>>> >>>>>>>>> This is definitly somehing where BC could help >>>>>>>>> medium >>>>>>>>> >>>>>>>>> Provable relationships are provable, either by single, >>>>>>>>> multi or third parties. This is definitly somehing where BC could help >>>>>>>>> strong >>>>>>>>> Acknowledgable a relationship between two or more must be able to >>>>>>>>> be acknowledged (single ack, bi-directional, majority,...) This is >>>>>>>>> definitly somehing where BC could help strong >>>>>>>>> Revocable A relationship can be revoked (linked to >>>>>>>>> accknowledge), right to be forgotten challenging. BC/CS could help on one >>>>>>>>> side, but right to be forgotten is not among them.... medium >>>>>>>>> Constrainable any relationship can be granted, revoked, build >>>>>>>>> based on constraints (eg laws) This is definitly somehing where BC could >>>>>>>>> help medium >>>>>>>>> >>>>>>>>> cu later >>>>>>>>> >>>>>>>>> Thorsten H. Niebuhr >>>>>>>>> tniebuhr(a)wedacon.net / tniebuhr(a)wedacon.de<mailto: >>>>>>>>> tniebuhr(a)wedacon.net> >>>>>>>>> >>>>>>>>> WedaCon Informationstechnologien GmbH >>>>>>>>> Office: +49 (251) 399 678-22<tel:%2B49%20%28251%29%20399%20678-22> >>>>>>>>> Fax: +49 (251) 399 678-50<tel:%2B49%20%28251%29%20399%20678-50> >>>>>>>>> Mobile: +49 (174) 991 257 4<tel:%2B49%20%28174%29%20991%20257%204> >>>>>>>>> Kroegerweg 29 D-48155 Muenster >>>>>>>>> http://www.wedacon.net<http://www.wedacon.net/> >>>>>>>>> >>>>>>>>> Amtsgericht Muenster HRB 6115 >>>>>>>>> USt.-ID: DE216758544 >>>>>>>>> StNr.: 336/5775/1487 >>>>>>>>> Geschaeftsfuehrender Gesellschafter: Thorsten H. Niebuhr >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 07.07.2016 17:27, Eve Maler wrote: >>>>>>>>> (end of message) >>>>>>>>> >>>>>>>>> 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/> Sydney, London, and Paris! >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> DG-BCC mailing list >>>>>>>>> DG-BCC(a)kantarainitiative.org<mailto:DG-BCC@kantarainitiative.org> >>>>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-BCc >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> DG-BSC mailing list >>>>>>>>> DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> >>>>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>>>>>> _______________________________________________ >>>>>>>>> DG-BSC mailing list >>>>>>>>> DG-BSC(a)kantarainitiative.org >>>>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> @commonaccord >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> DG-BSC mailing list >>>>>>>> DG-BSC(a)kantarainitiative.org >>>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> @commonaccord >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> @commonaccord >>>> >>> >>> >> >> >> -- >> @commonaccord >> > > -- @commonaccord

1 0

Re: [DG-BSC] BSC and Identity Relationship Management
by James Hazard 18 Jul '16

18 Jul '16

I'm not nearly done digesting, but http://hl7-fhir.github.io/consent.html indeed looks very interesting. The rubric of Who, What, When ... seems a helpful way to organizing objects. I've experimented with document organization that is quite similar. Would anyone be able to point me to examples of documents used in this ecosystem? E.g., consents from patients, agreements between organizations, etc., that are the legal support for these. To what extent do they reflect the specifics of the assumed consents? The ones I have seen paint very broadly. On Sun, Jul 17, 2016 at 4:20 PM, John Moehrke <johnmoehrke(a)gmail.com> wrote: > I hoped so, but waned to assure we were communicating. > > I am actively working within a Healthcare standards organization (HL7) to > develop a standard for capturing the details of a Privacy Consent. > http://hl7-fhir.github.io/consent.html > > I am co-chair of their security workgroup, and one of the leads on this > effort. > > John > > John Moehrke > Principal Engineering Architect: Standards - Interoperability, Privacy, > and Security > CyberPrivacy – Enabling authorized communications while respecting Privacy > M +1 920-564-2067 > JohnMoehrke(a)gmail.com > https://www.linkedin.com/in/johnmoehrke > https://healthcaresecprivacy.blogspot.com > "Quis custodiet ipsos custodes?" ("Who watches the watchers?") > > On Sun, Jul 17, 2016 at 3:03 PM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > >> John, >> >> Thanks. I took a look at your blog posts and see there is a lot to this >> subject area. >> >> Yes, I understand that the type of record is orthogonal to its >> sensitivity. A kind of information can be very sensitive in one >> circumstance and not sensitive at all in another. >> >> I'm trying to tease apart the notion of >> things-that-might-be-confidential, operating on the assumption that the >> taxonomy must include nearly all kinds of records, conversations, >> observations and things. >> >> I'm approaching this from the perspective of agreements for >> non-disclosure, data transfer, services and the like, which can cover a >> broad range of subjects. To be really effective, they have to get to the >> same level of specificity as the underlying engagements with third-parties, >> including data subjects. >> >> We (lawyers) tend to paint with broad brushes, e.g.: >> >> >> http://source.commonaccord.org/index.php?action=doc&file=Wx/com/cooleygo/US… >> or >> >> http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhea… >> >> The thought is that overly permissive and overly restrictive practices >> could be reduced by shared taxonomies, with a gain in legal certainty and >> ability to extend the benefit to the data subjects. >> >> Eager for more. >> >> Jim >> >> >> >> See my blog article >> >> On Sun, Jul 17, 2016 at 3:08 PM, John Moehrke <johnmoehrke(a)gmail.com> >> wrote: >> >>> Jim, >>> >>> Be careful and aware that the way that Healthcare data are organized is >>> by medical classification; and has very little to do with how sensitive the >>> data are. Meaning the structure and organization is for the benefit of the >>> healthcare treatment purpose, where few restrictions exist. This is why we >>> have security-tags, so that we can analyze the content of an object looking >>> for sensitive topics, from that discovery we tag the data. It is this tag >>> that is used in access control and audit logging; not the type of data. For >>> any object type it could be determined that the data are not sensitive, or >>> are highly sensitive. >>> >>> The other problem we have is that the data are about people, and those >>> people have opinions on what they themselves consider sensitive. >>> >>> In fact we (security and privacy experts in healthcare) tend to stay out >>> of the business of 'determining' how sensitive data are. We prefer to >>> leverage a service that does this for us. This service leverages all the >>> power of "clinical decision support' -- think about IBM Watson class >>> service. This service understands the current state of healthcare >>> knowledge, and thus it can better determine that an object that has a >>> medication is currently being prescribed for a condition that is currently >>> considered sensitive. >>> >>> See my blog article >>> >>> https://healthcaresecprivacy.blogspot.com/2014/01/recirculation-ballot-of-h… >>> or >>> >>> https://healthcaresecprivacy.blogspot.com/2015/07/how-to-set-confidentialit… >>> >>> I do need to write a new article on this topic as I am getting much >>> interest. I welcome the interest. >>> >>> John >>> >>> John Moehrke >>> Principal Engineering Architect: Standards - Interoperability, Privacy, >>> and Security >>> CyberPrivacy – Enabling authorized communications while respecting >>> Privacy >>> M +1 920-564-2067 >>> JohnMoehrke(a)gmail.com >>> https://www.linkedin.com/in/johnmoehrke >>> https://healthcaresecprivacy.blogspot.com >>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?") >>> >>> On Sun, Jul 17, 2016 at 1:36 PM, James Hazard <james.g.hazard(a)gmail.com> >>> wrote: >>> >>>> John, >>>> >>>> Thanks very much. ConfidentialityClassifications maps to what I (we >>>> lawyers?) think of as degree-of-care, access, disclosure. From that I >>>> found massive list of kinds of records - >>>> http://hl7-fhir.github.io/valueset-doc-typecodes.html. This is both >>>> i) just the kind of thing I need and ii) overwhelming. A huge itemization, >>>> it reflects format and subject matter in a way that I presume corresponds >>>> well to how the people involved think about the records, rather than the >>>> kind of abstract categories that tend to get including in legal documents. >>>> >>>> This is terrific. I'll play with the TypeCodes, and think about the >>>> ConfidentialityClassifications. >>>> >>>> Eager for more such. >>>> >>>> Jim >>>> >>>> On Sun, Jul 17, 2016 at 2:11 PM, John Moehrke <johnmoehrke(a)gmail.com> >>>> wrote: >>>> >>>>> Hi James, >>>>> >>>>> Here is the vocabulary in Healthcare. Some of it is well organized, >>>>> most of it is (the sensitivity tags) are a bag of anything people have >>>>> found useful as sensitivity topics. >>>>> >>>>> http://hl7-fhir.github.io/security-labels.html >>>>> >>>>> The link is to the current specification for HL7 FHIR; a new effort to >>>>> leverage general IT http RESTful concept. But the vocabulary is broadly >>>>> used in historic protocols as well. >>>>> >>>>> >>>>> John >>>>> >>>>> John Moehrke >>>>> Principal Engineering Architect: Standards - Interoperability, >>>>> Privacy, and Security >>>>> CyberPrivacy – Enabling authorized communications while respecting >>>>> Privacy >>>>> M +1 920-564-2067 >>>>> JohnMoehrke(a)gmail.com >>>>> https://www.linkedin.com/in/johnmoehrke >>>>> https://healthcaresecprivacy.blogspot.com >>>>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?") >>>>> >>>>> On Sun, Jul 17, 2016 at 12:03 PM, James Hazard < >>>>> james.g.hazard(a)gmail.com> wrote: >>>>> >>>>>> Very interested in following the discussion on the connections with >>>>>> IRM. >>>>>> >>>>>> Separately, can anyone point me to work on taxonomies of confidential >>>>>> information? >>>>>> >>>>>> Ideally, this taxonomy would be broad - for instance anything that >>>>>> might be specified in a non-disclosure agreement. But domain-specific is >>>>>> also interesting, e.g. kinds of medical information, kinds of business >>>>>> info, kinds of know-how and tech, etc. >>>>>> I am working on a taxonomy for "included" or "excluded" confidential >>>>>> information under a templated NDA, and it would be nice to be more >>>>>> systematic in teasing out the different types than we lawyers usually are. >>>>>> This taxonomy will intersect with the patient data taxonomy for a model >>>>>> consent. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 14, 2016 at 12:25 PM, Thomas Hardjono <hardjono(a)mit.edu> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> +1 . >>>>>>> >>>>>>> Thorsten, could we have you describe some of this work at the BSC-DG >>>>>>> call (next week, say). >>>>>>> >>>>>>> /thomas/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: dg-bsc-bounces(a)kantarainitiative.org [ >>>>>>> dg-bsc-bounces(a)kantarainitiative.org] on behalf of Scott Shorter [ >>>>>>> sshorter(a)kimbleassociates.com] >>>>>>> Sent: Thursday, July 14, 2016 11:51 AM >>>>>>> To: Eve Maler >>>>>>> Cc: Thorsten H. Niebuhr [WedaCon GmbH]; dg-bsc(a)kantarainitiative.org >>>>>>> Subject: Re: [DG-BSC] BSC and Identity Relationship Management >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> +1 to what Eve said. I’ll feed the contents of the “potential >>>>>>> links” column into the “potential use cases” hopper. >>>>>>> >>>>>>> Thanks Thorsten! >>>>>>> - >>>>>>> Scott >>>>>>> >>>>>>> Scott Shorter - Vice President, Security >>>>>>> sshorter(a)kimbleassociates.com<mailto:sshorter@kimbleassociates.com> >>>>>>> >>>>>>> On Jul 12, 2016, at 11:27 AM, Eve Maler <eve.maler(a)forgerock.com >>>>>>> <mailto:eve.maler@forgerock.com>> wrote: >>>>>>> >>>>>>> Hi Thorsten-- Apologies for a belated response to this. I've revised >>>>>>> the subject line to be sure it catches people's attention. >>>>>>> >>>>>>> This is a great analysis. I wonder if, as our use cases shape up, we >>>>>>> could seek explicit input/review from your group, and also leverage the >>>>>>> analysis in our final deliverable... >>>>>>> >>>>>>> >>>>>>> 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/> Sydney, London, and Paris! >>>>>>> >>>>>>> On Tue, Jul 12, 2016 at 5:30 AM, Thorsten H. Niebuhr [WedaCon GmbH] < >>>>>>> tniebuhr(a)wedacon.net<mailto:tniebuhr@wedacon.net>> wrote: >>>>>>> Hi @all >>>>>>> >>>>>>> dont know if I manage to take part of the call. >>>>>>> >>>>>>> Anyway: As already mentioned, I joined the DG because of the >>>>>>> potential links between the BC/SC Topic and what we currently discuss in >>>>>>> the WG-IRM (Identity Relationship Management). Here is a quick summary on >>>>>>> the principles we are working on right now in that space and where BC/SC >>>>>>> might play a role/ could help (from my pov). >>>>>>> >>>>>>> For more on the IRM-WG, see < >>>>>>> https://kantarainitiative.org/confluence/display/irm/Home> >>>>>>> https://kantarainitiative.org/confluence/display/irm/Home >>>>>>> >>>>>>> Principle Description Potential link into BC/SC Link >>>>>>> strength >>>>>>> Scalable IRM aware systems must be able to scale into >>>>>>> billions (internet of things) BC/SC are not centralized light >>>>>>> Actionable A relationship must be able to 'do' something, or >>>>>>> better: be able to transport the authorization to do something. could >>>>>>> use BC/SC data, but no real benefit here light >>>>>>> Immutable A relationship can be immutable (this thing was made >>>>>>> by...) This is definitly somehing where BC could help medium >>>>>>> Contextual A relationship must allow to be seen in a specific >>>>>>> 'context' (time, place, predecessor, post...) >>>>>>> >>>>>>> could use BC/SC data, but no real benefit here >>>>>>> light >>>>>>> >>>>>>> Transferable A relationship can be transfered, permanently or >>>>>>> temporary >>>>>>> >>>>>>> This is definitly somehing where BC could help >>>>>>> medium >>>>>>> >>>>>>> Provable relationships are provable, either by single, multi >>>>>>> or third parties. This is definitly somehing where BC could help strong >>>>>>> Acknowledgable a relationship between two or more must be able to >>>>>>> be acknowledged (single ack, bi-directional, majority,...) This is >>>>>>> definitly somehing where BC could help strong >>>>>>> Revocable A relationship can be revoked (linked to >>>>>>> accknowledge), right to be forgotten challenging. BC/CS could help on one >>>>>>> side, but right to be forgotten is not among them.... medium >>>>>>> Constrainable any relationship can be granted, revoked, build >>>>>>> based on constraints (eg laws) This is definitly somehing where BC could >>>>>>> help medium >>>>>>> >>>>>>> cu later >>>>>>> >>>>>>> Thorsten H. Niebuhr >>>>>>> tniebuhr(a)wedacon.net / tniebuhr(a)wedacon.de<mailto: >>>>>>> tniebuhr(a)wedacon.net> >>>>>>> >>>>>>> WedaCon Informationstechnologien GmbH >>>>>>> Office: +49 (251) 399 678-22<tel:%2B49%20%28251%29%20399%20678-22> >>>>>>> Fax: +49 (251) 399 678-50<tel:%2B49%20%28251%29%20399%20678-50> >>>>>>> Mobile: +49 (174) 991 257 4<tel:%2B49%20%28174%29%20991%20257%204> >>>>>>> Kroegerweg 29 D-48155 Muenster >>>>>>> http://www.wedacon.net<http://www.wedacon.net/> >>>>>>> >>>>>>> Amtsgericht Muenster HRB 6115 >>>>>>> USt.-ID: DE216758544 >>>>>>> StNr.: 336/5775/1487 >>>>>>> Geschaeftsfuehrender Gesellschafter: Thorsten H. Niebuhr >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 07.07.2016 17:27, Eve Maler wrote: >>>>>>> (end of message) >>>>>>> >>>>>>> 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/> Sydney, London, and Paris! >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DG-BCC mailing list >>>>>>> DG-BCC(a)kantarainitiative.org<mailto:DG-BCC@kantarainitiative.org> >>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-BCc >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DG-BSC mailing list >>>>>>> DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> >>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>>>> _______________________________________________ >>>>>>> DG-BSC mailing list >>>>>>> DG-BSC(a)kantarainitiative.org >>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> @commonaccord >>>>>> >>>>>> _______________________________________________ >>>>>> DG-BSC mailing list >>>>>> DG-BSC(a)kantarainitiative.org >>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> @commonaccord >>>> >>> >>> >> >> >> -- >> @commonaccord >> > > -- @commonaccord

1 0

Re: [DG-BSC] BSC and Identity Relationship Management
by James Hazard 17 Jul '16

17 Jul '16

Bingo. There is a lot to digest here. Digesting. http://hl7-fhir.github.io/consent.html. On Sun, Jul 17, 2016 at 4:20 PM, John Moehrke <johnmoehrke(a)gmail.com> wrote: > I hoped so, but waned to assure we were communicating. > > I am actively working within a Healthcare standards organization (HL7) to > develop a standard for capturing the details of a Privacy Consent. > http://hl7-fhir.github.io/consent.html > > I am co-chair of their security workgroup, and one of the leads on this > effort. > > John > > John Moehrke > Principal Engineering Architect: Standards - Interoperability, Privacy, > and Security > CyberPrivacy – Enabling authorized communications while respecting Privacy > M +1 920-564-2067 > JohnMoehrke(a)gmail.com > https://www.linkedin.com/in/johnmoehrke > https://healthcaresecprivacy.blogspot.com > "Quis custodiet ipsos custodes?" ("Who watches the watchers?") > > On Sun, Jul 17, 2016 at 3:03 PM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > >> John, >> >> Thanks. I took a look at your blog posts and see there is a lot to this >> subject area. >> >> Yes, I understand that the type of record is orthogonal to its >> sensitivity. A kind of information can be very sensitive in one >> circumstance and not sensitive at all in another. >> >> I'm trying to tease apart the notion of >> things-that-might-be-confidential, operating on the assumption that the >> taxonomy must include nearly all kinds of records, conversations, >> observations and things. >> >> I'm approaching this from the perspective of agreements for >> non-disclosure, data transfer, services and the like, which can cover a >> broad range of subjects. To be really effective, they have to get to the >> same level of specificity as the underlying engagements with third-parties, >> including data subjects. >> >> We (lawyers) tend to paint with broad brushes, e.g.: >> >> >> http://source.commonaccord.org/index.php?action=doc&file=Wx/com/cooleygo/US… >> or >> >> http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhea… >> >> The thought is that overly permissive and overly restrictive practices >> could be reduced by shared taxonomies, with a gain in legal certainty and >> ability to extend the benefit to the data subjects. >> >> Eager for more. >> >> Jim >> >> >> >> See my blog article >> >> On Sun, Jul 17, 2016 at 3:08 PM, John Moehrke <johnmoehrke(a)gmail.com> >> wrote: >> >>> Jim, >>> >>> Be careful and aware that the way that Healthcare data are organized is >>> by medical classification; and has very little to do with how sensitive the >>> data are. Meaning the structure and organization is for the benefit of the >>> healthcare treatment purpose, where few restrictions exist. This is why we >>> have security-tags, so that we can analyze the content of an object looking >>> for sensitive topics, from that discovery we tag the data. It is this tag >>> that is used in access control and audit logging; not the type of data. For >>> any object type it could be determined that the data are not sensitive, or >>> are highly sensitive. >>> >>> The other problem we have is that the data are about people, and those >>> people have opinions on what they themselves consider sensitive. >>> >>> In fact we (security and privacy experts in healthcare) tend to stay out >>> of the business of 'determining' how sensitive data are. We prefer to >>> leverage a service that does this for us. This service leverages all the >>> power of "clinical decision support' -- think about IBM Watson class >>> service. This service understands the current state of healthcare >>> knowledge, and thus it can better determine that an object that has a >>> medication is currently being prescribed for a condition that is currently >>> considered sensitive. >>> >>> See my blog article >>> >>> https://healthcaresecprivacy.blogspot.com/2014/01/recirculation-ballot-of-h… >>> or >>> >>> https://healthcaresecprivacy.blogspot.com/2015/07/how-to-set-confidentialit… >>> >>> I do need to write a new article on this topic as I am getting much >>> interest. I welcome the interest. >>> >>> John >>> >>> John Moehrke >>> Principal Engineering Architect: Standards - Interoperability, Privacy, >>> and Security >>> CyberPrivacy – Enabling authorized communications while respecting >>> Privacy >>> M +1 920-564-2067 >>> JohnMoehrke(a)gmail.com >>> https://www.linkedin.com/in/johnmoehrke >>> https://healthcaresecprivacy.blogspot.com >>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?") >>> >>> On Sun, Jul 17, 2016 at 1:36 PM, James Hazard <james.g.hazard(a)gmail.com> >>> wrote: >>> >>>> John, >>>> >>>> Thanks very much. ConfidentialityClassifications maps to what I (we >>>> lawyers?) think of as degree-of-care, access, disclosure. From that I >>>> found massive list of kinds of records - >>>> http://hl7-fhir.github.io/valueset-doc-typecodes.html. This is both >>>> i) just the kind of thing I need and ii) overwhelming. A huge itemization, >>>> it reflects format and subject matter in a way that I presume corresponds >>>> well to how the people involved think about the records, rather than the >>>> kind of abstract categories that tend to get including in legal documents. >>>> >>>> This is terrific. I'll play with the TypeCodes, and think about the >>>> ConfidentialityClassifications. >>>> >>>> Eager for more such. >>>> >>>> Jim >>>> >>>> On Sun, Jul 17, 2016 at 2:11 PM, John Moehrke <johnmoehrke(a)gmail.com> >>>> wrote: >>>> >>>>> Hi James, >>>>> >>>>> Here is the vocabulary in Healthcare. Some of it is well organized, >>>>> most of it is (the sensitivity tags) are a bag of anything people have >>>>> found useful as sensitivity topics. >>>>> >>>>> http://hl7-fhir.github.io/security-labels.html >>>>> >>>>> The link is to the current specification for HL7 FHIR; a new effort to >>>>> leverage general IT http RESTful concept. But the vocabulary is broadly >>>>> used in historic protocols as well. >>>>> >>>>> >>>>> John >>>>> >>>>> John Moehrke >>>>> Principal Engineering Architect: Standards - Interoperability, >>>>> Privacy, and Security >>>>> CyberPrivacy – Enabling authorized communications while respecting >>>>> Privacy >>>>> M +1 920-564-2067 >>>>> JohnMoehrke(a)gmail.com >>>>> https://www.linkedin.com/in/johnmoehrke >>>>> https://healthcaresecprivacy.blogspot.com >>>>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?") >>>>> >>>>> On Sun, Jul 17, 2016 at 12:03 PM, James Hazard < >>>>> james.g.hazard(a)gmail.com> wrote: >>>>> >>>>>> Very interested in following the discussion on the connections with >>>>>> IRM. >>>>>> >>>>>> Separately, can anyone point me to work on taxonomies of confidential >>>>>> information? >>>>>> >>>>>> Ideally, this taxonomy would be broad - for instance anything that >>>>>> might be specified in a non-disclosure agreement. But domain-specific is >>>>>> also interesting, e.g. kinds of medical information, kinds of business >>>>>> info, kinds of know-how and tech, etc. >>>>>> I am working on a taxonomy for "included" or "excluded" confidential >>>>>> information under a templated NDA, and it would be nice to be more >>>>>> systematic in teasing out the different types than we lawyers usually are. >>>>>> This taxonomy will intersect with the patient data taxonomy for a model >>>>>> consent. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 14, 2016 at 12:25 PM, Thomas Hardjono <hardjono(a)mit.edu> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> +1 . >>>>>>> >>>>>>> Thorsten, could we have you describe some of this work at the BSC-DG >>>>>>> call (next week, say). >>>>>>> >>>>>>> /thomas/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: dg-bsc-bounces(a)kantarainitiative.org [ >>>>>>> dg-bsc-bounces(a)kantarainitiative.org] on behalf of Scott Shorter [ >>>>>>> sshorter(a)kimbleassociates.com] >>>>>>> Sent: Thursday, July 14, 2016 11:51 AM >>>>>>> To: Eve Maler >>>>>>> Cc: Thorsten H. Niebuhr [WedaCon GmbH]; dg-bsc(a)kantarainitiative.org >>>>>>> Subject: Re: [DG-BSC] BSC and Identity Relationship Management >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> +1 to what Eve said. I’ll feed the contents of the “potential >>>>>>> links” column into the “potential use cases” hopper. >>>>>>> >>>>>>> Thanks Thorsten! >>>>>>> - >>>>>>> Scott >>>>>>> >>>>>>> Scott Shorter - Vice President, Security >>>>>>> sshorter(a)kimbleassociates.com<mailto:sshorter@kimbleassociates.com> >>>>>>> >>>>>>> On Jul 12, 2016, at 11:27 AM, Eve Maler <eve.maler(a)forgerock.com >>>>>>> <mailto:eve.maler@forgerock.com>> wrote: >>>>>>> >>>>>>> Hi Thorsten-- Apologies for a belated response to this. I've revised >>>>>>> the subject line to be sure it catches people's attention. >>>>>>> >>>>>>> This is a great analysis. I wonder if, as our use cases shape up, we >>>>>>> could seek explicit input/review from your group, and also leverage the >>>>>>> analysis in our final deliverable... >>>>>>> >>>>>>> >>>>>>> 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/> Sydney, London, and Paris! >>>>>>> >>>>>>> On Tue, Jul 12, 2016 at 5:30 AM, Thorsten H. Niebuhr [WedaCon GmbH] < >>>>>>> tniebuhr(a)wedacon.net<mailto:tniebuhr@wedacon.net>> wrote: >>>>>>> Hi @all >>>>>>> >>>>>>> dont know if I manage to take part of the call. >>>>>>> >>>>>>> Anyway: As already mentioned, I joined the DG because of the >>>>>>> potential links between the BC/SC Topic and what we currently discuss in >>>>>>> the WG-IRM (Identity Relationship Management). Here is a quick summary on >>>>>>> the principles we are working on right now in that space and where BC/SC >>>>>>> might play a role/ could help (from my pov). >>>>>>> >>>>>>> For more on the IRM-WG, see < >>>>>>> https://kantarainitiative.org/confluence/display/irm/Home> >>>>>>> https://kantarainitiative.org/confluence/display/irm/Home >>>>>>> >>>>>>> Principle Description Potential link into BC/SC Link >>>>>>> strength >>>>>>> Scalable IRM aware systems must be able to scale into >>>>>>> billions (internet of things) BC/SC are not centralized light >>>>>>> Actionable A relationship must be able to 'do' something, or >>>>>>> better: be able to transport the authorization to do something. could >>>>>>> use BC/SC data, but no real benefit here light >>>>>>> Immutable A relationship can be immutable (this thing was made >>>>>>> by...) This is definitly somehing where BC could help medium >>>>>>> Contextual A relationship must allow to be seen in a specific >>>>>>> 'context' (time, place, predecessor, post...) >>>>>>> >>>>>>> could use BC/SC data, but no real benefit here >>>>>>> light >>>>>>> >>>>>>> Transferable A relationship can be transfered, permanently or >>>>>>> temporary >>>>>>> >>>>>>> This is definitly somehing where BC could help >>>>>>> medium >>>>>>> >>>>>>> Provable relationships are provable, either by single, multi >>>>>>> or third parties. This is definitly somehing where BC could help strong >>>>>>> Acknowledgable a relationship between two or more must be able to >>>>>>> be acknowledged (single ack, bi-directional, majority,...) This is >>>>>>> definitly somehing where BC could help strong >>>>>>> Revocable A relationship can be revoked (linked to >>>>>>> accknowledge), right to be forgotten challenging. BC/CS could help on one >>>>>>> side, but right to be forgotten is not among them.... medium >>>>>>> Constrainable any relationship can be granted, revoked, build >>>>>>> based on constraints (eg laws) This is definitly somehing where BC could >>>>>>> help medium >>>>>>> >>>>>>> cu later >>>>>>> >>>>>>> Thorsten H. Niebuhr >>>>>>> tniebuhr(a)wedacon.net / tniebuhr(a)wedacon.de<mailto: >>>>>>> tniebuhr(a)wedacon.net> >>>>>>> >>>>>>> WedaCon Informationstechnologien GmbH >>>>>>> Office: +49 (251) 399 678-22<tel:%2B49%20%28251%29%20399%20678-22> >>>>>>> Fax: +49 (251) 399 678-50<tel:%2B49%20%28251%29%20399%20678-50> >>>>>>> Mobile: +49 (174) 991 257 4<tel:%2B49%20%28174%29%20991%20257%204> >>>>>>> Kroegerweg 29 D-48155 Muenster >>>>>>> http://www.wedacon.net<http://www.wedacon.net/> >>>>>>> >>>>>>> Amtsgericht Muenster HRB 6115 >>>>>>> USt.-ID: DE216758544 >>>>>>> StNr.: 336/5775/1487 >>>>>>> Geschaeftsfuehrender Gesellschafter: Thorsten H. Niebuhr >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 07.07.2016 17:27, Eve Maler wrote: >>>>>>> (end of message) >>>>>>> >>>>>>> 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/> Sydney, London, and Paris! >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DG-BCC mailing list >>>>>>> DG-BCC(a)kantarainitiative.org<mailto:DG-BCC@kantarainitiative.org> >>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-BCc >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DG-BSC mailing list >>>>>>> DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> >>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>>>> _______________________________________________ >>>>>>> DG-BSC mailing list >>>>>>> DG-BSC(a)kantarainitiative.org >>>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> @commonaccord >>>>>> >>>>>> _______________________________________________ >>>>>> DG-BSC mailing list >>>>>> DG-BSC(a)kantarainitiative.org >>>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> @commonaccord >>>> >>> >>> >> >> >> -- >> @commonaccord >> > > -- @commonaccord

1 0

Re: [DG-BSC] BSC and Identity Relationship Management
by James Hazard 17 Jul '16

17 Jul '16

John, Thanks. I took a look at your blog posts and see there is a lot to this subject area. Yes, I understand that the type of record is orthogonal to its sensitivity. A kind of information can be very sensitive in one circumstance and not sensitive at all in another. I'm trying to tease apart the notion of things-that-might-be-confidential, operating on the assumption that the taxonomy must include nearly all kinds of records, conversations, observations and things. I'm approaching this from the perspective of agreements for non-disclosure, data transfer, services and the like, which can cover a broad range of subjects. To be really effective, they have to get to the same level of specificity as the underlying engagements with third-parties, including data subjects. We (lawyers) tend to paint with broad brushes, e.g.: http://source.commonaccord.org/index.php?action=doc&file=Wx/com/cooleygo/US… or http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhea… The thought is that overly permissive and overly restrictive practices could be reduced by shared taxonomies, with a gain in legal certainty and ability to extend the benefit to the data subjects. Eager for more. Jim See my blog article On Sun, Jul 17, 2016 at 3:08 PM, John Moehrke <johnmoehrke(a)gmail.com> wrote: > Jim, > > Be careful and aware that the way that Healthcare data are organized is by > medical classification; and has very little to do with how sensitive the > data are. Meaning the structure and organization is for the benefit of the > healthcare treatment purpose, where few restrictions exist. This is why we > have security-tags, so that we can analyze the content of an object looking > for sensitive topics, from that discovery we tag the data. It is this tag > that is used in access control and audit logging; not the type of data. For > any object type it could be determined that the data are not sensitive, or > are highly sensitive. > > The other problem we have is that the data are about people, and those > people have opinions on what they themselves consider sensitive. > > In fact we (security and privacy experts in healthcare) tend to stay out > of the business of 'determining' how sensitive data are. We prefer to > leverage a service that does this for us. This service leverages all the > power of "clinical decision support' -- think about IBM Watson class > service. This service understands the current state of healthcare > knowledge, and thus it can better determine that an object that has a > medication is currently being prescribed for a condition that is currently > considered sensitive. > > See my blog article > > https://healthcaresecprivacy.blogspot.com/2014/01/recirculation-ballot-of-h… > or > > https://healthcaresecprivacy.blogspot.com/2015/07/how-to-set-confidentialit… > > I do need to write a new article on this topic as I am getting much > interest. I welcome the interest. > > John > > John Moehrke > Principal Engineering Architect: Standards - Interoperability, Privacy, > and Security > CyberPrivacy – Enabling authorized communications while respecting Privacy > M +1 920-564-2067 > JohnMoehrke(a)gmail.com > https://www.linkedin.com/in/johnmoehrke > https://healthcaresecprivacy.blogspot.com > "Quis custodiet ipsos custodes?" ("Who watches the watchers?") > > On Sun, Jul 17, 2016 at 1:36 PM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > >> John, >> >> Thanks very much. ConfidentialityClassifications maps to what I (we >> lawyers?) think of as degree-of-care, access, disclosure. From that I >> found massive list of kinds of records - >> http://hl7-fhir.github.io/valueset-doc-typecodes.html. This is both i) >> just the kind of thing I need and ii) overwhelming. A huge itemization, it >> reflects format and subject matter in a way that I presume corresponds well >> to how the people involved think about the records, rather than the kind of >> abstract categories that tend to get including in legal documents. >> >> This is terrific. I'll play with the TypeCodes, and think about the >> ConfidentialityClassifications. >> >> Eager for more such. >> >> Jim >> >> On Sun, Jul 17, 2016 at 2:11 PM, John Moehrke <johnmoehrke(a)gmail.com> >> wrote: >> >>> Hi James, >>> >>> Here is the vocabulary in Healthcare. Some of it is well organized, most >>> of it is (the sensitivity tags) are a bag of anything people have found >>> useful as sensitivity topics. >>> >>> http://hl7-fhir.github.io/security-labels.html >>> >>> The link is to the current specification for HL7 FHIR; a new effort to >>> leverage general IT http RESTful concept. But the vocabulary is broadly >>> used in historic protocols as well. >>> >>> >>> John >>> >>> John Moehrke >>> Principal Engineering Architect: Standards - Interoperability, Privacy, >>> and Security >>> CyberPrivacy – Enabling authorized communications while respecting >>> Privacy >>> M +1 920-564-2067 >>> JohnMoehrke(a)gmail.com >>> https://www.linkedin.com/in/johnmoehrke >>> https://healthcaresecprivacy.blogspot.com >>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?") >>> >>> On Sun, Jul 17, 2016 at 12:03 PM, James Hazard <james.g.hazard(a)gmail.com >>> > wrote: >>> >>>> Very interested in following the discussion on the connections with >>>> IRM. >>>> >>>> Separately, can anyone point me to work on taxonomies of confidential >>>> information? >>>> >>>> Ideally, this taxonomy would be broad - for instance anything that >>>> might be specified in a non-disclosure agreement. But domain-specific is >>>> also interesting, e.g. kinds of medical information, kinds of business >>>> info, kinds of know-how and tech, etc. >>>> I am working on a taxonomy for "included" or "excluded" confidential >>>> information under a templated NDA, and it would be nice to be more >>>> systematic in teasing out the different types than we lawyers usually are. >>>> This taxonomy will intersect with the patient data taxonomy for a model >>>> consent. >>>> >>>> >>>> >>>> On Thu, Jul 14, 2016 at 12:25 PM, Thomas Hardjono <hardjono(a)mit.edu> >>>> wrote: >>>> >>>>> >>>>> +1 . >>>>> >>>>> Thorsten, could we have you describe some of this work at the BSC-DG >>>>> call (next week, say). >>>>> >>>>> /thomas/ >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: dg-bsc-bounces(a)kantarainitiative.org [ >>>>> dg-bsc-bounces(a)kantarainitiative.org] on behalf of Scott Shorter [ >>>>> sshorter(a)kimbleassociates.com] >>>>> Sent: Thursday, July 14, 2016 11:51 AM >>>>> To: Eve Maler >>>>> Cc: Thorsten H. Niebuhr [WedaCon GmbH]; dg-bsc(a)kantarainitiative.org >>>>> Subject: Re: [DG-BSC] BSC and Identity Relationship Management >>>>> >>>>> Hi all, >>>>> >>>>> +1 to what Eve said. I’ll feed the contents of the “potential links” >>>>> column into the “potential use cases” hopper. >>>>> >>>>> Thanks Thorsten! >>>>> - >>>>> Scott >>>>> >>>>> Scott Shorter - Vice President, Security >>>>> sshorter(a)kimbleassociates.com<mailto:sshorter@kimbleassociates.com> >>>>> >>>>> On Jul 12, 2016, at 11:27 AM, Eve Maler <eve.maler(a)forgerock.com >>>>> <mailto:eve.maler@forgerock.com>> wrote: >>>>> >>>>> Hi Thorsten-- Apologies for a belated response to this. I've revised >>>>> the subject line to be sure it catches people's attention. >>>>> >>>>> This is a great analysis. I wonder if, as our use cases shape up, we >>>>> could seek explicit input/review from your group, and also leverage the >>>>> analysis in our final deliverable... >>>>> >>>>> >>>>> 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/> Sydney, London, and Paris! >>>>> >>>>> On Tue, Jul 12, 2016 at 5:30 AM, Thorsten H. Niebuhr [WedaCon GmbH] < >>>>> tniebuhr(a)wedacon.net<mailto:tniebuhr@wedacon.net>> wrote: >>>>> Hi @all >>>>> >>>>> dont know if I manage to take part of the call. >>>>> >>>>> Anyway: As already mentioned, I joined the DG because of the potential >>>>> links between the BC/SC Topic and what we currently discuss in the WG-IRM >>>>> (Identity Relationship Management). Here is a quick summary on the >>>>> principles we are working on right now in that space and where BC/SC might >>>>> play a role/ could help (from my pov). >>>>> >>>>> For more on the IRM-WG, see < >>>>> https://kantarainitiative.org/confluence/display/irm/Home> >>>>> https://kantarainitiative.org/confluence/display/irm/Home >>>>> >>>>> Principle Description Potential link into BC/SC Link >>>>> strength >>>>> Scalable IRM aware systems must be able to scale into billions >>>>> (internet of things) BC/SC are not centralized light >>>>> Actionable A relationship must be able to 'do' something, or >>>>> better: be able to transport the authorization to do something. could >>>>> use BC/SC data, but no real benefit here light >>>>> Immutable A relationship can be immutable (this thing was made >>>>> by...) This is definitly somehing where BC could help medium >>>>> Contextual A relationship must allow to be seen in a specific >>>>> 'context' (time, place, predecessor, post...) >>>>> >>>>> could use BC/SC data, but no real benefit here >>>>> light >>>>> >>>>> Transferable A relationship can be transfered, permanently or >>>>> temporary >>>>> >>>>> This is definitly somehing where BC could help >>>>> medium >>>>> >>>>> Provable relationships are provable, either by single, multi or >>>>> third parties. This is definitly somehing where BC could help strong >>>>> Acknowledgable a relationship between two or more must be able to be >>>>> acknowledged (single ack, bi-directional, majority,...) This is definitly >>>>> somehing where BC could help strong >>>>> Revocable A relationship can be revoked (linked to >>>>> accknowledge), right to be forgotten challenging. BC/CS could help on one >>>>> side, but right to be forgotten is not among them.... medium >>>>> Constrainable any relationship can be granted, revoked, build based >>>>> on constraints (eg laws) This is definitly somehing where BC could help >>>>> medium >>>>> >>>>> cu later >>>>> >>>>> Thorsten H. Niebuhr >>>>> tniebuhr(a)wedacon.net / tniebuhr(a)wedacon.de<mailto:tniebuhr@wedacon.net >>>>> > >>>>> >>>>> WedaCon Informationstechnologien GmbH >>>>> Office: +49 (251) 399 678-22<tel:%2B49%20%28251%29%20399%20678-22> >>>>> Fax: +49 (251) 399 678-50<tel:%2B49%20%28251%29%20399%20678-50> >>>>> Mobile: +49 (174) 991 257 4<tel:%2B49%20%28174%29%20991%20257%204> >>>>> Kroegerweg 29 D-48155 Muenster >>>>> http://www.wedacon.net<http://www.wedacon.net/> >>>>> >>>>> Amtsgericht Muenster HRB 6115 >>>>> USt.-ID: DE216758544 >>>>> StNr.: 336/5775/1487 >>>>> Geschaeftsfuehrender Gesellschafter: Thorsten H. Niebuhr >>>>> >>>>> >>>>> >>>>> >>>>> On 07.07.2016 17:27, Eve Maler wrote: >>>>> (end of message) >>>>> >>>>> 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/> Sydney, London, and Paris! >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> DG-BCC mailing list >>>>> DG-BCC(a)kantarainitiative.org<mailto:DG-BCC@kantarainitiative.org> >>>>> http://kantarainitiative.org/mailman/listinfo/dg-BCc >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> DG-BSC mailing list >>>>> DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> >>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>> _______________________________________________ >>>>> DG-BSC mailing list >>>>> DG-BSC(a)kantarainitiative.org >>>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>>> >>>> >>>> >>>> >>>> -- >>>> @commonaccord >>>> >>>> _______________________________________________ >>>> DG-BSC mailing list >>>> DG-BSC(a)kantarainitiative.org >>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>>> >>>> >>> >> >> >> -- >> @commonaccord >> > > -- @commonaccord

1 0

Re: [DG-BSC] BSC and Identity Relationship Management
by James Hazard 17 Jul '16

17 Jul '16

John, Thanks very much. ConfidentialityClassifications maps to what I (we lawyers?) think of as degree-of-care, access, disclosure. From that I found massive list of kinds of records - http://hl7-fhir.github.io/valueset-doc-typecodes.html. This is both i) just the kind of thing I need and ii) overwhelming. A huge itemization, it reflects format and subject matter in a way that I presume corresponds well to how the people involved think about the records, rather than the kind of abstract categories that tend to get including in legal documents. This is terrific. I'll play with the TypeCodes, and think about the ConfidentialityClassifications. Eager for more such. Jim On Sun, Jul 17, 2016 at 2:11 PM, John Moehrke <johnmoehrke(a)gmail.com> wrote: > Hi James, > > Here is the vocabulary in Healthcare. Some of it is well organized, most > of it is (the sensitivity tags) are a bag of anything people have found > useful as sensitivity topics. > > http://hl7-fhir.github.io/security-labels.html > > The link is to the current specification for HL7 FHIR; a new effort to > leverage general IT http RESTful concept. But the vocabulary is broadly > used in historic protocols as well. > > > John > > John Moehrke > Principal Engineering Architect: Standards - Interoperability, Privacy, > and Security > CyberPrivacy – Enabling authorized communications while respecting Privacy > M +1 920-564-2067 > JohnMoehrke(a)gmail.com > https://www.linkedin.com/in/johnmoehrke > https://healthcaresecprivacy.blogspot.com > "Quis custodiet ipsos custodes?" ("Who watches the watchers?") > > On Sun, Jul 17, 2016 at 12:03 PM, James Hazard <james.g.hazard(a)gmail.com> > wrote: > >> Very interested in following the discussion on the connections with IRM. >> >> Separately, can anyone point me to work on taxonomies of confidential >> information? >> >> Ideally, this taxonomy would be broad - for instance anything that might >> be specified in a non-disclosure agreement. But domain-specific is also >> interesting, e.g. kinds of medical information, kinds of business info, >> kinds of know-how and tech, etc. >> I am working on a taxonomy for "included" or "excluded" confidential >> information under a templated NDA, and it would be nice to be more >> systematic in teasing out the different types than we lawyers usually are. >> This taxonomy will intersect with the patient data taxonomy for a model >> consent. >> >> >> >> On Thu, Jul 14, 2016 at 12:25 PM, Thomas Hardjono <hardjono(a)mit.edu> >> wrote: >> >>> >>> +1 . >>> >>> Thorsten, could we have you describe some of this work at the BSC-DG >>> call (next week, say). >>> >>> /thomas/ >>> >>> >>> >>> ________________________________________ >>> From: dg-bsc-bounces(a)kantarainitiative.org [ >>> dg-bsc-bounces(a)kantarainitiative.org] on behalf of Scott Shorter [ >>> sshorter(a)kimbleassociates.com] >>> Sent: Thursday, July 14, 2016 11:51 AM >>> To: Eve Maler >>> Cc: Thorsten H. Niebuhr [WedaCon GmbH]; dg-bsc(a)kantarainitiative.org >>> Subject: Re: [DG-BSC] BSC and Identity Relationship Management >>> >>> Hi all, >>> >>> +1 to what Eve said. I’ll feed the contents of the “potential links” >>> column into the “potential use cases” hopper. >>> >>> Thanks Thorsten! >>> - >>> Scott >>> >>> Scott Shorter - Vice President, Security >>> sshorter(a)kimbleassociates.com<mailto:sshorter@kimbleassociates.com> >>> >>> On Jul 12, 2016, at 11:27 AM, Eve Maler <eve.maler(a)forgerock.com<mailto: >>> eve.maler(a)forgerock.com>> wrote: >>> >>> Hi Thorsten-- Apologies for a belated response to this. I've revised the >>> subject line to be sure it catches people's attention. >>> >>> This is a great analysis. I wonder if, as our use cases shape up, we >>> could seek explicit input/review from your group, and also leverage the >>> analysis in our final deliverable... >>> >>> >>> 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/> Sydney, London, and Paris! >>> >>> On Tue, Jul 12, 2016 at 5:30 AM, Thorsten H. Niebuhr [WedaCon GmbH] < >>> tniebuhr(a)wedacon.net<mailto:tniebuhr@wedacon.net>> wrote: >>> Hi @all >>> >>> dont know if I manage to take part of the call. >>> >>> Anyway: As already mentioned, I joined the DG because of the potential >>> links between the BC/SC Topic and what we currently discuss in the WG-IRM >>> (Identity Relationship Management). Here is a quick summary on the >>> principles we are working on right now in that space and where BC/SC might >>> play a role/ could help (from my pov). >>> >>> For more on the IRM-WG, see < >>> https://kantarainitiative.org/confluence/display/irm/Home> >>> https://kantarainitiative.org/confluence/display/irm/Home >>> >>> Principle Description Potential link into BC/SC Link >>> strength >>> Scalable IRM aware systems must be able to scale into billions >>> (internet of things) BC/SC are not centralized light >>> Actionable A relationship must be able to 'do' something, or >>> better: be able to transport the authorization to do something. could >>> use BC/SC data, but no real benefit here light >>> Immutable A relationship can be immutable (this thing was made >>> by...) This is definitly somehing where BC could help medium >>> Contextual A relationship must allow to be seen in a specific >>> 'context' (time, place, predecessor, post...) >>> >>> could use BC/SC data, but no real benefit here >>> light >>> >>> Transferable A relationship can be transfered, permanently or >>> temporary >>> >>> This is definitly somehing where BC could help >>> medium >>> >>> Provable relationships are provable, either by single, multi or >>> third parties. This is definitly somehing where BC could help strong >>> Acknowledgable a relationship between two or more must be able to be >>> acknowledged (single ack, bi-directional, majority,...) This is definitly >>> somehing where BC could help strong >>> Revocable A relationship can be revoked (linked to accknowledge), >>> right to be forgotten challenging. BC/CS could help on one side, but >>> right to be forgotten is not among them.... medium >>> Constrainable any relationship can be granted, revoked, build based on >>> constraints (eg laws) This is definitly somehing where BC could help >>> medium >>> >>> cu later >>> >>> Thorsten H. Niebuhr >>> tniebuhr(a)wedacon.net / tniebuhr(a)wedacon.de<mailto:tniebuhr@wedacon.net> >>> >>> WedaCon Informationstechnologien GmbH >>> Office: +49 (251) 399 678-22<tel:%2B49%20%28251%29%20399%20678-22> >>> Fax: +49 (251) 399 678-50<tel:%2B49%20%28251%29%20399%20678-50> >>> Mobile: +49 (174) 991 257 4<tel:%2B49%20%28174%29%20991%20257%204> >>> Kroegerweg 29 D-48155 Muenster >>> http://www.wedacon.net<http://www.wedacon.net/> >>> >>> Amtsgericht Muenster HRB 6115 >>> USt.-ID: DE216758544 >>> StNr.: 336/5775/1487 >>> Geschaeftsfuehrender Gesellschafter: Thorsten H. Niebuhr >>> >>> >>> >>> >>> On 07.07.2016 17:27, Eve Maler wrote: >>> (end of message) >>> >>> 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/> Sydney, London, and Paris! >>> >>> >>> >>> _______________________________________________ >>> DG-BCC mailing list >>> DG-BCC(a)kantarainitiative.org<mailto:DG-BCC@kantarainitiative.org> >>> http://kantarainitiative.org/mailman/listinfo/dg-BCc >>> >>> >>> >>> _______________________________________________ >>> DG-BSC mailing list >>> DG-BSC(a)kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> >>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>> _______________________________________________ >>> DG-BSC mailing list >>> DG-BSC(a)kantarainitiative.org >>> http://kantarainitiative.org/mailman/listinfo/dg-bsc >>> >> >> >> >> -- >> @commonaccord >> >> _______________________________________________ >> DG-BSC mailing list >> DG-BSC(a)kantarainitiative.org >> http://kantarainitiative.org/mailman/listinfo/dg-bsc >> >> > -- @commonaccord

1 0

BSC and Identity Relationship Management
by Eve Maler 17 Jul '16

17 Jul '16

Hi Thorsten-- Apologies for a belated response to this. I've revised the subject line to be sure it catches people's attention. This is a great analysis. I wonder if, as our use cases shape up, we could seek explicit input/review from your group, and also leverage the analysis in our final deliverable... *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/> *Sydney, London, and Paris!* On Tue, Jul 12, 2016 at 5:30 AM, Thorsten H. Niebuhr [WedaCon GmbH] < tniebuhr(a)wedacon.net> wrote: > Hi @all > > dont know if I manage to take part of the call. > > Anyway: As already mentioned, I joined the DG because of the potential > links between the BC/SC Topic and what we currently discuss in the WG-IRM > (Identity Relationship Management). Here is a quick summary on the > principles we are working on right now in that space and where BC/SC might > play a role/ could help (from my pov). > > For more on the IRM-WG, see > <https://kantarainitiative.org/confluence/display/irm/Home> > https://kantarainitiative.org/confluence/display/irm/Home > > *Principle* *Description* *Potential link into BC/SC* *Link strength* > Scalable IRM aware systems must be able to scale into billions (internet > of things) BC/SC are not centralized light > Actionable A relationship must be able to 'do' something, or better: be > able to transport the authorization to do something. could use BC/SC > data, but no real benefit here light > Immutable A relationship can be immutable (this thing was made by...) This > is definitly somehing where BC could help medium > Contextual A relationship must allow to be seen in a specific 'context' > (time, place, predecessor, post...) > > could use BC/SC data, but no real benefit here > light > Transferable A relationship can be transfered, permanently or temporary > > This is definitly somehing where BC could help > medium > Provable relationships are provable, either by single, multi or third > parties. This is definitly somehing where BC could help strong > Acknowledgable a relationship between two or more must be able to be > acknowledged (single ack, bi-directional, majority,...) This is > definitly somehing where BC could help strong > Revocable A relationship can be revoked (linked to accknowledge), right > to be forgotten challenging. BC/CS could help on one side, but right to > be forgotten is not among them.... medium > Constrainable any relationship can be granted, revoked, build based on > constraints (eg laws) This is definitly somehing where BC could help > medium > cu later > > Thorsten H. Niebuhr > tniebuhr(a)wedacon.net / tniebuhr(a)wedacon.de <tniebuhr(a)wedacon.net> > > WedaCon Informationstechnologien GmbH > Office: +49 (251) 399 678-22 > Fax: +49 (251) 399 678-50 > Mobile: +49 (174) 991 257 4 > Kroegerweg 29 D-48155 Muenster > http://www.wedacon.net > > Amtsgericht Muenster HRB 6115 > USt.-ID: DE216758544 > StNr.: 336/5775/1487 > Geschaeftsfuehrender Gesellschafter: Thorsten H. Niebuhr > > > > > On 07.07.2016 17:27, Eve Maler wrote: > > (end of message) > > > *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/> *Sydney, London, and Paris!* > > > _______________________________________________ > DG-BCC mailing listDG-BCC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-BCc > > >

4 3

Wiki home page has been updated with our goal statement of last week about our deliverable
by Eve Maler 14 Jul '16

14 Jul '16

Namely, a briefing note at the end of six months that answers these questions: - What is blockchain - What is CommonAccord - What are the kinds of contracts that have "smarts" - Use cases for the above - Issue identification and analysis for the above Some of our recent list discussion could, I suspect, contribute... *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/> *Sydney, London, and Paris!*

1 0

Notes from BSC telecon Julyl 14
by Eve Maler 14 Jul '16

14 Jul '16

(Apologies for any confusion; I put incorrect Thursday times in the meeting notes page! All correct now. Sigh. We finally have a process in place, and correct data...) http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… Thursday July 14 Attending: Eve, Jim, Scott, Thomas, Thorsten, Colin Thanks to Scott we have a new Use Cases <http://kantarainitiative.org/confluence/display/BSC/Use+Cases> page! Eve speaks in favor of having champions and recording stakeholders, where possible. Scott will add. Here's the template <http://kantarainitiative.org/confluence/display/BSC/Use+Case+Template>. Adding web sequence diagrams <https://www.websequencediagrams.com/> is a very nice touch. Thorsten's email about IRM liaison opportunities probably doesn't contain use cases as such, but their work on "IRM in the wild" may bubble up use cases, which we can capture here. Okay, returning to discussing our current use case: Jeff S stated in email the concern that getting proofs that something happened *out of* a blockchain is not going to be as scalable or performant as we might be assuming. For example, we're talking about consent receipts. If an individual argues they didn't consent, and the service operator argues they did, and it's two years later, and it's hard to find that needle in the haystack, what good is a blockchain? Does IPFS help? Certificate transparency (see the RFC and the Chrome implementation) is a model where the CAs publicly attest to the certificate so that you don't have to "trust the CA". Does this help the problem we're discussing, where it's hard to get "recorded truth" out of the ledger? J-LINC Labs uses Stellar <https://www.stellar.org/papers/stellar-consensus-protocol.pdf> as a lightweight consensus protocol. Interledger was also mentioned; Jim has looked at it and likes it. Jim's take is that blockchain is really a notarization service – just validating a record. He believes Bitcoin doesn't need all that strength; you could use a (central) trust provider instead. In most social transacting, you probably don't need all the blockchain infrastructure. On the other hand, it's the best solution for the worst case: It's for the wide ecosystem. It's for the Internet (or disconnected) use cases where there's a lot of loose coupling. Given that blockchain is therefore a social mechanism, and consensus is social, and blockchain seems best suited for "lack of centralized trust" use cases, Eve shares her concern about relying on lightweight consensus mechanisms if they open the way to vulnerabilities of a social/sociological/business sort (vs. a purely technical sort). Let's look at our current candidate use case, and others, with an eye towards the wide ecosystem implications. *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/> *Sydney, London, and Paris!*

1 0

Notes from BSC DG telecon on July 12
by Eve Maler 14 Jul '16

14 Jul '16

http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W The May 23-24 event at MIT, variously called *Digital Contracts, Identities, and Blockchain* and *Digital Identities, Contracts, and Blockchain*, had some notes as output. Here are relevant links: - Technical and Future Infrastructure track notes <https://docs.google.com/a/forgerock.com/document/d/14KD-KA-XPKKvuSfNx4E5B2Z…> - Business track notes <https://docs.google.com/document/d/1fNjd25h_Ne4HUedn-vKkfNP73TKZAG-PM_K7Qf6…> - Healthcare use cases track notes <https://docs.google.com/document/d/1nGTZHq7Q_51tu46jcivLLlS-1vTKXr9z_JcyntB…> - IBM Open Blockchain white paper <https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md> - Article <https://medium.com/enspiral-tales/bootstrapping-a-bossless-organisation-in-…> on bootstrapping a bosses organization - Screenshot <https://slack-files.com/T02DW4GQE-F1BEJRL2G-7421d194f1> from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) - CommonAccord intro presentation <https://docs.google.com/presentation/d/1LqdDjo41PlXBUj3l84gUVQI4H8GH04mvavH…> - CommonAccord site <http://www.commonaccord.org/> - CommonAccord Slack team invitation <https://cmacc-slack-add.herokuapp.com/> For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form <http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhea…> in CommonAccord. There's capacity for it to be signed. Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec. Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands. *AI:* John to share research consent templates with Jim/the group. On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect. *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/> *Sydney, London, and Paris!*

6 8

Proposed agenda for BSC-DG Call (July 14th, 2016)
by Thomas Hardjono 13 Jul '16

13 Jul '16

Folks, Just a quick reminder of our BSC-DG Call: - Tuesdays: 10:30AM-EST (7:30AM-PST & 16:30PM-CET) - 30 minutes - Thursdays: 2:00PM-EST (11AM-PST & 20:00PM-CET) -- 30 minutes - Call-in info: Use join.me/findthomas for both Voice and Screen-share. Agenda for July 14th: (a) Continue use-cases discussion. (b) Scott to present a sample use-case template into which we can fill use case content. Here are the notes from the previous call: http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… Best. Thomas/Eve/Jim

1 0

Using Join.me voice --- RE: Bridge details -- RE: BSC-DG Call Tuesday July/12/2016 at 10:30AM-EST (7:30AM-PST & 16:30PM-CET)
by Thomas Hardjono 12 Jul '16

12 Jul '16

Folks, We may not be able to use the bridge from last week. If so, let us try using the voice feature on Join.me. URL is just www.join.me/FindThomas /thomas/ ________________________________________ From: Thomas Hardjono [hardjono(a)mit.edu] Sent: Tuesday, July 12, 2016 9:48 AM To: dg-bsc(a)kantarainitiative.org Cc: eve.maler(a)forgerock.com; james.g.hazard(a)gmail.com; hardjono(a)media.mit.edu Subject: Bridge details -- RE: BSC-DG Call Tuesday July/12/2016 at 10:30AM-EST (7:30AM-PST & 16:30PM-CET) Folks, While we await the permanent number/code we can trying using last week's bridge. I've also attached a backup number. (a) Bridge number: Dial-in: Skype:+99051000000481 * US Dial-In: +1-805-309-2350 | Room Code: 613-2898 * For more dial-in information, see: http://kantarainitiative.org/confluence/display/GI/Telco+Bridge+Info Local & International Phone Numbers (Toll) Local, Skype & SIP Access United States Toll +1 (805) 309-2350 Alternate Toll +1 (714) 551-9842 Skype [+99051000000481] Skype Name: Turbo Bridge TurboPhone (beta): https://www.turbobridge.com/join.html Works with Internet Explorer on Windows only SIP Access (using IP phone or soft phone) sip:bridge@turbobridge.com SIP URL details: https://www.turbobridge.com/help/Index.html?context=180 (b) Backup number: Conference Dial-in Number: (605) 475-4700 Participant Access Code: 176720# Screen sharing using Join.Me: join.me/findthomas /thomas/ ________________________________________ From: Thomas Hardjono [hardjono(a)mit.edu] Sent: Monday, July 11, 2016 10:31 PM To: dg-bsc(a)kantarainitiative.org Cc: eve.maler(a)forgerock.com; james.g.hazard(a)gmail.com; hardjono(a)media.mit.edu Subject: BSC-DG Call Tuesday July/12/2016 at 10:30AM-EST (7:30AM-PST & 16:30PM-CET) Folks, Just a quick reminder of this week's BSC-DG call. - Tuesdays: 10:30AM-EST (7:30AM-PST & 16:30PM-CET) - 30 minutes - Thursdays: 2:00PM-EST (11AM-PST & 20:00PM-CET) -- 30 minutes Best. Thomas/Eve/Jim

1 0

Bridge details -- RE: BSC-DG Call Tuesday July/12/2016 at 10:30AM-EST (7:30AM-PST & 16:30PM-CET)
by Thomas Hardjono 12 Jul '16

12 Jul '16

Folks, While we await the permanent number/code we can trying using last week's bridge. I've also attached a backup number. (a) Bridge number: Dial-in: Skype:+99051000000481 * US Dial-In: +1-805-309-2350 | Room Code: 613-2898 * For more dial-in information, see: http://kantarainitiative.org/confluence/display/GI/Telco+Bridge+Info Local & International Phone Numbers (Toll) Local, Skype & SIP Access United States Toll +1 (805) 309-2350 Alternate Toll +1 (714) 551-9842 Skype [+99051000000481] Skype Name: Turbo Bridge TurboPhone (beta): https://www.turbobridge.com/join.html Works with Internet Explorer on Windows only SIP Access (using IP phone or soft phone) sip:bridge@turbobridge.com SIP URL details: https://www.turbobridge.com/help/Index.html?context=180 (b) Backup number: Conference Dial-in Number: (605) 475-4700 Participant Access Code: 176720# Screen sharing using Join.Me: join.me/findthomas /thomas/ ________________________________________ From: Thomas Hardjono [hardjono(a)mit.edu] Sent: Monday, July 11, 2016 10:31 PM To: dg-bsc(a)kantarainitiative.org Cc: eve.maler(a)forgerock.com; james.g.hazard(a)gmail.com; hardjono(a)media.mit.edu Subject: BSC-DG Call Tuesday July/12/2016 at 10:30AM-EST (7:30AM-PST & 16:30PM-CET) Folks, Just a quick reminder of this week's BSC-DG call. - Tuesdays: 10:30AM-EST (7:30AM-PST & 16:30PM-CET) - 30 minutes - Thursdays: 2:00PM-EST (11AM-PST & 20:00PM-CET) -- 30 minutes Best. Thomas/Eve/Jim

1 0

BSC-DG Call Tuesday July/12/2016 at 10:30AM-EST (7:30AM-PST & 16:30PM-CET)
by Thomas Hardjono 11 Jul '16

11 Jul '16

Folks, Just a quick reminder of this week's BSC-DG call. - Tuesdays: 10:30AM-EST (7:30AM-PST & 16:30PM-CET) - 30 minutes - Thursdays: 2:00PM-EST (11AM-PST & 20:00PM-CET) -- 30 minutes Best. Thomas/Eve/Jim

1 0

Reminder: Our two-calls-a-week schedule doesn't start until next week
by Eve Maler 07 Jul '16

07 Jul '16

(end of message) *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/> *Sydney, London, and Paris!*

1 0

Notes from BSC DG telecon on July 5
by Eve Maler 05 Jul '16

05 Jul '16

Since we'll be meeting so frequently, I've gone for a hybrid approach to collecting meeting notes: Put all notes from each month into a single wiki page. The TOC for each of these pages will hopefully be self-explanatory and not too terribly overwhelming. If you'd prefer for me to collect *all* notes into a single page across our lifespan, I can change to that. http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… Eve is taking notes and is happy to take notes in future. *Attendees and introductions* Please send introductions to the list if Eve got anything wrong! - Jim Hazard - Lawyer frustrated with word processing - Eve Maler - ForgeRock - interesting UMA/smart contract connections - Thomas Hardjono - interest in getting a high-level language specified for contracts - Andrew Hughes - runs the Leadership Council - Jeff Stallman - blockchain developer - Scott Shorter - Kimble & Associates - doing some ONC work, auditing, and governance - Don Quigley - director of services leader for GE - Mark Aronson - Penn council of notaries - Kathleen Connor - consultant involved in UMA, UMA legal, and ONC - Ann Vroom - private individual interested in blockchain - Clare Nelson - AllClearID - Thorsten Niebuhr - John Wunderlich - Javier Moreno - Colin Wallis *What is a DG about?* A DG has more informal deliverables. It might, for example, recommend formation of a WG. There are several Kantara WGs and efforts that have a legal flavor to them: - UMA, with its UMA legal subgroup - Consent and Information Sharing - The Identity Assurance effort, with its trust framework components Smart contracts, broadly defined as executable code to represent legal agreements, are one way to approach agreements. *Participant goals* Jim briefly described his work on digitizing legal agreements. Eve briefly described some discussion from the Digital Contracts event/workshop of six weeks ago. The worlds of smart contracts and digital contracts that use natural language are distinct. There’s a gap between them. It seems to be narrowing, but there seems to be urgency about closing the gap and connecting them. Mark says that notary had been used previously as a synonym for timestamping. Now blockchain is coming to the fore in the same way. John would like to clarify what goes, and what should go, on a blockchain. Jim believes that smart contracts would be good to focus on independently of how they themselves are recorded. Blockchain is often the wrong way to store information. Jeff concurs with that. Blockchain is a suite of technologies, and you don’t always need all of them. Kathleen is working for the DHA security architect. The overhead for establishing trust frameworks is incredible. Adding agility would be great. Also, helping privacy, security, and administrative parts of healthcare to scale — HL7 V2, V3, and FHIR — is important. Clare is a fan of Steve Wilson of Constellation. UBS is spending a lot of money in financial services. She’s interested in pursuing a conversation along that path. John also notes that “contracts of adhesion” that often force individuals to accept terms and conditions are another use case where scalability of forming agreements would help — in this case, help individuals directly. Scott brings up a long-ago goal of technically verifiable agreements that have been parameterized. It now seems a lot more possible. *Logistics and deliverables* How often to meet? Andrew recommends five months of intensive meeting and discussion, one month of intensive writing, and the reporting out. Several people speak up in favor of frequent short/intensive meetings. Deliverables? Thomas suggests a use case document, ranked by priority. John summarizes the discussion by suggesting a final deliverable that would be a briefing note that contains “what is a BC, what is CmA, what are the kinds of contracts that have ‘smarts’, use cases, issue identification and analysis”, etc. We could take a look at some of the outputs of the Digital Contracts event held May 23-24, which Kantara helped to sponsor as part of our work. Jim met with Bart Suiches of the Philips Blockchain Lab subsequently to the Digital Contracts event and discussed patient consents as a use case. John cautions about using health as our first or primary use case for discussion. Jim agrees that it’s the hardest case, which makes it attractive to him. But we can start simple. Bart told him they’re absorbed figuring out the GDPR. Don’t forget that we can use our mailing list for discussion. *Next steps* *AI:* Eve: Share out links to notes and artifacts from the Digital Contracts event. Let’s meet twice a week for 30 minutes each, at different times to spread out for US and Europe, and to avoid the UMA call. They will be (we think) at Tue 11am ET and Thu 2pm ET. The group reached consensus on having Thomas and Eve as co-chairs. Scott kindly agreed to serve as use case collector on the DG wiki. John created a use case template <http://kantarainitiative.org/confluence/display/infosharing/Use+Case%3A+Tem…> for CIS WG usage we might consider using. *AI:* Thomas: Send out a note confirming the call times and set up the call dial-ins with Shannon. We’ll start the repeating call series next week. *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/> *Sydney, London, and Paris!*

1 0

Correction - RE: Twice-weekly BSC-DG telecon calls
by Thomas Hardjono 05 Jul '16

05 Jul '16

Correction: - Tuesdays: 10:30AM-EST (7:30AM-PST & 16:30PM-CET) - 30 minutes - Thursdays: 2:00PM-EST (11AM-PST & 20:00PM-CET) -- 30 minutes (Thanks Marc) /thomas/ ------------------------------------------ >>> -----Original Message----- >>> From: Thomas Hardjono >>> Sent: Tuesday, July 05, 2016 3:42 PM >>> To: dg-bsc(a)kantarainitiative.org >>> Cc: Thomas Hardjono; eve.maler(a)forgerock.com; Jim Hazard >>> (james.g.hazard(a)gmail.com) Shannon Taylor (staylor(a)virtualmgmt.com) >>> Subject: Twice-weekly BSC-DG telecon calls >>> >>> >>> Folks, >>> >>> Thank you for attending the first DG Telecon call today. >>> >>> In order to avoid a time-clash with the Kantara CIS weekly call, we will >>> swap the times on Tuesdays and Thursdays for our telecons. >>> >>> Note that our twice-weekly calls is only scheduled for 30 minutes each. >>> >>> Here are the times: >>> >>> - Tuesdays: 10:30AM-EST (7:30AM-PST & 16:30PM-CET) - 30 minutes >>> >>> - Thursdays: 2:00AM-EST (11AM-PST & 20:00PM-CET) -- 30 minutes >>> >>> >>> I will follow-up with the bridge numbers. >>> >>> In the meantime, please begin to think about use-cases. >>> >>> >>> Best. >>> >>> >>> Thomas/Eve/Jim >>> >>> >>> >>> ------------------------------------------ >>>

1 0

Twice-weekly BSC-DG telecon calls
by Thomas Hardjono 05 Jul '16

05 Jul '16

Folks, Thank you for attending the first DG Telecon call today. In order to avoid a time-clash with the Kantara CIS weekly call, we will swap the times on Tuesdays and Thursdays for our telecons. Note that our twice-weekly calls is only scheduled for 30 minutes each. Here are the times: - Tuesdays: 10:30AM-EST (7:30AM-PST & 16:30PM-CET) - 30 minutes - Thursdays: 2:00AM-EST (11AM-PST & 20:00PM-CET) -- 30 minutes I will follow-up with the bridge numbers. In the meantime, please begin to think about use-cases. Best. Thomas/Eve/Jim ------------------------------------------

1 0

BSC Proposed Agenda & Bridge details --- RE: BSC first telecon call (Kantara DG - Blockchain and Smart Contracts)
by Thomas Hardjono 30 Jun '16

30 Jun '16

Folks, Below is the proposed agenda and call-in information for our first BSC telecon next week. Best. Thomas/Jim/Eve -------------------------------------------------- == Kantara Blockchain & Smart Contracts DG == (a) Proposed Agenda: (i) Introductions, purpose & duration of the BSC DG. (ii) Use-Cases. (iii) Potential work items. (iv) Frequency of future telecons & dates/times. (b) Bridge information: Date: Tuesday, July 5, 2:00pm EDT (11AM-Pacific) Dial-in: Skype:+99051000000481 * US Dial-In: +1-805-309-2350 | Room Code: 613-2898 * For more dial-in information, see: http://kantarainitiative.org/confluence/display/GI/Telco+Bridge+Info Local & International Phone Numbers (Toll) Local, Skype & SIP Access United States Toll +1 (805) 309-2350 Alternate Toll +1 (714) 551-9842 Skype [+99051000000481] Skype Name: Turbo Bridge TurboPhone (beta): https://www.turbobridge.com/join.html Works with Internet Explorer on Windows only SIP Access (using IP phone or soft phone) sip:bridge@turbobridge.com SIP URL details: https://www.turbobridge.com/help/Index.html?context=180 -------------------------------------------------

1 0

Kantara: Blockchain and Smart Contract DG MEETING NOTICE
by Shannon Taylor 29 Jun '16

29 Jun '16

All, The Kantara Blockchain and Smart Contract Discussion Group will hold a meeting on Tuesday, July 5 at 2:00pm EDT. The call details can be found below or in the attached. Please take this opportunity to update your calendar accordingly so you don't miss this meeting. Regards, Shannon Taylor _____ Tuesday, July 5 2:00pm EDT Dial-in: Skype:+99051000000481 * US Dial-In: +1-805-309-2350 | Room Code: 613-2898 * For more dial-in information, see: http://kantarainitiative.org/confluence/display/GI/Telco+Bridge+Info +The following commands may be used participants during the conference call:+ *0 Plays menu of Keypad Commands *3 Promote to Host (if non-host) *5 Raise your hand *6 Mute yourself (toggle on/off) *# Private roll call of participants *\* Mute music-on-hold (toggle on/off) Local & International Phone Numbers (Toll) Local, Skype & SIP Access United States Toll +1 (805) 309-2350 Alternate Toll +1 (714) 551-9842 Skype [+99051000000481] Skype Name: Turbo Bridge TurboPhone (beta): https://www.turbobridge.com/join.html Works with Internet Explorer on Windows only SIP Access (using IP phone or soft phone) sip:bridge@turbobridge.com SIP URL details: https://www.turbobridge.com/help/Index.html?context=180

1 0

Result from Doodle poll -- RE: BSC first telecon call (Kantara DG - Blockchain and Smart Contracts)
by Thomas Hardjono 28 Jun '16

28 Jun '16

Folks, I have left open the Doodle poll for a week now, and have just closed it. The following is the final date/time for our first telecon: - Date: July 5th - Time: 2PM-EST (11AM-PST or 19:00 UK time) - apologies to people in Europe. I will follow-up with the dial-in information and draft agenda. Note that during this meeting we will decide on the frequency of future meetings and date/time. Best. Thomas, Jim and Eve ________________________________________ From: dg-bsc-bounces(a)kantarainitiative.org [dg-bsc-bounces(a)kantarainitiative.org] on behalf of Thomas Hardjono [hardjono(a)mit.edu] Sent: Tuesday, June 21, 2016 2:56 PM To: dg-bsc(a)kantarainitiative.org Cc: hardjono(a)media.mit.edu Subject: [DG-BSC] BSC first telecon call (Kantara DG - Blockchain and Smart Contracts) Folks, We are planning to have the first telecon call of our discussion group (DG) on blockchain and smart contracts (BSC) in the week of July 5th. (Note that July 4th is a public holiday in the US). I have created a Doodle poll for people to decide the best date/time during that week (Tuesday, Wednesday or Thursday that week): http://doodle.com/poll/5yiiwpcpqrnnhiux The bridge/telecon number will follow. Best. Thomas, Jim and Eve _______________________________________________ DG-BSC mailing list DG-BSC(a)kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

1 0

BSC first telecon call (Kantara DG - Blockchain and Smart Contracts)
by Thomas Hardjono 21 Jun '16

21 Jun '16

Folks, We are planning to have the first telecon call of our discussion group (DG) on blockchain and smart contracts (BSC) in the week of July 5th. (Note that July 4th is a public holiday in the US). I have created a Doodle poll for people to decide the best date/time during that week (Tuesday, Wednesday or Thursday that week): http://doodle.com/poll/5yiiwpcpqrnnhiux The bridge/telecon number will follow. Best. Thomas, Jim and Eve

1 0