ID Technology

Being “Real” about Hyperledger Indy & Aries / Anoncreds

Kaliya Young · September 7, 2022 ·

Executive Summary

This article surfaces a synthesis of challenges / concerns about Hyperledger Indy & Aries / Anoncreds, the most marketed Self-Sovereign Identity technical stack. It is aimed to provide both business and technical decision makers a better understanding of the real technical issues and related business risks of Hyperledger Indy & Aries / Anoncreds, which have not been shared and discussed openly or publicly as the author believes need to be.

Who I am

My name is Kaliya Young. You may know me as the Identity Woman. I have been working on user-centric identity and most recently Self-Sovereign Identity standards for the past 20 years. Something fun has started to happen in recent years at identity events, more people who don’t know me are asking me if I have heard of or been to the Internet Identity Workshop (IIW), the landmark community forum for identity standard development I co-founded 17 years ago and still co-lead today.

As someone who didn’t come from a technical background and doesn’t write code, I have made tremendous efforts to reach where I am today, able to explain technology accurately and facilitate deep technical discussions and collaborations. For years, I have participated in technical sessions and engaged myself in all types of forums in technical communities building user-centric identity to learn about technical details and ask questions.

I have exerted determination and persistence throughout my career, because I deeply care about what I do, and I feel that I owe it to those who have helped me become a community leader to do what I believe is right. They don’t always share the same views with me but they believe in my genuine intention and my capability to provide unique value to this emerging area of technology. I have deep respect for all of them and others who have been working diligently to make user-centric identity a reality, many of whom helped shape the narratives of this article when they knew they might be affected by its release.

Here, I thank all of you who helped me capture the technical details in a truthful manner in this article, and my business partner, Lucy Yang, who supported me in making the difficult decision to write it and helped review and edit it.

How Open Standards Get to Market

Open standards are developed by a large technical community of people who see the need to lay some foundational ground of how to do a particular thing (If you are not familiar with open standards, here is a podcast that may be helpful). Due to the scale of efforts and influence, it always takes time for open standards to emerge, evolve and mature. A mature standard needs to go through multiple versions of iteration spanning across at least a decade or even more. During this time, you see a community of business and technical developers, normally a growing one, implementing and marketing a standard in many different ways and then feeding their experience back to the standard group in order to shape the next generation of the standard for the better.

Self-Sovereign Identity (SSI) has just been through its first six years of early exploration, during which we see several paths of technology implementation emerge, co-opetition (cooperation between commercial competitors for their mutual advantage) happens, and convergence takes place in time. The W3C Verifiable Credentials (VCs) standard is a good example with the existence of different flavors of VCs (You can find more about the VC flavors in this article I wrote and the associated infographic I developed with Lucy).

If you are a business decision maker looking into SSI, you may wonder if these technical choices matter, especially when the standards are at their early stages. The answer is yes, because all these implementation experiences are going to influence where the standard goes in the future. When a poor technology choice today later becomes a part of a standard, it will have a pervasively negative impact on all of us. It is essential for the pioneers of an industry to make choices to implement and explore possibilities as well as conduct honest critical evaluation of those choices as they meet the real world, so that the next generation of standards can take this into account as they evolve.

I have encountered business leaders who believe in the absolute power of market forces, thus making business decisions without knowing enough or at all about technical details, as well as technical leaders who see market dominance as the solution to a troubled path. While it is true that the market in general rewards whatever is marketed the best, not necessarily built the best, it is also true that critiques for and against different options is an important part of how a market should function, because many want to avoid another market success like the browser cookies, which has turned out to be a “disaster” for netizens.

I believe that those who picked early and explored a pathway on the landscape of potential should all be applauded – it takes a lot of courage to heavily invest in an implementation path at the very early stage of standard development. If the path doesn’t turn out well, it will have a significant impact on the business(es) of those who make significant early investments, especially if they need to abandon most of what they have built. The decision to pivot the technology becomes even more difficult if one has a relatively sizable business, a client and partner base relying on their technology, a group of early investors, and a market leader reputation to maintain. Because of that, it is almost understandable why some want to hold on tight to a problematic path even when they are aware of the issues with their technology stack. And it is with this understanding and respect for all early adopters / implementers that I am writing this article about Hyperledger Indy & Aries / Anoncreds, which so far has been the most-marketed SSI technical stack but not built as well as marketed nor the best one in the market.

Being “Real” about Hyperledger Indy & Aries / AnonCreds

Hyperledger Indy and Aries are two open source projects at the Hyperledger Foundation, a sub-organization of the Linux Foundation. Together with Hyperledger Ursa, the three projects form the core blockchain-based SSI stack at Hyperledger. Aries and Ursa initially originated from Indy, but later became separate projects focusing on different technical aspects:

Indy is a combination of Indy SDK (crypto and ledger communication library) and Indy Node (the ledger implementation code). The Indy blockchain holds the credential schemas and Decentralized Identifiers (DIDs) of issuers and potentially governance registry listings.
Aries is the code for agent applications that all actors in the identity ecosystem can use – issuers, holders and verifiers. This code writes to Indy ledgers and facilitates data exchange, making Indy and Aries a couple tightly implemented together.
Ursa is the cryptographic library used by Indy and Aries.
Anoncreds (ZKP-CL) is a low-level protocol for data exchange that defines data model (VC flavor) and interaction workflows that Indy and Aries use.

I am going to surface a synthesis of challenges / concerns about Hyperledger Indy & Aries / Anoncreds that many have found and brought to my attention. These concerns have existed for some time and have caused friction internal to the community without much public knowledge of them. As SSI is becoming more widely considered by governments, businesses and others around the world, I feel the professional responsibility to raise these lesser-known issues of the most marketed technical SSI option and say them out loud. It is important for anyone considering Hyperledger Indy & Aries / Anoncreds to know and understand these issues and their related business risks before making their decisions.

1. LACK OF STANDARDIZATION AND WEAK STANDARD ALIGNMENT

• No well-documented and agreed-upon specification

Open source code and open standard are two different things. Open standards define a recipe that allow people to implement the same thing in different ways, whether open source or not. By following the same recipe, we ensure some very basic interoperability across software / internet applications, for example, we can send emails from Gmail to Outlook. This interoperability is very important for identity credentials, as we need to use them pretty much everywhere.

Indy / Aries have only been open source code bases that didn’t go through a standardization process to have a well-documented and agreed-upon specification. Those who don’t want to use the code bases can implement what they think the recipe is at their own risk, creating potential interoperability and other challenges down the road. And there is no specification for the Anoncreds format (implemented in the Indy code base now) that could be used to test different implementations, and there is no alternative implementation of Anoncreds to Indy. One can use wrappers to implement the Indy code into another programming language, but this is most likely going to cause memory management and error handling issues, making it hard to build stable software.

