Thomas, There are many ways to get where we're headed with personas, verifiable claims, and non-correlatable transaction identifiers and you are contributing to a valuable conversation. I love that you are bringing UMA into the conversation because I tend to consider the authorization server as a key component of identity and tightly coupled to persona. Privacy engineering identity can build on standards (and would-be standards) including: - FIDO (for non-correlatable yet persistent identifiers) - W3C Verifiable Claims (for a triple blind attribute verification architecture) - Hierarchical Deterministic keys in blockchain - Decentralized UMA authorization servers as online agents and self-sovereign support technology - TOR and other anonymization protocols for an UMA authorization server The more I learn about decentralized ID (in the Rebooting Web of Trust context) and blockchains, the harder it is to map this work into traditional standards and governance like OpenID Connect and IDESG. The tools for privacy engineering identity are out there but the governance model that will put them together in a sustainable decentralized way remains elusive. Adrian On Thu, Sep 8, 2016 at 8:18 AM, John Moehrke <johnmoehrke@gmail.com> wrote:

Thomas,

That functionality - usecase - is critical to the use-case I presented on "Evidence Notebook". In that case the a human may need many identities, for the various things he is working on in his virtual notebooks. These identities need to be opaque at times, and later exposed for who they represent. I explain this in my use-case, but would very much rather it be a common building block concept that could be leveraged rather than re-explained.

In my case these 'transaction identities' would be used for years before being exposed and retired. Is that timeframe acceptable in your use-case? The term 'transaction' tends to lead me to very short term use.

John

John Moehrke Principal Engineering Architect: Standards - Interoperability, Privacy, and Security CyberPrivacy – Enabling authorized communications while respecting Privacy M +1 920-564-2067 JohnMoehrke@gmail.com https://www.linkedin.com/in/johnmoehrke https://healthcaresecprivacy.blogspot.com "Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Thu, Sep 8, 2016 at 6:18 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

Thomas;

This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" < hardjono@mit.edu> wrote:

Folks,

...

This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet).

One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP)

The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS).

When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created.

When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP).

At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP.

The PP keeps these transaction-identifiers as long as she needs, and may even archive them.

The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract.

If this is useful, I can write it up for the use-cases page.

/thomas/ _______________________________________________ DG-BSC mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

_______________________________________________ DG-BSC mailing list 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

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

So a while back I came across the text in “On Identity” by Amin Maalouf (2000) that the requirement for an identity boils down to the information required to keep someone from impersonating, not really the information required to identify or establish an identity. Not sure it helps but may change the perspective, I have found this useful at times. Sal From: dg-bsc-bounces@kantarainitiative.org [mailto:dg-bsc-bounces@kantarainitiative.org] On Behalf Of j stollman Sent: Thursday, September 08, 2016 11:42 AM To: John Wunderlich Cc: hardjono@media.mit.edu; dg-bsc@kantarainitiative.org Subject: Re: [DG-BSC] User-Managed Identities for Blockchains (using UMA for user-centric control over blockchain identities) John, With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain": I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository. Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca> wrote: Thomas; This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work. John Wunderlich, Sent frum a mobile device, Pleez 4give speling erurz "...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" <hardjono@mit.edu> wrote: Folks, This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet). One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP) The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS). When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created. When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP). At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP. The PP keeps these transaction-identifiers as long as she needs, and may even archive them. The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract. If this is useful, I can write it up for the use-cases page. /thomas/ _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

Luk, et al, The devil being in the details: The industry has been incorporating more and more behavioral data into the authentication process to merely verify identity. Multi-factor authentication now commonly includes answering questions about relationships (mother's maiden name, second grade teacher's name) or behavior (favorite book or movie) just to verify an identity. Arguably, we could just use biological data (fingerprints, iris scans, DNA) for identity verification, but because there are usually ways to hack a purely biometric system ("what you are"), it is often necessary to supplement such systems with "what you know" and "what you have". I don't know that anyone has come to consensus on a minimum set of data that would be sufficient to establish identity for all stakeholders. A second problem arises when one RP seeks information about you from another RP, such as when a credit card issuers seeks information from others on your credit worthiness. This cross-RP collaboration implies that one cannot maintain separate personas for the new issuer and the reference sources the issuer uses to verify your credit-worthiness. The different personas will become cross-correlated. And over enough time, many (most? all?) of one's unique personas will become polluted by such cross-correlations. Do we have a solution? Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com> Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Fri, Sep 9, 2016 at 2:51 AM, Luk Vervenne <luk.vervenne@synergetics.be> wrote:

Agreed Jeff,

The danger is organisations try to define identity by collecting attributes that ‘proof’ the identity. The next thing is sharing data over this "Know Your Customer” data. Blockchain or not!

This is why a *clean separation* is needed between * core identity* (as a representation of the individual online) versus personal ‘*attributes*’, which is data *about* the individual/persona. As such, an identity provider is only to *define* and/or *proof* the core identity. Period. (yes we have national ID cards in Europe)

In Thomas picture, the notion of *persona *in fact then holds two different elements: - a *pairwise persistent pseudonym* per service provider (read: no correlation) of a* fully* pairwise persistent pseudonym per web service (see: privacy-preservation in deep WS call chains) - a *persona* which (can) represent a selection (think a directed graph) of contextualized personal data to be shared, possibly valid over a number of organisations within that context.

The consistent use of pairwise persistent pseudonyms solves * a lot of problems* by rethinking identity * in a symmetrical way.* - Identity disclosure now becomes *the sole prerogative of the individual* - Analytics on *pairwise* pseudonymous identified data now becomes much more acceptable.

We have all the above done using using a SAML-ID-WSF2 and OpenID-UMA framework. It is complex. Time for blockchain-isch tech to make things simpler (where possible!)

Secondly, we should distance ourselves of where personal data is hosted: on premise, with the individual, in the ecosystem cloud or with a PDS vendor. The same authorisation methods should always be used.

Again, I plea to follow Thomas use case, with the separation of pseudo-identifiers and persona's

Luk.

On 8 Sep 2016, at 17:42, j stollman <stollman.j@gmail.com> wrote:

John,

With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain":

I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

Thomas;

This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" < hardjono@mit.edu> wrote:

Folks,

...

This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet).

One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP)

The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS).

When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created.

When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP).

At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP.

The PP keeps these transaction-identifiers as long as she needs, and may even archive them.

The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract.

If this is useful, I can write it up for the use-cases page.

/thomas/ _______________________________________________ DG-BSC mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

_______________________________________________ DG-BSC mailing list 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

Luckily, ...I live in Europe where we have Gov ID cards. The trend you mention is a real and deliberate pest. For your second problem we use a "discovery service" which maps pairwise pseudonym A of company X into pariwise pseudonym B for company Y We can do this for every web service so the user sees in his privayc app (Privacy Hub) what serivces where involved in any transaction. All services also communicate with the audut bus, so two per transaction. Maybe this is something for the blockchain?? It provides an audit summary (containing the transaction summary but no personal data) Luk On 9 Sep 2016, at 17:03, j stollman <stollman.j@gmail.com<mailto:stollman.j@gmail.com>> wrote: Luk, et al, The devil being in the details: The industry has been incorporating more and more behavioral data into the authentication process to merely verify identity. Multi-factor authentication now commonly includes answering questions about relationships (mother's maiden name, second grade teacher's name) or behavior (favorite book or movie) just to verify an identity. Arguably, we could just use biological data (fingerprints, iris scans, DNA) for identity verification, but because there are usually ways to hack a purely biometric system ("what you are"), it is often necessary to supplement such systems with "what you know" and "what you have". I don't know that anyone has come to consensus on a minimum set of data that would be sufficient to establish identity for all stakeholders. A second problem arises when one RP seeks information about you from another RP, such as when a credit card issuers seeks information from others on your credit worthiness. This cross-RP collaboration implies that one cannot maintain separate personas for the new issuer and the reference sources the issuer uses to verify your credit-worthiness. The different personas will become cross-correlated. And over enough time, many (most? all?) of one's unique personas will become polluted by such cross-correlations. Do we have a solution? Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com<mailto:stollman.j@gmail.com> +1 202.683.8699 <mailto:stollman.j@gmail.com> Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Fri, Sep 9, 2016 at 2:51 AM, Luk Vervenne <luk.vervenne@synergetics.be<mailto:luk.vervenne@synergetics.be>> wrote: Agreed Jeff, The danger is organisations try to define identity by collecting attributes that ‘proof’ the identity. The next thing is sharing data over this "Know Your Customer” data. Blockchain or not! This is why a clean separation is needed between core identity (as a representation of the individual online) versus personal ‘attributes’, which is data about the individual/persona. As such, an identity provider is only to define and/or proof the core identity. Period. (yes we have national ID cards in Europe) In Thomas picture, the notion of persona in fact then holds two different elements: - a pairwise persistent pseudonym per service provider (read: no correlation) of a fully pairwise persistent pseudonym per web service (see: privacy-preservation in deep WS call chains) - a persona which (can) represent a selection (think a directed graph) of contextualized personal data to be shared, possibly valid over a number of organisations within that context. The consistent use of pairwise persistent pseudonyms solves a lot of problems by rethinking identity in a symmetrical way. - Identity disclosure now becomes the sole prerogative of the individual - Analytics on pairwise pseudonymous identified data now becomes much more acceptable. We have all the above done using using a SAML-ID-WSF2 and OpenID-UMA framework. It is complex. Time for blockchain-isch tech to make things simpler (where possible!) Secondly, we should distance ourselves of where personal data is hosted: on premise, with the individual, in the ecosystem cloud or with a PDS vendor. The same authorisation methods should always be used. Again, I plea to follow Thomas use case, with the separation of pseudo-identifiers and persona's Luk. On 8 Sep 2016, at 17:42, j stollman <stollman.j@gmail.com<mailto:stollman.j@gmail.com>> wrote: John, With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain": I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository. Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com<mailto:stollman.j@gmail.com> +1 202.683.8699<tel:%2B1%20202.683.8699> <mailto:stollman.j@gmail.com> Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca<mailto:john@wunderlich.ca>> wrote: Thomas; This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work. John Wunderlich, Sent frum a mobile device, Pleez 4give speling erurz "...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" <hardjono@mit.edu<mailto:hardjono@mit.edu>> wrote: Folks, This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet). One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP) The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS). When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created. When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP). At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP. The PP keeps these transaction-identifiers as long as she needs, and may even archive them. The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract. If this is useful, I can write it up for the use-cases page. /thomas/ _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ 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<mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc

You say that like government ID cards are a good thing.... Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN> Call: +1 (647) 669-4749 eMail: john@wunderlich.ca On 9 September 2016 at 11:52, Luk Vervenne <luk.vervenne@synergetics.be> wrote:

Luckily, ...I live in Europe where we have Gov ID cards. The trend you mention is a real and deliberate pest.

For your second problem we use a "discovery service" which maps pairwise pseudonym A of company X into pariwise pseudonym B for company Y We can do this for every web service so the user sees in his privayc app (Privacy Hub) what serivces where involved in any transaction. All services also communicate with the audut bus, so two per transaction. Maybe this is something for the blockchain?? It provides an audit summary (containing the transaction summary but no personal data)

Luk

On 9 Sep 2016, at 17:03, j stollman <stollman.j@gmail.com> wrote:

Luk, et al,

The devil being in the details: The industry has been incorporating more and more behavioral data into the authentication process to merely verify identity. Multi-factor authentication now commonly includes answering questions about relationships (mother's maiden name, second grade teacher's name) or behavior (favorite book or movie) just to verify an identity.

Arguably, we could just use biological data (fingerprints, iris scans, DNA) for identity verification, but because there are usually ways to hack a purely biometric system ("what you are"), it is often necessary to supplement such systems with "what you know" and "what you have". I don't know that anyone has come to consensus on a minimum set of data that would be sufficient to establish identity for all stakeholders.

A second problem arises when one RP seeks information about you from another RP, such as when a credit card issuers seeks information from others on your credit worthiness. This cross-RP collaboration implies that one cannot maintain separate personas for the new issuer and the reference sources the issuer uses to verify your credit-worthiness. The different personas will become cross-correlated. And over enough time, many (most? all?) of one's unique personas will become polluted by such cross-correlations.

Do we have a solution?

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Fri, Sep 9, 2016 at 2:51 AM, Luk Vervenne <luk.vervenne@synergetics.be> wrote:

Agreed Jeff,

The danger is organisations try to define identity by collecting attributes that ‘proof’ the identity. The next thing is sharing data over this "Know Your Customer” data. Blockchain or not!

This is why a *clean separation* is needed between * core identity* (as a representation of the individual online) versus personal ‘*attributes*’, which is data *about* the individual/persona. As such, an identity provider is only to *define* and/or *proof* the core identity. Period. (yes we have national ID cards in Europe)

In Thomas picture, the notion of *persona *in fact then holds two different elements: - a *pairwise persistent pseudonym* per service provider (read: no correlation) of a* fully* pairwise persistent pseudonym per web service (see: privacy-preservation in deep WS call chains) - a *persona* which (can) represent a selection (think a directed graph) of contextualized personal data to be shared, possibly valid over a number of organisations within that context.

The consistent use of pairwise persistent pseudonyms solves * a lot of problems* by rethinking identity * in a symmetrical way.* - Identity disclosure now becomes *the sole prerogative of the individual* - Analytics on *pairwise* pseudonymous identified data now becomes much more acceptable.

We have all the above done using using a SAML-ID-WSF2 and OpenID-UMA framework. It is complex. Time for blockchain-isch tech to make things simpler (where possible!)

Secondly, we should distance ourselves of where personal data is hosted: on premise, with the individual, in the ecosystem cloud or with a PDS vendor. The same authorisation methods should always be used.

Again, I plea to follow Thomas use case, with the separation of pseudo-identifiers and persona's

Luk.

On 8 Sep 2016, at 17:42, j stollman <stollman.j@gmail.com> wrote:

John,

With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain":

I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca> wrote:

Thomas;

This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" <hardjono@mit.edu

...

wrote:

Folks,

This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet).

One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP)

The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS).

When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created.

When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP).

At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP.

The PP keeps these transaction-identifiers as long as she needs, and may even archive them.

The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract.

If this is useful, I can write it up for the use-cases page.

/thomas/ _______________________________________________ DG-BSC mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

_______________________________________________ DG-BSC mailing list 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

-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

Oh, it's better than that. https://www.dlapiper.com/en/us/insights/publications/2015/08/new-eu-regulati... Adrian On Friday, September 9, 2016, Luk Vervenne <luk.vervenne@synergetics.be> wrote:

No, a proper "Identification authory" that defines your *core identity.* Period.

It happens that - historically - some eu countries has this done by government. In the nineties Belgium gov. did it. UK has a set of idm now. And Notaries in the netherlands do it now too.

Luk

On 9 Sep 2016, at 21:45, John Wunderlich <john@wunderlich.ca <javascript:_e(%7B%7D,'cvml','john@wunderlich.ca');>> wrote:

You say that like government ID cards are a good thing....

Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN>

Call: +1 (647) 669-4749 eMail: john@wunderlich.ca <javascript:_e(%7B%7D,'cvml','john@wunderlich.ca');>

On 9 September 2016 at 11:52, Luk Vervenne <luk.vervenne@synergetics.be <javascript:_e(%7B%7D,'cvml','luk.vervenne@synergetics.be');>> wrote:

...

Luckily, ...I live in Europe where we have Gov ID cards. The trend you mention is a real and deliberate pest.

For your second problem we use a "discovery service" which maps pairwise pseudonym A of company X into pariwise pseudonym B for company Y We can do this for every web service so the user sees in his privayc app (Privacy Hub) what serivces where involved in any transaction. All services also communicate with the audut bus, so two per transaction. Maybe this is something for the blockchain?? It provides an audit summary (containing the transaction summary but no personal data)

Luk

On 9 Sep 2016, at 17:03, j stollman <stollman.j@gmail.com <javascript:_e(%7B%7D,'cvml','stollman.j@gmail.com');>> wrote:

Luk, et al,

The devil being in the details: The industry has been incorporating more and more behavioral data into the authentication process to merely verify identity. Multi-factor authentication now commonly includes answering questions about relationships (mother's maiden name, second grade teacher's name) or behavior (favorite book or movie) just to verify an identity.

Arguably, we could just use biological data (fingerprints, iris scans, DNA) for identity verification, but because there are usually ways to hack a purely biometric system ("what you are"), it is often necessary to supplement such systems with "what you know" and "what you have". I don't know that anyone has come to consensus on a minimum set of data that would be sufficient to establish identity for all stakeholders.

A second problem arises when one RP seeks information about you from another RP, such as when a credit card issuers seeks information from others on your credit worthiness. This cross-RP collaboration implies that one cannot maintain separate personas for the new issuer and the reference sources the issuer uses to verify your credit-worthiness. The different personas will become cross-correlated. And over enough time, many (most? all?) of one's unique personas will become polluted by such cross-correlations.

Do we have a solution?

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com <javascript:_e(%7B%7D,'cvml','stollman.j@gmail.com');> +1 202.683.8699 <javascript:_e(%7B%7D,'cvml','stollman.j@gmail.com');>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Fri, Sep 9, 2016 at 2:51 AM, Luk Vervenne <luk.vervenne@synergetics.be <javascript:_e(%7B%7D,'cvml','luk.vervenne@synergetics.be');>> wrote:

Agreed Jeff,

The danger is organisations try to define identity by collecting attributes that ‘proof’ the identity. The next thing is sharing data over this "Know Your Customer” data. Blockchain or not!

This is why a *clean separation* is needed between * core identity* (as a representation of the individual online) versus personal ‘*attributes*’, which is data *about* the individual/persona. As such, an identity provider is only to *define* and/or *proof* the core identity. Period. (yes we have national ID cards in Europe)

In Thomas picture, the notion of *persona *in fact then holds two different elements: - a *pairwise persistent pseudonym* per service provider (read: no correlation) of a* fully* pairwise persistent pseudonym per web service (see: privacy-preservation in deep WS call chains) - a *persona* which (can) represent a selection (think a directed graph) of contextualized personal data to be shared, possibly valid over a number of organisations within that context.

The consistent use of pairwise persistent pseudonyms solves * a lot of problems* by rethinking identity * in a symmetrical way.* - Identity disclosure now becomes *the sole prerogative of the individual* - Analytics on *pairwise* pseudonymous identified data now becomes much more acceptable.

