Amira Progress Report (2026)

Amira is a use case for pseudonymous identity that has grown over time, and today is available as a fully featured demo, showing the power of what was imagined almost a decade ago.

If you’re already familiar with the Amira use case, you’ll be most interested in how we’ve made Amira a reality with XIDs. Jump to that!

Original Issue (January 2017)

The Amira use case (originally an “Alice” use case) was first presented on January 12, 2017 by Christopher Allen as an issue on the W3C vc-use-cases repo. The crux of the use case was:

“she wishes to take a more active role in making a better world. However, she knows if she stands out from the crowd that any activism she may get involved in may not only affect her, they may affect her parents or even her extended family abroad.”

As a use case for verifiable claims (verifiable credentials), it had a few major parts:

1. Amira wants to privately contribute to a software project.
2. Amira anonymously provides reputational information.
3. Amira is able to increase her anonymous reptuation over time.
4. Amira is able to selectively revoke parts of her anonymity in the future.

RWOT 5 Advanced Reading (July 2017)

Christopher Allen revised the original use case as an advance reading for Rebooting the Web of Trust 5 in Boston. One of the most important revisions in the advance reading was that it recognized Amira’s story as being about “pseudonymous identity” and linked it to the DID standard then being worked on at the RWOT workshops.

The concept of pseudonymous identity is crucial because it provides a container for Amira’s anonymous reputational information: an alternate identity that is stable and consistent and that can accrue credentials over time, eventually bootstrapping into an identity that might be as trusted and respected as any real-life, non-pseudonymous identity.

The advanced reading also provided the first technical details suggesting that the Amira use case soon become a reality, using current near-future technology. That included DIDs (still in process at the time, since they weren’t published until 2022) and multisigs.

Amira 1.0.0 White Paper (July 2018)

Amira became a group project in October 2017 at RWOT5 in Boston and then was finalized and polished over the next nine months, ultimately resulting in a more complete white paper. The white paper used Joe Andrieu and Ian Henderson’s “information lifecycle engagement model” to lay out a 15-step model for using the imagined pseudonymous identity:

1. Pre-Contact. Amira wants to support a women’s crisis program run by Ben, but fears doing so will affect her job.
2. Contact. Amira’s friend, Charlene, verifies that she can contact Ben on the pseudonymous RISK network.
3. Triage. Charlene talks with Amira about the RISK network and verifies it meets her needs.
4. Direction. Charlene explains RISK to Amira and sets up a secret contact phrase with her to verify identity.
5. Consent. Amira creates a pseudonymous identity on RISK and signs their code of conduct with her new identifier.
6. Configure. Amira sets up a DID on RISK and confirms it with Charlene using their contact phrase.
7. Services. Amira writes a self-attestation and gets it endorsed by Charlene, who then introduces her to Ben. After discussions, Ben writes a contract for Amira to work on SisterSpaces, and begins paying her in Bitcoin as she completes milestones.
8. Enhancements. Amira adds her pseudonymous identity to a developer directory on RISK.
9. Updates. Amira buys a hardware wallet, replaces her old credentials with new ones generated by the wallet, and publishes them.
10. Problems/Issues. Amira’s credentials are compromised, leading her to create a new DID.
11. Maintenance. Amira downloads a new version of RISK that allows her to publish endorsements.
12. Migration. Amira migrates her identity to CommonX, receiving new countersigned attestations as she does.
13. Recovery. Amira gets new endorsements for her replacement DID.
14. Exit. Amira hands off maintenance on SisterSpaces to another developer and removes her public posting of endorsements.
15. Re-Engagement. Amira re-activates her public posting of endorsements.

W3C Amira (July 2019)

As part of the work on the DID standard, Amira was also released through the W3C as a Draft Community Group Report. It’s substantially identical to the 2018 paper.

XID Amira Demo (May 2026)

Five years later, Blockchain Commons was able to start making Amira a reality with XIDs, a capstone technology that uses Gordian fundamentals such as Gordian Envelope to create a truly self-sovereign identifier.

XIDs take a step beyond W3C DIDs, which ended up compromised in ways that took away from the holder control. Some of these flaws were old enough that they showed up in the Amira white paper, but we didn’t have proper alternatives at the time, so the problems made their way into the standard. It was only when we finished work on the lower levels of the Blockchain Commons stack in 2024 and advanced to XIDs that we were finally able to demonstrate the practicality of our true intentions for self-sovereign identity; we hope to see those intentions in future iterations of the standard.

Our newest version of the Amira story therefore demonstrates not just the ideas of pseudonmyous identity that Christopher first imagined back in 2017, but also how they can apply to true self-sovereignty.

Amira 1.0.0 Requirements

Amira was always intended as a use case that could lay out requirements that would define real-world usage of pseudonymous identity. Here’s a run-down of some of the most important requirements identified in the Amira 1.0.0 white paper, referenced with the step numbers in the engagement model.