Due to market pressure, the Indy / Aries community recently started the standardization process for Anoncreds, years behind other credential formats that have already been engaged in standardization for years.

• Anoncreds (ZKP-CL) not aligning with the core W3C VC Data Model

The core VC data model uses JWT or JSON-LD data formats, both leveraging the material in the credentials themselves and not needing to pull down a schema from a ledger for verifications.

Anoncreds, which doesn’t use any standard data representation technology or VC data model(s), has its own format called ZKP-CL. The schema of this format is built using a JSON structure, but unlike the VC formats mentioned above, when a credential is created using ZKP-CL, the issuer must create a credential schema and write it to an (Indy) ledger for the credentials conforming to that schema to be verifiable. As a result, the verifiers have to get the schemas for the particular credential from the ledger and use that in the calculation to understand the veracity of the credential, making computation more intensive.

The discussion of Anoncreds 2.0 has been underway for several years, including a version of Anoncreds that uses BBS signatures, providing it some potential for adopting different VC data models. However, the progress on this effort has been extremely slow, and this effort will essentially mean reinventing the entirety of Anoncreds stack (Indy SDK and Node).

2. LACK OF TECHNICAL RIGOR

• An old, less performant signature algorithm that is not suitable for a new product

Indy & Aries / Anoncreds is using a signature algorithm called the Camenisch-Lysyanskaya (CL) signature, based on the work by Jan Camenisch and Anna Lysyanskaya published in 2001-2004. CL-signatures uses 2048-bit keys based on RSA cryptography, which is actively being phased out, deprecated, and marked as “legacy” algorithms in some contexts. It is questionable to put it into new technical deployments that are at the beginning of their lifecycle.

CL-signatures, slower and less performant than its modern alternatives, can lead to a set of trade offs that create security issues. For example, key sizes have to be larger to ensure security, requiring more bandwidth to transmit keys around. The larger key sizes also cause slow validation / transaction time (up to 7 seconds for a validation and approximately 30 seconds for credential definition generation when a new issuer is provisioned). The computing requirements also result in the need for powerful user devices for wallets, which means only users with powerful enough mobile devices can use the technology.

Furthermore, CL-signatures are too special to be supported by mainstream secure enclaves and secure elements. As a result, there is no way to protect the cryptographic key material used for holder binding in hardware. That means protection against credential theft and impersonation is software-based only, which is not sufficient for substantial and high assurance use cases. For example, any legitimate user can extract their COVID credential along with its cryptographic commitment to the wallet (link secret) from their phone and sell it on the Internet, meaning potentially millions of users could present a false credential. Given the unlinkability of Anoncreds, it would be impossible to determine which credential was sold – so it cannot be revoked to stop the fraud.

Reputable government agencies such as NIST (US National Institute for Standards in Technology) and BSI (German Federal Office for Information Security) have never approved CL-signatures for government use, an indication that many government projects won’t be able to adopt Anoncreds in its current form, which has a dependency on CL-signatures.

• No proper review and audit of the CL-signatures algorithm implementation

It can take years for new cryptographic curves and primitives coming out of academic work / paper to be ready for scaled deployment in real-world environments. Products that leverage cryptography, in order to ensure safe deployment, normally have a particular life cycle development pathway involving massive testing and vetting by experts.

When Hyperledger accepted the proposed Indy implementation as a donation, the CL-signatures was not battle tested to the same degree as more commonly used cryptographic schemes such as Ed25519 in TLS to secure the Internet or secp256k1 to secure billions of dollars of assets on Bitcoin and Ethereum. There were a significant number of steps missing, including an audit and peer review by cryptographic expert communities. For example, the Internet Engineering Task Force (IETF), a major standard organization for technical standards that make up the Internet protocol suite, delegates its cryptographic audit and review to IRTF Crypto Forum Research Group (CFRG).

Rigorous testing is particularly important for implementation of cryptographic products since most often cryptographic issues emerge from the actual libraries / code bases of cryptographic operations which expose unsafety and vulnerability, rather than the cryptography itself.

• Miscommunication and overhype about link secrets and their role in subject-holder binding

Indy & Aries / Anoncreds implemented an “innovative” idea that embeds a “link secret”, a long number (same for every credential issued into a wallet), within another long number (different for every credential issued into the wallet). This has been communicated as the secret sauce that one implements Anoncreds can use to prove credentials in the same wallet are issued to the same person. This is not only an inaccurate depiction of the capability of the technology stack (as explained in an earlier point regarding CL-signatures) but also a miscommunication of the value of link secrets.

As a matter of fact, link secrets can only ensure that two credentials share a common secret value. One could have two people use the same wallet to collect different credentials, or create a link secret that is in two different wallets and present attributes of credentials from both wallets. In these scenarios, verifiers won’t be able to know if the credentials in the same wallet are issued to the same person. Therefore, even though link secrets can provide value, it is important we have an accurate understanding of its value and don’t rely on/communicate the mechanism for assurances it can’t provide.

This communication gap creates expectations and misplaced assumptions that could lead to significant security issues. An IEEE paper in 2019 explained it in more depth.

3. SERIOUS TECHNICAL, SCALABILITY AND GOVERNANCE ISSUES

• Indy & Aries / Anoncreds was constructed in a way that limited cryptographic agility or “upgradeability” or maintainability or extensibility or portability

Cryptography in large-scale applications has grown progressively more modular over the last decade or so, making it possible for a specification and technology stack to swap out the old algorithm for a new one.

However, Indy was designed to conflate data representation with the cryptographic algorithmic implementation, making it cryptographically fragile – when the algorithms are cracked, the whole stack breaks. There is no “next algorithm” to migrate to relative to the same data structure. This means that when it does break, the whole stack needs to be re-built from scratch.

Therefore, it is a normative best practice to use cryptographic signatures around data in a way that does not conflate a data representation with the cryptographic algorithms. Some well-specified options include Data Integrity (DI), CBOR Object Signing and Encryption (COSE), and Javascript Object Signing and Encryption (JOSE).

• Indy is not able to support large-scale issuance, verification and revocation

Indy was originally built to be single-threaded so that it could support a native token for in-network economics that required double-spend proofing. However, this significantly impacted Indy wallets’ ability to support large-scale implementations. Some implementers validated this scalability issue through their own experience, for example, using the Indy SDK to issue a bit over 18,000 credentials, which ended up taking four hours. One can potentially improve the situation by implementing Aries Askar, which is a standalone solution not pluggable into the Indy SDK.

On the verification side, if 1000 people log into a website at the same time, the verification speed will be very slow and cost prohibitively high. When looking at high scale applications such as the New York COVID certificate application which needed to support millions of verifications per day, an Indy ledger would just fall over.

