@FindThomas

Digital Identity, Trust and Privacy on the open Internet

Archive for the ‘Identity’ Category

Public keys on blockchains: confusing existence with trust

without comments

Today Identity and Access Management (IAM) represents a core component of the Internet infrastructure,  without which users would not be able to obtain online services in a timely and scalable manner. Enterprise IAM infrastructures are well integrated into other enterprise infrastructure services — such as directory services — which provide control over employees and assets. In the case of Consumer IAM most end-users are oblivious to the underlying identity federation infrastructures that allow them to perform Web Single Sign-On (SSO) to various online services and which enables them to grant their mobile apps access to various personal resources (e.g. contacts list, calendar, etc).

The recent emergence of the Bitcoin system has created various discourses of the role of “blockchain identity”. Here the three notable fundamental features of Bitcoin are its combined use of:

  • peer-to-peer network of physically distributed mining nodes,
  • consensus-based transaction status agreement algorithm and
  • restrictive scripting language (opcodes) for transaction expression.

These three aspects of the Bitcoin system provide mining nodes with true independence in processing transactions, subject only to the 51\% majority requirement of the consensus scheme. It is precisely this node-independence that translates to “user independence” in the sense of the user not being beholden to any one mining node (or a small minority of nodes) in the Bitcoin system.

However, it is this “user independence” (in the context of Bitcoin) that have led many to incorrectly extrapolate (speculate) that the same degree user independence can be achieved in all DLTs (distributed ledger technology) in general — something that is not necessarily true in DLTs generically speaking. The Bitcoin system is an instance of a DLT, but not all proposed DLTs possess the three fundamental features of Bitcoin.

Furthermore, many commentators have equated “user independence” (in Bitcoin) to “individual empowerment” in DLTs in general, a jump in speculation that is too far and which have led to confusion among the non-technical audience.

This misunderstanding regarding individual empowerment is exacerbated when the use of self-issued public-key pairs (in the Bitcoin system) is extrapolated to mean that these self-issued keys can be used as a “digital identity” for individuals in general. More specifically, the use of self-issued public-key pairs have led many to deduce (incorrectly) that a public-key used in the Bitcoin system can be “trusted” as a “digital identity” simply because it has been recorded on a transaction-block which has been replicated by all nodes on the peer-to-peer network.

That is, the existence of a key in transaction block is being confused with trust in the provenance and ownership of that key.

Some have even coined the term “trustless” when referring to the peer-to-peer network of mining nodes, forgetting that high-value transaction networks are built on both technical-trust and legal-trust — both leading to business and social trust.

It is worth recalling that this problem of digital identity versus public keys emerged first in the mid-1990s in the context of self-signed X509 certificates,  Simple PKI (RFC2693) and in the Pretty Good Privacy (PGP) system (RFC1991). Although an implementation of the PGP system may provide technical-trust, the PGP proposal was never broadly adopted by industry due to a lack of a corresponding model for business and legal trust.

Written by thomas

April 21st, 2017 at 7:56 pm

Core Identity Issuers (Part II)

without comments

Continuing from the previous post (Part I of the Core Identity series), the goal of a Core Identity Issuer (CoreID Issuer) is to collate sufficient data – aggregate data and non-PII data — from members of a given Circle of Trust in order to create a Core Identity and Core Identifier for a given user (see Figure).

The Issuer performs this task as a trusted member of the Circle of Trust, governed by rules of operations (i.e. legal contract) and with the consent of the user. Architectures and techniques such as MIT OPAL/Enigma can be used here in order for the CoreID Issuer to obtain privacy-preserving aggregate data from the various sources who are members of the Circle of Trust.

 

coreid-issuer-v03png