We have all the above done using using a SAML-ID-WSF2 and OpenID-UMA framework. It is complex. Time for blockchain-isch tech to make things simpler (where possible!)

Secondly, we should distance ourselves of where personal data is hosted: on premise, with the individual, in the ecosystem cloud or with a PDS vendor. The same authorisation methods should always be used.

Again, I plea to follow Thomas use case, with the separation of pseudo-identifiers and persona's

Luk.

On 8 Sep 2016, at 17:42, j stollman <stollman.j@gmail.com <javascript:_e(%7B%7D,'cvml','stollman.j@gmail.com');>> wrote:

John,

With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain":

I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com <javascript:_e(%7B%7D,'cvml','stollman.j@gmail.com');> +1 202.683.8699 <javascript:_e(%7B%7D,'cvml','stollman.j@gmail.com');>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca <javascript:_e(%7B%7D,'cvml','john@wunderlich.ca');>> wrote:

Thomas;

This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" < hardjono@mit.edu <javascript:_e(%7B%7D,'cvml','hardjono@mit.edu');>> wrote:

Folks,

This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet).

One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP)

The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS).

When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created.

When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP).

At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP.

The PP keeps these transaction-identifiers as long as she needs, and may even archive them.

The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract.

If this is useful, I can write it up for the use-cases page.

/thomas/ _______________________________________________ DG-BSC mailing listDG-BSC@kantarainitiative.org <javascript:_e(%7B%7D,'cvml','DG-BSC@kantarainitiative.org');>http://kantarainitiative.org/mailman/listinfo/dg-bsc

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org <javascript:_e(%7B%7D,'cvml','DG-BSC@kantarainitiative.org');> http://kantarainitiative.org/mailman/listinfo/dg-bsc

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org <javascript:_e(%7B%7D,'cvml','DG-BSC@kantarainitiative.org');> http://kantarainitiative.org/mailman/listinfo/dg-bsc

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

Ok, so help me think this through: 1 - let's assume that e-IDAS decides to recognize 3 blockchains as reliable public ledgers 2 - I install an open source "core identity" app in my iPhone and link the private key to a transaction in one or more of the 3 blockchains (along the lines of https://s3.amazonaws.com/stampery-cdn/docs/Stampery-BTA-v5-whitepaper.pdf ) 3 - I go to some government authority (e.g.: the post office) and they link my core identity to some directory that they run (the authority becomes the "issuer" in the Verifiable Claims sense https://w3c.github.io/webpayments-ig/VCTF/use-cases/ ) 4 - I can establish personas and linked pairwise persistent pseudonyms using technologies and standards yet to be named. The standards protect me from tracking of my activities by the various service providers involved. I think this is called "triple-blind". 5 - A persona controls which attributes it associates with a PPP and whether the attribute is verifiable or just self-asserted Is there any other way of parsing the general blockchain id approach? Adrian On Fri, Sep 9, 2016 at 4:28 PM, Luk Vervenne <luk.vervenne@synergetics.be> wrote:

Indeed. It's like Jeff says… idm is just thàt, and needs not to be involved with personal data attributes. separation of concern.

luk

On 9 Sep 2016, at 22:23, Adrian Gropper <agropper@healthurl.com> wrote:

Oh, it's better than that. https://www.dlapiper.com/en/us/insights/ publications/2015/08/new-eu-regulation-for-electronic-signatures/

Adrian

On Friday, September 9, 2016, Luk Vervenne <luk.vervenne@synergetics.be> wrote:

...

No, a proper "Identification authory" that defines your *core identity.* Period.

It happens that - historically - some eu countries has this done by government. In the nineties Belgium gov. did it. UK has a set of idm now. And Notaries in the netherlands do it now too.

Luk

On 9 Sep 2016, at 21:45, John Wunderlich <john@wunderlich.ca> wrote:

You say that like government ID cards are a good thing....

Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN>

Call: +1 (647) 669-4749 eMail: john@wunderlich.ca

On 9 September 2016 at 11:52, Luk Vervenne <luk.vervenne@synergetics.be> wrote:

...

Luckily, ...I live in Europe where we have Gov ID cards. The trend you mention is a real and deliberate pest.

For your second problem we use a "discovery service" which maps pairwise pseudonym A of company X into pariwise pseudonym B for company Y We can do this for every web service so the user sees in his privayc app (Privacy Hub) what serivces where involved in any transaction. All services also communicate with the audut bus, so two per transaction. Maybe this is something for the blockchain?? It provides an audit summary (containing the transaction summary but no personal data)

Luk

On 9 Sep 2016, at 17:03, j stollman <stollman.j@gmail.com> wrote:

Luk, et al,

The devil being in the details: The industry has been incorporating more and more behavioral data into the authentication process to merely verify identity. Multi-factor authentication now commonly includes answering questions about relationships (mother's maiden name, second grade teacher's name) or behavior (favorite book or movie) just to verify an identity.

Arguably, we could just use biological data (fingerprints, iris scans, DNA) for identity verification, but because there are usually ways to hack a purely biometric system ("what you are"), it is often necessary to supplement such systems with "what you know" and "what you have". I don't know that anyone has come to consensus on a minimum set of data that would be sufficient to establish identity for all stakeholders.

A second problem arises when one RP seeks information about you from another RP, such as when a credit card issuers seeks information from others on your credit worthiness. This cross-RP collaboration implies that one cannot maintain separate personas for the new issuer and the reference sources the issuer uses to verify your credit-worthiness. The different personas will become cross-correlated. And over enough time, many (most? all?) of one's unique personas will become polluted by such cross-correlations.

Do we have a solution?

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Fri, Sep 9, 2016 at 2:51 AM, Luk Vervenne < luk.vervenne@synergetics.be> wrote:

Agreed Jeff,

The danger is organisations try to define identity by collecting attributes that ‘proof’ the identity. The next thing is sharing data over this "Know Your Customer” data. Blockchain or not!

This is why a *clean separation* is needed between * core identity* (as a representation of the individual online) versus personal ‘*attributes*’, which is data *about* the individual/persona. As such, an identity provider is only to *define* and/or *proof* the core identity. Period. (yes we have national ID cards in Europe)

In Thomas picture, the notion of *persona *in fact then holds two different elements: - a *pairwise persistent pseudonym* per service provider (read: no correlation) of a* fully* pairwise persistent pseudonym per web service (see: privacy-preservation in deep WS call chains) - a *persona* which (can) represent a selection (think a directed graph) of contextualized personal data to be shared, possibly valid over a number of organisations within that context.

The consistent use of pairwise persistent pseudonyms solves * a lot of problems* by rethinking identity * in a symmetrical way.* - Identity disclosure now becomes *the sole prerogative of the individual* - Analytics on *pairwise* pseudonymous identified data now becomes much more acceptable.

We have all the above done using using a SAML-ID-WSF2 and OpenID-UMA framework. It is complex. Time for blockchain-isch tech to make things simpler (where possible!)

Secondly, we should distance ourselves of where personal data is hosted: on premise, with the individual, in the ecosystem cloud or with a PDS vendor. The same authorisation methods should always be used.

Again, I plea to follow Thomas use case, with the separation of pseudo-identifiers and persona's

Luk.

On 8 Sep 2016, at 17:42, j stollman <stollman.j@gmail.com> wrote:

John,

With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain":

I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca> wrote:

Thomas;

This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" < hardjono@mit.edu> wrote:

Folks,

This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet).

One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP)

The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS).

When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created.

When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP).

At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP.

The PP keeps these transaction-identifiers as long as she needs, and may even archive them.

The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract.

If this is useful, I can write it up for the use-cases page.

/thomas/ _______________________________________________ DG-BSC mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

_______________________________________________ DG-BSC mailing list 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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

I suspect that "core identity" outside of a sophomore philosophy class is subject to a basic identity uncertainty principle whereby "core identity" and "identity attributes" are actually complementary variables 𝜎i𝜎a ≥ e/2 where e is a minimal identity constant. Call this Eve's Uncertainty Principle. Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN> Call: +1 (647) 669-4749 eMail: john@wunderlich.ca On 9 September 2016 at 21:51, Eve Maler <eve.maler@forgerock.com> wrote:

What is this "core identity" of which you all speak? :-)

Most of the proofing techniques in the world, in-person or not, are eminently spoofable, and there are lots of people in the world in circumstances where they don't have these techniques and documents available to them anyway. And there are heuristic but statistically pretty accurate ways to lock down someone's real-world identity using digital data (like what this company <http://www.bloomberg.com/news/articles/2016-08-05/this-company-has-built-a-profile-on-every-american-adult> does with data fusion).

Feeling feisty on a Friday night ;),

*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/> *London and Paris!*

On Fri, Sep 9, 2016 at 2:10 PM, Adrian Gropper <agropper@healthurl.com> wrote:

...

Ok, so help me think this through:

1 - let's assume that e-IDAS decides to recognize 3 blockchains as reliable public ledgers