The credential revocation scheme of Indy is not scalable at high volumes either. One always has to balance performance / functionality with user privacy. A large batch size of revocation list, e.g. 10 million revoked credentials, will better guarantee user privacy through obfuscation and effectively prevent tracking of users on-chain. However, an implementer of Indy said that they could only set the batch size at 10K credentials to keep a reasonable performance. An additional issue on the mobile side – larger batch size will result in larger tails / cryptographic file that a user needs to download from the Indy ledger.

You can find a research paper that came out in April 2022 here, which documented very clearly the scalability issues with Indy ledgers and the approach of how verifications are processed using on-chain located schemas for credentials:

“We conclude that issues of Trust Registry scalability have multiple facets. While Hyperledger Indy captures data useful to underpin a decentralized identity scheme, the knock-on effect of its scalability limitations may indeed place constraints on properties of security and decentralization. The current credential verification process relies on transaction processing by a ledger with transaction processing bottlenecks, which may constrain the ideal of non-repudiation.”

• Indy networks have a governance and economic issue

One of the features people like about blockchains is that they provide for a network of nodes that all agree on a certain state – this means that people are not depending on one database or trusting one party to maintain it. Different parties can work together to maintain a network that all trust. Different ledgers can scale to different sizes of node networks. The Bitcoin network has tens of thousands of nodes for example, across “light” and “full” nodes.

Recent years have seen major advances as node-networking and consensus mechanisms evolve in tandem to power global blockchains. However, if you run an Indy network with more than 25 active write and consensus nodes operating at a time, performance plummets. The limitation poses serious governance issues as it is nearly impossible for Indy networks to have more than a small number of nodes in active operations.

Another major governance issue comes from the configuration of Indy’s auth_rules. By default, it takes one “Trustee” to do almost anything other than freezing the network (which takes three trustees), such as removing DIDs, changing any rule, setting fees, minting tokens, and / or even adding new trustees. Most Indy networks have adjusted the number from one to three “trustees” as the number required to do anything. This means you only need three individuals to collude to take down the entire network, or three individuals’ emails to phish to take down the entire network, or three trustees to erase information from the ledger. There have been Indy networks where more than half of their trustees all come from the same company – meaning that company effectively controls the network.

The governance issues plus technical challenges make it hard for Indy networks to make any economic sense to exist as stand-alone ledgers just for storing credential schemas and DID Documents. That is why some early Indy networks have faced concerns of going down because there are not enough people/organizations wanting to operate nodes.

• Aries has limited adaptability for mobile

Beyond the above-mentioned computing requirements caused by the CL-signatures that lead to limitations on the mobile device side, there are also limitations at the application development level.

Aries is an umbrella of several agent frameworks written in different languages, which differ in feature set and community support. It is not possible to incorporate Aries into a native iOS app because there is no “Aries Framework Swift” (Swift is the native programming language for iOS), so nobody with a native iOS app can add an Aries wallet to it. This severely limits its adoptability. Some have tried to develop an Aries Framework Swift but gave up due to a multitude of challenges.

The only two Aries frameworks that work on mobile today are React-Native and Xamarin (not actively supported anymore), which power a decreasing number of mobile apps in the market, as native Swift and cross-OS Flutter take up more and more market share in recent years.

Additionally, due to the large number of external dependencies Indy has, such as OpenSSL, Libzmp, a React-Native wallet installing the Aries libraries can take up 70+ MB space, a huge amount for those who don’t have the latest iPhones. The external dependencies also make it a pain for developers to support mobile platforms with Aries.

Finding a Way Forward Together as a Community

I am releasing this article right before the Hyperledger Global Forum in Dublin, Ireland from September 12-13, 2022, where I am speaking on multiple occasions about Self-Sovereign Identity / Decentralized Identity. I look forward to engaging there with anyone about this article, whether you are happy to see these issues finally being publicly shared or concerned about how it will influence your business.

I have rooted my entire career in this community and care about all of you who are working hard to make our common mission a reality. As the world is paying more attention to our work and eager to work with us, I am committed to helping us find a way forward as a community.

Exciting SSI announcement was not well received by some

Kaliya Young · December 17, 2018 ·

The Microsoft-Mastercard SSI alliance is great news, but some thought it was a bad thing.

By all accounts, Fast Company’s Cale Guthry Weissman is a good reporter who knows his audience. Informed that Microsoft and Mastercard were partnering to create a new kind of digital identity, he went to get some answers, assessed the situation, and wrote an article that called the alliance “frightening”

But the solution they offer–a one-stop, universal identification for any and all applications–would mean that every citizen would be entering into a system built by private companies that centralizes all of their personal data. Every digital company wants to be a data hoover, and this program seems to underscore the extent of this pursuit.
[…]
Overall, this announcement speaks to a common tone-deafness among large companies when it comes to privacy. While proving digital identity can certainly be onerous, some solutions may only imperil us even more.

Microsoft and Mastercard have a frightening plan to create “digital identities”, Fast Company 12/04/18

Weissman can be forgiven for such a sentiment; tech companies have a well earned reputation for turning their users into unwitting laborers on data farms. But it should be noted that Mastercard isn’t “a tech company”. When Weissman reached the global credit card company for comment they explained their bold new venture with excitement, emphasising that they’re going to use trusted sources to give control to the user, who will “share only the information needed to conduct their transactions,” but it didn’t really seem to take. They came off like someone who walked into a party wearing a set of Google Glass, then tried to use the uncomfortable pause that it created to explain how his dork goggles weren’t just a mass surveillance tool, they were also going to change the world! The spokesman would have done better to explain that SSI applications are explicitly NOT “centralized” as Weissman came away understanding, but they appear to have got a bit carried away.

“The next update will let me see into your soul, but it’s nothing to worry about.”

It seems like a good solution because it is a good solution, but Mastercard won’t be able to sell it themselves

We have no reason to doubt that Mastercard’s excitement is earnest. Credit card companies live the third-party verification problem every day, because they’re third party verifiers. Mastercard sees ease-of-use and fraud prevention savings in this project that are meaningful, and are excited about being able to achieve them without having to handle customer data. They’re telling their merchants and cardholders: “Look! You’re going to FINALLY have control of your own verification process! No more 2 pieces of ID with a credit card, and we don’t even have to hand the process over to a data-harvesting behemoth to get it done! (You just know Facebook or Amazon would have underbid anyone to get their hands on card verification contract, and for all the wrong reasons.) But Fast Company isn’t inclined to take them at their word. After all, they are partnering with Microsoft, who would surely know what to do with a bunch of cardholder and merchant data.
Microsoft, for their part, declined comment, which is interesting since they have so many good people working on this project who could comment eloquently including Daniel Buchner, Pamela Dingle and Kim Cameron among others. Perhaps from the PR department the silence is born of experience. Microsoft is the butt of the funniest tech jokes, and is aware of the shadow they cast. There isn’t anything they say to the general public to convince them that an identity play they’re making isn’t just another way to sink their tentacles into their users a bit further. The process knowledge just isn’t out there. Best say nothing until it’s ready.