• Pseudonymity. Create an identity that’s not tied to a real-world identity, but that nonetheless is stable [#5].
• Signing. Sign with your identity [#5, #7].
• Attestations. Write attestations linked to your identity [#7].
• Endorsements. Sign attestations made by yourself or others [#7].
• Rotation. Rotate your keys without losing your identity [#9].
• Publication. Broadcast attestations and endorsements [#11].
• Exit & Return. Choose to exit or return to your identifier [#15].

There are a few other requirements in Amira related to Portability [#12] and Recovery [#13] which are vitally important parts of a pseudonymous identity ecosystem, but which don’t provide sufficient continuity of identity in Amira 1.0.0, so we instead cover them, along with other advancements, in the next section.

Amira 2.0.0 Requirements

Amira was written very early in our march toward self-sovereign identity: five years before DIDs were locked down as a standard. Even then, DIDs ended up less holder-controlled (and so less self-sovereign) than we hoped.

What follows are some improvements to the original Amira requirements that make them more self-sovereign, more private, and more stable.

• Decentralization. Control your self-sovereign identity [updating #5].
  • The original engagement model focused on an imaginary network called RISK, but in doing so it took some agency from Amira. In the model, her DID is something she creates within RISK. Instead, she should be able to create and control her self-sovereign identity herself, just lending its use to a network like RISK (if something like that is even necessary), while she remains the Principal Authority.
• Bootstrapping. Build your identity through progressive trust [expanding #7].
  • A lot of the interesting work in Amira occurs in a single step of the engagement model, #7 (Services). We really need more details there, as Amira needs to figure out how to bootstrap her empty pseudonymous identifier into a trusted identity. This can be done through offering proof of existing work, receiving multiple endorsements, and slowly creating trust through progressive steps.
• Recovery. Recover your identity without loss after compromise [updating #10].
  • Fundamentally, if the underlying key for an identity is compromised, you’re going to lose the identity, as happens in Amira 1.0.0. She has to create a new identity and get it re-endorsed after an attack. However, there are ways to lessen the likelihood of that happening, through hetergenous division of keys: keeping more-powerful identity management keys offline while using less-powerful operational keys on a day-to-day basis. In this situation, it’s the operational key that’s most likely to be compromised, and it can be replaced without having to reset the identity as happens in the Amira engagement model.
• Portability. Move your identity without loss [updating #12].
  • It’s a bit painful seeing Amira have to recreate her identity when she moves from RISK to CommonX. Though she “cryptographically links” the profiles, she still has to seek out new endorsements, which shouldn’t be required under the “Portability” principle of self-sovereign identity. If Amira is truly in *Control* of her identity (per above), then all she has to do is publish her identity on a new service or link it to a profile on the new service. She doesn’t cryptographically “link” to the old profile, she just cryptographically proves possession by signing with a private key. Afterward, she shouldn’t need new endorsements, because they’re all linked to the portable identity.
• Disclosure [expanding #7]. Selectively determine what information to release.
  • The Amira use case doesn’t focus much on how Amira releases the information in her pseudonymous identity. As a result, it misses out on the ideas of selective disclosure and data minimization: she should be able to release as little about her identity as she wants at any time.

Learning XIDs

XIDs were created to demonstarte a new, truly self-sovereign version of decentralized identifiers that did away with many of the compromises that had crept into DIDs, among them: the theft of agency from the holder; the disambiguation of a DID and its data; the lack of strong support for selective disclosure; and the ability for DIDs to “phone home”. Instead, XIDs are imagined as “autonomous cryptographic objects”, created by holders, modified by holders, and wholly self-contained and self-sufficient.

However, XIDs were also created to fulfill the requirements of both Amira 1.0.0 and the expanded requirements that we’ve laid out to make Amira more self-sovereign and stable. The Learning XIDs project, which is essentially fourth iteration of the Amira Use Case following the issue, advanced reading, and white paper, does so as part of a tutorial on how XIDs work. It does so by offering a real-world demo of Amira’s creation and use of a decentralized identifier that works today, fulfilling almost a decade worth of thought leading up to this point.

Here are some of the main points found in Learning XIDs and how they relate to the Amira requirements to date:

• Decentralization.
  • §1.1. XIDs are built as autonomous cryptographic objects that are self-contained.
• Control.
  • §1.3. Amira creates her XID on her own and so has complete control of it using her “inception key.”
• Pseudonymity.
  • §1.3. A XID is defined by a unique numerical identifier (which is controlled by the inception key) and can also have a nickname. None of these are related to Amira’s real name.
• Signing.
  • §1.3. Amira signs her XID with her inception key.
  • §2.1. Amira makes an attestation key, registers it in her XID, and uses it to sign attestations.
  • §4.1. Amira makes a contract key, registers it in her XID, and uses it to sign contracts.
• Publication.
  • §1.4. Amira publishes her XID to GitHub.
  • §2.2. Amira publishes commits of detached attestations.
  • §4.2. Ben publishes commits of contracts.
• Portability.
  • §1.4. Amira could choose to publish her XID to a different site. Provenance marks would show which publication was the most up-to-date.
• Attestations.
  • §2.1. Amira creates detached attestations.
  • §2.2. Amira elides and commits to detached attestations.
  • §2.3. Amira encrypts detached attestations.
  • §3.1. Amira creates embedded attestations (in her XID).
• Endorsements.
  • §3.3. Amira receives peer endorsements.
• Bootstrapping.
  • §2.2. Amira uses commitments to build trust over time.
  • §3.2. Amira creates verifiable self-attestations.
• Disclosure.
  • §4.3. Amira chooses what to reveal in views of her XID.
  • §4.4. Amira removes overly identifying information.
• Rotation.
  • §5.2. Amira rotates a laptop key.
• Recovery.
  • §5.5. Amira rotates keys and disavows endorsements after a compromise, but keeps her identity.
• Exit & Return.
  • §1.1. Amira could choose to stop or restart use of her XID at any time since it’s an autonomous cryptographic object.

We suggest reading through the entire tutorial and playing through it at bcts.dev, but the above links highlight the requirements derived from the Amira use case.

What’s Next?

Are there requirements we’re still missing for self-sovereign identity? Let us know for possible integration into a future iteration of Amira.