2 - I install an open source "core identity" app in my iPhone and link the private key to a transaction in one or more of the 3 blockchains (along the lines of https://s3.amazonaws.com/stampery-cdn/docs/Stampery-BTA-v5- whitepaper.pdf )

3 - I go to some government authority (e.g.: the post office) and they link my core identity to some directory that they run (the authority becomes the "issuer" in the Verifiable Claims sense https://w3c.github.io/webpayments-ig/VCTF/use-cases/ )

4 - I can establish personas and linked pairwise persistent pseudonyms using technologies and standards yet to be named. The standards protect me from tracking of my activities by the various service providers involved. I think this is called "triple-blind".

5 - A persona controls which attributes it associates with a PPP and whether the attribute is verifiable or just self-asserted

Is there any other way of parsing the general blockchain id approach?

Adrian

On Fri, Sep 9, 2016 at 4:28 PM, Luk Vervenne <luk.vervenne@synergetics.be

...

wrote:

...

Indeed. It's like Jeff says… idm is just thàt, and needs not to be involved with personal data attributes. separation of concern.

luk

On 9 Sep 2016, at 22:23, Adrian Gropper <agropper@healthurl.com> wrote:

Oh, it's better than that. https://www.dlapiper.com /en/us/insights/publications/2015/08/new-eu-regulation-for-e lectronic-signatures/

Adrian

On Friday, September 9, 2016, Luk Vervenne <luk.vervenne@synergetics.be> wrote:

...

No, a proper "Identification authory" that defines your *core identity.* Period. It happens that - historically - some eu countries has this done by government. In the nineties Belgium gov. did it. UK has a set of idm now. And Notaries in the netherlands do it now too.

Luk

On 9 Sep 2016, at 21:45, John Wunderlich <john@wunderlich.ca> wrote:

You say that like government ID cards are a good thing....

Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN>

Call: +1 (647) 669-4749 eMail: john@wunderlich.ca

On 9 September 2016 at 11:52, Luk Vervenne <luk.vervenne@synergetics.be

...

wrote:

...

Luckily, ...I live in Europe where we have Gov ID cards. The trend you mention is a real and deliberate pest.

For your second problem we use a "discovery service" which maps pairwise pseudonym A of company X into pariwise pseudonym B for company Y We can do this for every web service so the user sees in his privayc app (Privacy Hub) what serivces where involved in any transaction. All services also communicate with the audut bus, so two per transaction. Maybe this is something for the blockchain?? It provides an audit summary (containing the transaction summary but no personal data)

Luk

On 9 Sep 2016, at 17:03, j stollman <stollman.j@gmail.com> wrote:

Luk, et al,

The devil being in the details: The industry has been incorporating more and more behavioral data into the authentication process to merely verify identity. Multi-factor authentication now commonly includes answering questions about relationships (mother's maiden name, second grade teacher's name) or behavior (favorite book or movie) just to verify an identity.

Arguably, we could just use biological data (fingerprints, iris scans, DNA) for identity verification, but because there are usually ways to hack a purely biometric system ("what you are"), it is often necessary to supplement such systems with "what you know" and "what you have". I don't know that anyone has come to consensus on a minimum set of data that would be sufficient to establish identity for all stakeholders.

A second problem arises when one RP seeks information about you from another RP, such as when a credit card issuers seeks information from others on your credit worthiness. This cross-RP collaboration implies that one cannot maintain separate personas for the new issuer and the reference sources the issuer uses to verify your credit-worthiness. The different personas will become cross-correlated. And over enough time, many (most? all?) of one's unique personas will become polluted by such cross-correlations.

Do we have a solution?

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Fri, Sep 9, 2016 at 2:51 AM, Luk Vervenne < luk.vervenne@synergetics.be> wrote:

Agreed Jeff,

The danger is organisations try to define identity by collecting attributes that ‘proof’ the identity. The next thing is sharing data over this "Know Your Customer” data. Blockchain or not!

This is why a *clean separation* is needed between * core identity* (as a representation of the individual online) versus personal ‘ *attributes*’, which is data *about* the individual/persona. As such, an identity provider is only to *define* and/or *proof* the core identity. Period. (yes we have national ID cards in Europe)

In Thomas picture, the notion of *persona *in fact then holds two different elements: - a *pairwise persistent pseudonym* per service provider (read: no correlation) of a* fully* pairwise persistent pseudonym per web service (see: privacy-preservation in deep WS call chains) - a *persona* which (can) represent a selection (think a directed graph) of contextualized personal data to be shared, possibly valid over a number of organisations within that context.

The consistent use of pairwise persistent pseudonyms solves * a lot of problems* by rethinking identity * in a symmetrical way.* - Identity disclosure now becomes *the sole prerogative of the individual* - Analytics on *pairwise* pseudonymous identified data now becomes much more acceptable.

We have all the above done using using a SAML-ID-WSF2 and OpenID-UMA framework. It is complex. Time for blockchain-isch tech to make things simpler (where possible!)

Secondly, we should distance ourselves of where personal data is hosted: on premise, with the individual, in the ecosystem cloud or with a PDS vendor. The same authorisation methods should always be used.

Again, I plea to follow Thomas use case, with the separation of pseudo-identifiers and persona's

Luk.

On 8 Sep 2016, at 17:42, j stollman <stollman.j@gmail.com> wrote:

John,

With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain":

I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca> wrote:

Thomas;

This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" < hardjono@mit.edu> wrote:

Folks,

This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet).

One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP)

The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS).

When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created.

When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP).

At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP.

The PP keeps these transaction-identifiers as long as she needs, and may even archive them.

The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract.

If this is useful, I can write it up for the use-cases page.

/thomas/ _______________________________________________ DG-BSC mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

_______________________________________________ DG-BSC mailing list 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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

_______________________________________________ DG-BSC mailing list 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

-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

Ok, having re-read the thread. The Persona Provider of Thomas is, in effect, a proxy server for the 'real' IDP. It has the function of hiding the identifiers between Alice and IDP. The fact they are pair wise pseudonymous isn't totally relevant - it's a nice feature but not the purpose of the Persona Provider. The PP can be an attribute aggregator (under Alice's authorization ) or can pass assertions or assertion references. I guess the point I'm trying to make is that the Persona Provider is not related to the discussion of "core identity " attributes nor to ID proofing or determination of entity uniqueness. Techniques for authentication of information and ID proofing are interesting but not the central topic for "blockchain identity". The question that needs some exploration for me is how can a persistent, potentially widely viewable, structure (maybe blockchain) be used to support or create identifiers or credentials that are portable from one idp to the next in Alice's chain of "Persona Providers" that allow Alice to assert the identifiers she wants to and attributes thd RP is willing to accept. All in a way that cannot be tracked or unpacked in reverse by the RP or colluding intermediaries to reveal the usage pattern or the identifiers Alice uses elsewhere. On Fri, Sep 9, 2016 at 7:50 PM Andrew Hughes <andrewhughes3000@gmail.com> wrote:

At the risk of taking this thread too far off track...

Identification is concerned with distinguishing a unique entity within the pool of entities to a degree of certainty.

One or more credentials are used to establish that this unique entity is associated ("bound") to information records at an "acceptable" authority (which might be deemed authoritative).

The attributes from that bound information record may be asserted to some relying party.

A group of organizations may decide that a specific group of attributes can be used for their main use cases. And they may name these attributes "core" within their trust framework or equivalent federation agreement.

I have forgotten the point under debate. :) On Fri, Sep 9, 2016 at 7:15 PM John Wunderlich <john@wunderlich.ca> wrote:

...

I suspect that "core identity" outside of a sophomore philosophy class is subject to a basic identity uncertainty principle whereby "core identity" and "identity attributes" are actually complementary variables

𝜎i𝜎a ≥ e/2 where e is a minimal identity constant. Call this Eve's Uncertainty Principle.

Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN>

Call: +1 (647) 669-4749 eMail: john@wunderlich.ca

On 9 September 2016 at 21:51, Eve Maler <eve.maler@forgerock.com> wrote:

...

What is this "core identity" of which you all speak? :-)

Most of the proofing techniques in the world, in-person or not, are eminently spoofable, and there are lots of people in the world in circumstances where they don't have these techniques and documents available to them anyway. And there are heuristic but statistically pretty accurate ways to lock down someone's real-world identity using digital data (like what this company <http://www.bloomberg.com/news/articles/2016-08-05/this-company-has-built-a-profile-on-every-american-adult> does with data fusion).

Feeling feisty on a Friday night ;),

*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/> *London and Paris!*

On Fri, Sep 9, 2016 at 2:10 PM, Adrian Gropper <agropper@healthurl.com> wrote:

...

Ok, so help me think this through:

1 - let's assume that e-IDAS decides to recognize 3 blockchains as reliable public ledgers