Microsoft have good reasons to be this helpful.

The Microsoft that dominated the 90s and early oughts got their lunch eaten by Google, Facebook and Amazon, who cornered users into a Faustian bargain that they didn’t even know they were making. Microsoft’s unbreakable hold on the enterprise software market financed attempts to compete in the data and advertising realm, but it’s clear by now that beating data harvesters at their own game isn’t in the company’s DNA. This identity play may be Microsoft doing the next best thing: taking them out at the knees by giving the data control back to the customers.
Facebook is able to give access Cambridge Analytica and others access to user data by virtue of the fact that they have it. They could (and still do) broker access to users via their data, because they have ongoing user consent. If the user revokes that consent, nobody is checking if they’re honouring that revocation.
But they can’t sell what they don’t have. A user-centred permissions system would allow individuals to give Twitch streaming access to their X-Box ONE account, or not. LinkedIN could offer seamless work history verification, which would allow for an easy transition into the corporate HR services business, handling payroll, insurance and benefits for enterprises – all newly simplified user centric verifiable credentials. There are all sorts of places Microsoft can organically grow their core software business once the framework is in place to allow users and organizations to provide and revoke data from each other… once they can get over concerns people have over how the system actually operates.
There is not yet an SSI killer app. While Microsoft would no doubt like very much to develop one, they’re probably just as happy having someone else strike the discovery vein that gets the public’s attention. Once the user base gets wise to their new-found control, a self-sovereign-ID-enabled Microsoft will be in a position to enter the 2020s as a major player in this new market place of decentralized identity and credentials under the true control of the user.
(With files from Braden Maccke. Feature image courtesy Humans Unlimited Blog.)

MyData 2018: Domains of Identity & Self-Sovereign Identity

Kaliya Young · August 30, 2018 ·

Here are the slides of my talks and some links to the material covered.
1. The MyData —> Identity Connection
If you don’t have control of your identifiers you can’t control your data.
2. How did I begin in Identity?
Via the Planetwork Community and its vision of the Augmented Social Network White Paper.
3. The Domains of Identity – My Masters Report
4. An Overview of Self-Sovereign Identity
If you are interested in our report on SSI it can be found here. It is priced for the audience we wrote it for C-Level Executives.
5. Conclusion —> Creating Alignment
I referenced my three phase plan for Systems Leadership & the Short, Long Report & resource guide that accompany them.

See the Larger System
Reflective and Generative Conversation
Co-Create the Future

I concluded by highlighting ideas from this post by Eugene Kim
The Art of Aligning Groups

The Domains of Identity & Self-Sovereign Identity MyData 2018 from Kaliya "Identity Woman" Young

Dear IDESG, I’m sorry. I didn't call you Nazi's.

Kaliya Young · November 9, 2014 · Leave a Comment

The complaint was that I called my fellow IDESG colleagues Nazi’s. He was unsatisfied with my original statement about the tweet on our public management council mailing list. Some how this led to the Ombudsman taking on the issue and after I spoke with him in Tampa it was followed by a drawn out 5 week “investigation” by the Ombudsman before he issued a recommendation.
Then turns out after all was said and done there was never actually a formal complaint. There was the ombudsman taking action on his own. (its funny how organizations can use Ombudsman to not actually protect people with in institutions but use them as institutional forces to push people out who speak up and ask too many questions)
During the time I was being investigated I experienced intensive trolling about the matter on twitter itself. The trolling was done by someone obviously familiar with the situation who was upset. There were only 5 people familiar with them matter as it was ongoing through this investigation.During my own IIW conference the troll topped off the week by making implicit rape threats. This was very very disruptive and upsetting to me so much so I don’t even remember that IIW.
Here is the tweet that I authored while pondering theories of organizational dynamics in Tampa and without any intent to cause an association in the mind of a reader with IDESG, NSTIC, nor any person or persons in particular note that I did not reference anyone with a @____ or add any signifying hashtags e.g., #idesg or #nstic in this tweeted comment. So unless you were reading everything you would never know I said it.

I own that the tweet was provocative but it was It was not my intent to cause harm to anybody or to the IDESG organization and wider identity community.
We can’t put documents up for community and public input and say “its 40 page document nobody has time to read” and laugh as if it is funny that the process is so bad that there is no ability for the body of the organization let alone the public to have insight. That is how not good things begin to happen no one is looking. I was trying to make a point that the meeting was being badly badly run and that poor process can lead to really bad outcomes.
I am very sorry if the tweet had an emotionally negative impact on people on the management council. I fully acknowledge that referencing anything relative to the Nazi era is triggering. It touches on our collective shame and surfaces vulnerability it is very hard to look at.
I also believe that we have to actually be prepared to do so. If we don’t examine the past we can’t be sure we will not repeat it. [Please click to see my my next post for this to be further expounded upon]
I didn’t choose to say anything along these lines because I was in the middle of a process with the Ombudsman I thought that would be honored and let to run its course.
I also didn’t feel one should feed internet trolls – one was being very aggressive and pestering me for an apology.
I think that we all need to keep in mind our roles as Directors of the IDESG when we interact with the public and with each other.
This includes hiding behind pseudonyms and aggressively trolling to get back at someone you are upset with. Which also happened – either deal with the issue in a formal process or take them out on twitter but do’t do both.
The whole process left my and my attorney puzzled. My attorney wrote a letter to the Management Council/Board of Directors with a whole bunch of questions and now that this is posted we look forward to their answers to those questions.
No one from he IDESG including the ombudsman ever responded or was concerned by the aggressive trolling and implicit rape threats on twitter by someone intimately familiar with the ongoing ombudsman process.
Abusive behavior towards women isn’t just a physical thing it is a psychological as well. I have felt unsafe in the Identity community since this incident. I am now setting it aside though and stepping forth in my full power.

Resources for HopeX Talk.

Kaliya Young · July 21, 2014 · 1 Comment

I accepted an invitation from Aestetix to present with him at HopeX (10).
It was a follow-on talk to his Hope 9 presentation that was on #nymwars.
He is on the volunteer staff of the HopeX conference and was on the press team that helped handle all the press that came for the Ellsberg – Snowden conversation that happened mid-day Saturday. It was amazing and it went over an hour – so our talk that was already at 11pm (yes) was scheduled to start at midnight.
Here are the slides for it – I modified them enough that they make sense if you just read them. My hope is that we explain NSTIC, how it works and the opportunity to get involved to actively shape the protocols and policies maintained.

