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.AdrianOn 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:
- Thirty years ago, your street address was sufficient to target people for violence in Belfast.
- In many countries a person's family name is sufficient basis to target them for ethnic/tribal/caste violence
- Face images -- used for facial recognition -- could similarly be used for ethnic targeting.
Jeff--------------------------------- Jeff Stollman+1 202.683.8699Truth never triumphs — its opponents just die out.Science advances one funeral at a time.Max PlanckOn 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;-0John 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+1 202.683.8699Truth never triumphs — its opponents just die out.Science advances one funeral at a time.Max PlanckOn 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 FroomkinOn 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.o rg 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
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/