2 - I install an open source "core identity" app in my iPhone and link the private key to a transaction in one or more of the 3 blockchains (along the lines of https://s3.amazonaws.com/stampery-cdn/docs/Stampery-BTA-v5-whitepaper.pdf )

3 - I go to some government authority (e.g.: the post office) and they link my core identity to some directory that they run (the authority becomes the "issuer" in the Verifiable Claims sense https://w3c.github.io/webpayments-ig/VCTF/use-cases/ )

4 - I can establish personas and linked pairwise persistent pseudonyms using technologies and standards yet to be named. The standards protect me from tracking of my activities by the various service providers involved. I think this is called "triple-blind".

5 - A persona controls which attributes it associates with a PPP and whether the attribute is verifiable or just self-asserted

Is there any other way of parsing the general blockchain id approach?

Adrian

On Fri, Sep 9, 2016 at 4:28 PM, Luk Vervenne < luk.vervenne@synergetics.be> wrote:

...

Indeed. It's like Jeff says… idm is just thàt, and needs not to be involved with personal data attributes. separation of concern.

luk

On 9 Sep 2016, at 22:23, Adrian Gropper <agropper@healthurl.com> wrote:

Oh, it's better than that. https://www.dlapiper.com/en/us/insights/publications/2015/08/new-eu-regulati...

Adrian

On Friday, September 9, 2016, Luk Vervenne < luk.vervenne@synergetics.be> wrote:

...

No, a proper "Identification authory" that defines your *core identity.* Period. It happens that - historically - some eu countries has this done by government. In the nineties Belgium gov. did it. UK has a set of idm now. And Notaries in the netherlands do it now too.

Luk

On 9 Sep 2016, at 21:45, John Wunderlich <john@wunderlich.ca> wrote:

You say that like government ID cards are a good thing....

Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN>

Call: +1 (647) 669-4749 eMail: john@wunderlich.ca

On 9 September 2016 at 11:52, Luk Vervenne < luk.vervenne@synergetics.be> wrote:

> Luckily, ...I live in Europe where we have Gov ID cards. > The trend you mention is a real and deliberate pest. > > For your second problem we use a "discovery service" which maps > pairwise pseudonym A of company X into pariwise pseudonym B for company Y > We can do this for every web service so the user sees in his privayc > app (Privacy Hub) what serivces where involved in any transaction. > All services also communicate with the audut bus, so two per > transaction. > Maybe this is something for the blockchain?? > It provides an audit summary (containing the transaction summary but > no personal data) > > Luk > > On 9 Sep 2016, at 17:03, j stollman <stollman.j@gmail.com> wrote: > > Luk, et al, > > The devil being in the details: The industry has been incorporating > more and more behavioral data into the authentication process to merely > verify identity. Multi-factor authentication now commonly includes > answering questions about relationships (mother's maiden name, second grade > teacher's name) or behavior (favorite book or movie) just to verify an > identity. > > Arguably, we could just use biological data (fingerprints, iris > scans, DNA) for identity verification, but because there are usually ways > to hack a purely biometric system ("what you are"), it is often necessary > to supplement such systems with "what you know" and "what you have". I > don't know that anyone has come to consensus on a minimum set of data that > would be sufficient to establish identity for all stakeholders. > > A second problem arises when one RP seeks information about you from > another RP, such as when a credit card issuers seeks information from > others on your credit worthiness. This cross-RP collaboration implies that > one cannot maintain separate personas for the new issuer and the reference > sources the issuer uses to verify your credit-worthiness. The different > personas will become cross-correlated. And over enough time, many (most? > all?) of one's unique personas will become polluted by such > cross-correlations. > > Do we have a solution? > > Jeff > > > --------------------------------- > Jeff Stollman > stollman.j@gmail.com > +1 202.683.8699 > > > Truth never triumphs — its opponents just die out. > Science advances one funeral at a time. > Max Planck > > On Fri, Sep 9, 2016 at 2:51 AM, Luk Vervenne < > luk.vervenne@synergetics.be> wrote: > > Agreed Jeff, > > The danger is organisations try to define identity by collecting > attributes that ‘proof’ the identity. > The next thing is sharing data over this "Know Your Customer” data. > Blockchain or not! > > This is why a *clean separation* is needed between * core identity* (as > a representation of the individual online) versus personal ‘ > *attributes*’, which is data *about* the individual/persona. > As such, an identity provider is only to *define* and/or *proof* > the core identity. Period. (yes we have national ID cards in Europe) > > In Thomas picture, the notion of *persona *in fact then holds two > different elements: > - a *pairwise persistent pseudonym* per service provider (read: no > correlation) of a* fully* pairwise persistent pseudonym per web > service (see: privacy-preservation in deep WS call chains) > - a *persona* which (can) represent a selection (think a directed > graph) of contextualized personal data to be shared, possibly valid over a > number of organisations within that context. > > The consistent use of pairwise persistent pseudonyms solves * a lot > of problems* by rethinking identity * in a symmetrical way.* > - Identity disclosure now becomes *the sole prerogative of the > individual* > - Analytics on *pairwise* pseudonymous identified data now becomes > much more acceptable. > > We have all the above done using using a SAML-ID-WSF2 and OpenID-UMA > framework. It is complex. > Time for blockchain-isch tech to make things simpler (where > possible!) > > Secondly, we should distance ourselves of where personal data is > hosted: on premise, with the individual, in the ecosystem cloud or with a > PDS vendor. > The same authorisation methods should always be used. > > Again, I plea to follow Thomas use case, with the separation of > pseudo-identifiers and persona's > > Luk. > > On 8 Sep 2016, at 17:42, j stollman <stollman.j@gmail.com> wrote: > > John, > > With respect to your comment, "I think you have correctly > identified a normative inverse relationship between "Core Identity" > attributes what should be written openly to a blockchain": > > I share your belief in the separation of a Core Identity from > attributes included in various personas that may be unveiled to particular > RPs. But it is not clear to me where one can draw the line. The Core > Identity needs to have enough data to authenticate the user and his/her > various personas, so that the RP can then authorize activity based on the > attributes provided in the persona. But what data and how much of it do we > need to unmistakably authenticate the user? The more attributes we include > in the Core Identity, the more vulnerable the user becomes to having that > data used against them by an adversary who can break into the Core Identity > repository. > > Jeff > > > --------------------------------- > Jeff Stollman > stollman.j@gmail.com > +1 202.683.8699 > > > Truth never triumphs — its opponents just die out. > Science advances one funeral at a time. > Max Planck > > On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca> > wrote: > > Thomas; > > This aligns well with Canadian privacy views of a 'biographical > core' and the social reality that we all have many identities that we > present to the world. When I read this and note the piece that I just > posted about the potential conflict between the GDPR 'right to erasure' and > Blockchain, I think you have correctly identified a normative inverse > relationship between "Core Identity" attributes what should be written > openly to a blockchain. Exciting work. > > John Wunderlich, > > Sent frum a mobile device, > Pleez 4give speling erurz > > "...a world of near-total surveillance and endless record-keeping is > likely to be one with less liberty, less experimentation, and certainly far > less joy..." A. Michael Froomkin > > > > > On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" < > hardjono@mit.edu> wrote: > > Folks, > > This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet). > > One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP) > > The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS). > > When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created. > > When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP). > > At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP. > > The PP keeps these transaction-identifiers as long as she needs, and may even archive them. > > The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract. > > > If this is useful, I can write it up for the use-cases page. > > /thomas/ > _______________________________________________ > DG-BSC mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc > > > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > system manager. This message contains confidential information and is > intended only for the individual named. If you are not the named addressee > you should not disseminate, distribute or copy this e-mail. Please notify > the sender immediately by e-mail if you have received this e-mail by > mistake and delete this e-mail from your system. If you are not the > intended recipient you are notified that disclosing, copying, distributing > or taking any action in reliance on the contents of this information is > strictly prohibited. > > _______________________________________________ > DG-BSC mailing list > 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 > > > > >

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

_______________________________________________ DG-BSC mailing list 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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

--

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

-- *Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

Here’s a bit more input from the various points of view of major governments, complex supply chains and ISO & ITU-T…. The PP, as described, is a TAP (Trusted Attribute Provider - a common term). TAPs are an example of a Trusted Intermediary - PKI bridges, attribute brokers, independent certified assurers are other examples. The PP has much in common with RBAC - Role Based Access Control, where the relying party does not need to know the identity of the subject, only to have a trusted attribute (e.g. an entitlement (I am a member of X), an eligibility (I am over 18)) from an Authoritative Source i.e. is deemed authoritative by the community or in regulation. In most RBAC situations, the asserting party is the Authoritative Source - e.g. Boeing says this person is flight engineer on project X today, Raytheon says flight engineers on Project X can access this set of project data. Raytheon don’t need to know the flight engineer’s name, but they do need to know that Boeing (asserting party) can provide the bound identity if subsequently required. PP attributes are for authorisation & access control purposes, not for ID and authentication. However, some ID attributes may also form part of the PP attribute set for access control decisions. The pairwise pseudonymous tokens are interesting, but it seems to me that one is veronymous (ID disclosed) and the other is pseudonymous. And it seems to presume that mutual authentication between the TAP and RP has already occurred underneath. Perhaps it would be a good idea to map out how this might work in more detail. Re “authentication & proofing not being the central topic for block chain identity”, I disagree to the extent that without these, there is no trust in the BC at any Level of Assurance. One of the questions being asked today is how do we define LoA in the block chain? What would LoA 4 look like in terms of ISO 29115, or High in terms of US SP800-53 for cyber controls? Where should this discussion happen (see below re 26 Sep)? All that said, there are other aspects that also need to be considered. Privacy is an important factor. As described in the EU General Data Protection Regulation, a system that does not contain any Personally Identifiable Information (PII) is anonymous. If PII exists in a system that discloses attributes without identity, pseudonymity exists. The process of pseudonymisation is a trusted intermediary function between both the IDP and TAP, and the relying party. There can be more than one configuration of relationships. (IDP & TAP) - TI - RP, IDP - TAP - TI - RP. Organisationally, these could be separate legal entities or separate functions within one organisation. Generally, for reasons of compliance and anti-collusion, they should be separated in accordance with the principles of two man rules. ASINP (Architecture for the Secure Identification of Natural Persons) is a methodology for assessing and preventing collusion within governments regarding the issuance of government credentials. ASINP originated from the Belgian Government and was taken up by the many nations within the EU under the guidance of the European Commission. Collusion outside the government is another matter. Arguably, new techniques for big data and predictive data analytics are driving major holders of big data (potential attribute providers) to consider how to get value out of customer data. Microsoft declared several months ago that they are going to follow Google and Facebook to get max value, particularly from location data; Apple is taking a different approach “Differential Privacy” to obfuscate PII with other, dummy data. There are likely to be some big policy collisions ahead, particularly with governments. There is another small meeting next week between UN, EU, Apple, FB, MS, Google, Yahoo and Interpol to progress draft legal text around privacy vs surveillance. The existing dialogue is highlighting the need for new trusted intermediaries and much improved & more flexible key management. Some of this could/should be relevant to the DG-BSC discussion. Of note, all of the above is of interest to the Block Chain community in two major ways: How it affects what goes into the BC for business purposes, and what the BC then has to record and do as a result What functional components will be required within the BC’s underlying functionality. Australia has proposed to ISO that a new group or groups be established in ISO to develop standards for BCs. Other nations have responded to the proposal. Separately, there is at least one initiative in the banking sector to develop standards for BCs. Within UK, the British Standards Institute and some of the BC companies behind the banking sector initiative are meeting on 26 Sep in London to work out some next steps. These will likely be fed into the big ISO machine and may be discussed in Abu Dhabi, SC27 at the end of Oct. Colin Wallis is aware. The London meeting is an opportunity for KI to input some questions - please send any to me. How do we want to pull in useful inputs into our DG BSC discussions? We can’t eat the whole elephant. Where do we wish to focus in a way that ensures our efforts are relevant and useful? All comments welcome!!! regards, Patrick Patrick Curry Director British Business Federation Authority - BBFA Ltd M: +44 786 024 9074 T: +44 1980 620606 patrick.curry@bbfa.info www.bbfa.info – a not-for-profit, self-regulating body On 10 Sep 2016, at 08:04, Luk Vervenne <luk.vervenne@synergetics.be> wrote:

On 10 Sep 2016, at 06:23, Andrew Hughes <andrewhughes3000@gmail.com <mailto:andrewhughes3000@gmail.com>> wrote:

Ok, having re-read the thread.

The Persona Provider of Thomas is, in effect, a proxy server for the 'real' IDP. It has the function of hiding the identifiers between Alice and IDP. The fact they are pair wise pseudonymous isn't totally relevant - it's a nice feature but not the purpose of the Persona Provider. The PP can be an attribute aggregator (under Alice's authorization ) or can pass assertions or assertion references.

That is correct, but I argue there is a difference in intent: - Persona’s main purpose is providing access to contextual personal data to one or more organisations within that context. - Pairwise pseudonymous identifiers are there to never-disclose the core identity of the individual, as one of the means to re-establish the symmertical balance between individual and organisation. I feel this is a priority without which the rest is moot.

I guess the point I'm trying to make is that the Persona Provider is not related to the discussion of "core identity " attributes nor to ID proofing or determination of entity uniqueness.

Techniques for authentication of information and ID proofing are interesting but not the central topic for "blockchain identity".

The question that needs some exploration for me is how can a persistent, potentially widely viewable, structure (maybe blockchain) be used to support or create identifiers or credentials that are portable from one idp to the next in Alice's chain of "Persona Providers" that allow Alice to assert the identifiers she wants to and attributes thd RP is willing to accept.

All in a way that cannot be tracked or unpacked in reverse by the RP or colluding intermediaries to reveal the usage pattern or the identifiers Alice uses elsewhere.

Hence the paiwise pseudonymous tokens. I’m more interested in the audit (summary) of a policy-driven transaction between individual and organistiton either being sender and receiver. We work with sticky policies ending up in ecosystem connectors which - if agreed - generate those audit summaries (smart contracts) These are stored in a "proof-in-court” ecosystem database My hope (and I’m not a blockhain expert) is that we can use blockchain here, ...given some clear benefits! Luk

On Fri, Sep 9, 2016 at 7:50 PM Andrew Hughes <andrewhughes3000@gmail.com <mailto:andrewhughes3000@gmail.com>> wrote: At the risk of taking this thread too far off track...

Identification is concerned with distinguishing a unique entity within the pool of entities to a degree of certainty.

One or more credentials are used to establish that this unique entity is associated ("bound") to information records at an "acceptable" authority (which might be deemed authoritative).

The attributes from that bound information record may be asserted to some relying party.

A group of organizations may decide that a specific group of attributes can be used for their main use cases. And they may name these attributes "core" within their trust framework or equivalent federation agreement.

I have forgotten the point under debate. :) On Fri, Sep 9, 2016 at 7:15 PM John Wunderlich <john@wunderlich.ca <mailto:john@wunderlich.ca>> wrote: I suspect that "core identity" outside of a sophomore philosophy class is subject to a basic identity uncertainty principle whereby "core identity" and "identity attributes" are actually complementary variables

𝜎i𝜎a ≥ e/2 where e is a minimal identity constant. Call this Eve's Uncertainty Principle.

Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN>

Call: +1 (647) 669-4749 eMail: john@wunderlich.ca <mailto:john@wunderlich.ca>

On 9 September 2016 at 21:51, Eve Maler <eve.maler@forgerock.com <mailto:eve.maler@forgerock.com>> wrote: What is this "core identity" of which you all speak? :-)

Most of the proofing techniques in the world, in-person or not, are eminently spoofable, and there are lots of people in the world in circumstances where they don't have these techniques and documents available to them anyway. And there are heuristic but statistically pretty accurate ways to lock down someone's real-world identity using digital data (like what this company <http://www.bloomberg.com/news/articles/2016-08-05/this-company-has-built-a-profile-on-every-american-adult> does with data fusion).

Feeling feisty on a Friday night ;),

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/> London and Paris!

On Fri, Sep 9, 2016 at 2:10 PM, Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote: Ok, so help me think this through:

1 - let's assume that e-IDAS decides to recognize 3 blockchains as reliable public ledgers

2 - I install an open source "core identity" app in my iPhone and link the private key to a transaction in one or more of the 3 blockchains (along the lines of https://s3.amazonaws.com/stampery-cdn/docs/Stampery-BTA-v5-whitepaper.pdf <https://s3.amazonaws.com/stampery-cdn/docs/Stampery-BTA-v5-whitepaper.pdf> )

3 - I go to some government authority (e.g.: the post office) and they link my core identity to some directory that they run (the authority becomes the "issuer" in the Verifiable Claims sense https://w3c.github.io/webpayments-ig/VCTF/use-cases/ <https://w3c.github.io/webpayments-ig/VCTF/use-cases/> )

4 - I can establish personas and linked pairwise persistent pseudonyms using technologies and standards yet to be named. The standards protect me from tracking of my activities by the various service providers involved. I think this is called "triple-blind".

5 - A persona controls which attributes it associates with a PPP and whether the attribute is verifiable or just self-asserted

Is there any other way of parsing the general blockchain id approach?

Adrian

On Fri, Sep 9, 2016 at 4:28 PM, Luk Vervenne <luk.vervenne@synergetics.be <mailto:luk.vervenne@synergetics.be>> wrote: Indeed. It's like Jeff says… idm is just thàt, and needs not to be involved with personal data attributes. separation of concern.

luk

...

On 9 Sep 2016, at 22:23, Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote:

Oh, it's better than that. https://www.dlapiper.com/en/us/insights/publications/2015/08/new-eu-regulati... <https://www.dlapiper.com/en/us/insights/publications/2015/08/new-eu-regulation-for-electronic-signatures/>

Adrian

On Friday, September 9, 2016, Luk Vervenne <luk.vervenne@synergetics.be <mailto:luk.vervenne@synergetics.be>> wrote: No, a proper "Identification authory" that defines your core identity. Period. It happens that - historically - some eu countries has this done by government. In the nineties Belgium gov. did it. UK has a set of idm now. And Notaries in the netherlands do it now too.

Luk

...

On 9 Sep 2016, at 21:45, John Wunderlich <john@wunderlich.ca <>> wrote:

You say that like government ID cards are a good thing....

Sincerely, John Wunderlich @PrivacyCDN <https://twitter.com/PrivacyCDN>

Call: +1 (647) 669-4749 <tel:%2B1%20%28647%29%20669-4749> eMail: john@wunderlich.ca <>

On 9 September 2016 at 11:52, Luk Vervenne <luk.vervenne@synergetics.be <>> wrote: Luckily, ...I live in Europe where we have Gov ID cards. The trend you mention is a real and deliberate pest.

For your second problem we use a "discovery service" which maps pairwise pseudonym A of company X into pariwise pseudonym B for company Y We can do this for every web service so the user sees in his privayc app (Privacy Hub) what serivces where involved in any transaction. All services also communicate with the audut bus, so two per transaction. Maybe this is something for the blockchain?? It provides an audit summary (containing the transaction summary but no personal data)

Luk

...

On 9 Sep 2016, at 17:03, j stollman <stollman.j@gmail.com <>> wrote:

Luk, et al,

The devil being in the details: The industry has been incorporating more and more behavioral data into the authentication process to merely verify identity. Multi-factor authentication now commonly includes answering questions about relationships (mother's maiden name, second grade teacher's name) or behavior (favorite book or movie) just to verify an identity.

Arguably, we could just use biological data (fingerprints, iris scans, DNA) for identity verification, but because there are usually ways to hack a purely biometric system ("what you are"), it is often necessary to supplement such systems with "what you know" and "what you have". I don't know that anyone has come to consensus on a minimum set of data that would be sufficient to establish identity for all stakeholders.

A second problem arises when one RP seeks information about you from another RP, such as when a credit card issuers seeks information from others on your credit worthiness. This cross-RP collaboration implies that one cannot maintain separate personas for the new issuer and the reference sources the issuer uses to verify your credit-worthiness. The different personas will become cross-correlated. And over enough time, many (most? all?) of one's unique personas will become polluted by such cross-correlations.

Do we have a solution?

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com <> +1 202.683.8699 <tel:%2B1%20202.683.8699> <>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Fri, Sep 9, 2016 at 2:51 AM, Luk Vervenne <luk.vervenne@synergetics.be <>> wrote: Agreed Jeff,

The danger is organisations try to define identity by collecting attributes that ‘proof’ the identity. The next thing is sharing data over this "Know Your Customer” data. Blockchain or not!

This is why a clean separation is needed between core identity (as a representation of the individual online) versus personal ‘attributes’, which is data about the individual/persona. As such, an identity provider is only to define and/or proof the core identity. Period. (yes we have national ID cards in Europe)

In Thomas picture, the notion of persona in fact then holds two different elements: - a pairwise persistent pseudonym per service provider (read: no correlation) of a fully pairwise persistent pseudonym per web service (see: privacy-preservation in deep WS call chains) - a persona which (can) represent a selection (think a directed graph) of contextualized personal data to be shared, possibly valid over a number of organisations within that context.

The consistent use of pairwise persistent pseudonyms solves a lot of problems by rethinking identity in a symmetrical way. - Identity disclosure now becomes the sole prerogative of the individual - Analytics on pairwise pseudonymous identified data now becomes much more acceptable.

We have all the above done using using a SAML-ID-WSF2 and OpenID-UMA framework. It is complex. Time for blockchain-isch tech to make things simpler (where possible!)

Secondly, we should distance ourselves of where personal data is hosted: on premise, with the individual, in the ecosystem cloud or with a PDS vendor. The same authorisation methods should always be used.

Again, I plea to follow Thomas use case, with the separation of pseudo-identifiers and persona's

Luk.

...

On 8 Sep 2016, at 17:42, j stollman <stollman.j@gmail.com <>> wrote:

John,

With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain":

I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com <> +1 202.683.8699 <tel:%2B1%20202.683.8699> <>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca <>> wrote: Thomas;

This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" <hardjono@mit.edu <>> wrote:

Folks,

This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet).

One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/ <http://www.findthomas.net/blog/>). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP)

The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS).