[Read more…] about Resources for HopeX Talk.

Core Concepts in Identity

Kaliya Young · July 31, 2013 · 1 Comment

One of the reasons that digital identity can be such a challenging topic to address is that we all swim in the sea of identity every day. We don’t think about what is really going in the transactions….and many different aspects of a transaction can all seem do be one thing. The early Identity Gang conversations focused a lot on figuring out what some core words meant and developed first shared understanding and then shared language to talk about these concepts in the community.
I’m writing this post now for a few reasons.
There is finally a conversation about taxonomy with the IDESG – (Yes! after over a year of being in existence it is finally happening (I recommended in my NSTIC NOI Response that it be one of the first things focused on)
Secondly I have been giving a 1/2 day and 1 day seminar about identity and personal data for several years now (You can hire me!). Recently I gave this seminar in New Zealand to top enterprise and government leaders working on identity projects 3 times in one week. We covered:

The Persona and Context in Life
The Spectrum of Identity
What is Trust?
A Field Guide to Internet Trust
What is Personal Data
Market Models for Personal Data
Government Initiatives Globally in eID & Personal Data

Info Sharing Agreements! Support it! Make it Real!

Kaliya Young · May 23, 2012 · 2 Comments

Joe Andrieu and the Information Sharing Working Group has put a lot of work and effort into creating a Standard set of Information Sharing Agreements represented by a standard label. They want to invest in user -research to make it really work.
I am putting in $100 and I encourage all of you to do the same. They need to raise $12000 in the next 8 days.
See the Kickstarter Campaign here.

Recent Travels Pt1: IIW

Kaliya Young · November 27, 2011 · Leave a Comment

IIW is always a whirlwind and this one was no exception. The good thing was that even with it being the biggest one yet it was the most organized with the most team members. Phil and I were the executive producers. Doc played is leadership role. Heidi did an amazing job with production coordinating the catering, working with the museum and Kas did a fabulous job leading the notes collection effort and Emma who works of site got things up on the wiki in good order.
We had a session that highlighted all the different standards bodies standards and we are now working on getting the list annotated and plan to maintain it on the Identity Commons wiki that Jamie Clark so aptly called “the switzerland” of identity.

We have a Satellite event for sure in DC January 17th – Registration is Live.
We are working on pulling one together in Toronto Canada in
early February, and Australia in Late March.
ID Collaboration Day is February 27th in SF (we are still Venue hunting).
I am learning that some wonder why I have such strong opinions about standards…the reason being they define the landscape of possibility for any given protocol. When we talk about standards for identity we end up defining how people can express themselves in digital networks and getting it right and making the range of possibility very broad is kinda important. If you are interested in reading more about this I recommend Protocol: and The Exploit. This quote from Bruce Sterling relative to emerging AR [Augmented Reality] Standards.

If Code is Law then Standards are like the Senate.

Web Wide Sentence Level Annotation -> Hypothes.is

Kaliya Young · October 15, 2011 · Leave a Comment

I first met Dan Whaley last spring via an introduction from Jim Fournier co-founder of Planetwork. I was inspired by the vision he was working on building Hypothes.is – a way to have sentence level annotation of news and other articles on a web wide scale. Really a foundation for peer review on the web. The motivation for his work is to support greater discernment of the truth around climate change and other key issues facing our society and our planet. (Another area I could see this being really useful right now is around accountability in the financial system and ways to make that real.)
He asked me to be a part of the project as an advisor particularly around identity issues and technology options for identity. He is taking my advice and coming to IIW this coming week. Its an honor to be amongst other distinguished advisors like Brewster Kahle, John Perry Barlow, Mark Surman and others..

He has been working on a development plan and has a solid on one in place. He has launched a Kickstarter Campaign and stars in the video that articulates the vision of the project. If you are inspired by the vision I encourage you to contribute.

Is Google+ is being lynched by out-spoken users upset by real names policy?

Kaliya Young · August 28, 2011 · 5 Comments

Following my post yesterday Google+ says your name is “Toby” not “Kunta Kinte”, I chronicled tweets from this morning’s back and forth with Tim O’Reilly and Kevin Marks, Nishant Kaushik, Phil Hunt, Steve Bogart and Suw Charman-Anderson.
I wrote the original post after watching the Bradley Horwitz (@elatable) – Tim O’Reilly (@timoreilly) interview re: Google+. I found Tim’s choice of words about the tone (strident) and judgement (self-righteous) towards those standing up for their freedom to choose their own names on the new social network being rolled out by Google internet’s predominant search engine disappointing. His response to my post was to call me self-righteous and reiterate that this was just a market issue.
I myself have been the victim of a Google+ suspension since July 31st and yesterday I applied for a mononym profile (which is what it was before they insisted I fill out my last name which I chose to do so with my online handle and real life identity “Identity Woman”)
In the thread this morning Tim said that the kind of pressure being aimed at Google is way worse then anything they are doing and that in fact Google was the subject of a “lynch mob” by these same people. Sigh, I guess Tim hasn’t read much history but I have included some quotes form and links to wikipedia for additional historial context.
Update: inspired in part by this post an amazing post “about tone” as a silencing/ignoring tactics when difficult, uncomfortable challenges are raised in situations of privilege was written by Shiela Marie.
I think there is a need for greater understanding all around and that perhaps blogging and tweeting isn’t really the best way to address it. I know that in the identity community when we first formed once we started meeting one another in person and really having deep dialogues in analogue form that deeper understanding emerged. IIW the place we have been gathering for 6 years and talking about the identity issues of the internet and other digital systems is coming up in mid-October and all are welcome. The agenda is created live the day of the event and all topics are welcome.
Here’s the thread… (oldest tweets first)
Note all the images of tweets in this thread are linked to the actual tweet (unless they erased the tweet). [Read more…] about Is Google+ is being lynched by out-spoken users upset by real names policy?

Google+ says your name is "Toby" NOT "Kunta Kinte"

Kaliya Young · August 27, 2011 · 21 Comments

This post is about what is going on at a deeper level when Google+ says your name is “Toby” NOT “Kunta Kinte”. The punchline video is at the bottom feel free to scroll there and watch if you don’t want to read to much.

This whole line of thought to explain to those who don’t get what is going on with Google+ names policy arose yesterday after I watched the Bradley Horwitz – Tim O’Reilly interview (they start talking about the real names issue at about minute 24).

Lets try going with the Mononym for Google+

Kaliya Young · August 27, 2011 · 6 Comments

Seeing that Google+ is approving mononyms for some (Original Sai, on the construction of names Additional Post) but not for others (Original Stilgherrian Post Update post ).
I decided to go in and change my profile basically back to what it was before all this started. I put a ( . ) dot in the last name field. In my original version of my google proflile my last name was a * and when they said that was not acceptable I put my last name as my online handle “Identity Woman”.
[Read more…] about Lets try going with the Mononym for Google+

Google+ and my "real" name: Yes, I'm Identity Woman

Kaliya Young · July 31, 2011 · 25 Comments

When Google+ launched, I went with my handle as my last name. This makes a ton of sense to me. If you asked most people what my last name is, they wouldn’t know. It isn’t “common” for me. Many people don’t even seem to know my first name. I can’t tell you how many times I have found myself talking with folks at conferences this past year and seeing ZERO lighbulbs going off when I say my name “Kaliya”, but when I say I have the handle or blog “Identity Woman” they are like “Oh wow! You’re Identity Woman… cool!” with a tone of recognition – because they know my work by that name.
One theory I have about why this works is because it is not obvious how you pronounce my name when you read it. And conversely, it isn’t obvious how you write my name when you hear it. So the handle that is a bit longer but everyone can say spell “Identity Woman” really serves me well professionally. It isn’t like some “easy to say and spell” google guy name like Chris Messina or Joseph Smarr or Eric Sachs or Andrew Nash. I don’t have the privilege of a name like that so I have this way around it.
So today…I get this

I have “violated” community standards when using a name I choose to express my identity – an identity that is known by almost all who meet me. I, until last October, had a business card for 5 years that just had Identity Woman across the top.

Display Name – To help fight spam and prevent fake profiles, use the name your friends, family, or co-workers usually call you. For example, if your full legal name is Charles Jones Jr. but you normally use Chuck Jones or Junior Jones, either of these would be acceptable. Learn more about your name and Google Profiles.

Authored: National! Identity! Cyberspace! Why we shouldn’t freak out about NSTIC.

Kaliya Young · January 10, 2011 · 2 Comments

This is cross posted on my Fast Company Expert Blog with the same title.

I was very skeptical when I first learned government officials were poking around the identity community to learn from us and work with us. Over the last two and a half years, I have witnessed dozens of dedicated government officials work with the various communities focused on digital identity to really make sure they get it right. Based on what I heard in the announcements Friday at Stanford by Secretary of Commerce Locke and White House Cybersecurity Coordinator Howard Schmidt to put the Program Office in support of NSTIC (National Strategy for Trusted Identities in Cyberspace) within the Department of Commerce. I am optimistic about their efforts and frustrated by the lack of depth and insight displayed in the news cycle with headlines that focus on a few choice phrases to raise hackles about this initiative, like this from CBS News: Obama Eyeing Internet ID for Americans.
I was listening to the announcement with a knowledgeable ear, having spent the last seven years of my life focused on user-centric digital identity. Our main conference Internet Identity Workshop held every 6 months since the fall of 2005 has for a logo the identity dog: an allusion to the famous New Yorker cartoon On the internet, nobody knows you are a dog. To me, this symbolizes the two big threads of our work: 1) maintaining the freedom to be who you want to be on the internet AND 2) having the freedom and ability to share verified information about yourself when you do want to. I believe the intentions of NSTIC align with both of these, and with other core threads of our communities’ efforts: to support identifiers portable from one site to another, to reduce the number of passwords people need, to prevent one centralized identity provider from being the default identity provider for the whole internet, to support verified anonymity (sharing claims about yourself that are verified and true but not giving away “who you are”), support broader diffusion of strong authentication technologies (USB tokens, one-time passwords on cellphones, or smart cards), and mutual authentication, allowing users to see more closely that the site they are intending to do business with is actually that site.
Looking at use cases that government agencies need to solve is the best way to to understand why the government is working with the private sector to catalyze an “Identity Ecosystem”.
The National Institutes of Health is a massive granting institution handing out billions of dollars a year in funding. In the process of doing so, it interacts with 100,000’s of people and does many of those interactions online. Many of those people are based at institutions of higher learning. These professors, researchers, post-docs and graduate students all have identifiers that are issued to them by the institutions they are affiliated with. NIH does not want to have the expense of checking their credentials, verifying their accuracy and enrolling them into its system of accounts, and issuing them an NIH identifier so they can access its systems. It wants to leverage the existing identity infrastructure, to just trust their existing institutional affiliation and let them into their systems. In the United States, higher educational institutions have created a federation (a legal and technical framework) to accept credentials from other institutions. The NIH is partnering with the InCommon Federation to be able to accept, and with that acceptance to trust, identities from its member institutions and thus reduce the cost and expense of managing identities, instead focusing on its real work: helping improve the health of the nation through research.