The goals of the Core-ID Issuer within a Circle of Trust are as follows:

  • Onboard a member-user: The Issuer’s primary function is to on-board users who are known to the CoT community, and who have requested and consented to the creation of a Core Identity.
  • Collate PII-free data into a Core Identity: The Issuer obtains aggregate data and other PII-free data regarding the user from members of the CoT. This becomes the core identity for the user, which is retained by the Issuer for the duration selected by the user. The Issuer must keep the core identity as secret, accessible only to the user.
  • Generate Core Identifier (unlinkable): For a given user and their core identity, the Issuer generates a core identifier (e.g. random number) that must be unlikable to the core identity. Note that a core identifier must not be used in a transaction. The core identifier value may be contained as a signed certificate or other signed data structure, with the Persona Provider as its intended audience (see Figure).
  • Issue Core Assertions regarding the Core Identifier: The purpose of the Issuer generating a core identifier is to allow PII-free core-assertions regarding the user to be created. These signed core assertions must retain the privacy of the user, and must declare assertions about the core identifier.
  • Interface with Persona Providers: The Issuer’s main audience is the Persona Provider, who must operate with the Issuer under legal trust framework that calls-out user privacy as a strict requirement. The Issuer must make available the necessary issuance end-points (i.e. APIs) as well as validation end-points to the Persona Provider. In some cases, from an operational deployment view the Issuer and Persona Provider may be co-located or even tightly coupled under the same provider entity, although the functional difference and boundaries are clear.

Written by thomas

September 20th, 2016 at 6:58 pm

Core Identities and Transaction Identifiers for Blockchains

without comments

Etymology: Middle French identité, from Late Latin identitat-, identitas, probably from Latin identidem repeatedly, contraction of idem et idem, literally, same and same (Merriam-Webster Dictionary).

Identity is about trusted data — trusted personal data. Human beings live within social constructs and communities. People who know me can vouch for me. Organizations that know me can issue assertions or attestations about me.

At the heart of all this is the notion of the core identity, something that is inherent as part of me and inalienable from me.

There are a number of key concepts and principles underlying the notion of core identities, core identifiers and personas (see Figure).

coreid-persona-concept-v04png

 

A fundamental concept is that of derived identities and derived identifiers which provides not only privacy to its user (the person or organization that it represents) but also a degree of defense in the case of attacks against identity providers (e.g. identity theft) and for a safety net in the rare case of weaknesses within the underlying cryptographic implementations.

I would argue that transaction identities and transaction identifiers are the forms of identities that should be used on the Internet and that they must be derived (e.g. cryptographically) from a core identity which itself must be kept as private or secret. Should a transaction identity be compromised or stolen, it can be placed on a public “blacklist” and a new one be derived for the user. The derivation process or algorithms must maintain the privacy of the user and the secrecy of the user’s core identity.

Some definitions:

We define identity as the collective aspect of the set of characteristic or features by which a thing (e.g. human; device; organization) is recognizable and distinguishable one from another.  In the context of a human person, individuality of a person plays an important role in that it allows a community of people to recognize the distinct characteristics of an individual person and consider the person as a persisting entity.

  • Core identity: The collective aspect of the set of characteristics (as represented by personal data) by which a person is uniquely recognizable, and from which a unique core identifier may be generated based on the set of relevant personal data.

Thus, for example, the set of transaction data associated with a person can be collated and be used to create a core identity that distinguishes that person from others. Out of this set of transaction data, a core identifier may be generated and be held as a joint secret by its issuer and the person. The core identity pertaining to a person must be kept secret, and not be used in transactions.

  • Core Identifier: A secret data (e.g. string) or secret mechanism (e.g. crypto function) that uniquely identifies a person or entity. The core identifier must be immutable, must be kept secret, and never be used directly in transactions.
  • Persona: A persona is defined by and created based on a collection of attributes used in a given context or a given relationship. Thus, a person may have a work-persona, home-persona, social-persona, and others.  Each of these personas is context-dependent and involves only the relevant subset of the core identity characteristics of that person. A person may have one or more personas.
  • Transaction Identity and Identifier: When an individual seeks to perform a transaction (e.g. on the Internet, on a blockchain or other transacting mediums) he or she chooses a relevant persona and derives from that persona a transaction identity (and corresponding digital identifier) to be used in the transaction. A transaction identity maybe short-lived and may even be created only for that single transaction instance. A useful analogy is that of credit card numbers, which may be used at a Point of Sale (POS) locations without the user needing to provide any additional identifiers (i.e. reveal data from their core identity such as Social Security Number) and which may be replaced at any time without impacting the user’s core identity.

Written by thomas

September 8th, 2016 at 3:56 am

Posted in Identity

Tagged with