When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created.

When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP).

At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP.

The PP keeps these transaction-identifiers as long as she needs, and may even archive them.

The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract.

If this is useful, I can write it up for the use-cases page.

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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

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

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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/> _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org <mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc <http://kantarainitiative.org/mailman/listinfo/dg-bsc>

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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. _______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org <mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc <http://kantarainitiative.org/mailman/listinfo/dg-bsc> -- Andrew Hughes CISM CISSP Independent Consultant In Turn Information Management Consulting

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com <> ca.linkedin.com/pub/andrew-hughes/a/58/682/ <> Identity Management | IT Governance | Information Security

-- Andrew Hughes CISM CISSP Independent Consultant In Turn Information Management Consulting

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com <> ca.linkedin.com/pub/andrew-hughes/a/58/682/ <> Identity Management | IT Governance | Information Security

_______________________________________________ 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

John, I agree that it would be valuable to define an ethics of identity. I think that this would need to be supplemented with a technical analysis of vulnerability and harm. In my observation, most people tend to look at the ramifications of different identity schemes only within the context of the application that are trying to support. I suggest that it would be better to look at worst-case impacts of disclosing particular attributes and combinations of attributes. It is important to look at worst-case impacts because any persistent attributes are likely to survive changes in political/social regimes, making people who appear to be "safe" to day, vulnerable tomorrow. The transgender problem you raise is a good example. Others include the following: 1. Thirty years ago, your street address was sufficient to target people for violence in Belfast. 2. In many countries a person's family name is sufficient basis to target them for ethnic/tribal/caste violence 3. Face images -- used for facial recognition -- could similarly be used for ethnic targeting. Jeff --------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com> Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Sat, Sep 10, 2016 at 6:36 AM, John Wunderlich <john@wunderlich.ca> wrote:

Jeff;

The first and framing issue is that we don't have, that I know of, an 'ethics of identity' to help identity professionals or identity technologists or identity researchers distinguish between what they can do and what they should do (although ethics review boards in academe may have opined on this in individuals studies). For example, consider a common identity attribute like gender on passports. I recall being at a conference where the then Homeland Security Secretary was on a panel with a transgender activist who pointed out that if his birth gender (female) was on his passport that could be a death sentence in some countries. Most of what the GDPR uses as examples of 'sensitive' data have similar potentially devastating impacts if revealed to the wrong authorities, inappropriate individuals or are made public. Ethical guidelines or an "Ethics of Identity" would help us separate that which is real world analog Alice from the digital Core Identity and derived personas and attributes that get picked up and used in Thomas' diagram.

Personas would run the gamut from unique one time revocable and anonymous to persistent non-revocable government issued personas. And I assume that Thomas' model can be used accross the spectrum. Problems would arise however, if systems expected that Alice would have one and only one Persona Provider. That may not be inherent or implicit in the design that we have seen, but I worry that such an identity architecture would be prone to network effects and, even if individuals could run their own or select from several persona providers, in a reasonably short order there would be (as in search or social networking) a single dominant player. And what would be the constraints on such a player.

If Thomas can apply the Core-ID and leverage other technologies to architecturally ensure a multiplicity of persona providers, for an Alice controlled persona provider ecosystem in which identity professionals could apply ethical guidelines in building particular systems, that would be a hell of a use case;-0

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

_____________________________ From: j stollman <stollman.j@gmail.com> Sent: Thursday, September 8, 2016 11:42 AM Subject: Re: [DG-BSC] User-Managed Identities for Blockchains (using UMA for user-centric control over blockchain identities) To: John Wunderlich <john@wunderlich.ca> Cc: Thomas Hardjono <hardjono@mit.edu>, <hardjono@media.mit.edu>, < dg-bsc@kantarainitiative.org>

John,

With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain":

I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

Thomas;

This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" < hardjono@mit.edu> wrote:

Folks,This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet).One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP)The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS).When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created.When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP).At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP.The PP keeps these transaction-identifiers as long as she needs, and may even archive them. The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract.If this is useful, I can write it up for the use-cases page./thomas/_______________________________________________DG-BSC mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc

...

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

Out of scope, but two data points regarding the ethics of data: 1. The most robust fabric of formal ethics for the use of sensitive information is certainly lawyers' codes of professional ethics (déontologie, Code of Professional Conduct, etc.) These have long histories and get tested anew every day, including in confrontations between different legal systems. They deal with the dilemma that the client must be confident in confiding everything, the lawyer must use client info only to help the client, and the lawyer must not be party to crime or fraud. This requires squaring many circles. 2. With respect to big data, I would think that the issue overlaps with the ethics of AI. On Sun, Sep 11, 2016 at 4:04 PM, John Wunderlich <john@wunderlich.ca> wrote:

Jeff;

As it happens, one of the initiatives of the Kantara Initiative is to work or advocate towards an Identity Professionals Association. Out of scope for this DG, but probably a good place to come up with a Code of Conduct or Ethics code based as you suggest on vulnerability and harm.

Parenthetically, I wonder if such a code has been proposed for “Big Data” and the data scientists who work there???

On Sep 11, 2016, at 15:20, j stollman <stollman.j@gmail.com> wrote:

John,

I agree that it would be valuable to define an ethics of identity. I think that this would need to be supplemented with a technical analysis of vulnerability and harm. In my observation, most people tend to look at the ramifications of different identity schemes only within the context of the application that are trying to support. I suggest that it would be better to look at worst-case impacts of disclosing particular attributes and combinations of attributes. It is important to look at worst-case impacts because any persistent attributes are likely to survive changes in political/social regimes, making people who appear to be "safe" to day, vulnerable tomorrow. The transgender problem you raise is a good example. Others include the following:

1. Thirty years ago, your street address was sufficient to target people for violence in Belfast. 2. In many countries a person's family name is sufficient basis to target them for ethnic/tribal/caste violence 3. Face images -- used for facial recognition -- could similarly be used for ethnic targeting.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Sat, Sep 10, 2016 at 6:36 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

Jeff;

The first and framing issue is that we don't have, that I know of, an 'ethics of identity' to help identity professionals or identity technologists or identity researchers distinguish between what they can do and what they should do (although ethics review boards in academe may have opined on this in individuals studies). For example, consider a common identity attribute like gender on passports. I recall being at a conference where the then Homeland Security Secretary was on a panel with a transgender activist who pointed out that if his birth gender (female) was on his passport that could be a death sentence in some countries. Most of what the GDPR uses as examples of 'sensitive' data have similar potentially devastating impacts if revealed to the wrong authorities, inappropriate individuals or are made public. Ethical guidelines or an "Ethics of Identity" would help us separate that which is real world analog Alice from the digital Core Identity and derived personas and attributes that get picked up and used in Thomas' diagram.