The NIH also has a vast library of research and information it shares with the general public via the internet. Government sites are prohibited from using cookie technology (putting a unique number in your browser cookie store to remember who you are) and this is a challenge because cookies are part of what helps make Web 2.o interactive experiences. So say that your mom just was diagnosed with breast cancer and you want to do a bunch of in-depth research on breast cancer treatment studies. You go to the NIH and do some research on it, but it really requires more then one sitting, so if you close your browser and come back tomorrow, they don’t have a way to help you get back to the place you were.

The NIH doesn’t want to use a cookie and doesn’t want to know who you are. They would like to be helpful and support your being able to use their library over time, months and years, in a way that serves you, which means you don’t have to start from scratch each time you come to their website. It was fascinating to learn about the great lengths to which government officials were going to adopt existing standards and versions of those standards that didn’t link users of the same account across government websites (see my earlier post on Fast Company). They proactively DID NOT want to know who users of their library were.

One more use case from the NIH involves verified identities from the public. The NIH wants to enroll patients in ongoing clinical trials. It needs to actually know something about these people – to have claims about them verified, what kind of cancer do they have, where are they being treated and by whom, where do they live, etc. It wants to be able to accept claims issued by third parties about the people applying to be part of studies. It does not want to be in the business of verifying all these facts, which would be very time consuming and expensive. It wants to leverage the existing identity infrastructures in the private sector that people interact with all the time in daily life, and accept claims issued by banks, data aggregators, utility companies, employers, hospitals etc.

These three different kinds of use cases are similar to others across different agencies, and those agencies have worked to coordinate efforts through ICAM which was founded in September 2008 (Identity, Credential and Access Management Subcommittee of the Information Security & Identity Management Committee established by the Federal CIO Council). They have made great efforts to work with existing ongoing efforts and work towards interoperability and adopting existing and emerging technical standards developed in established industry bodies.

