July 2016 - DG-BSC - mailman.kantarainitiative.org

Notes from BSC telecon July 21
by Eve Maler 21 Jul '16

21 Jul '16

http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… Agenda: - 10 min: Review Tuesday's discussion briefly if we have substantially different people on the call - Rest of the time: Figure out the broad outlines of use case #1 in light of our new understanding Attending: Thomas, Eve, Scott, Don, Marco, Matisse In doing a use case, here are questions we could consider answering: - Who is the party we want to empower or give autonomy to? That would be the "Alice", so to speak. - What is the transaction we are describing? This would be the gerund that goes into the use case name. (Like "consent", e.g.) - What is the domain of the transaction? (Like "health research", e.g.) We need a champion to stand up and take the new use case wiki page further. Is that Jim? John? Both together? Please see the new Alice Consents to Health Research <http://kantarainitiative.org/confluence/display/BSC/Alice+Consents+to+Healt…> use case page for details. For next week: - The briefing note dumping ground to throw eggs at - Use case work *AI:* Thomas: Ask Shannon to tidy up the calendar. *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!*

3 3

Agenda for BSC telecon 2016-07-21 (today!)
by Eve Maler 21 Jul '16

21 Jul '16

*Note that we're now using Kantara line A* (TurboBridge) for the phone line. You may experience trouble getting into it using Skype, in which case try the web interface instead -- though that choice seems incompatible with Safari browsers. Sigh. :) http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… We meet *Thursdays* for 30 minutes at 11am PT / 2pm ET / 7pm UK / 8pm CET . We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options <https://www.turbobridge.com/international.html>, web interface <https://panel.turbobridge.com/webcall/>, more info <https://www.turbobridge.com/join.html>, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar <http://kantarainitiative.org/confluence/display/BSC/Calendar> for our full meeting schedule. Agenda: - 10 min: Review Tuesday's discussion briefly if we have substantially different people on the call - Rest of the time: Figure out the broad outlines of use case #1 in light of our new understanding *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 July 19
by Eve Maler 21 Jul '16

21 Jul '16

http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… Agenda: - 15 min: Sharpen our deliverable ToC/value prop - E.g., focus on transactions/contracts aspects? verticals/sectors? what other constraints to make our goals achievable and valuable?... - Choose a mini-goal for Aug 5 (the one-month mark) - 15 min: Thorsten: present IRM touchpoints and next steps - Homework for Thursday: next steps on patient consent for research (?) use case Attending: Eve, Thorsten, Jim, Marc D, John, Philip (Thomas regrets) *Sharpening our deliverable:* Is our primary audience the Kantara leadership, as John suggests? Kantara is in the business <https://kantarainitiative.org/what-we-do/> of identity innovation and interior. Jim notes that he's discovered the centrality of identity to his purposes, while blockchain is really one of a variety or family of technologies that are potentially relevant to his purposes, namely "moving legal onto GitHub, more or less – making legal processes cheaper and faster and getting them closer to user control and autonomy". Other technologies : IPFS and so on. We seem to have achieved rough consensus about this vision for the scope of our briefing note: We want to focus on use cases that are about "contracting and transacting" in the context of empowering individuals, smaller companies, smaller countries, and communities in a "peer to peer" way with larger companies and countries etc. (not meaning P2P technologies necessarily, though it might do so). "Legal" means a formal statement of relationships, and it could include contracts, permits, consents, and so on. All legal documents increment relationships between some "Persons" (including both human and non-human). *IRM presentation:* Thorsten presented <https://slides.com/wedaslide/irm-bcsc/> some thoughts (of his own) on the IRM principles. We're thinking that capturing various technologies adjacent to blockchain (many of which he has listed here) and presenting an analysis of them in our briefing note would be a valuable idea. Scott (not on the line but on the screenshare) added this link <https://kantarainitiative.org/confluence/download/attachments/69275399/asse…> to a taxonomy of identity types, including human and other. *AI:* Eve: Create a GDoc that would be a briefing note dumping ground for outline ideas (see above re Thorsten comments). *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!*

4 7

Agenda for BSC telecon July 19 (note the switch to Kantara Line A)
by Eve Maler 18 Jul '16

18 Jul '16

Please note that we're now fully in the swing of using the Kantara dial-in infrastructure (TurboBridge). A number of people have have problems using Skype in combination with it; if you have this problem, try the web interface. (I can't get it to work with Safari, myself, but it's awesome with Chrome.) http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… We meet *Tuesdays* for 30 minutes at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET . We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options <https://www.turbobridge.com/international.html>, web interface <https://panel.turbobridge.com/webcall/>, more info <https://www.turbobridge.com/join.html>, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar <http://kantarainitiative.org/confluence/display/BSC/Calendar> for our full meeting schedule. Agenda: - 15 min: Sharpen our deliverable ToC/value prop - E.g., focus on transactions/contracts aspects? verticals/sectors? what other constraints to make our goals achievable and valuable?... - Choose a mini-goal for Aug 5 (the one-month mark) - 15 min: Thorsten: present IRM touchpoints and next steps - Homework for Thursday: next steps on patient consent for research (?) use case *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

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