My vote is for different but persistent pairwise pseudonyms/persona (so per service provider / per web service).I that sense it is a “fully" persistent pairwise pseudonymisation / persona that can dive into the "deep web serivce call chains" needed to preform an business service.
luk
On 8 Sep 2016, at 14:22, Adrian Gropper <agropper@healthurl.com> wrote:
AdrianThe tools for privacy engineering identity are out there but the governance model that will put them together in a sustainable decentralized way remains elusive.Privacy engineering identity can build on standards (and would-be standards) including: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.
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.
- 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
______________________________
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 list DG-BSC@kantarainitiative.org http://kantarainitiative.org/m ailman/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/ _________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-bsc