BSC and Identity Relationship Management
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@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@wedacon.net / tniebuhr@wedacon.de <tniebuhr@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
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@kimbleassociates.com<mailto:sshorter@kimbleassociates.com> On Jul 12, 2016, at 11:27 AM, Eve Maler <eve.maler@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@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@wedacon.net / tniebuhr@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@kantarainitiative.org<mailto:DG-BCC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-BCc _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc
+1 . Thorsten, could we have you describe some of this work at the BSC-DG call (next week, say). /thomas/ ________________________________________ From: dg-bsc-bounces@kantarainitiative.org [dg-bsc-bounces@kantarainitiative.org] on behalf of Scott Shorter [sshorter@kimbleassociates.com] Sent: Thursday, July 14, 2016 11:51 AM To: Eve Maler Cc: Thorsten H. Niebuhr [WedaCon GmbH]; dg-bsc@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@kimbleassociates.com<mailto:sshorter@kimbleassociates.com> On Jul 12, 2016, at 11:27 AM, Eve Maler <eve.maler@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@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@wedacon.net / tniebuhr@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@kantarainitiative.org<mailto:DG-BCC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-BCc _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc
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@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@kantarainitiative.org [ dg-bsc-bounces@kantarainitiative.org] on behalf of Scott Shorter [ sshorter@kimbleassociates.com] Sent: Thursday, July 14, 2016 11:51 AM To: Eve Maler Cc: Thorsten H. Niebuhr [WedaCon GmbH]; dg-bsc@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@kimbleassociates.com<mailto:sshorter@kimbleassociates.com>
On Jul 12, 2016, at 11:27 AM, Eve Maler <eve.maler@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@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@wedacon.net / tniebuhr@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@kantarainitiative.org<mailto:DG-BCC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-BCc
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
-- @commonaccord
participants (4)
-
Eve Maler -
James Hazard -
Scott Shorter -
Thomas Hardjono