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... 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<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<tel:%2B1%20202.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<tel:%2B1%20202.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 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. _______________________________________________ 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/