Let’s continue exploring what an identity ecosystem that really works could mean. The IRS and the Social Security Administration would each like to be able to let each person it has an account for login and interact with it online. We as those account holders would like to do this – it would be more convenient for us – but we want to know that ONLY we can get access to our records, that that they won’t show our record to someone else.
So let’s think about how one might be able to solve this problem.
One option is that each agency that interacts with anywhere from thousands to millions of citizens issues their own access credentials to the population it serves. This is just a massively expensive proposition. With citizens interacting with lots of agencies, they would need to manage and keep straight different IDs from different agencies. This is untenable from a end-user perspective and very expensive for the agencies.

Another option is that the government issues one digital ID card to everyone ,and this one ID could be used at a bunch of different agencies that one might interact with. This is privacy-invasive and not a viable solution politically. No one I have ever talked to in government wants this.

So how to solve this challenge – how to let citizens login to government sites that contain sensitive personal information – whether it be tax records, student loan records, Department of Agriculture subsidies, or any other manner of government services, and be sure that it really is the person via an Identity Ecosystem.
Secretary Locke’s Remarks: The president’s goal is to enable an Identity Ecosystem where Internet users can use strong, interoperable credentials from public and private service providers to authenticate themselves online for various transactions.
What does a private sector service provider use case look like in this ecosystem?

When we open accounts, they are required to check our credentials and verify our identities under know-your-customer laws. People have bank accounts and use them for many years. They know something about us because of their persistent ongoing relationship with us: storing our money. Banks could, in this emerging identity ecosystem, issue their account holders digital identity credentials that would be accepted by the IRS to let them see their tax records.

The private sector, for its own purposes, does a lot to verify the identities of people, because it has to do transactions with them that include everything from opening a bank account, to loaning money for a house, to setting up a phone or cable line, to getting a mobile phone, to a background check before hiring. All of these are potential issuers of identity credentials that might be accepted by government agencies if appropriate levels of assurance are met.

What does is a public service provider look like in this ecosystem?
The Federal Government does identity vetting and verification for its employees. Homeland Security Presidential Directive 12 (HSPD-12), Policy for a Common Identification Standard for Federal Employees and Contractors directs the implementation of a new standardized identity badge designed to enhance security, reduce identity fraud, and protect personal privacy. To date, it has issued these cards to over 4 million employees and contractors.
These government employees should in this emerging ecosystem be able to use this government-issued credential if they need to verify their identities to commercial entities when they want to do business with in the private sector.

There is a wide diversity of use cases and needs to verify identity transactions in cyberspace across the public and private sectors. All those covering this emerging effort would do well to stop just reacting to the words “National” “Identity” and “Cyberspace” being in the title of the strategy document but instead to actually talk to the the agencies to to understand real challenges they are working to address, along with the people in the private sector and civil society that have been consulted over many years and are advising the government on how to do this right.

I am optimistic that forthcoming National Strategy and Program Office for Trusted Identities in Cyberspace will help diverse identity ecosystem come into being one that reduce costs (for governments and the private sector) along with increasing trust and overall help to make the internet a better place.

[Read more…]

Cartoon of the year!

Kaliya Young · December 27, 2010 · Leave a Comment

Infocards, while currently not enjoying broad adoption, are inevitable — Paul Madsen Cartoon

When I first saw this cartoon in my aggregator it made me laugh and sigh.
At the privacy event at MIT at the beginning of this month the word on the street was that both OpenID as we know it and information cards as we know it are both “dead”.
I am a bit afraid for naming this “whispered fact” in the public blogosphere. The reason I am doing it is because I am very interested in learning more from people who were at the event about what was covered and what they think is promising.
I do know that there is energy behind moving OpenID ABC forward and John Bradley & Nat Sakimura are working hard on it.

When to share your real name? Blizzard and their Real ID plans.

Kaliya Young · July 8, 2010 · 1 Comment

I was recently CCed in a tweet referencing this article “Why Real ID is a Really Bad Idea“about World of Warcraft implementing their version of a “Real ID” in a way that violated the trust of its users.
The woman writing the article is very clear on the identity “creep” that happened and got to the point of requiring users to use the Real ID account within the system to post on forums and EVEYWHERE they interacted on company websites.
She articulates clearly why this creates an unhealthy climate and a chilled atmosphere for many users.
[Read more…] about When to share your real name? Blizzard and their Real ID plans.

Thoughts on the National Strategy for Trusted Identities in Cyberspace

Kaliya Young · June 25, 2010 · 1 Comment

Update: This blog post was written while reading the first draft released in the Summer of 2010. A lot changed from then to the publishing of the document in April 2011.
Here is my answer to the NSTIC Governence Notice of Inquiry.
And an article I wrote on Fast Company: National! Identity! Cyberspace! Why you shouldn’t freak out about NSTIC.
Interestingly in paragraph two on the White House blog it says that NSTIC stands for “National Strategy for Trusted Initiatives in Cyberspace” rather than “National Strategy for Trusted Identities in Cyberspace”.

This first draft of NSTIC was developed in collaboration with key government agencies, business leaders and privacy advocates. What has emerged is a blueprint to reduce cybersecurity vulnerabilities and improve online privacy protections through the use of trusted digital identities.

Fire Fox and Identity in the Browser

Kaliya Young · November 28, 2009 · Leave a Comment

ReadWriteWeb reports this week:

Decrying redirects and iframes, Raskin tells of a brave new world where an in-browser button that defies navigational difficulties allows for something closer to true identity portability than we’ve seen yet:Identity will be one of the defining themes in the next five years of the Web. Nearly every site has a concept of a user account, registration, and identity. Searching for “sign in” on Google yields over 1.8 billion hits. And yet, the browser does nothing to make this experience better save for some basic auto form filling. The browser leaves websites to re-implement identity management, and forces users to learn a new scheme for every site… Your identity is too important to be owned by any one company. Your friends are too important to be owned by any one company.

Finally! They said it!

Comments in reaction to the ReadWriteWeb post highlight Information Cards & CardSpace are not mentioned – I point out in my comment that the work is all connected ant pointed to the IIW conversations about Active Clients attended by all.
Aza open their post with this paragraph:

Identity will be one of the defining themes in the next five years of the Web. Nearly every site has a concept of a user account, registration, and identity. Searching for “sign in” on Google yields over 1.8 billion hits. And yet, the browser does nothing to make this experience better save for some basic auto form filling. The browser leaves websites to re-implement identity management, and forces users to learn a new scheme for every site.

They make these key points following the images they have (you should check the images out)

• Identity is part of where you are, and what you are looking at (Amazon looks different depending on if you are signed in or not). That’s why we put it in the URL Bar.
• For most sites, you’ll probably only have one identity, so login will be a single click or automatic.
• Putting verbs into the navigation bar isn’t new. See Taskfox.
• To increase visibility, webpages should be able to make a Javascript call that opens the login/signup bubble.
• For webpages that want to own the login-process, the account creation simply acts as the ultimate form-fill. For those interested in the evolution of the idea, you can see an early mockup with comments as well as Alex Faaborg’s similiar mockups.