Personas would run the gamut from unique one time revocable and anonymous to persistent non-revocable government issued personas. And I assume that Thomas' model can be used accross the spectrum. Problems would arise however, if systems expected that Alice would have one and only one Persona Provider. That may not be inherent or implicit in the design that we have seen, but I worry that such an identity architecture would be prone to network effects and, even if individuals could run their own or select from several persona providers, in a reasonably short order there would be (as in search or social networking) a single dominant player. And what would be the constraints on such a player.

If Thomas can apply the Core-ID and leverage other technologies to architecturally ensure a multiplicity of persona providers, for an Alice controlled persona provider ecosystem in which identity professionals could apply ethical guidelines in building particular systems, that would be a hell of a use case;-0

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

_____________________________ From: j stollman <stollman.j@gmail.com> Sent: Thursday, September 8, 2016 11:42 AM Subject: Re: [DG-BSC] User-Managed Identities for Blockchains (using UMA for user-centric control over blockchain identities) To: John Wunderlich <john@wunderlich.ca> Cc: Thomas Hardjono <hardjono@mit.edu>, <hardjono@media.mit.edu>, < dg-bsc@kantarainitiative.org>

John,

With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain":

I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

Thomas;

This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" < hardjono@mit.edu> wrote:

Folks,This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet).One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP)The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS).When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created.When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP).At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP.The PP keeps these transaction-identifiers as long as she needs, and may even archive them. The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract.If this is useful, I can write it up for the use-cases page./thomas/_______________________________________________DG-BSC mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc

...

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

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

-- @commonaccord

Under GDPR individuals will have a right of action - and can be represented by an advocacy group (effectively like a class action). See Art 79 and 80. http://www.commonaccord.org/index.php?action=doc&file=Wx/eu/europa/eur-lex/GDPR/Form/0.md#Article.79.Sec On Sun, Sep 11, 2016 at 6:56 PM, Adrian Gropper <agropper@healthurl.com> wrote:

Professionalism is not the issue. The only kind of identity professionals I see are the ones in IAPP working to protect the interests of institutions at the expense of the individuals. Unless individuals have a right of action, the way we have with lawyers and doctors, a profession's ethics are really just regulation.

Adrian

On Sun, Sep 11, 2016 at 4:36 PM, James Hazard <james.g.hazard@gmail.com> wrote:

...

Out of scope, but two data points regarding the ethics of data:

1. The most robust fabric of formal ethics for the use of sensitive information is certainly lawyers' codes of professional ethics (déontologie, Code of Professional Conduct, etc.) These have long histories and get tested anew every day, including in confrontations between different legal systems. They deal with the dilemma that the client must be confident in confiding everything, the lawyer must use client info only to help the client, and the lawyer must not be party to crime or fraud. This requires squaring many circles.

2. With respect to big data, I would think that the issue overlaps with the ethics of AI.

On Sun, Sep 11, 2016 at 4:04 PM, John Wunderlich <john@wunderlich.ca> wrote:

...

Jeff;

As it happens, one of the initiatives of the Kantara Initiative is to work or advocate towards an Identity Professionals Association. Out of scope for this DG, but probably a good place to come up with a Code of Conduct or Ethics code based as you suggest on vulnerability and harm.

Parenthetically, I wonder if such a code has been proposed for “Big Data” and the data scientists who work there???

On Sep 11, 2016, at 15:20, j stollman <stollman.j@gmail.com> wrote:

John,

I agree that it would be valuable to define an ethics of identity. I think that this would need to be supplemented with a technical analysis of vulnerability and harm. In my observation, most people tend to look at the ramifications of different identity schemes only within the context of the application that are trying to support. I suggest that it would be better to look at worst-case impacts of disclosing particular attributes and combinations of attributes. It is important to look at worst-case impacts because any persistent attributes are likely to survive changes in political/social regimes, making people who appear to be "safe" to day, vulnerable tomorrow. The transgender problem you raise is a good example. Others include the following:

1. Thirty years ago, your street address was sufficient to target people for violence in Belfast. 2. In many countries a person's family name is sufficient basis to target them for ethnic/tribal/caste violence 3. Face images -- used for facial recognition -- could similarly be used for ethnic targeting.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Sat, Sep 10, 2016 at 6:36 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

Jeff;

The first and framing issue is that we don't have, that I know of, an 'ethics of identity' to help identity professionals or identity technologists or identity researchers distinguish between what they can do and what they should do (although ethics review boards in academe may have opined on this in individuals studies). For example, consider a common identity attribute like gender on passports. I recall being at a conference where the then Homeland Security Secretary was on a panel with a transgender activist who pointed out that if his birth gender (female) was on his passport that could be a death sentence in some countries. Most of what the GDPR uses as examples of 'sensitive' data have similar potentially devastating impacts if revealed to the wrong authorities, inappropriate individuals or are made public. Ethical guidelines or an "Ethics of Identity" would help us separate that which is real world analog Alice from the digital Core Identity and derived personas and attributes that get picked up and used in Thomas' diagram.

Personas would run the gamut from unique one time revocable and anonymous to persistent non-revocable government issued personas. And I assume that Thomas' model can be used accross the spectrum. Problems would arise however, if systems expected that Alice would have one and only one Persona Provider. That may not be inherent or implicit in the design that we have seen, but I worry that such an identity architecture would be prone to network effects and, even if individuals could run their own or select from several persona providers, in a reasonably short order there would be (as in search or social networking) a single dominant player. And what would be the constraints on such a player.

If Thomas can apply the Core-ID and leverage other technologies to architecturally ensure a multiplicity of persona providers, for an Alice controlled persona provider ecosystem in which identity professionals could apply ethical guidelines in building particular systems, that would be a hell of a use case;-0

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

_____________________________ From: j stollman <stollman.j@gmail.com> Sent: Thursday, September 8, 2016 11:42 AM Subject: Re: [DG-BSC] User-Managed Identities for Blockchains (using UMA for user-centric control over blockchain identities) To: John Wunderlich <john@wunderlich.ca> Cc: Thomas Hardjono <hardjono@mit.edu>, <hardjono@media.mit.edu>, < dg-bsc@kantarainitiative.org>

John,

With respect to your comment, "I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain":

I share your belief in the separation of a Core Identity from attributes included in various personas that may be unveiled to particular RPs. But it is not clear to me where one can draw the line. The Core Identity needs to have enough data to authenticate the user and his/her various personas, so that the RP can then authorize activity based on the attributes provided in the persona. But what data and how much of it do we need to unmistakably authenticate the user? The more attributes we include in the Core Identity, the more vulnerable the user becomes to having that data used against them by an adversary who can break into the Core Identity repository.

Jeff

--------------------------------- Jeff Stollman stollman.j@gmail.com +1 202.683.8699 <stollman.j@gmail.com>

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Thu, Sep 8, 2016 at 7:18 AM, John Wunderlich <john@wunderlich.ca> wrote:

...

Thomas;

This aligns well with Canadian privacy views of a 'biographical core' and the social reality that we all have many identities that we present to the world. When I read this and note the piece that I just posted about the potential conflict between the GDPR 'right to erasure' and Blockchain, I think you have correctly identified a normative inverse relationship between "Core Identity" attributes what should be written openly to a blockchain. Exciting work.

John Wunderlich,

Sent frum a mobile device, Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin

On Thu, Sep 8, 2016 at 12:23 AM -0400, "Thomas Hardjono" < hardjono@mit.edu> wrote:

Folks,This may or may not be a use-case proper for BSC-DG, but I thought I'd mention it here because its an "infrastructure" technology that supports scaling of blockchains. (analogy: DNS is not part of Internet routing in TCP/IP, but it sure does help us use the Internet).One of the key concepts we (at MIT) are trying to develop further in CoreID (diagram is here http://www.findthomas.net/blog/). Part of it is the idea of a new kind of identity provider called the "persona provider" (PP)The Persona Provider could be implemented as a combination of an UMA Authorization Server combined with an UMA Resource Server. (PP = AS + RS).When Alice creates an account at the Persona Provider (PP), she convinces the PP initially that she is legit by supplying the PP with signed assertions (blinded assertion) which the Core Identity Issuer (upstream) has created.When Alice needs to transact on the blockchain using an anonymous-verifiable identity, she goes to her account at the PP and self-generates a transaction-identity (transaction-identifier) to be used on the blockchain or within a smart contract. She can self-generate as many transaction-identifiers as she needs -- no limit. The PP provides the crypto-tools to do this (just like bitcoin-wallets / client softwares or PGP).At the same time, she could optionally set policy on the account, treating the the blinded assertions (from the Core Identity Issuer) as resources. The transaction identities (which are anonymous-verifiable strings) can also be treated as resources sitting on the PP.The PP keeps these transaction-identifiers as long as she needs, and may even archive them. The PP also makes available a Identity Verification end-point (API) that allows the counter-party (RP) -- or anyone for that matter -- to verify a transaction-identifier found on a blockchain or in a smart-contract.If this is useful, I can write it up for the use-cases page./thomas/_______________________________________________DG-BSC mailing listDG-BSC@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-bsc

...

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

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

-- @commonaccord

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

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

-- @commonaccord