Identity can be a real pain to discuss. #GoodID turns about to be a great way to talk about the diverse needs of different stakeholders in digital identity, resulting in actionable plans to shift policy. Continue reading →
<img fetchpriority="high" decoding="async" src="https://blog.joeandrieu.com/wp-content/uploads/2019/02/dreamstimeextrasmall_77238067.jpg" alt="" class="wp-image-1395" width="281" height="187" srcset="https://blog.joeandrieu.com/wp-content/uploads/2019/02/dreamstimeextrasmall_77238067.jpg 480w, https://blog.joeandrieu.com/wp-content/uploads/2019/02/dreamstimeextrasmall_77238067-300x200.jpg 300w" sizes="(max-width: 281px) 100vw, 281px" /> Ancient barbarian warrior or Gladiator ready to fight Identity can be a real pain to discuss. I’ve been to dozens of workshops and conferences over the last decade plus and the quality of engagement varies from exciting, enthusiastic progress to frustrating, disheartening dysfunction—even within the same event. So many of us bring our own ax to grind that even when we think we are in agreement, we can spend ridiculous amounts of time in rat holes and rabbit holes that just don’t go anywhere productive. Yet, identity matters. So we push on through, hoping to forge common ground and make headway against the seemingly intractable task of figuring out how identity should work in the digital age. So it is rare that I get to enjoy as productive a conversation about identity as I did earlier this month at Good ID: What’s policy got to do with it?, organized by the Omidyar Network, run by Caribou Digital, and held at the Shorenstein Center of the Harvard Kennedy School. It wasn’t a collaborative writing exercise like we host at Rebooting the Web of Trust. It wasn’t an unconference open space like we gather for at the Internet Identity Workshop. It wasn’t a trade conference with presentations and panels like we get at Know Identity. Nor was it a large scale summit bringing together the international community with technologists like ID2020. On the contrary, it was an intimate gathering of passionate and experienced individuals from diverse fields, first discussing what “Good ID” might mean and how policy can help us get there, then committing to concrete actions to collectively advance the cause. Not only did we avoid the all too common pitfalls I’ve seen again and again at other gatherings, under the calm, competent hand of facilitator Tessa Finlev of the Institute for the Future, we rappelled from a stratospheric, high-concept, open discussion about what Good ID means, down to specific, detailed, self-assigned marching orders. <img decoding="async" src="https://blog.joeandrieu.com/wp-content/uploads/2019/02/dreamstimeextrasmall_49235755.jpg" alt="Fan boy photo" class="wp-image-1390" width="240" height="160" srcset="https://blog.joeandrieu.com/wp-content/uploads/2019/02/dreamstimeextrasmall_49235755.jpg 480w, https://blog.joeandrieu.com/wp-content/uploads/2019/02/dreamstimeextrasmall_49235755-300x200.jpg 300w" sizes="(max-width: 240px) 100vw, 240px" /> [Not actually me] I apologize for the apparent fan-boy nature of what I’ve written so far, but creating a productive dialog on identity is hard. Omidyar and Caribou Digital deserve credit for deftly bringing a challenging topic to such a productive engagement. The meeting brought together great people and guided us through a focused conversation leading to actionable tasks. What was particularly exciting about the Good ID workshop is that it is focused on how we transform policy to realize the ambitions of well-meaning identity advocates everywhere. At the end of the day, it doesn’t matter what the “Identerati” talk about if policy makers ignore the lessons learned from literally decades of experiments in digital identity. Billions of dollars have been invested in bringing digital identity systems to bear on the world’s problems. From consumer-based identity services from Microsoft and Facebook, to sovereign identity systems like Aadhaar in India or RealID in the United States, to the most recent open standard advances of OpenID Connect and immanent decentralized identifier standard at the W3C. The key failure point in extant systems—and the greatest risk in those still under development—is failure of decision makers to make the right decisions. These were failures in policy, not technology. With Facebook, the system worked. We just didn’t understand how it could be manipulated and abused until Cambridge Analytica showed us. With Aadhaar, the biometrics and authentication technologies work as intended—it just overcentralizes too much personal data in a brittle state mandated, privately run system, effectively creating a vast digital surveillance system. With OpenID, large companies like Facebook and Google were happy to issue “identities” but refused to accept them from others, resulting in an extension of their monopoly power rather than the liberating user-centric vision its inventors intended. With decentralized identifiers, I have no doubt that the underlying technology will deliver the basic nuts and bolts of an identity layer, but will credential issuers and relying parties adopt the technology as we intend? Or will they co-opt the basic function to re-intermediate themselves into our digital lives? The challenge isn’t in the technology, it is in shifting the mindset, perspective, and will of decision makers. The hard part is shifting the policy of the powers in charge, toward creating and maintaining identity systems that respect and ensure human dignity rather than trapping people in technology distopias governed by the tyranny of data, where what’s in the database matters more than the humanity of the person in front of you. And that is precisely what Good ID is all about. <img loading="lazy" decoding="async" src="https://blog.joeandrieu.com/wp-content/uploads/2019/02/dreamstimeextrasmall_122574196.jpg" alt="" class="wp-image-1383" width="276" height="184" srcset="https://blog.joeandrieu.com/wp-content/uploads/2019/02/dreamstimeextrasmall_122574196.jpg 480w, https://blog.joeandrieu.com/wp-content/uploads/2019/02/dreamstimeextrasmall_122574196-300x200.jpg 300w" sizes="auto, (max-width: 276px) 100vw, 276px" /> Two businesspersons shaking hands in agreement in casual business setting at office It’s a conversation about shifting policy at every level to better support humanity in the digital age. It’s about taking all stakeholders’ needs into account, from law enforcement to tax authorities, from illegal immigrants to victims of domestic violence, from mega corporations with a billion users to local community organizations like churches and schools. Each and every one of these constituencies bring unique perspectives and needs to the conversation about digital identity. Some need rigorous accountability, others need the freedom to engage society on their own terms. Some need to set and enforce regulatory frameworks that cross international boundaries, others just want to be able to communicate with people they trust. Some thrive in Western notions of individuality and freedom, others feel more at home with notions of harmony and placing society before self. If we are going to build a global system of identity on top of our global system of digital telecommunications—both the Internet and mobile interconnectivity—then we must do so with bright eyes and open hearts to the real, concrete needs of every player in the mix. The different needs and requirements and the resulting disagreements over what determines good policy will never fully disappear, but by understanding both the differences and the commonalities, we have the best chance to find policy that best suits the most needs of all parties. It was a GREAT conversation in Boston. I look forward to continuing it at http://good-id.org as we work together to shape digital identity in the 21st century.
Aadhaar: digital identity writ large in India
India has forged new ground in digital infrastructure with its IndiaStack [1] initiative and Aadhaar, the biometric identity system at its core. Aadhaar is the largest state-sponsored digital identity system in the world. With over 1.1 billion Indian residents enrolled, … Continue reading →
India has forged new ground in digital infrastructure with its IndiaStack [1] initiative and Aadhaar, the biometric identity system at its core. Aadhaar is the largest state-sponsored digital identity system in the world. With over 1.1 billion Indian residents enrolled, it is transforming the world’s second most populous nation from an underdeveloped state into an advanced digital society. It isn’t perfect, but its successes and failures offer important lessons in the opportunities and the pitfalls of national identity systems. Architecturally, Aadhaar is a voluntary, biometric-based identity proofing layer upon which additional services can be built. By design, it is as minimal as possible, enabling a single function: state-endorsed biometric authentication of individual Indian residents. It is one of five core IndiaStack applications, which together provide foundational digital services throughout India. The other four are eKYC – Digitize your KYC (Know Your Customer for bank account creation). UPI – Transfer money between bank accounts in India. Digilocker – Retrieve, Store & Share verified digital documents. eSign – Sign any document electronically. In addition to these government provided applications, registered companies can build apps on top of IndiaStack. In the words of its chief architect: Large scale social problems require “unbundling of the problem” and creation of “shared digital infra” as “public good” on top of which “innovative solutions” can be “assembled” to meet diverse contextual needs. –Pramod Varma, Chief Architect, Aadhaar At the 2017 ID2020 [2] summit, Pramod Varma put it this way: Aadhaar provides robust de-duplication so services can know definitively that people aren’t lying about their identity, such as filing double claims for benefits or other advantages. A set of open APIs, IndiaStack provides “digital infrastructure platforms as public good to allow solutions to be assembled by the ecosystem.” In other words, the five IndiaStack services are a public good that enables applications that better serve the people of India. Aadhaar’s separation of identity from the services which depend on it is a profound shift towards a human-centered Internet. No longer is an individual’s identity tracked on an ad-hoc basis by private, corporate interests like Google and Facebook. Instead, identity proofing is provided as a fundamental utility of the state, just like roads, water, and the courts. Or a passport. Many contend the opposite: that the functional result of a system like Aadhaar is the subjugation of the individual to the state. That by creating a national system to track everyone’s digital actions, India has, in fact, reduced the humanity of its residents to mere digital ones and zeros. While traveling abroad may deserve additional credentialing, like passports, makes sense, within one’s own country, a free state has no legitimate cause for persistent tracking of individuals’ digital transactions. In short, Aadhaar is at least as controversial as it is enabling. To understand the conversation about Aadhaar, let’s examine it through the lens of Functional Identity, introduced in my two previous articles. Speaking of Identity [3] and How Identity Can Enable A People-Centered Internet [4]. The experience It starts with enrollment. Individuals in India establish an Aadhaar number by visiting a registrar or enrolling agency. Enrollees provide proof of identity and address through documentation, assertion by a head of family, or specially authorized “Introducers”. Biometrics are captured by certified devices: retina scan and fingerprints. Individual’s demographics are also recorded: name, birthdate, physical address, and an optional mobile number or email address. These are associated in a central government database with a unique identifier, the enrollee’s new 12 digit Aadhaar number. When individuals use Aadhaar for authentication to various services, they provide their Aadhaar number and at least two of three authentication mechanisms (biometrics, demographics, and a One Time PIN sent by email or mobile). This request is encrypted and sent to a central verification service, which returns a simple Yes or No, indicating successful authentication or not. Services are then provided or denied. Let’s put this in terms of Functional Identity. Here are the nouns and verbs of Functional Identity in Aadhaar. The nouns Individuals in India, both citizens and otherwise. Unique, 12 digit Aadhaar numbers are created in the centralized Aadhaar database for each enrolled individual. Biometric templates (retina, fingerprint), demographic data (name, date of birth, address, gender), and optional contact info (email or mobile). Plus, any attributes stored by service providers and associated with an individual’s Aadhaar number. While these are not within the Aadhaar system, they are a functional part of the identity enabled by Aadhaar. Sensor readings from authentication devices. Meta-data associated with each authentication request: timestamp, source of authentication request, etc. The only derived attributes I discovered are One Time PINs which can be sent to the registered email or mobile number for immediate use at the point of authentication. Please email me if you know of any Aadhaar analytics creating new attributes based on raw data and attributes. The verbs Attributes are acquired at enrollment, which takes place at authorized enrollment centers, some of which are privately owned and operated. Biometric scans and demographics are acquired at the point of authentication throughout active use of the system. Biometric and demographic attributes are correlated with the Aadhaar number during enrollment. At the point of authentication, at least two of the following three are submitted to a centralized registry for verification: biometric scans from sensor readings, demographic data matching registered attributes, and/or a One Time PiIN (OTP) sent via mobile text or email On a successful match, the individual is correlated with their Aadhaar number. Services relying on Aadhaar correlate the physical person and their own records with that identifier. Based on the internal records associated with a given Aadhaar number, various services may be provided or denied. For example, the national welfare system uses Aadhaar to ensure no one is paid twice for the same welfare benefit. Services may also accumulate records that can be securely and reliably associated with the authenticated individual, restricting future access to that individual or someone with their explicit consent. At the point of authentication, the central verification service analyzes the sensor data, demographics, and One Time PIN to find a matching profile. Presumably anomaly detection monitors authentication requests to help detect possible cyberattacks. Other data mining may occur, but legally it needs to face the test of national security. Details of any such mining are not public at this time. Data is secured by cryptography, process, and regulation. Resident data and raw biometrics are always kept encrypted, even within registry data centers. Individuals can freeze their Aadhaar number so nobody can use it, even them. By law the biometric and demographic data used for authentication cannot be stored. In practice, not all systems adhere to the requirements. The controversy Aadhaar is a transformative experiment, designed to leapfrog India’s infrastructure from an underfunded, underdeveloped bureaucracy struggling to reach all of its citizens to an efficient digital society where cost-effective electronic services can be reliably provided more quickly, more broadly, and with greater impact at lower cost and waste. At the same time, the open approach raises fundamental questions about privacy in a digital world. As “voluntary” use of Aadhaar for services effectively becomes mandatory due to the hassle of alternatives, IndiaStack becomes a compulsory architecture of surveillance covering nearly all digital life, requiring neither probable cause nor search warrants. As IndiaStack enables even more services and touches on even more aspects of individuals’ lives, the surveillance coverage and privacy risks only increase. Shouldn’t it be possible for a person to buy a cup of coffee without the government knowing about it? Is it really appropriate to embed government tracking into the majority of transactions in an Indian person’s life? Several court cases have charged Aadhaar, IndiaStack, and related services with violating the rights of Indians to “life and liberty” as protected under Article 21 of the Indian constitution. In August of this year (2017), the Indian Supreme Court ruled that privacy is more than just a common law right, subject to legislative override. Rather, it is a fundamental right that cannot be denied without appropriate cause and due process. “The State must ensure that information is not used without the consent of users and that it is used for the purpose and to the extent it was disclosed,” said Justice S K Kaul. He added that … “automated processing of personal data… to analyse or predict… performance at work, economic situation, health, personal preferences… can result in discrimination based on religion, ethnicity and caste.” … Justice Chandrachud ruled that creating regimes for data protection “requires a careful and sensitive balance between individual interests and legitimate concerns of the state”. [5] The court’s ruling sends several cases back to lower courts for judgment in light of a more stringent constitutional, rather than common law, test of legality. The controversy is far from settled. As the details are considered, the benefits must be weighed against the harms. Ultimately, India must decide whether the good outweighs the bad as well as what can and should be done to reduce those harms without losing this promising new digital infrastructure. In my next column, I’ll dive into that debate: The benefits and the harms, the options for improvement and lessons learned. It’s clear that Aadhaar is an unprecedented success by many measures. The rest of the world has much to learn from both its victories and its failures. Perhaps, through Aadhaar, we can better understand the true opportunity for a people-centered Internet. This article also appears at https://peoplecentered.net/2017/11/16/aadhaar-digital-identity-writ-large-in-india/ [1] The IndiaStack website. http://indiastack.org [2] ID2020 http://id2020summit.org [3] https://peoplecentered.net/2017/06/11/speaking-of-identity/ [4] https://peoplecentered.net/2017/07/26/how-identity-can-enable-a-people-centered-internet/ [5] Kaushik, Krishin, “Right to Privacy: After Supreme Court judgment, all eyes now on Aadhaar case” The Indian Express. August 25, 2017. Accessed online October 17, 2017, http://indianexpress.com/article/india/right-to-privacy-verdict-what-next-all-eyes-now-on-aadhaar-case-4812352/
Ten years ago I wrote a blog post that captured a key architectural insight at the core of VRM: putting the user at the center of integration not only improves the quality of services, it simplifies our systems. The article captured the gestalt of VRM and helped catalyze a range of conversations that still shape the VRM approach. Since then, we have seen a lot of progress. Here are a few standout examples. Continue reading →
Ten years ago I wrote a blog post that captured a key architectural insight at the core of VRM: putting the user at the center of integration not only improves the quality of services, it simplifies our systems. When we put the user at the center, and make them the point of integration, the entire system becomes simpler, more robust, more scalable, and more useful. The article captured the gestalt of VRM and helped catalyze a range of conversations that still shape the VRM approach. Since then, we have seen a lot of progress. Sometimes we proceeded in fits and starts and there were certainly failures along the way, including my own venture, SwitchBook. When I started pulling together my notes for this anniversary post, I was mildly surprised and delighted at how much real work got done and the real-world impact we’ve had. Here are a few VRMy developments in the last decade worth noting. Please chime in with a comment if you know of a good one to add to the list. Coming in December of that same year, OAuth kicked off a series of standard protocols for identity, attribute sharing, and permissions, including OAuth 2.0, OpenID Connect, and User Managed Access (now at 2.0). These efforts brought together the leading technology companies to collaboratively develop new standards that give individuals greater flexibility and control over data exchange between online services. Companies like Personal.com. (now TeamData), Digi.me, and Cozy Cloud shipped user-driven personal data stores. Software project HIE of One offers a personal data store that lets individuals manage our own healthcare data. In Europe, GDPR has ushered in a new wave of regulatory requirements and penalties driving companies and organizations to give individuals easier access to, greater control of, and more security in our personal data. JLINC Labs offers a provenance service layer that allows companies to quickly attain GDPR compliance for the right to erasure and data provenance by giving individuals direct control over which data is used for what purposes. Kantara Initiatives’ Consent & Information Sharing Work Group (CISWG) has published its Consent Receipt Specification to help both individuals and organization keep track of data provenance and terms of use. Working with the CISWG, Customer Commons has picked up the challenge of developing customer-driven terms of use called “first party terms”. Asserted by individuals when interacting with websites, they are designed to provide a balance to the ubiquitous company-asserted terms of use we all are forced to accept when we interact online. Perhaps the biggest recent splash has been made by self-sovereign technology, which provides distributed identity services completely independent of any centralized authority. Using distributed ledger technology, firms like Evernym, Blockstream, Digital Bazaar, Microsoft, and IBM are enabling a wide range of robust identity services that put individual users in the driver’s seat. Collaborative initiatives like Sovrin, Hyperledger, the Decentralized Identity Foundation (DIF), Rebooting Web of Trust, W3C Verifiable Claims Working Group, and ID2020 bring technologists together to develop open source and open standards solutions that realize secure, privacy enhancing, self-sovereign architectures. ID2020 brought the self-sovereign technology conversation to the UN, convening technologists, UN staff, representatives from sovereign states, and NGOs to explore how block-chain based approaches might enable cost-effective, scalable solutions for U.N. Sustainable Development Goal 16.9 https://sustainabledevelopment.un.org/sdg16: to give everyone on the planet a legal identity by 2030, including birth registration. International non-profit technology solutions organization iRespond has agreements in place and is seeking funding for a self-sovereign identity layer to bootstrap identification credentials for tribal people in the border region of Myanmar and Thailand. These self-sovereign credentials will the recognized and used by local governments to provide work permits, health care, and other services. There is still a long way to go, and there probably always will be room to improve whatever systems we build. The conversations continue at the Internet Identity Workshop (IIW), the People Centered Internet, and of course, on the Project VRM mailing list as well as the collaborative initiatives mentioned above. Do you know a VRMy project that’s made a difference? Share with us in the comments.
Identity is one of the most important constructs of society. It’s also one of the hardest to discuss. It is how we keep track of people and things and, in turn, how they keep track of us. When we build identity systems without a core understanding of identity, we risk inadvertently compromising human dignity. Continue reading →
Identity is one of the most important constructs of society. It’s also one of the hardest to discuss. I’ve been in perhaps hundreds of conversations in over a dozen years about user-centric and digital identity. I’ve realized that many of our challenges in digital identity stem from two problems in these conversations. First, miscommunication; we often use the same words with different meanings. Second, we get distracted by compelling but unproductive discussions about different aspects of identity. In response, I’ve begun a conversation about how to talk about identity in a way that is both accessible and rigorous. I want to find a way to discuss identity that laypeople understand, without alienating technologists. Digital identity—like the rest of our Internet-enabled world—is scaling faster than society knows how to handle. If we don’t develop a simple way for experts to talk with regular people about both identity and its realization in digital identity, it will be nearly impossible to build an Internet identity layer that fully addresses the needs of a modern global society. One way or another, that identity layer is being built. I believe a better conversation will make a difference. Consider for a moment a slightly different way to think about identity: Functional Identity. If the approach feels off or triggers a reaction, please drop me a line at joe@legreq.com. If we are to discover how to talk about this simply and effectively, your response is a valuable part of the discourse. Reframing Identity Our framing of identity determines how we talk about it. The facets of identity are so rich that we each bring our own hot buttons and agendas to any discussion. Some engage from a philosophical perspective, others cultural. Some dive into political issues and others get meta-physical and spiritual. These different frames are valid aspects identity’s impact on our lives. Not just valid. Vital. They help answer the question of “Why?” Why it matters, why we should care. Unfortunately, they also inflame passions. We often talk past each other to make points that have minimal relevance in other frames, leaving everyone frustrated and unheard. As an engineer, I’m concerned with how things work. I want to learn how to fix what’s broken and how to build new things. In short, I want to know how things function. With identity, this functional perspective sidesteps the inflammatory rabbit holes, without dismissing them. Once we understand how Identity works and how we use it, we can explore how different identity choices affect individuals and society. Functional Identity lets us investigate the HOW without prejudice to WHY, viewing identity systems based on how they work and then, in turn, how they affect individuals and society. A Functional Definition Identity is how we keep track of people and things and, in turn, how they keep track of us. That’s it. We learn people’s names, we observe them and hear gossip and consume media. We then apply that sense of who they are to our dealings with them. Others do the same in return. In computational systems, we assign identifiers, we accumulate observations, we correlate those observations with entities, we make conclusions based on those observations and we apply those conclusions in interactions with those same entities. In other contexts, we give people name tags, we share business cards, and we wear bracelets. All to facilitate keeping track of each other. This simple definition is provocative. It triggers associations with Big Brother and the surveillance state. It brings up ideas about embedded chips and tattooed serial numbers. It conjures fears of government or corporations constantly tracking what we do. Which is ok, because, in fact, those are the most feared abuses of identity. It’s important to realize when we talk about identity that we are always talking about how we keep track of people. There are also a number of wonderful uses of identity that are worth remembering. The joy of a child saying “Momma” or a lover calling out your name. The pride in your name on a diploma. The simple benefit of seeing another’s name tag at a workshop and better remembering that fascinating conversation. Identity enables so much good stuff *because* it helps us keep track of people and things. Like white space in visual design or writing, identity systems are also defined by how they prevent or minimize tracking. While identity is useful, too much tracking is untenable. Every identity system makes choices about efficiency and privacy, enabling specific means of tracking while limiting others. Realizing that the good consequences of identity inevitably enable the bad is fundamental to understanding how to build systems that appropriately balance the two. The functional approach reaches beyond digital systems to understand how identity works throughout society. By better understanding how identity functions, we will be able to build systems that enhance privacy and human dignity, while improving identity assurance and security. Why? Engineers, entrepreneurs, and financiers sometimes ask “Why?” Why are we spending so much time with navel-gazing conversations about identity? Why not just build something and fix it if it is broken? To be fair, I get why “Identity” with a capital “I” is banned in certain working groups. Those distracting conversations can derail productive efforts to build good systems and ship working code. And yet, there is a vitally important and simple reason to better understand identity: human dignity. When we build identity systems without a core understanding of identity, we risk inadvertently compromising human dignity. There are times when security concerns demand compromise. Fine. It’s the job of our political systems—local, national, and international—to moderate the worst abuses and to establish boundaries and practices that serve basic human rights. But when engineers unwittingly compromise the ability of individuals to self-express their identity, when our systems subject individuals to unreasonable restrictions and deny basic services because of a flawed understanding of identity, that’s an avoidable tragedy. What might seem minor today could lead to the loss of privacy, liberty, or even life for an individual whose identity is unintentionally compromised. That’s why it pays to understand identity, so the systems we build intentionally enable human dignity instead of accidentally destroy it. In a future column, we’ll discuss the elements of Functional Identity, with the eventual goal of defining the fundamental objects and methods that comprise any identity system, digital or otherwise. From there we can start to explore the impact on privacy and freedom and human dignity that different identity systems afford. In the meantime, I’m off to ID2020, a UN Summit about the potential for blockchain technology to help with UN Sustainable Development Goal (SDG) 16.9. We’ll be exploring how self-sovereign identity might enable us to create a legal identity for everyone on the planet by 2030, including birth registration. Not a small task. I hope you’ll join me as we continue the conversation. This article also appears at https://peoplecentered.net/2017/06/11/speaking-of-identity/
User Driven Services: 9. Self-managed Identity
9. Self-managed Identity User Driven Services let users manage their own online identity. Unless we control our identity online, we risk unnecessary exposure to identity theft and unwanted correlation of online activity. At the same time, online services increase the … Continue reading →
9. Self-managed Identity User Driven Services let users manage their own online identity. <img loading="lazy" decoding="async" class="alignright size-full wp-image-587" title="Name tag" src="https://blog.joeandrieu.com/wp-content/uploads/2009/05/dreamstime_4473313hello-my-name-iscropped.jpg" alt="Name tag" width="288" height="196" srcset="https://blog.joeandrieu.com/wp-content/uploads/2009/05/dreamstime_4473313hello-my-name-iscropped.jpg 480w, https://blog.joeandrieu.com/wp-content/uploads/2009/05/dreamstime_4473313hello-my-name-iscropped-300x203.jpg 300w" sizes="auto, (max-width: 288px) 100vw, 288px" />Unless we control our identity online, we risk unnecessary exposure to identity theft and unwanted correlation of online activity. At the same time, online services increase the risk of attacks when using the same identifier for multiple functions. User Driven Services allow users to be in maximum control of their identity by distinguishing between the four different types of identifiers used online: Authentication IDs Presentation IDs Reference IDs Internal IDs Users should be able choose their own third-party identity service and have complete control over the three external identifiers used by any User Driven Service: their authentication IDs, their reference IDs, and their presentation IDs. The internal ids relating these external identifiers should never be exposed. Identity Providers should operate in non-correlation modes—so that different services providers automatically receive different authentication tokens, and all presentation IDs should be hand selected by the user for each service whenever possible. The ideal service will enable intentional correlation only upon user directive, allowing individuals to claim blog posts, social profiles, and microblogging accounts as their own, after initially anonymous or psuedonymous use. Services are also more flexible when they allow users to use multiple distinct identifiers within a given class, e.g., having more than one email address or online chat handle. Finally, when possible, services should allow for anonymous and anonymized use. Examples OpenID allows users to use a third party service for Single Sign On at millions of websites, bypassing potentially millions of usernames and passwords. Information Cards allow “clicking in” to relying websites rather than logging in, using the credentials and authentication of third party Identity Providers. Azigo’s RemindMe service allows users to selectively activate membership credentials, such as AAA or AARP affiliation, on specific websites for special offers and discounts—without divulging such affiliations to the website in question. Questions Does the service allow third party identity providers for managing authentication? Does the service fully distinguish all four identifiers used in online identy: Authentication ID–used for logins Presentation ID–used for labelling authorship and ownership Reference ID–used for referring to specific users, e.g., for sending messages Internal ID–used internally to link the other three IDs to each other and to appropriate privileges. Does the service allow users to modify and manage the three exposed identifiers: Authentication, Presentation, and Reference? Does the service allow users to have multiple identifiers in the same class, such as two email addresses or multiple chat handles? This article is part of a series. It is the ninth of ten characteristics of User Driven Services: Impulse from the User Control Transparency Data Portability Service Endpoint Portability Self Hosting User Generativity Improvability Self-managed Identity Duty of Care One more to go… This material is based upon work supported by the National Science Foundation under Award Number IIP-08488990. Any opinions, findings, and conclusions or recommendations expressed in this publication are those of the author and do not necessarily reflect teh views of the National Science Foundation.
A functional model for best practice Identity implementations. The Identity Quartet is a framework for online services that allows users to express their Identity on their own terms. When I use the term “Identity”, I refer to the set of … Continue reading →
A functional model for best practice Identity implementations. The Identity Quartet is a framework for online services that allows users to express their Identity on their own terms. When I use the term “Identity”, I refer to the set of identifiers used in reference to users in online services. At the December 2008 Internet Identity Workshop, Randy Farmer introduced what he called the “Tripartite Model of Identity.” He presented a pattern distilled from years of groundbreaking work building virtual communities. This article is a write up of a four component model based on Randy’s initial concept. I also build on the ideas discussed at the IIW session on Non-correlatable IDs with OpenID. The Quartet In online systems, we use Identity in four roles, using four potentially distinct identifiers. Each of those four will be present in any system that allows users to login, present themselves online, and receive incoming services. Often, systems use the same identifier to fulfill multiple roles. However, there are good reasons that these identifiers should be managed separately, especially across organizational boundaries. The four identifiers are: Authentication IDs Presentation IDs Reference IDs Internal IDs Authentication IDs To access privileged services, users must present an identifier to claim their right to that service. Common identifiers include session IDs, cryptographic tokens, and usernames. Usernames are probably the most common identifier for logging into services. Paired with a password for authentication, this is a cornerstone of how we use identity to gain access to privileged services. That access authorization typically persists without logging in again through the use of a session ID. In a user-centric context we can separate the authentication ID used at a Relying Party with that used at the Identity Provider, allowing for directed identity as described by Kim Cameron in his Seven Laws of Identity. In a capability-based authentication regime, the identifier itself could contain a cryptographically signed delegation of authority for a particular privilege, but, in general authentication IDs don’t need to be that fancy. Presentation IDs Handles, nicknames, and character names are used to label content for display to others in the system. Often these presentation identifiers are humorous or obviously fictional, such as “HappyCamper” in an online chat or “Thor the Destroyer” in World of Warcraft. They need not relate to actual user characteristics, nor do they need to be unique. Their only role is to present a label as the author, owner, or embodiment of a post, comment, rating, or character. Just as there are multiple “John Smiths” in the New York white pages, there’s no reason there can’t be multiple accounts with the same presentation ID in an online community, as evidenced by the vast number of users with the handle “Jesus Jesus Jesus” on Facebook. In reciprocal multiplicity, online games like World of Warcraft often allow each user to create and simultaneously maintain multiple characters, with different names, avatars, descriptions, characteristics and property. Since presentation IDs are intended to be shown to a wider audience and because their uniqueness is not technically required, it is prudent to separate presentation identifiers from authentication. There is no need to advertise authentication identifiers widely, as that simply increases security risk by giving away a critical—and preferably secret—component required for accessing privileged services. Reference IDs Service requests need a way to refer to intended parties. The most prevalent reference identifier is the local-part in an email address, the part before the @ sign, e.g., “joe” in “joe@example.com”. This identifier allows users to contact one another, without referring to anything else (such as a blog post or a job listing). It should be unique for each intended incoming role (e.g., admin@example.com or joe@example.com), but there is no technical reason that any given user can’t have more than one reference identifier, as is commonly seen when multiple email addresses auto-forward to the same individual. Also, often for a given role, it makes sense for a reference identifier to forward messages to several individuals, e.g., admin@example.com could forward the email to three different users to improve the response time for handling the issue. Since this reference ID is intended to be used by users other than the recipient (that should be obvious!), it makes sense to distinguish it from authentication IDs used to access the system. Distinguishing the reference ID from the presentation ID allows users to receive directed incoming services (such as email) while displaying handles that are common to multiple users. Combined with an appropriate service endpoint, reference IDs allow for any number of incoming services to be provided in reference to that ID. Internal IDs Every system needs to keep track of which identifiers relate to each other and to specific privileges. For example, what email messages should be shown to the user with a particular authentication ID? And which users should be able to post to a bulletin board? Internal IDs link together the authentication, presentation, and reference identifiers in the system, allowing users who are logged in to a system to see the appropriate service interfaces and have particular services performed as directed, including the proper presentation of their Identity to fellow users. The internal identifier is typically the primary key in a database table managing the list of users, and may also be used in a permissions table to keep track of service privileges. Because it is an internal identifier, it need never be revealed to the outside world and, to minimize hacking, it shouldn’t be. Because it is completely internal, it can also enable anonymous access to services through appropriate anonymized mechanisms for authentication IDs. Separation of identifiers improves Identity Many systems use the same identifier for multiple roles, such as using your email address as your login username for a system, such as AOL once required (and might still). However, systems can be more robust, more flexible, and more secure if they explicitly delineate the four identifiers to help avoid unintended correlation and attack vectors. This is especially true across trust boundaries. Using your AOL login as the AOL email service endpoint simplifies the mental model for users new to online services at some minor cost to security by exposing the login id to everyone a user gives their email address to. Using your AOL username as a login to other services is asking for both a loss of privacy from cross-site correlation of your identity and attacks on your account login. Fortunately, the latest technology can avoid this—if we use it correctly. It isn’t just enough to enable OpenID, SAML, or Information Cards on our systems. For truly user-driven Identity we need to explicitly delineate the identifiers used for authentication, presentation, and reference from each other and internal identifiers, both within and between organizations. We should also enable users to choose their own identifiers for the first three… and keep the internal identifier completely secret. Examples Traditional System (with distinct identifiers) 1. Authentication ID jandrieu 2. Presentation ID Joe Andrieu 3. Reference ID joe@example.com 4. Internal ID 10485 OpenID 2.0 (in non-correlation mode, with distinct identifiers) Relying Party Identity Provider 1. Authentication ID http://joe.example.com 2. Authentication ID2 RP-specific Token from IDP 3. Presentation ID Happy Camper via Attribute Exchange 4. Reference ID joe@example.com available via Service Discovery 5. Internal ID 10485 987656 There’s no reason users can’t select their own authentication ID in each of the above situations, although in practice, the RP-specific token is usually dynamically generated on behalf of users. Similarly, Presentation IDs can easily be specified by users in either system, leveraging OpenID’s Attribute Exchange Extension when appropriate. The reference IDs can also be user defined in either of the above approaches, with OpenID allowing fourth parties to discover a user’s service endpoint and endpoint-specific reference ID for any service authorized by the user for that party. And clearly, the internal identifiers in all three situations have no innate need to be correlated with any of the others except through the secret internal ID. This allows for the maximum possible user choice and, potentially, maximum anonymity. The Identity Quartet pattern isn’t rocket science. In fact, it makes things simpler when it comes to security, maintenance, and user control. The Quartet makes systems more flexible and more secure while giving users more freedom to manage how they interact and present themselves online. It is one way to turn user-centric Identity services of OpenID and Information Cards into truly user-driven Identity. [Update: 4/17/2009 Revised “routing ID” to “reference ID”.]
Doc Searls recently brought my attention to a White Paper by Phil Windley, about his company, Kynetx. It does a good job explaining the thinking behind their architecture, and raises some questions that, for me, challenge some underlying assumptions and … Continue reading →
Doc Searls recently brought my attention to a White Paper by Phil Windley, about his company, Kynetx. It does a good job explaining the thinking behind their architecture, and raises some questions that, for me, challenge some underlying assumptions and business choices. Problem Domain The distributed nature of the web is a big part of its power–nobody needs to ask permission from a central authority to use it or create with it. However, that disaggregation limits the cohesion for sophisticated uses, leaving users to hobble together ad-hoc mash-ups of value from multiple, diverse service providers. For example, the average travel planner spends 29 days from their first query to their first purchase. No tool I know of facilitates that entire process effectively. Solving this problem in a general way—while retaining the authority of the individual and the flexibility of open systems—is perhaps the greatest opportunity for VRM. The personal data store and VRM relationship services are two prongs of an architectural shift for enabling this kind of aggregation while remaining open. Once you put the user in the driver’s seat, with coherent controls over the flow and the data, the experience can integrate around the user, even as they drive anywhere on the Internet. Solution Kynetx’s solution is built on one primary capability: A rules engine (and language) for contextual customization based on strong identity-based claims, using the user-centric Identity of Information Cards. This puts Kynetx squarely in the web augmentation service business. Adaptive Blue (and their Glue product) is perhaps the most sophisticated approach to this space, but Yahoo’s Toolbar also augments web pages, as does Skype (putting its SkypOut button on any phone # it recognizes), and the granddaddies of all web-augmentation services are the ad blocker plug-ins that remove banner ads on websites. I distinguish web augmentation from web media enhancements, like PDF and Flash and Java, in that the latter are embeddable or downloadable extensions to the core HTML/http architecture of the web, while augmentation services provide third-party manipulation of website presentation on behalf of the user. They actually tweak the web page as the user sees it, rather than offering websites a new way to package content or functionality. Web augmentation isn’t new, but it is gaining adoption and breadth. There is a low-grade market war going on in this space. While browsers define the official battleground of the World Wide Web; augmentation services are the guerilla warriors of next generation browsing. The approach that reaches ubiquity first will create significant value throughout the architecture: for users, software vendors, and service providers. So, the question that comes to my mind is where does Kynetx fit into all of this? The value proposition of a rules-engine for customization is powerful, if that engine makes it easy to leverage strong identity. Every website will, imo, want to take advantage of the unique value of user-centric identity and Information Cards in particular. However, rewriting your customization to do that will take resources and that will slow adoption. If Kynetx can simplify how websites plug- in to the Identity meta-layer that sounds like a real value. Gaps There are however, several gaps that I see in Kynetix’s approach mapped out in the white paper. First, who are the target developers: websites or Third party services. Or both? It’s not clear to me if the primary authors of KRL rulesets (and hence Kynetx’s customers) will be the destination website developers or third party augmentation services. For example, . Adaptive Blue‘s Glue augments web pages so that things like movies can be recognized across domains for social commentary, ratings, and sharing. That means that Glue modifies the presentation of web pages at IMDB, Netflix, Amazon, Blockbuster, etc. In this pattern, it is the third-party, Glue, that would be running KRL rulesets, not the websites. Is this the intended architecture for Kynetx? Is the point of the Kynetx Information Card to provide authorization by the user to allow services like Glue to augment their web experience, while the rest of the plug- in handles injection into the web page within the browser? Or, is the main point that web services themselves would leverage Kynetx’s Information Card approach to manage third party identity for customization? For example, so Hertz could seamlessly provide AAA or AARP discounts if, and only if, the appropriate AAA or AARP information cards (KIX) are presented by the user? In this case, Hertz writes the customization, but doesn’t need to know upfront what the user’s affiliations might be. If the first case is intended, the white paper doesn’t do a good job explaining how this fits into a larger, open ecosystem, nor does it highlight this unique architectural opportunity. If a user wants Orbitz to help augment its travel planning experience, even when it is at Expedia or Southwest airlines or Hilton.com, it would be great to do that in a secure, authorized, privacy-sensitive way. But it isn’t quite clear if this is the point of Kynetx’s approach. (Although it is a great opportunity, one that r-buttons and SwitchBook see in the not-so-far future). If the second case is the goal, it isn’t clear to me why Kynetx is better than other customization frameworks. With a card selector and cards issued from the right authority, users can already present AAA or AARP credentials to websites, which in turn can integrate that information into their existing CMS or other presentation code (Drupal, PHP, perl, Ruby-on-Rails, etc.). If the value proposition is in speed-to-market for identity-based customization, then the white paper needs to make that case first and foremost. If that’s the goal, then it also suggests a business model, which I talk about in a bit. It could also be that both of these are part of the approach: allowing both the website developer and third parties augment the web experience based on strong identity. This is the general idea behind r-buttons and would almost certainly speed deployment. However, the white paper doesn’t address the issues of contention when multiple providers want to augment the same page. Given the open-ended javascript functionality associated with a KIX, this could be a challenge. Second, isn’t re-aggregation actually about creating a coherent context? While the Kynetx approach allows users to present a particular relationship at a particular website, that doesn’t seem to solve the stated problem. I don’t see how it actually achieves a cross-web aggregated experience. In fact, it seems that the best aggregated experience should combine many relationship cards at many different services. In the 29-day travel planning scenario, won’t users need to send their AAA and AARP cards to every site they visit? (Or some large subset?) Does the card selector require a ceremony for every website every session? Or just once and then it is a permanent approval, such as confirming once with Expedia that the user is a AAA member? Managing this A x B complexity with A Information Cards and B websites scales poorly if every site has a distinct ceremony–and even worse if each card presented at each site is a distinct ceremony. This apparent model of KIX based aggregation seems to miss an opportunity, one that is near to my heart as the core of the Search Map architecture for User-driven Search. It seems to me that for a given web-based task–such as travel planning–what you need is a user-driven personal data store that tracks the user’s progress across the Web. This data store should be 100% transparent, 100% editable, and seamlessly transferable/accessible to authorized vendors under terms controled by the user. We call our version of this a Search Map, an electronic document that provides the user a concrete way to manage and express their Search intent. It is also a seamless way to manage and express user context. In the white paper, Phil asserts that “users are freed from managing episode context themselves” as a core benefit. But, I don’t think this is actually a benefit. Attempting to achieve that goal could end up being more patronizing than useful, following in the footsteps of “Clippy” the Microsoft Windows help agent which tried to figure out the context and help users, but failed miserably. “I see you are writing a letter. Would you like assistance?” Ack! It’s not that users don’t want to manage their context, it’s that they haven’t been given simple, value-producing tools to do so. Consider spreadsheets: it’s not that users want to balance the budget on a computer—doing budgets on a computer isn’t inherently rewarding. It’s that spreadsheets make it easy to get value out of balancing their budget on the computer. Managing KIX across 29 days of travel planning and potentially a hundred+ websites sounds like a chore… unless we have a coherent expression of the context (in something like a Search Map, perhaps) that is easy to use and immediately useful. Third, over-centralization limits scale. The Kynetx model, as I understand it, doesn’t scale to the full World Wide Web, because it centralizes two core functions: resolving requests for augmentation and the validation of injection javascript as safe, private, and secure. Both of these constrain the growth opportunity for a KRL-based approach to augmenting web services. First, it places the core usage-time server demand on a single service. Given the business model of charging for ruleset evaluations, there is no obvious incentive for Kynetx to release an open source reference implementation to make it easier for alternate KRE service providers. In fact, there is every expectation that Kynetx will be motivated to “win the market share” battle and be the primary KRE service. Which, unfortunately, makes it just another silo, and will face precisely the same sort of scaling issues that plague Twitter. Second, by making Kinetx the arbiter of “quality” it places a single entity in control ofwhat constitutes “safe”. Even with good intentions, such centralized moral authority is not just dangerous, it alienates potential innovation. Nobody wants to be forced to seek permission for their new functionality. That was, IMO, the primary reason the World Wide Web dominated AOL so quickly. The way to reach web scale is to make it absolutely trivial for /anyone/ to play the game. Several open source implementations and open standards enabled anyone who wanted to, to set up their own web server and try out the World Wide Web as a service provider. And, despite that lack of central control, lots of companies made lots of money providing enhanced software to manage those systems. So don’t fall for the illusion that central control is required or desirable for a big financial win. Signing software is understood technology; we can enable signed KIX functionality with a validated identity as a first step towards quality control. Then, by opening up the validation service–and separating it from the distribution/matching of those KIX functions, we can allow software developers and service providers the freedom to innovate and provide their own approaches to what is valid and what isn’t. Some providers will choose to accept ANY signed KIX and simply track reputation. Others will charge a fee for developers, but run through a quality control check and review. By opening it up, you allow users and developers the freedom to manage KIX quality however they like, without building a presumptive “download at your own risk” ecosystem. With Kynetx the sole authority on “quality” for KIX functionality, we would have both a technical and a political bottleneck that would retard the adoption of a generalized approach to the disaggregated web experience. [Btw, it would be great if there were a name for the javascript injected into the browser when a KRL rule fires after evaluating the context and the user identity. This is currently just the “associated KIX functionality”, which is a bit wordy.] Fourth, what about privacy and data rights management? On the whole, it isn’t clear to me what data might be sent around in the claims of various Information Cards, but there is no discussion in the white paper about the data rights associated with that information. If I’m telling Hertz that I’m an AARP member, can they use that data to start sending me junk mail or SPAM targeting AARP members? Frankly, this is a hole in the entire user-centric Identity framework. OpenID Attribute Exchange and Information Cards allow users to use a third party service for the management and presentment of minimally sophisticated facets of identity (much better than username & password), but neither inherently enables users to specify a data rights regime for the claims or attributes so provisioned. In effect, we’ve made it easy for users to provide additional data about themselves, but missed the opportunity for users to easily control the use of that data. Since Kynetx has a goal of seamlessly augmenting users’ web experience, isn’t it incumbant on them to assure that seamlessness both protects users’ right to privacy and prevents unintended over-customization based on supposedly private data? This is another manifestation of the “Tivo thinks I’m gay” problem, where Tivo analyzes viewing behavior and assumes things about the user, with no way for the user to manage their profile. The data rights problem happens because there is nothing to keep Tivo from telling Hertz, GE, or NBC they think the user is gay. The problem in the Kynetx approach happens when service providers start passing presumably private data to third parties—and users lack the means to control that leakage once the service provider knows certain data. This level of data rights control needs to be built in from the start for VRM and user-driven applications. Business Model At the core, I think the business model needs rethinking. Although a CPM-based pricing for KRL evaluations seems to align the value proposition directly with costs, it actually presents more risk and less control to potential customers than other models. It also presents greater risk and less stability for Kynetx itself. What service providers and developers want to see in a technology platform is one with a free entry point (so you can get testing and trying it ASAP, even if a production system would need a for-fee license), a constrained, predictable cost structure, and economies of scale. Charging per evaluation offers none of these. This model instead creates an artificial scarcity and then charges by the drop. What you want is to create abundance and sell buckets and hoses and pumps. Doc calls this the “because of” effect. Constraining KRL evaluation to support a pay-by-drink business model will artificially constrain adoption. Instead, run to ubiquity and sell the best tools for leveraging the system you’ve helped create. At the same time, the evaluation of rulesets will have highly variable demand, with great spikes and drops far outside of Kynetx’s control. Tying revenue to that demand volatility means an unpredictable, wild revenue profile, flattening out only with insanely large numbers of users. This works for mega services like Amazon Web Services, but for a start up moving from initial revenue to predictable cash flow, it can be unsettling. In contrast, an IDE sales model or subscription based service with monthly fees bounds developer expenses and stabilizes the revenue curve. I like the idea of KRL rulesets. Currently, SwitchBook is planning on using Javascript, RegEx, and XPath, for similar evaluations. That approach not only feels ad-hoc, it is. I’d like to see a unified approach that is flexible, cross-platform, and supported by a good development and test environment. I think Kynetx could go far by creating an open source platform for KRL rulesets, then providing a robust IDE and testing framework for those who want to manage KRL rules to meet business needs. I think this is nicely pointed to in the mention in the White Paper of A/B testing with different KRLs. This is precisely the kind of sophistication that businesses will need to make the most of KRLs and which can easily be separated from the core infrastructure that enables KRLs in an open way for everybody. Also, the consulting opportunities to analyze, customize, and manage KRL rulesets is a huge business opportunity. Doing that well is likely to remain a black art for a long time to come; helping Fortune 1000 companies do it well should be lucrative. As Dale Olds put it referring to Novel’s Bandit Project: First, enable an open identity-metasystem, then sell tools to companies to help them manage it. Collaborations I like the value proposition of platform-independent identity-based customization. It fits well with VRM’s r-buttons, MyDex’s Personal Data Store service, and SwitchBook’s Search Maps. I think there’s still some brain work to be done figuring out how we can all support each other and simultaneously build sustainable business models, but I’ve no doubt there’s a way if we all invest in exploring those opportunities. Although I focused on questions and concerns about Kynetx in this post, I have great respect for Phil and hope to work with him as both our companies–and the entire VRM community–build out viable solutions to these kinds of problems.
At last month’s Internet Identity Workshop and the subsequent DataSharing Summit, Markus S and Drummond Reed unpacked several ideas about r-cards, which, to a certain extent, are an evolution of the Information Card at the heart of CardSpace. Going into … Continue reading →
At last month’s Internet Identity Workshop and the subsequent DataSharing Summit, Markus S and Drummond Reed unpacked several ideas about r-cards, which, to a certain extent, are an evolution of the Information Card at the heart of CardSpace. Going into IIW, I understood r-cards simply as a hybrid of InfoCard’s managed and personal card models. Managed cards are issued by another party–all the data associated/transmitted with that card is controlled by that managing party, while personal cards are self-asserted, allowing individuals to serve as their own card provider, controlling all of the associated data. R-cards then, allow a managing party to co-control a card with the user–with some data controlled by the managing party and some controlled by the user. However, during the IIW demo of r-card, I had an epiphany about how powerful the r-card is, once we actually allow the user to manage the personal claims through multiple, dereferenceable links. <o></o>One issue that came up during the demo was that if the “personal” side of the r-card is manually entered claims, such as contact information, then the user is creating a management nightmare: duplicate claims would need to be entered and maintained across many different r-cards. The more r-cards, the worse the problem. The “obvious” solution discussed at the session was to allow the user to specify specific claims that are served by other IdPs, such as a Personal Address Manager. And for completeness sake, let’s note that such claims could be mashed up from multiple other IdPs, not just a single one. Thus, any number of claims from a particular IdP could act as a sort of sub-card, combining with other subcards at presentation time. The net result of this is a realization that that perhaps the most interesting thing about r-cards is their use as dynamic cards or aggregate cards or mashup identity cards. That’s pretty cool in itself. However, it also struck me that this also potentially fixes usability problems around authorizing a bunch of vendor’s (M) access to identity claims at a variety of different identity providers (N). This potentially requires N points of authorization and authentication for each M vendors (or relying parties). Sub-cards (or r-cards) may combine that task at the point of presentation for much greater user understanding and simplicity. Since the Card Selector is itself a trusted point of authorization, we should be able to use the “mashup” gesture as explicit authorization for relying parties to access the claims specified in the sub-cards. That is, the UI of creating the r-card/mashup card/dynamic card also explicitly approves access to specific claims from multiple IdPs, since after all, the selector is where you select which claims to present to relying parties. This adjustment to the Information Card ceremony greatly simplifies the user experience, while retaining all the power of distributed claims at appropriate IdPs. For example, it would allow me to specify my Passport # to United Airlines, as a verifiable claim served by the US Secretary of State IdP (which should be trusted by UA), streamlining any international travel I might do, while retaining my contact info at my Personal Address Manager. All with the same authorization ceremony I use with any information card relying party.<o> </o> This realization was, for me, the most surprising insight into the power of the r-card. In fact, I’m wondering if the name “r-card” captures it best.
Bandit, Higgins, Open Source, Profit and Novell
At EIC2008 last month, Dale Olds of Novell’s Bandit Project gave me a few minutes and some insight into how Novell (and others) are mixing open source with proprietary software to architect a whole new Identity paradigm online. I’ve been … Continue reading →
At EIC2008 last month, Dale Olds of Novell’s Bandit Project gave me a few minutes and some insight into how Novell (and others) are mixing open source with proprietary software to architect a whole new Identity paradigm online. I’ve been following the user-centric Identity movement ever since Doc Searls talked me into attending IIW2006b, an unconference. EIC is a classic Enterprise technology sales conference on identity management. The two events couldn’t be more different, even though both have excellent content and are focused on Identity. EIC was all about big business selling to each other, while IIW is all about engineers making user-centric Identity work. Identity? A lot of you are familiar with the term, but for those who might not know what I mean, I’m talking about how people authenticate themselves for access to online systems. Traditionally based on usernames and passwords, online Identity presents a host of problems, not the least of which is that an individual may have dozens or even hundreds of different usernames and passwords, one for each new web service or corporate LAN accessed. This proliferation is itself a security risk–as people reuse passwords despite the best efforts of zealous IT gurus everywhere. It is also an information management nightmare: how are we supposed to remember all of that? Which reinforces the problem of reused passwords and unfortunately typically insecure password reset. Today’s identity management software provides solutions to this problem, largely through federation and user-centric Identity. In short, federation is how corporate IT systems rely on other corporate systems–provided by other departments or even other companies–to authenticate your identity and share information about you. It can be used for authentication, or as in the case of FaceBook’s Beacon, it can be used to pass on highly sensitive personal data. (Blockbuster is now in a lawsuit over this, which I expect they’ll lose.) As Doc Searls likes to put it, federation is about large companies having safe sex with each other, using your data. You can see how this starts to relate to your offline identity, as bits and pieces of your data trail could be used to build a profile and steal your identity or use it for other nefarious purposes, like spamming you with “targeted” ads. In contrast, user-centric Identity is an architecture where individuals present the credentials of their choice for authentication at online services. Instead of the vendor-to-vendor systems integration and trust contracts of federation, “Relying Parties” authenticate a visitor by relying on the Identity services of an “Identity Provider” of the visitor’s choice. Relying parties may not accept all ID Providers, but in general, the choice of who authenticates your identity lies with you. Key technologies in this space are OpenID, InfoCards, and a variety of standards from the Liberty Alliance. These are the core of the conversation at IIW. Of course, you can do federation with a user-centric Identity architecture; that’s not the point. The point is that in the user-centric world, the user is in charge of their identity. Or, as Doc Searls advocates, in the user-driven world, the user is driving the transaction. So, when I sat down with Dale at EIC, I had already heard about Bandit—I even have the t-shirt—yet, I was wondering how Bandit fit into the whole mash up of technology behind user-centric Identity. I know that OpenID is a URL-based approach for identity that has generated significant traction because it is easy for relying parties to implement and for tech savvy users to use. I also know that Higgins and CardSpace both implement Information Cards, or InfoCards: one an open source, extendable client and server implementation, the other a polished proprietary client app from Microsoft. I even had some inkling of the various protocols created and under development by the Liberty Alliance, who started life as a federation standards group and has embraced user-centric approaches as it builds out its services stack. And I even knew about Sxipper and Vidoop, the first a client application that helps users manage their identity presentation online, whether the online services are user-centric or not, and the latter an Identity Provider with a unique method for verifying that you are you. But what I didn’t quite get was how Bandit fit into it all. I know they are supporters of Higgins and Information Cards, but is Bandit a client app like Sxipper? A card selector like CardSpace? Is it a server implementation that could be used by companies like Vidoop? Is it open source and if so, how does it fit into Novell’s business model? Dale was able to make it fairly clear: Bandit is an open source project supported by Novell. Bandit provided the card selector for the Higgins project and participate in OSIS (Open Source Identity Systems), a working group of the Identity Commons comprised of different Identity technology providers working towards interoperability. They also support the soon to be announced InfoCard Foundation, although there have been no official announcements by anyone yet about that particular project. Novell, as a separate entity, is putting engineering and organizational resources into these open source and interoperability efforts because they see a bright future in selling Identity management tools once we get the Internet Identity-enabled. That’s when the light went on. Bandit is about helping create the entire infrastructure of Identity, the Identity Meta-System, as Kim Cameron calls it. Once that infrastructure is in place, Novell will be able to sell companies a number of tools that make it easy to leverage that infrastructure. As Dale put it, the open source part of this is about enabling Identity: assuring that the basic plumping and services are present and understood. The subsequent business model is helping companies manage identity, once we have the essential plumbing in place. Think of it like http and HTML as enabling the world-wide-web, while products like Cold Fusion, IIS, and Drupal help companies manage web services. The web wouldn’t exist without the open source gift from CERN some fifteen years ago, and without that underlying plumbing of protocols and formats, software providers like Netscape, Microsoft, IBM, Sun, and Novell, wouldn’t have made a dollar selling web technologies to anyone. Instead, with a web-enabled world, literally thousands of companies competed to provide web software, making billions of dollars in the process. Novell sees a similar dynamic with Identity. Clearly, so does Microsoft and Sun, and hundreds of other companies. So do I. And it looks pretty damn cool from here. p.s. my apologies for the lack of links and images. I realized I better post this before the real-time world overtakes me. I hope to see a bunch of you at IIW p.s. bonus link: Doc Searls on vendors bankrolling open source.
Majority of Americans dislike unauthorized use of behavioral data
From Yahoo News: Majority Uncomfortable with Websites Customizing Content Based Visitors Personal Profiles Level of Comfort Increases When Privacy Safeguards Introduced ROCHESTER, N.Y.–(BUSINESS WIRE)–A majority of U.S. adults are skeptical about the practice of websites using information about a … Continue reading →
From Yahoo News: Majority Uncomfortable with Websites Customizing Content Based Visitors Personal Profiles Level of Comfort Increases When Privacy Safeguards Introduced ROCHESTER, N.Y.–(BUSINESS WIRE)–A majority of U.S. adults are skeptical about the practice of websites using information about a person’s online activity to customize website content. However, after being introduced to four potential recommendations for improving websites privacy and security polices, U.S. adults become somewhat more comfortable with the websites use of personal information. Good stuff, although one should read closely to understand exactly what users dislike. Customization isn’t the problem… it’s the unauthorized invasion of privacy. The questions asked by Harris were rather leading. It would be interesting to see what people say to “if asked, would you allow a Search engine to provide enhanced results based on your behavior.” My understanding is most people do opt-in to the advanced features of Google desktop, which asks essentially the same question at install time. People don’t like surreptitious activities, but if you ask up front, it’s much easier for folks to say yes.