They also make this point…

Chris Messina and others has been advocating for a model which follows the Facebook Connect lead: a single verb, to connect. Once connected, you decide exactly what information to share in an asynchronous manner. Unfortunately this bleeds information — your name is known to all websites which which you connect. We’d like to explore what a connect metaphor in combination with the ability to remain anonymous but connected means.

I agree with the firefox folks. Having a way to do verified anonymity is essential.
“Selective Disclosure” is the name for technologies that do this.
The firefox team should check out Stefan’s U-Prove Technology that may be released shortly by MSFT that acquired it over a year ago –
(seems like Stefan killed his blog when he moved to MSFT..mmm..anyways.)
Firefox folks invite people to get involved here.

Open Identity for Open Government Explained

Kaliya Young · September 9, 2009 · 7 Comments

Today the United States Government with digital identity industry leaders announced the development of a pilot project with NIH and related agencies using two of the open identity technology standards OpenID and Information Cards.
This is, as a friend said to me, a “jump the shark moment” – these technologies are moving out from their technologists technology cave into mainstream adoption by government agencies. We are seeing the convergence of several trends transform the way citizens participate in and communicate with government:

Top-down support for open government
The proliferation of social media
The availability of open identity technologies

The Obama administration open government memorandum called for transparency participation, collaboration and federal agencies have begun to embrace Web 2.0 technologies like blogs, surveys, social networks, and videocasts.
Today there are over 500 government websites and about 1/3 of them require a user name and password. Users need to be able to register and save information and preferences on government websites the same way they do today with their favorite consumer sites, but without revealing any personally identifiable information to the government.
The challenge is that supporting this kind of citizen interaction with government via the web means that identity needs to be solved. On the one hand you can’t just ask citizens to get a new user-name and password for all the websites across dozens of agencies that they log in to. On the other you also can’t have one universal ID that the government issues to you and works across all government sites. Citizens need a way to interact with their government pseudonymously & in the future in verified ways.
So how will these technologies work?
Those already familiar with OpenID know that typically when users login with it they give their own URL – www.openIDprovider.com/username. (see this slideshare of mine if you want to see OpenID 101) There is a little known part of the OpenID protocol called directed identity – that is a user gives the name of their identity provider – Yahoo!, Google, MSN etc – but not their specific identifier. The are re-directed to their IdP and in choosing to create a directed identity they get an identifier that is unique to the site they are logging into. It will be used by them again and again for that site but is not correlatable across different websites / government agencies. The good news is it is like having a different user-name across all these sites but since the user is using the same IdP with different identifiers (unlinked publicly) but connected to the same account they just have to remember one password.
Information Cards are the new kids on the identity block in a way – this is their first major “coming out party” – I am enthusiastic bout their potential. It requires a client-side tool called a selector that stores the user’s “digital cards”. Cards can be created by the end user OR third parties like an employer, financial institution, or school can also issue them.

In essence, this initiative will help transform government websites from basic “brochureware” into interactive resources, saving individuals time and increasing their direct involvement in governmental decision making. OpenID and Information Card technologies make such interactive access simple and safe. For example, in the coming months the NIH intends to use OpenID and Information Cards to support a number of services including customized library searches, access to training resources, registration for conferences, and use of medical research wikis, all with strong privacy protections.

Dr. Jack Jones, NIH CIO and Acting Director, CIT, notes, “As a world leader in science and research, NIH is pleased to participate in this next step for promoting collaboration among Assurance Level 1 applications. Initially, the NIH Single Sign-on service will accept credentials as part of an “Open For Testing” phase, with full production expected within the next several weeks. At that time, OpenID credentials will join those currently in use from InCommon, the higher education identity management federation, as external credentials trusted by NIH.” In digital identity systems, certification programs that enable a site — such as a government agency — to trust the identity, security, and privacy assurances from an identity provider are called trust frameworks. The OIDF and ICF have worked closely with the federal government to meet the security, privacy, and reliability requirements set forth by the ICAM Trust Framework Adoption Process (TFAP), published on the IDManagement.gov website. By adopting OpenID and Information Card technologies, government agencies can cost effectively serve their constituencies in a more personalized and user friendly way.

“It’s good to see government taking a leadership role in moving identity technology forward. It’s also good to see government working with experts from private sector and especially with the Information Card Foundation and the OpenID Foundation because identity is not a technical phenomenon — it’s a social phenomenon. And technological support for identity requires the participation of a broad community and of representatives of government who define the legal framework within which identity will operate,” said Bob Blakley, Vice President and Research Director, Identity and Privacy Strategies, Burton Group. “Today’s announcement supplies the most important missing ingredient of the open identity infrastructure, mainly the trust framework. Without a trust framework it’s impossible to know whether a received identity is reliable.”

Under the OIDF and ICF’s open trust frameworks, any organization that meets the technical and operational requirements of the framework will be able to apply for certification as an identity provider (IdP). These IdPs can then supply authentication credentials on behalf of their users. For some activities these credentials will enable the user to be completely anonymous; for others they may require personal information such as name, email address, age, gender, and so on. Open trust frameworks enable citizens to choose the identity technology, identity provider, and credential with which they are most comfortable, while enabling government websites to accept and trust these credentials. This approach leads to better innovation and lower costs for both government and citizens.

The government is looking to leverage industry based credentials that citizens already have to provide a scalable model for identity assurance across a broad range of citizen and business needs – doing this requires a trust framework to assess the trustworthiness of the electronic credentials; see Trust Framework Provider Adoption Process (TFPAP). A Trust Framework Provider is an organization that defines or adopts an online identity trust model involving one or more identity schemes, has it approved by a government or community such as ICAM, and certifies identity providers as compliant with that model. The OIDF and ICF will jointly serve as a TFP operating an Open Trust Framework as defined in their joint white paper, Open Trust Frameworks for Open Government.
Both the OpenID and Information Card Foundation have been working very hard on this for many months – last night I was fortunate to their boards at a history first ever joint dinner.
There are two women in particular though who have driven this forward: Judith Spencer of the Federal Identity, Credential, and Access Management Committee on the government side and Mary Ruddy of Meristic Inc on the industry side. Both of them will be speaking about the project at the Gov 2.0 Summit on Thursday.
Personally this announcement shows how far things have come since I facilitated the first Internet Identity Workshop in 2005 with 75 idealistic identity technologies talking about big ideas for use-centric identity. I am really looking forward to discussing these developments at the forthcoming 9th Internet Identity Workshop in November.