Yuren's Blog - Tech

The Door Opened by OpenClaw

Fri, 06 Feb 2026 00:00:00 GMT

“How is OpenClaw different from other AI bots?”

To answer this question, let me start with the first thing I asked it to help with: finding coffee shops I’d like.

I have very specific preferences when it comes to coffee, which means I’d have to click into every single coffee shop on Google Maps, checking whether their menu lists the coffee’s origin, processing method, and so on before I could filter out the ones I’d actually enjoy. This has always been a real pain, and no other bot supported browsing store photos on Google Maps either.

So after setting up OpenClaw, my first question was about nearby coffee shops. My next question was whether it could look at the shop’s interior photos or Google reviews. That’s when its response got really interesting.

“Currently only returning basic information, no photos or review content.”

“If you want, I can add photo and review functionality to this skill, but it’ll take a bit of time to modify the code. Should I do it?”

My jaw literally dropped when I saw this reply. When I used ChatGPT or Gemini before, the room for customization was limited, and I’d never encountered a bot that could modify its own code to solve my problem. It was like watching it pick up a soldering iron, crack open its own mechanical chest, and rewire itself.

After discussing it with the bot, here’s what it produced.

Coming back to the question of “how OpenClaw differs from other AI bots,” I’d say OpenClaw is like “having a software engineer as a partner, and giving them a computer.” Beyond using the existing tools on the computer to solve problems, the most important thing is that it can create and modify tools. If its current tools can’t view Google Maps images, it simply modifies the code to add that capability.

Most current AI chatbots primarily provide tools, and those tools need to be built by someone else before users can access specific services. OpenClaw, on the other hand, builds its own tools even when nobody has provided them. Even a tool like Claude Code, which can also build tools, is somewhat different — Claude Code’s purpose is to collaboratively develop software with you.

OpenClaw’s purpose in building tools is to solve your problems in a more general sense.

From there, I started tackling some of my other frustrations. For instance, I have a habit of reading news from various countries, but for reading speed, I usually have to find foreign news sites with Chinese versions — like The New York Times, Deutsche Welle, RFI, and so on. But with OpenClaw, I simply asked it to research which media outlets from different countries offer RSS feeds for their original-language news sites, then asked it to pick out stories I’d likely find interesting based on its understanding of me, translate them into Chinese, and produce an audio news briefing every morning. Now I can just listen to the news when I wake up.

I even added a rating system so it can use my feedback to improve its news selection next time 😁

Of course, this brings us back to the elephant in the room. Is OpenClaw really that unsafe?

This is easy enough to imagine. Give a software engineer a computer (even without admin privileges) and consider what they could do and how dangerous that could be. Ask your engineer friends about the silly things that happen in engineering circles — accidentally deleting databases, messing up git, nuking the root directory, and so on. This bot is capable of doing all of those things (even though the model itself has many safety measures in place).

OpenClaw is roughly at that level of risk, plus the additional possibility of being hijacked through Prompt Injection to do other things. In my case, if someone injects malicious content into an RSS feed or comments, I’m not confident it can adequately defend against that kind of attack.

So I’d say the security concerns are quite serious, especially if you don’t provide it with an isolated environment and instead run it on your own computer — that makes the security issues even greater.

But none of this can overshadow the fact that OpenClaw is an experiment brimming with creativity and fun. If you look at how Anthropic or OpenAI conduct experiments, they’re relatively cautious, hoping to accomplish more within a controllable scope. OpenClaw takes the opposite approach: what if I give an AI bot a computer — how fun could that be?

It’s like the dance of Shiva — the beginning of destruction, and also the moment of rebirth.

Making Claude Code Run Its Own Acceptance Tests

Tue, 22 Jul 2025 00:00:00 GMT

Over the past few months, I’ve been developing with Cursor and Claude Code, continuously pushing the boundaries to see what LLM assistance can achieve. Throughout this process, I’ve encountered common issues that many developers face:

Development speed is fast, but quality varies. When it works well, it’s surprisingly good; when it fails, it’s equally surprising
When requirements aren’t clear enough, the LLM fills in details on its own, and these details aren’t necessarily what I want
The LLM writes too fast and generates too much code, causing cognitive overload for developers who can’t help but accept everything when reviewing the content

After various experiments, from a software developer’s perspective, I’ve found a working method that suits collaboration with LLMs: returning to acceptance testing. After this extended period of AI collaboration, I’ve discovered that working with LLMs shares many similarities with working with human engineers: the clearer the requirements and the more discussion, the more likely the output will meet expectations.

This made me recall the Cucumber framework and its Gherkin syntax that I learned early in my career. Cucumber is a Behavior-Driven Development (BDD) tool that uses human-readable and machine-readable documents as acceptance criteria. For example, if we’re developing a Todo application, one specification would be the ability to submit a todo item by pressing Enter. Using Gherkin syntax, we can describe it like this:

  Scenario: Add todo item
    When I enter "Buy milk" in the input field
    And I press the Enter key
    Then I should see "Buy milk" in the list
    And the input field should be cleared

But how does this translate into executable tests? Typically, you need to write glue code to bridge the specification with the test logic:

const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('@playwright/test');

// Assume we have a page object to manipulate the browser
let page;

When('I enter {string} in the input field', async function (text) {
  // Find the input field and enter text
  const inputField = await page.locator('input[type="text"]');
  await inputField.fill(text);
});

When('I press the Enter key', async function () {
  // Press Enter key in the input field
  const inputField = await page.locator('input[type="text"]');
  await inputField.press('Enter');
});

Then('I should see {string} in the list', async function (expectedText) {
  // Verify that the todo item appears in the list
  const todoItems = await page.locator('.todo-item');
  const itemTexts = await todoItems.allTextContents();
  expect(itemTexts).toContain(expectedText);
});

Then('the input field should be cleared', async function () {
  // Verify that the input field is cleared
  const inputField = await page.locator('input[type="text"]');
  const value = await inputField.inputValue();
  expect(value).toBe('');
});

I’ve used Cucumber in several side projects before, but never in production projects. The main reason is that introducing such a mechanism isn’t easy. It’s already rare for teams to accept TDD, let alone bridging specifications to automated testing.

It’s also related to my frequent work in startup teams. Startups typically don’t have the luxury of time to practice the cycle planning from specification to testing.

However, the biggest obstacle was writing glue code. Because it breaks down each sentence into separate actions, a single test scenario gets fragmented into many small pieces. Additionally, when writing Gherkin, you need to be very careful to write the same sentences identically for the same functionality, so they can be merged in the glue code. For example:

When I click the button "ok"
When I go to click the button "ok"

These would be split into two different test logic fragments. Remember, when doing the same thing, the descriptions must be exactly the same.

In short, using Cucumber was a novel and interesting experience, but various obstacles prevented me from using it in production projects.

However, things are different in the age of LLM-assisted software development, because LLMs can directly read specifications written in Gherkin and execute them directly without needing glue code.

Since LLMs can directly read and understand specifications, and through the Model Context Protocol (MCP), Cursor or Claude Code can directly operate browsers and mobile emulators to assist development. This means we can use Gherkin to describe the expected behavior, and the LLM can verify through MCP whether its development results pass acceptance testing.

Gherkin syntax serves as an excellent bridge. It’s a standard syntax that both humans and LLMs can understand, so we can use this specification to confirm implementation details before development, and after development is complete, let the LLM read this specification and use MCP to operate browsers and mobile devices for acceptance testing. For a detailed demonstration, please watch the YouTube video below.

!youtube[WvGY_Jcm_kY]

This not only serves as a communication tool with LLMs, but when it discovers that acceptance conditions aren’t met, it can also observe and modify the implementation.

If you’re interested, you can try it yourself on GitHub: yurenju/llm-bdd-coding-demo

BDD + TDD

BDD can reduce the problem of unexpected results through clearer specifications and acceptance criteria, but it cannot solve the cognitive overload problem for developers. Combining it with incremental TDD can alleviate this issue.

When using BDD, development specifications and acceptance criteria can be well defined, but another situation frequently encountered in LLM development is that the LLM writes too fast. When the amount of content generated at once exceeds my cognitive capacity, I can’t resist the temptation to directly press confirm, but sometimes not looking carefully results in content that’s not what I wanted.

To solve this cognitive load, I’ve recently been testing BDD + TDD. The BDD part uses Gherkin as acceptance criteria as described earlier. But I ask the LLM to break down components, and when developing each component, follow this sequence:

First write the interface, empty classes, or empty functions, and throw an unimplemented error like throw new Error('not implemented yet')
Ask it to write only test descriptions, meaning the automated test’s describe('description') and it('description'), and let me review them without implementing any test logic
At this stage, I’ll know roughly what level of testing it intends to write, and I can communicate directly about the granularity of tests. Usually, I significantly reduce the test items because generally, it writes too detailed
After confirming the test items, ask it to write the test logic
Run the tests. At this point, all newly added tests should fail (red phase)
Ask it to start implementing, and run tests after implementation. Theoretically, all the tests we wrote should pass (green phase)

Under this development flow, the output of each stage stays within my cognitive capacity, and I can properly review its output. Then, after having a clear understanding of “what is correct,” like the BDD flow, it can perform well with clear completion conditions.

If you’re interested in this type of development flow, you can refer to my previous work yurenju/cursor-tdd-rules. If you need to use it with Claude Code, some modifications will be required.

However, please remember that these are still evolving collaborative development methods. Tools and usage techniques are updating very quickly, and they may soon become outdated.

The main purpose of using this development method is to reduce my own cognitive burden, allowing projects to remain under my control while using LLMs as much as possible to accomplish my goals. At the same time, by defining boundaries and goals, I can better communicate with the LLM about what my objectives actually are.

Through this process, I also feel that I become clearer about what I want from the early stages of development. The key to working with LLMs is similar to working with humans: more frequent communication and requirement confirmation.

So perhaps it’s not that different from working with humans after all - it’s about strengthening your communication skills.

Asked AI to Write Code, But It Can't Understand Me?

Wed, 23 Apr 2025 00:00:00 GMT

Recently, one of the sub-projects in our company’s new project experimented with a new development approach: attempting to write most of the code using AI (Cursor), minimizing human intervention as much as possible, hoping to understand the future software development model through small-scale experimentation.

We also hoped that with AI’s assistance, we could significantly shorten the development cycle:

If you’ve tried this on a slightly larger project, you can probably guess what our initial results were like:

Whenever we wanted AI to do a bit more, it often couldn’t follow our expectations. Most work that can be completed in one go is usually simple, clear, and unambiguous tasks—these are usually done well.

Of course, we won’t stop using AI for development because of this. For me personally, over 80-90% of the code is now developed using AI, with extensive use of conversational development. Since AI has deep software development capabilities, I can seriously act as a supervisor, ensuring that its work is completed as expected.

But how do we reach this level? Before actually introducing AI to a project, we need to reflect on how we usually develop software projects within the team.

Traditional Software Development Discussions

In traditional software development processes, teams often conduct strategic discussions from a product perspective, and then the engineering team discusses technical solutions. After meetings and documentation, once consensus is reached, the product is gradually developed through iterative development.

What’s important in the software development process is the team’s consensus and context. When we expect AI to create the ideal system in our minds based on just a few words, relying on the common sense of software engineers it has learned, what’s missing is conveying the most important consensus and context to it.

Because it’s not a mind reader—it won’t know this context from just a few short conversations.

Teams can build consensus and clarify context through meetings and documentation. So how do we provide such information to AI? There are several things we can try.

Use Rules to Define Direction

In Cursor, you can define rules. Although writing quality rules still requires a lot of time to consider and refine, rules can set a general direction for AI and bring its working style closer to the team’s.

For example, should we write tests? To what extent? What kind of git commit messages do we prefer? What are the component writing conventions, naming rules, and technology stack to adopt? Without communicating these, it will often do as it pleases, like a software engineer who just joined the team and hasn’t yet adapted to the development culture.

Break Down Specs and Progress Step by Step

Write a feature specification before implementation (of course, have it write it). Fully read and discuss the spec first, ensure what it wants to do is the same as what you want to do, then ask it to implement.

You don’t have to write all the feature specs yourself. In our case, usually after creating a task in a project management service (like Asana), I tell it what I know this task should do, and ask it to write the spec. Then we discuss and update the spec it produced, and after completing the spec, open a new Chat Context and ask it to implement according to the spec.

If you feel the spec isn’t written well, then revise the rule that generates the spec so that the team can generate better documentation quality when creating specs in the future.

The length of specs will vary depending on team habits, but shorter ones are easier to read and make it easier to develop according to our intentions. This helps us better achieve our goals.

As mentioned earlier, without context or consensus, it’s very difficult to make the product we want. Besides establishing context and consensus through Rules, another way to avoid this problem is to set the goal first, but don’t write all the specs at once—only write the spec for the feature you’re about to complete.

Since we’ll correct the direction it wants to go based on the spec it writes, each time we write and implement a spec, we can correct deviations. This allows the project to move from idea to actual product in the expected direction.

Specs Should Have Acceptance Criteria

The content of specs will vary with each team, but I recommend having Acceptance Criteria. These acceptance criteria explicitly tell AI what counts as done. Such clear conditions can help AI more concretely know to what extent it needs to complete something.

There are many ways to define acceptance criteria. From an engineer’s perspective, automated tests or checks can be substituted, such as unit tests or integration tests. Also, if you’re developing a web application, you can use microsoft/playwright-mcp to have AI open a browser to see what the current result is, and verify by directly operating the webpage.

When it can better judge the current results, it becomes easier to determine completion and take subsequent actions.

If automated verification isn’t possible, you can also ask it to list manual testing methods, verify them yourself, and then tell it the results. Of course, it would be better if it can verify and fix itself.

So Far…

We’re also still trying out this development model, and there are many things that need adjustment in this process. Currently, we feel the rules -> spec -> implementation workflow works reasonably well. When writing specs, there’s an opportunity to discuss with AI and update the plan, so before starting work, we can adjust it to the form we want to complete.

However, we’ve also encountered the problem that Cursor isn’t very good at following rules. Over time, these issues should gradually be fixed, or better practices will accumulate. But until that day comes, we’ll likely need to frequently modify rules. Currently, we feel that rules that are too long tend to be forgotten, and clear and short ones work better. Also, the description of rules is important because it affects when AI wants to apply specific rules.

Also, recently many people have been talking about Vibe Coding, which is developing through conversation in an almost intuitive way, not caring much about implementation details.

But actually, a large part of what’s called “intuition” is that you already have deep background knowledge and experience in a domain, which allows you to seemingly effortlessly complete things using “intuition.” In reality, not everyone can do this, and it also involves expressive ability.

To reach this level, you still need to see whether the person operating has sufficiently deep insights into the product domain and possesses sufficiently refined and clear expressive ability.

I think everyone should approach from their own perspective, seeing what method suits them for collaborating with AI to develop software projects. As a software engineer and a curious person, plus having accumulated certain expressive abilities from years of writing, I adopt methods suitable for me to collaborate with AI—more precisely describing my needs, dividing work, setting acceptance criteria and software development preferences, and even using automated testing methods to enable AI to do better.

I just start from my own perspective, understanding what I like and what I’m good at, then customize the workflow with AI. In this interaction, I discovered that compared to writing code, I prefer building products. Interacting with AI gives me the opportunity to separate these two things more clearly and understand myself better.

And everyone is different. My advice is to look back and examine what you like and what you’re good at, then find a suitable way to collaborate with AI. There’s no shortcut to understanding yourself—everyone just has to spend a lot of time exploring.

Even if your interest is writing code yourself and this process brings you happiness, then perhaps not using AI is best for you. In Naoki Urasawa’s interview, he mentions his view on AI art, saying: “Because I think drawing is very enjoyable, for someone like me who can find joy in work, wouldn’t it be a waste to leave it to AI?”

What the masses are pursuing isn’t necessarily what’s right for you. You still need to look back and understand what kind of person you are, what you’re passionate about, and take the next step from your own perspective.

It’s okay if AI can’t understand what you’re saying. Understanding yourself is more important.

Trading Tokens Directly Within Claude Desktop

Thu, 13 Mar 2025 00:00:00 GMT

Conversational AI tools initially had no access to external information, but gradually began to integrate external tools such as search functionality. However, “search” is a broad and expansive feature. For specific functions like checking the weather or querying stock prices, while web search can accomplish these tasks, it still falls short compared to directly integrating new weather or stock market features through APIs.

Looking at the broader picture, there are countless services on the internet, making it impossible to connect them all through APIs. Moreover, some tools are not in HTTP API format but are only available on local computers. For example, when programming, it would be ideal for an editor to access precise browser screens, structures, and developer debugging information, which cannot be connected through HTTP APIs.

MCP is an open standard designed to help AI understand how to utilize tools. For instance, if you want assistance with task management, you can use an Asana MCP to connect to a task management service via API, enabling it to help plan entire projects, create necessary data, and even manage task dependencies.

The browser-assisted development mentioned earlier can also be achieved through mcp-playwright, which allows browser manipulation, direct console reading for error detection, and automatic correction.

I happened to have a work-related task that required researching related matters, so I experimented with writing a Uniswap MCP using Protocolink and Moralis, allowing direct trading within Claude Desktop.

You can watch the demonstration at this YouTube link.

After completing this, it made me reflect on the development of messaging apps over the past decade. Initially, LINE MINI App and Telegram Mini Apps became popular, but later most functionality was redirected to external web pages, with only small, simple UI elements embedded within messaging conversations. I would take the same approach, as implementing on external sites is simpler—only the most essential user authentication needs to be handled within LINE.

A few months ago, when I saw Vercel’s AI SDK 3.0, it was a moment when I realized that future software user interfaces might be very different. Their announcement included a tool that could generate a weather display interface directly after querying the weather.

I initially thought it was completely dynamic UI generation, but after carefully reading the documentation, I found that you still need to predefine UI components.

Even if they haven’t achieved that yet, it opened up a space for imagination: What if UI components could dynamically assemble appropriate UI interfaces based on the context of received data? What if future user interactions are completely different from today? Will it be voice conversations followed by completely dynamic generation of suitable user interfaces?

What kind of impact will this have on our industry?

I think projecting or imagining the future is an interesting endeavor. The future appears chaotic yet interesting, but I hope the interesting aspects outweigh the chaos.

Postscript

This uniswap-mcp was written solely for research purposes, and 99% of the code was written by Cursor. We all know that we shouldn’t pass private keys into programs through environment variables, but for those who are still curious, here’s the source code. Please only use it for testing and research purposes, and don’t put too much money into it.

https://github.com/yurenju/uniswap-mcp

Before the Perplexity Comet Browser Release

Tue, 25 Feb 2025 00:00:00 GMT

Perplexity is about to launch a new browser called Comet. While we don’t know what it will actually look like, it’s interesting to imagine. Suppose this browser enables human-AI collaboration for web browsing. For instance, when you need to find information, it could search across various search engines, read through results, and organize the data for you. If you need to update Google Docs or Notion, it could directly open the web page and modify the document. If that’s the case, the impact could be quite significant.

I once heard a reason for building humanoid robots: the entire world is designed with humans as the reference point—stairs, door handles, washing machines, TV remotes, and so on. If a new creation takes a different form, it won’t be able to interact with the infrastructure that has been accumulated over hundreds or thousands of years.

I think this browser feels somewhat similar. Traditionally, if web services wanted to allow machine access, they had to develop new APIs. They even implemented human verification systems like reCAPTCHA to counter various automated crawlers.

But if the next generation of browsers enables human-AI collaboration for web browsing, suddenly much of the existing infrastructure becomes accessible. Automation barriers disappear—when human intervention is needed, the AI requests your assistance, then continues working once you’ve helped. Imagining this future reveals a very different world. Many cross-service integrations that previously seemed complex suddenly become simple—though we’ll also need to solve many new problems 🤣

The future remains chaotic yet fascinating. I hope the fascinating parts outweigh the chaos.

ChatGPT as a Reflection and Extension of Curiosity

Mon, 29 Apr 2024 00:00:00 GMT

The root of originality is curiosity. Just as a good question is itself an essential component of the answer, curiosity is also a form of original power. — Paul Graham¹

Recently, I’ve been using ChatGPT extensively in my daily life—proofreading my articles, having it offer counterarguments when I take notes, and using it to further understand various questions that puzzle me. Of course, I also question its answers. The more I use it, the more I realize it’s a kind of projection. It’s like a knowledgeable dialogue machine that occasionally gets details wrong. But when you don’t speak to it, it won’t proactively solve your questions.

Only when you ask does this dialogue machine methodically organize its response.

In the interview “Naoki Urasawa × Mai Yoneyama Special Drawing Conversation,” Naoki Urasawa shared his views on AI drawing tools. He mentioned that when creating an incredibly magnificent sunset scene in animation, hand-drawing would take an enormous amount of time, and AI drawing tools could help in such cases. However, before that, you must already have your own imagination of that magnificent scene in your mind to subsequently use AI drawing as an aid.

“If there’s no image in your head, it won’t work either,” Naoki Urasawa said.

Coming back to my own use of ChatGPT, I also assign it roles. For example, the role I use for proofreading notes is “You are a strict editor who will offer counterarguments or criticisms to my notes and suggest how to revise the content.” But when you set a role for it, you’re imposing your needed functions and perspectives onto it. So you’re conversing with an extended version of yourself—one that simply has a larger knowledge base. But you set its perspective, role, and tasks, and these settings are what truly provide originality.

As someone full of curiosity, I continuously ask it various questions. When facing difficulties, I dialogue with this extended role I’ve established, allowing myself to better understand my own views through iterative cycles. On the surface, I use ChatGPT to seek answers, but the underlying source of power is curiosity and questioning.

To me, ChatGPT is a projection and extension of curiosity. Ultimately, what matters is the person asking the questions.

Quoted from Chou Chin-Hua’s translation of “How to Do Great Work” Facebook post, with minor textual adjustments by me ↩

tw-did Additional Information

Thu, 08 Feb 2024 00:00:00 GMT

In the previous article, I mentioned that the collaboration structure of this project is somewhat complex. Every time someone asks me about it, I have to spend a lot of time explaining, so I’m writing it down here so that in the future I can just direct people to read this short article.

The origin of this project was actually a contract bid issued by the Ministry of Digital Affairs (MODA), which was won by the Frontier Foundation. Most of the members from the Frontier Foundation participating in this contract came from the DA0 community. This contract actually included many projects, one of which was the verification project connecting W3C DIDs (Decentralized Identifiers) and the Mobile Citizen Digital Certificate - the open-source project I’m involved in. However, I did not participate in the contract bid - this is where it gets complicated 😎

As mentioned earlier, I was invited by the Ethereum Foundation and accepted their Grant Program. This was because some enthusiastic individuals within the foundation believed that such integration opportunities between decentralized identity and government agencies are very rare, and they hoped to achieve this through open-source methods that serve the public interest. After discussions, the foundation decided to provide technical support for this project. The method of this technical support was to find a suitable person through the Grant Program to be responsible for planning and implementing this project, and that’s how I became involved.

So under this technical support framework, I accepted the Ethereum Foundation’s Grant Program to provide technical support for this project, including design, planning, and development, ultimately delivering the source code to the Frontier Foundation to complete the contract. I did not develop this project alone - several other developers also participated in frontend development, deployment, and other work. For details, please see the contributors section of the README.

From my perspective, I participated in an open-source project and received a grant from the Ethereum Foundation. I have no contractual relationship with the Frontier Foundation and did not participate in the contract bid. I was merely a participant in an Ethereum Foundation grant program, providing technical support and developing an open-source project.

This grant program ended at the end of December. After it ended, in mid-January, Doni from the Ministry of Digital Affairs asked if I was interested in providing a two-week technical feasibility assessment for the upcoming Taiwan Digital Identity Wallet draft. At that point, I participated as a consultant in the MODA draft technical assessment, and this consulting work also ended at the end of January.

So if you heard that Noah from DA0 was responsible for this project, that’s correct. Noah was primarily responsible for most of the coordination work, publicity, and exchange activities in this project. If you also heard that the Ethereum Foundation sponsored this development work, that’s also correct, because I participated in the planning and development of this project as technical support.

I hope this explanation helps everyone understand this complex collaboration relationship 🤣

Proof of Concept: Privacy-First Digital Identity for Taiwan Residents

Sun, 04 Feb 2024 00:00:00 GMT

In the W3C DIDs series of articles, starting with “Digital Identity Issues from Facebook Account Bans and the DID Solution,” I pointed out that current digital identities are controlled by large corporations like Google or Facebook, who can delete your digital identity without your permission or consent. The second article, “W3C DIDs: A Digital Identity Standard That Dismantles Power Structures,” explored in depth how the DIDs and VC standards can solve issues of digital identity autonomy and privacy. The third article, “Semaphore: A Privacy-Enhanced Identity Solution,” provided a deeper understanding of how cutting-edge technologies like Semaphore offer anonymous yet verifiable development kits.

This article will integrate the above information to explain the project I developed in the second half of last year.

Thanks to Phini from the Ethereum Foundation for the invitation. In the second half of 2023, I received funding from the Foundation’s Grant Program to participate in a multi-party collaborative project and develop an experimental project called tw-did, which integrates Taiwan’s Mobile Natural Person Certificate, W3C DIDs/VC, and the Semaphore zero-knowledge proof framework to improve the autonomy and privacy issues present in centralized digital identity solutions.

This project has now been transferred to the Ministry of Digital Affairs (MODA). The collaboration structure of this project is somewhat complex, and I will supplement the details in a subsequent short article.

First, let me introduce the Mobile Natural Person Certificate, which hasn’t been mentioned before.

Mobile Natural Person Certificate

When filing taxes in Taiwan, the most convenient method is to use online tax filing directly. One of the identity verification methods is the Natural Person Certificate. The Natural Person Certificate is a chip card with a private key stored in a secure chip. It can be used for signing and verification through a card reader, serving as a digital certificate for Taiwan residents.

Residents who don’t yet have a card need to apply in person at a household registration office. After the office issues the physical card, this chip card can be used at other government agencies, such as for online tax filing services.

While the Natural Person Certificate is secure, the disadvantage of the physical card is that it requires a chip card reader to use. Even though this chip card also supports NFC contactless reading, in most cases, an insertion-type card reader is needed. In addition to requiring an additional card reader for computer use, it’s also difficult to use on smartphones.

The Mobile Natural Person Certificate was developed to solve this inconvenience problem. The Mobile Natural Person Certificate is an extended solution to the Natural Person Certificate. After downloading the Mobile Natural Person Certificate app, Android devices can use NFC to read information from the Natural Person Certificate card and bind this physical card to the smartphone. In the future, users can directly use the smartphone app as a Natural Person Certificate card.

During verification, it is protected by biometric authentication such as fingerprint or face recognition. After unlocking, the private key in the secure hardware is used for signing and identity verification.

The Mobile Natural Person Certificate solves the inconvenience of the physical chip card, allowing identity verification as a Taiwan resident through a smartphone. If the goal is convenience, it indeed solves a major problem. Additionally, it uses biometric verification devices, requires no password memorization, and stores the private key in the phone’s secure area, providing adequate security. Combined with fingerprint or facial recognition data that never leaves the phone, it’s an overall well-rounded solution.

Of course, the Mobile Natural Person Certificate is still a centralized identity verification solution. We can examine this solution through the two main issues of current identity verification solutions mentioned in previous articles: autonomy and privacy.

Before that, it should be explained that when a user uses the Mobile Natural Person Certificate at an organization to verify their Taiwan resident identity, the Ministry of the Interior’s API will be used for the verification process.

Autonomy

Although the Mobile Natural Person Certificate uses asymmetric cryptography for identity verification, the service issuer also participates in the verification process. This means that if the government wants to block a specific Taiwan resident, it can refuse to provide verification services through a blacklist when the verification process calls the API.

To give an extreme example, suppose a foreign credit card company supports Taiwan residents applying for credit cards and integrates the Mobile Natural Person Certificate as a verification method. If Taiwan becomes an authoritarian state in the future and revokes all previously issued Taiwan resident certificates, even if this foreign credit card company is willing to accept applications from former Taiwan residents, the government can still easily use a blacklist to prevent anyone the government dislikes from passing verification.

Privacy

This has the same root as the autonomy issue. Because the issuer participates in the verification process, it means the government knows every time a user performs verification. This wasn’t a big problem before, because the Mobile Natural Person Certificate was only open to government agencies for verification procedures, and the public could accept the government tracking login behavior to other government agencies.

However, after the second half of 2023, according to an announcement, the scope of application for the Mobile Natural Person Certificate has been expanded to non-governmental organizations. At this point, privacy issues need more careful consideration. Imagine if a service like online banking requires using the Mobile Natural Person Certificate service to verify identity when logging in - the government can record every user’s digital footprint during login behavior, thus extending digital footprint collection to private enterprises.

The above argument may seem to portray the government negatively, but that’s not actually the case. In one episode of the Blocktrend podcast featuring an interview between Hsu Ming-En and DouNi, it was mentioned that if new technologies are not properly guided, technology may not necessarily move toward universally accepted values, because governments possess great power. If technology’s direction is not appropriately guided, it can easily go astray.

If we have the opportunity to establish mechanisms and frameworks, we should design technology frameworks to move in a good direction as early as possible. Since we can design with autonomy and privacy first, we should move in that direction.

TW-DID Experimental Project

After explaining the Mobile Natural Person Certificate, I can finally introduce this project. tw-did is an experimental project that integrates the Mobile Natural Person Certificate, W3C DIDs/VC standards, and the Semaphore zero-knowledge proof framework, using the project’s output to glimpse the future and examine current shortcomings.

Regarding the autonomy and privacy issues that still exist in the aforementioned Mobile Natural Person Certificate, tw-did can solve these two problems by integrating the Mobile Natural Person Certificate to interface with and convert Taiwan resident qualification certificates into W3C VC format certificates. Furthermore, through Semaphore, privacy is pushed even further, making it completely unnecessary to disclose digital identity during the verification process.

Next, we will explain in two parts: W3C DIDs/VC Integration and Semaphore Integration.

W3C DIDs/VC Integration

tw-did provides a web service. This service first uses the Mobile Natural Person Certificate to log in and verify the user’s Taiwan resident identity, then verifies the user’s DID identity. After both pieces of information are successfully verified, a Verifiable Credential (VC) format certificate is issued to the user, allowing the user to use this certificate on other websites where they need to prove they are a Taiwan resident.

As introduced in “W3C DIDs: A Digital Identity Standard That Dismantles Power Structures,” both the issuer and the holder can adopt different DID Methods. However, to keep the experimental environment simple, the tw-did project uniformly adopts the Ethereum blockchain’s DID Method did:ethr and Ethereum accounts as DID identifiers. When verifying DID identity, the common Ethereum verification method Sign-In with Ethereum (SIWE) is used to verify through MetaMask message signing that the user actually owns that account, thus proving they own the private key of that DID.

After confirming through the Mobile Natural Person service that the holder is a Taiwan resident and owns that DID identifier, tw-did as the issuer can issue a VC format certificate to the user. When issuing, tw-did will use the issuer DID to sign the certificate and provide it to the holder for download and storage. The overall issuance flow is as follows:

Step 2 of the issuance flow still calls the Ministry of the Interior API and provides the user’s national ID number, but this is the only API call that discloses the holder’s identity. In the verification flow, which holder is performing verification is not disclosed.

Assuming a bank now supports the W3C DIDs/VC standard verification flow, users can present this certificate to prove they are indeed Taiwan citizens. The flow diagram is as follows:

When a verification organization like a bank requests a user to provide a specific VC format certificate, it will also issue a cryptographic challenge. When the user receives this request, they will use the private key corresponding to their DID to respond to the cryptographic challenge, and package the original VC certificate, challenge, and challenge response (i.e., signature) together into a Verifiable Presentation (VP) document to reply to the bank.

The bank will then check whether the various contents of the VP format certificate are correct, and will additionally request the revocation list from the issuer. Because it does not query via API whether a specific certificate has been revoked, but instead obtains the entire revocation list at once, allowing the verifier to find the revocation information for that certificate in the list themselves. This way, the issuer can remain unaware of which holder is currently performing verification, but can still determine whether it has been revoked.

Finally, the Ministry of the Interior’s API will not be called. This also means the Ministry of the Interior does not participate in the verification flow.

When verification succeeds and the bank confirms the user is a Taiwan resident, they can begin using the bank’s services. Similarly, let’s verify the digital identity autonomy and privacy under this architecture.

Autonomy

When the bank verifies the user’s identity through a VP format certificate, the original VC certificate in the VP document already contains the issuer’s signature. The bank can directly use public information to verify the issuer’s signature without the issuer’s participation, so it also cannot block the verification flow.

Although the issuer can mark a certificate as revoked, even so, the issuer’s signature on this certificate is still valid, because the signature result is non-repudiable. This means that even if the certificate is revoked, the verifier can still decide whether to accept this certificate in such a situation.

As shown in the above diagram, the various states of VC are verified separately. Verifying the expiration date does not affect verifying the issuer’s signature, and revoking the certificate does not affect verifying the issuer’s signature.

To use the previous extreme example, suppose Taiwan becomes an authoritarian state in the future and revokes all former resident identities. When a verifier receives a user’s revoked certificate, they can still consider whether to accept such a certificate as proof, rather than placing all power in the issuer’s hands.

Compared to cases where the issuer participates in the entire verification flow, the W3C DIDs/VC specification flow still possesses higher digital identity autonomy.

Privacy

This is also related to whether the issuer participates in the verification flow. When users present VC format certificates at the bank, the issuer cannot know about or track it. This ensures privacy protection during the verification flow.

Under the conventional W3C DIDs/VC architecture, autonomy and privacy are already protected. Next, let’s see what benefits Semaphore integration can bring us.

Semaphore Integration

Compared to the general W3C DIDs standard verification procedure, Semaphore integration can achieve the purpose of verifying qualifications even without disclosing DID identification.

In the case of the tw-did experimental project, a conventional VC certificate will record the holder’s DID identification string (including the Ethereum account address), from which public key information can be parsed to verify whether this VC certificate is correct.

But this also means the user’s Ethereum account address will be disclosed.

With Semaphore integration, there is no need to provide DID identification at all to prove one has Taiwan resident qualifications. When applied to the Mobile Natural Person Certificate example, it means users do not need to disclose their Ethereum address to verify their Taiwan resident identity.

However, as mentioned in the previous article, Semaphore is a development kit, not a standard like W3C DIDs. Therefore, the work we carried out in the tw-did experimental project was to attempt to integrate Semaphore into the W3C DIDs/VC standard. A better approach would be to establish a new DID Method like did:semaphore and specify various interaction methods. However, considering time and implementation difficulty, we decided to first use did:web to wrap the semaphore verification method as an experimental evaluation solution.

In the Semaphore integration issuance flow, after the user confirms their Taiwan resident identity through the Mobile Natural Person Certificate service, the user will generate a Semaphore Identity on the client side. This identity consists of public and secret parts:

Public: Commitment, functions similar to the public key part of asymmetric cryptography
Secret: Trapdoor and nullifier, functions similar to the private key part of asymmetric cryptography

The public commitment will be provided to tw-did, where it will be added to a Semaphore Group as proof of Taiwan resident qualification. The list of all commitments registered in tw-did can be obtained by anyone and is public data.

In the Semaphore verification process, a verifier like a bank will issue a cryptographic challenge, and only Semaphore Identities with Taiwan resident qualifications can generate the correct challenge response.

This is divided into two steps: generating proof and verification. Generating proof is executed on the holder’s client side, while verification is performed by the verifier’s service.

When the holder generates proof, they need the cryptographic challenge, their own Semaphore Identity, and a list of all qualified commitments, of which the commitment list needs to be requested from tw-did. With these three input parameters, the corresponding proof can be generated.

When the verifier verifies, they need two input parameters. The first is the proof submitted by the holder, and the second is also the commitments list. With these two parameters, the proof can be verified.

We can compare the proof verification flow of general asymmetric cryptography with Semaphore zero-knowledge proof.

General asymmetric cryptography uses a private key to sign, and the verifier needs to obtain the corresponding public key for verification. Since the public key represents the DID key pair, DID identity information will still be exposed to some degree. In the Semaphore verification flow, there is no need to provide a specific commitment corresponding to a specific identity, but only a list of all qualified commitments. This way, verification can be performed without disclosing identity.

Compared to conventional W3C DIDs/VC, this further strengthens privacy. During verification, one can only know that the other party meets the qualifications, but cannot know who specifically. Conventional VC certificates must always include public key information, so if you don’t want the verifier to know your Ethereum account, you can use this more advanced Semaphore zero-knowledge proof to achieve enhanced privacy protection.

However, it should be noted that the Semaphore integration is highly experimental, so some shortcuts were taken in development, making the current prototype’s digital identity autonomy not as good as conventional VC. But this is a clearly understood problem with known improvement methods, which will be discussed in the later Review and Discussion section.

Demo Video

This time I tried attaching a demonstration video with each milestone release. Looking back now, it’s quite interesting - I didn’t expect the project to change so much from August to October 😎

You can see the introduction and videos for each milestone here: https://github.com/moda-gov-tw/tw-did/releases

Here I’ll embed the Milestone 6 video:

{{< rawhtml >}} Your browser does not support the video tag. {{< /rawhtml >}}

There are two tabs here: the Web tab is the issuer, and the SampleVerifier tab is the verifier.

In the Web tab, the user’s identity is first verified through the Mobile Natural Person Certificate service. In this service integration, a notification is sent through the Mobile Natural Person Certificate app that the user has already installed, or the user can also choose to scan a QR code to perform the login procedure.

After logging in, Sign-In With Ethereum is used to verify through signature whether the user actually owns an Ethereum account. The final step is to generate a Semaphore identity and register its commitment in the tw-did database.

This completes the preliminary work for the issuance procedure.

Finally, users can download two different types of VC certificates. The first is a VC certificate issued to the holder’s Ethereum account address, and the other is a VC certificate issued to the holder’s Semaphore Identity. The file names are vc-ethereum.json and vc-semaphore.json, respectively.

Next is the SampleVerifier sample page for the verification procedure. This page is for development and debugging purposes, so it’s relatively bare-bones. The verification website can verify the two types of certificates issued above, for Ethereum and Semaphore respectively.

In the Ethereum certificate verification part, users are first asked to select a VC certificate issued to an Ethereum address as a DID. Users can directly use the file selection function to select vc-ethereum.json for verification, or press “Select on DID” to select the required Ethereum certificate on the issuance website. After selection, parsing work begins. When verify is pressed, it signs through MetaMask and generates a VP document to confirm the holder’s qualifications.

In the Semaphore certificate verification part, pressing Semaphore Challenge and verify will have the verification website generate a cryptographic challenge in real-time, and the holder will generate proof on the client side, package it into a VC format certificate, and return it to the verification website for the verification procedure.

Review and Discussion

Looking at the GitHub commit history, I submitted the first commit in early August, and the project was completed at the end of October. Before learning about this project, my understanding of DID was very superficial, so both research and development were completed under very urgent conditions.

Therefore, there are inevitably shortcomings in both research and implementation. Much was learned and done simultaneously, and some knowledge was only understood after the project ended regarding how to do better. I’ll write it here for future developers’ reference.

This project has several most important goals:

Does this prototype provide imagination of future scenarios, helping to understand what we can do in future production environments?
When these mechanisms are integrated together, are the autonomy and privacy of digital identity protected?
Were problems encountered during development that can serve as reference for production environments?

Does the Prototype Provide Imagination of Future Scenarios

What was integrated in this experiment was the Mobile Natural Person Certificate, and the issued certificates can be used by another verification service to confirm whether this user is a Taiwan resident.

We can imagine that in the future, this Taiwan resident certificate could be used by many services as audit data for identity verification, such as opening bank accounts, or e-commerce platforms auditing whether sellers are Taiwan residents.

However, since it’s a prototype, at this stage, no verification units would actually trust this certificate. In the future, production environment certificates would still need to be issued by more formal organizations, such as the Ministry of the Interior or the Ministry of Digital Affairs, to increase verification organizations’ level of trust in this certificate. There may even need to be legal basis to use it in more formal settings.

Regarding certificate storage, when imagining a future where multiple different certificates need to be stored, there will need to be a VC Wallet app to accomplish this purpose.

Digital Identity Autonomy and Privacy

As mentioned earlier, centralized digital identity lacks autonomy and privacy. Even the Mobile Natural Person Certificate service has the same problems. When a verification organization (especially non-governmental organizations) adopts the Mobile Natural Person Certificate as a verification method, there are different concerns regarding both autonomy and privacy. For example, as in the previous example, when opening a bank account, there are autonomy concerns that the government can directly block the verification procedure to prevent specific users from opening accounts, while simultaneously having privacy concerns that the government will know which bank users go to open accounts.

After interfacing with the Mobile Natural Person Certificate and issuing VC certificates, the characteristic that the issuer doesn’t need to participate during verification ensures the autonomy and privacy of digital identity.

In terms of autonomy, because the issuer does not participate in the verification procedure (except for the revocation list), they cannot erase a person’s digital identity by blocking the verification procedure. Even if the revocation function is used to mark a certificate as revoked, the issuer cannot deny having once signed and endorsed this digital certificate.

In terms of privacy, similarly because the issuer does not participate in the verification procedure, the issuer cannot know which user is performing the verification procedure.

Of course, during research and development, we encountered quite a few problems. Below I’ll share some related experiences.

Development Kits

First, in this project, I used Veramo, a TypeScript development kit. From the experience of developing this project, Veramo is quite flexible and not difficult to use. In this development, I implemented a new signature verification method Semaphore2023. Although the process was somewhat convoluted, it was ultimately completed.

However, since these are still relatively new development kits, W3C DIDs/VC-related developers don’t have as much attention as popular development frameworks like React or Vue, so the documentation isn’t as comprehensive. Therefore, when developing non-built-in features, it’s still necessary to read the source code to proceed.

Because the project timeline was relatively tight, I didn’t do very in-depth research when initially selecting kits. Later, I saw several different development kits, such as SpruceID’s Rust-implemented SpruceKit and another TypeScript library implemented by Ceramic, ceramicnetwork/js-did. These all look like choices worth trying, especially js-did, which appears to have functionality for integrating WebAuthn into did:key, worthy of deeper research.

Lack of Wallet

At the time of implementation, I didn’t find a suitable VC Wallet to store certificates issued by the issuer. Originally, I had planned to quickly implement a Wallet, but due to time constraints, it wasn’t completed. You can find the wallet app on GitHub, which just had the frontend interface completed but logic not yet implemented. In the end, we put the credential selection functionality for the verification procedure on the issuer’s website. This doesn’t actually conform to the principle that the issuer doesn’t participate in the verification procedure, but considering there was no suitable VC Wallet found at the time of implementation, this was an acceptable experimental approach.

Although nothing suitable was found initially, after the project ended, I discovered that Microsoft Authenticator, which Microsoft usually uses for two-factor authentication, supports storing VCs. See this article for details.

If we had discovered earlier that Microsoft Authenticator has this functionality, we would have referred to their integration method to allow certificates to be stored in the MS Authenticator app.

Lack of Exchange Protocol

When initially reading W3C documents, there were no specifications on how to exchange credentials. Therefore, neither issuer issuing certificates to holders nor holders presenting VPs to verifiers were defined. Since there was no definition, the most intuitive method was to generate a certificate file for users to download, and verifiers would similarly submit a VC through the native file selection function of the webpage, letting users sign it and then convert it to a VP.

While researching Microsoft Authenticator, we also discovered that the exchange protocol used by the app is the openid-vc and openid-vp standards established by another organization, OpenID.

Although the initial implementation still achieved the experimental purpose, if actually implementing a production product, one could consider adopting the standard established by OpenID, and then use Microsoft’s Microsoft Authenticator as a VC Wallet to store certificates.

Semaphore integration indeed greatly improved privacy, but because it’s experimental, there are indeed many implementation details that need refinement.

For example, we used the did:web DID Method and wrapped a new verification type Semaphore2023 inside it. Here, we actually extended a new verification type through Veramo, while simultaneously establishing an anonymous DID identity did:web:tw-did.github.io:hidden on GitHub Pages. A better approach here might be to add a new DID method did:semaphore and natively support anonymous identity.

At the same time, there’s also the problem that other kits won’t support Semaphore2023, this special verification type. For example, the previously mentioned MS Authenticator cannot use this verification type we defined ourselves. If the entire specification can be thought through clearly, registered in the DID Specification Registries, and promoted, it would be more appropriate.

Additionally, the implementation of the verification procedure violates the principle of autonomy by requesting public information commitments list from the issuer. Because it’s requesting public information, it doesn’t cause privacy problems. However, the issuer can still choose not to provide commitments to block everyone from verifying their identity.

This problem can be solved using the on-chain version of Semaphore. When using the on-chain version, many things can be achieved by directly interacting with smart contracts, and there’s no need to request the commitments list from the issuer, thus solving the autonomy problem. Of course, if blockchain needs to be used in the issuance mechanism, other problems unique to blockchain will arise, such as transaction fee expenditure issues.

In short, there are still many places in the implementation details of integrating Semaphore into W3C DIDs that need refinement, and may require more iterations and discussions to find a more mature approach.

Conclusion

Overall, I think this experimental project is excellent. It glimpses the future through a key scenario - verifying Taiwan resident identity - giving people concerned about this issue (that is, you who have read this article to this point) a more concrete outline of digital identity with greater autonomy and privacy. At the same time, the implementation part went far enough to understand obstacles that may be encountered in future production environments.

On the other hand, it also explored more deeply whether the necessary technology is currently available if one wants to achieve the level of anonymous but verifiable qualifications through zero-knowledge proof. It can also stimulate everyone’s imagination to think about how important such highly privacy-preserving technology is to us, and whether there are other negative impacts.

Of course, for me, it was also a great exploration. I actually didn’t understand DID that well before, and only with this project did I truly gain a deep understanding of these matters.

My plan for this year is to independently develop small services or apps, which won’t be related to DID or blockchain. However, I still hope that previous development experience can play some role. So if you want to find someone to discuss or exchange ideas about the DID topic, you can still contact me. I’ll allocate some time to this topic. While I won’t have time to develop projects, exchanging existing experience and perspectives is no problem. Welcome to email me!

Semaphore: A Privacy-Enhanced Identity Solution

Fri, 02 Feb 2024 00:00:00 GMT

When attending a concert, you simply need to present a paper ticket to enter the venue. Occasionally, for events requiring real-name registration, you may need to show identification. With paper tickets, staff can verify your identity without your movements being tracked.

However, in digital life, it’s a different story.

In digital life, when you need to prove your identity for verification, your authentication action is almost invariably recorded. Taking the same example, if you present an electronic ticket to enter a concert venue, there’s a high probability that your entry information will be logged.

Often, these records serve meaningful purposes that users can understand and accept. For instance, entry and exit records are indeed necessary to prevent a single ticket from being used multiple times. However, the easy-to-track nature of digital footprints has gone too far, resulting in many troublesome phenomena. The most common is that after browsing websites, Facebook and Google become flooded with related advertisements. It’s as if someone is following you down the street with a notebook, recording your every move—the magazines you flipped through at the convenience store, the drinks you like. Then repeatedly posting advertisements they think you’ll buy on the routes you take.

In the past, implementations of identity login and verification never considered making this difficult to track, because effectiveness, ease of evaluation, and trackability are the strengths of digital records. But when people began to recognize the importance of digital footprints to privacy, they looked back to discover that the digital technologies we commonly use today don’t have that difficult-to-track characteristic.

And Semaphore is a mechanism born from this need.

Semaphore is an identity verification mechanism implemented through Zero Knowledge Proof (ZKP) in cryptography. Traditional digital identity verification requires explicit input of your identification information. For example, when logging into a Google account, you need to enter your account name and password, and the account name itself is your identification information.

In Semaphore’s usage scenarios, you don’t need to input information like account name. Instead, it only verifies your qualification, not the user’s specific corresponding digital identity. Let’s use the same ticketing platform scenario, but with three different technical implementations to explain this concept.

Example Scenario

Paper Tickets

When using paper tickets, Alice obtains a paper ticket after purchasing it from the ticketing website. At the event venue, she presents the ticket to staff member Bob, who checks whether the ticket is valid. If correct, Bob allows Alice to attend the event.

Paper tickets have some inherent drawbacks. For instance, they require additional anti-counterfeiting measures to prevent others from forging tickets. Additionally, such scenarios can typically use electronic checking methods, such as QR code scanning verification to prevent a single ticket from being used twice. However, when adopting electronic checking mechanisms, they generally also record the user’s footprints.

Digital Tickets

When using digital tickets, Alice must first log in to the ticketing platform with an account and purchase a ticket. After successful purchase, Alice is added to the audience list. Upon arrival at the event venue, she presents a QR code on her phone screen for entry. Bob verifies the ticket correctness through the QR code and then allows Alice to enter, with the system marking Alice’s ticket as having entered.

The advantage of digital tickets is more convenient verification. Although there are technical issues to overcome, during entry, the backend database can quickly confirm whether the audience member is an attendee, and it can detect if multiple people use the same ticket for entry.

The disadvantage is the digital footprint problem. It’s fine when used reasonably, but the current situation is far too abusive, especially with advertising.

Semaphore Identity Authentication

Semaphore is a development kit to help developers create an anonymous yet verifiable login mechanism. First, you still need to log in to the ticketing platform and purchase a ticket, but here the ticketing platform has users register their Semaphore Identity. If a name is entered, the ticketing platform will still know the user’s name and corresponding ID number. For example, after Alice registers, her ID number 0x1234 will still correspond to her name Alice.

On the event day when Alice enters, she similarly presents a QR code for entry. At this time, staff member Bob also scans the ticket, but this QR code doesn’t contain the user’s explicit identity verification information (such as account name or email). Instead, it allows the verifier to present a cryptographic challenge, and the user replies with a challenge solution without revealing their identity. This solution can only be answered by one of the attendees, thus proving they are an attendee without revealing who they actually are.

This means that during ticket verification, the attendance list only shows information like user1, user2, user3, user4, which represent four attendees respectively, but the platform cannot know the correspondence between userN and the actual attendee’s ID number.

When Alice successfully verifies, the platform only knows that among these four attendees eligible to enter, one person has entered and three people have not yet entered. As for who exactly entered, the verifier has no way of knowing, and this ticket will be marked as used, preventing others from entering with the same ticket.

All these functions are implemented based on zero-knowledge proof technology in cryptography, using cryptography to guarantee that the user’s qualifications can be verified without revealing their exact identity.

This offers even stronger privacy protection compared to the W3C DIDs/VC mechanism. During VC verification, the user’s public key is unavoidably revealed, whereas Semaphore doesn’t reveal any user identification information.

Reasons and Scenarios for Using Semaphore

As mentioned earlier, the digital identity verification technologies commonly used today unavoidably disclose user identity. When these records are linked together, the resulting digital footprints pose a major threat to personal privacy. Shadow-like, inescapable advertisements aren’t annoying enough—even when users switch between two completely different account platforms, such as social networking sites and blog sites with no common account, advertisements can still follow everywhere. These things are extremely annoying.

Another more worrying concern is website intrusion incidents. When hackers break into a website and users have a lot of data and footprints on that website, these things become materials for fraud or the next intrusion, spread across the boundless internet. For instance, I myself am relatively careful and cautious when using the internet, but Google One’s dark web monitoring function still shows that my data has been leaked in large quantities, and most of these leaks come from websites being compromised and sold on the dark web.

When more websites use technologies like Semaphore, the data stored on websites is minimized. In situations where even the website itself cannot identify users’ digital footprints, even if data is stolen, it becomes useless.

Of course, such anonymous yet verifiable technology cannot be applied to all scenarios. Besides ticketing, here are some examples where Semaphore can be used for authentication. However, Semaphore can only solve privacy issues, and typically the examples involve many complex situations that need handling, but we’ll focus only on privacy issues here.

Online Alcohol Purchase

Generally, when buying alcohol online, you don’t want your personal privacy identity information to be known, but age information needs to be verified. If after verifying identity with a specific service, people with adult qualifications can all obtain a Semaphore-compliant qualification certificate, then in the future when buying alcohol online, they just need to present this certificate without being tracked through specific identity identification to their digital footprints.

When verifying age here, since you can only know whether qualifications are met but not the exact identity, retailers also won’t store any privacy data. Of course, the service providing identity verification still has privacy data, but the attack surface is much smaller.

Whistleblower Platforms

Whether for sexual harassment or various whistleblower platforms, there’s usually a need to verify that the user has the qualification to report specific incidents while maintaining anonymity. Imagine if when a company registers on a platform, it needs to register employees through semaphore identity into the system. When reporting is needed, Semaphore identity verification can serve as an identity verification method that can verify while maintaining anonymity.

For example, on sexual harassment prevention platforms during reporting, it can be confirmed that the reporter actually worked at that company while maintaining anonymity.

Medication or Poverty Assistance

Some medication assistance and poverty assistance can also be solved using similar methods when there are long-term stigmatization issues in society. For instance, assistance qualification lists can be established through Semaphore, but when receiving assistance, there’s no need to actually present identity, yet it can confirm they have the qualification to receive assistance.

Opinion Surveys

Opinion surveys (or electronic voting) are also scenarios that frequently need to verify identity while maintaining anonymity when expressing opinions. However, opinion surveys still have many problems to solve, with privacy being just one major issue among many more that need resolution. On this topic, I recommend watching Tom Scott’s YouTube video “Why Electronic Voting Is Still A Bad Idea.”

The above are some examples I thought of, but generally speaking, any scenario that is anonymous but requires qualification verification can adopt Semaphore as a development kit.

Conclusion

Semaphore, as a development kit built using zero-knowledge proof, can actually have many different applications in privacy. Of course, with improved privacy, this also means restricting the power of platforms.

In the feedback from the previous article “W3C DIDs: Redefining Identity Authority,” there was one response that left a deep impression. It mentioned that such utopian mechanisms are beautiful but won’t be used by anyone. I actually partially agree with this view, because such mechanisms indeed require participation and investment from giant enterprises to succeed easily, and why would giant enterprises want to restrict their already powerful authority?

However, since digital footprints and personal privacy issues deeply affect everyone, they have gradually attracted attention from various sides. For instance, the EU’s GDPR (General Data Protection Regulation) has begun to more strictly restrict the use of privacy data, and even the recent European Digital Identity Wallet (EUDIW) will also adopt the W3C Verifiable Credentials 1.1 standard, further strengthening privacy protection from the perspective of cross-national regulations and supervision.

Meanwhile, Apple, which relies relatively less on profiting from privacy, has also introduced App Tracking Transparency in recent years, allowing users to decide for themselves whether to disclose their digital footprints to apps. These are all signs of gradually repairing digital footprint issues.

I’m a relatively pessimistic person, and I also agree that these privacy-related developments won’t change the world very quickly. But seeing these developments still brings a bit of hope—we can’t just pessimistically tell the teacher that they don’t understand the bully just because the bully always picks on the victim. Changing people’s views or habits is very difficult, but I also hope to provide some assistance within my capabilities.

Coming back to the topic, Semaphore, as a development kit, has the function of enabling developers to develop identity verification mechanisms that better conform to privacy principles. However, it’s not a standard like W3C DIDs but a more foundational development kit, so developers still need to build more complete privacy-first identity verification mechanisms.

Now some projects are gradually introducing Semaphore’s identity verification mechanism.

For example, zuzalu passport (zupass), as a conference/event identity verification platform, adopts Semaphore as the foundational infrastructure for zupass identity verification and released the Proof-Carrying Data (PCD) SDK as a credential solution. Zupass is like a lightweight DID solution but doesn’t deliberately comply with W3C DIDs/VC standards.

Additionally, UniRep, as an anonymous reputation system that can receive and grant reputation, also adopts Semaphore as the underlying identity identification solution.

Overall, Semaphore is still a very novel solution, and while from a developer’s perspective, Semaphore has already packaged the zero-knowledge proof framework for identity verification in a very easy-to-use manner, these cryptographic technologies are still a cutting-edge field. Developers still need to understand the concepts of the entire technology and also need to carefully evaluate various aspects of the development kit through experimental attempts.

Therefore, Semaphore still has a way to go before large-scale application, but as more people pay attention to such privacy-focused technologies, I believe there will be opportunities to improve privacy issues on the internet.

To Be Continued…

As for why I’m introducing Semaphore in the W3C DIDs series of articles? Mainly because in the second half of last year, I worked on a project that integrated Taiwan’s Ministry of the Interior’s Mobile Natural Person Certificate, W3C DIDs, and the Semaphore zero-knowledge proof framework, experimentally verifying the possibility of integrating these different technologies while evaluating various pros and cons.

This actually stacks the privacy protection of W3C DIDs and VC with Semaphore, pushing privacy protection further forward to more cutting-edge and unknown edges. In such a state, we can more easily observe various aspects of these technologies.

However, whether it’s W3C DIDs/VC, Semaphore, or even decentralized identity itself, they are all very difficult to explain clearly at once. That’s why this series of articles was created to lay out all the knowledge. The next article will be the last in the series. I hope to have the opportunity to finish writing and publish it this month. Stay tuned!

W3C DIDs: A Digital Identity Standard Dismantling Power Structures

Mon, 01 Jan 2024 00:00:00 GMT

In the previous related article Examining Digital Identity Issues and DID Solutions Through Facebook’s Unjust Account Suspension, I revisited the current state of digital identity through my own tragedy of being suspended by Facebook without cause, and briefly mentioned W3C DIDs, a standard attempting to disrupt this status quo. Now I want to explore more deeply how the W3C DIDs mechanism can transform the current landscape.

Readers who haven’t read the previous article may want to revisit it first 😎

Current State

From my perspective, current digital identity services have several issues:

Autonomy

Current digital identities are not owned by users but by large corporations, which allow you to use those digital identities—just like how my Facebook account was permanently deleted without requiring my consent.

Privacy

Identity providers (i.e., companies like Google and Facebook) can track users’ login behavior, and users’ digital footprints serve as their monetization tools. Through users’ digital footprints, they can fuel their advertising and generate substantial profits. Combined with other services owned by these companies, such as Google’s search engine, Facebook’s social network, and the Facebook comment functionality embedded in websites, they can piece together a complete picture of users and serve them advertisements they’d like—or even scam ads they’re more likely to fall for.

But how do DIDs solve these problems? First, let’s gain a deeper understanding of DIDs.

W3C DIDs

W3C Decentralized Identifiers (DIDs) is a standard for decentralized identity, allowing users to perform identity verification using cryptography-based digital identities. In practice, when using W3C DIDs, it’s often necessary to combine them with another standard: W3C Verifiable Credentials (VCs). These two standards handle different functions:

DIDs standard: How to verify a DID identity
VCs standard: The credential issued when one DID endorses a claim about another DID

For example, when Alice purchases a game called First Fantasy, developed by game developer “SE”, on a gaming purchase platform (let’s call it Stream), Stream will issue Alice a proof of game purchase.

In this scenario, Stream as the platform will have a DID identity, and Alice will also have a personal DID identity. Before Alice purchases the game, Stream will first find verification information from Alice’s DID identity and verify this Alice DID identity. The DID standard specifies what this verification information should be.

After Alice passes DID verification and purchases the game, Stream will issue Alice a game purchase proof in VC standard format, where Stream’s DID serves as the issuer, certifying that Alice purchased the game First Fantasy on Stream. This is a credential generated to endorse a specific claim. Systems that receive this credential can verify whether the information recorded in the VC is correct based on the information contained within. This is the functionality provided by the VC standard.

A DID identity looks like this:

A DID identity consists of three fields separated by colons. The first field is always the string did, the second field is the DID Method. Since there are many different types and platforms for cryptography-based digital identities—including blockchain platforms, non-blockchain platforms, public key information placed on users’ own websites, and even locally generated public keys—the access methods for these different DID types are called DID Methods, and the second field indicates which DID Method this DID identity uses. The third field is an identifier string specific to the particular DID Method.

For example, the following DID identity: did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a means:

did: This is a DID identity
ethr: This DID identity uses the ethr DID Method
0xb9c5...6e8a: The user uses this string to represent a specific identity in this DID Method (think of it as an ID number)

This DID identity string, when parsed through an appropriate library, can reveal how to interact with this DID—for example, how to verify identity or verify credentials. This interaction information is a JSON file called a DID Document.

Here are a few different DID Methods:

did:key: Users directly provide the public key in the DID identity string, without placing public key information elsewhere
did:web: Users place public key information on their own website
did:ethr: Users specify their account address on the Ethereum blockchain as the DID identity

Besides these three, there are many more DID Methods. For more types, please refer to DID Specification Registries.

did:key

did:key means the DID identity string itself contains public key information, so no blockchain or other place to store the public key is needed. For example, in the DID identity did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK, the third part z6Mk...2doK is the public key of an algorithm, and this information is sufficient to verify this DID identity. To determine which encryption algorithm, you can judge from the beginning of the third field, for example:

z6Mk: Ed25519 algorithm
zQ3s: Secp256k1 algorithm
zDn: P-256 algorithm

So the above example z6Mk...2doK can be identified as requiring the Ed25519 algorithm to verify messages.

The advantage of did:key is that it’s very simple and managed by users themselves. If packaged as an app, it can even use biometric devices like TouchID to securely store the private key, making it a very convenient choice. The disadvantage is less flexibility—for example, if you want several different devices like phones and computers to manage one DID identity, there isn’t a secure management method.

Another disadvantage is that the current format of did:key doesn’t support the WebAuthn format, so you can’t use biometric devices directly on web pages to manage did:key—it must be packaged as a mobile app.

2024-02-05 Update: I recently saw ceramicnetwork/js-did/key-webauthn, which looks like it might be possible to generate and verify did:key using WebAuthn.

did:web

did:web is a method where users provide DID interaction information by uploading a JSON to a specific URL. For example, the DID identity did:web:mattr.global actually obtains DID identity information from the URL https://mattr.global/.well-known/did.json. The owner of this DID can adjust their identity verification requirements by changing this JSON file placed on the website—for example, they can have different cryptographic keys on multiple devices, allowing them to log in on phones, computers, and tablets, or they can regularly update and replace keys to maintain security.

The advantage of did:web is also its simplicity, and updating is very convenient. I think because people feel they own that URL, they feel it’s quite secure. The disadvantage is that it’s not particularly convenient for ordinary people. A simple method might be to upload a file to Github pages—easy for engineers but somewhat difficult for average users.

However, from a decentralization perspective, did:web has some drawbacks. For example, if it’s on Github Pages, when you have a conflict of interest with Github and the company decides to remove your website, your digital identity is taken away. Not to mention that domain names, even when registered, have time limits, and you might also have conflicts of interest with domain registrars that could cause the domain to become invalid.

Of course, from most people’s perspective, this method already has sufficient autonomy. But if you’re concerned, you can use the slightly less flexible did:key, or consider the next solution, did:ethr.

did:ethr

did:ethr is a DID Method that places DID identity interaction information on Ethereum or compatible blockchains. For example, in the DID identity did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74, the third part is the account address, and users can use the private key controlling this account to verify this DID identity. The default verification method is signing a message, which is something Ethereum blockchain users do frequently and is quite intuitive.

Besides being ready to use out of the box, it can also be advanced configured through a smart contract, allowing for multi-device/private key management of the same DID identity and advanced features like key updates and rotation.

The advantage of did:ethr is that, like did:web, it has more options to adjust DID identity while being sufficiently decentralized, guaranteeing that as long as you possess the corresponding private key, you have complete control over the DID identity. There are no intermediaries like cloud server providers or domain registrars who might have conflicts of interest with users and take away your digital identity.

But the disadvantages are also obvious. Since did:ethr uses blockchain technology, users who haven’t been exposed to blockchain will find the barrier too high and difficult to use.

Verifiable Data (VC)

VCs, like DID Documents, are JSON files. As previously stated, a VC is a credential issued by one DID to another DID to endorse a specific claim. Using the same example of the game purchase platform Stream, Stream’s DID might be did:web:streamgame.com, and if Alice chooses to use her Ethereum blockchain account to represent her identity, her DID would be something like did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74.

Here we can also observe that the issuer and holder in a VC can use different DID Methods, so an issuer who stores their public key on a website can also issue a VC credential to a user who uses an Ethereum account address as their DID identity.

When Alice purchases a game, Stream’s system will issue a VC game purchase credential to Alice, as shown in this example:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "issuer": {
    "id": "did:web:streamgame.com"
  },
  "credentialSubject": {
    "id": "did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74",
    "purchaseId": "123456789",
    "gameTitle": "First Fantasy",
    "purchaseDate": "2023-12-31T15:00:00Z",
    "paymentAmount": 59.99,
    "currency": "USD",
    "platform": "PC"
  },
  "type": ["VerifiableCredential"],
  "issuanceDate": "2023-10-30T07:57:06.000Z",
  "proof": {
    "type": "JwtProof2020",
    "jwt": "eyJhbGci...2rzP0K5wow"
  }
}

This example describes that the issuer is did:web:streamgame.com, the person who purchased the game is Alice’s DID did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74, and the credentialSubject field contains game purchase information.

What’s important here is that the proof field contains the issuer’s signature information for this VC. Anyone who obtains this file can verify whether it was indeed signed and issued by Steam. After Alice obtains this credential, she can present it to others or companies to prove she owns this game.

For example, the game company “SE” that developed First Fantasy, the game she purchased, has released the next generation game Middle Fantasy, and the new version isn’t sold on Stream but instead available for digital purchase on “SE“‘s official website. However, buyers can enjoy a 40% discount on Middle Fantasy by providing proof of purchasing First Fantasy.

Additionally, since the id attribute in credentialSubject records Alice’s DID identity, when “SE“‘s official website confirms that the user is the purchaser recorded in the VC, they can also request the user’s DID signature to ensure they are indeed the purchaser of this purchase proof, not someone who stole it.

Next, let’s use this same example to examine the differences between current identity verification mechanisms and DID-based identity verification mechanisms.

Example: Differences Between Current Identity Verification and DIDs

In the above example, Alice purchased First Fantasy from the game purchase platform Stream, and the new version Middle Fantasy is sold digitally on “SE“‘s official website, where anyone who previously purchased the previous version First Fantasy on Stream can buy Middle Fantasy at a 40% discount.

Current Identity Verification Mechanism

With current identity verification mechanisms, the Stream game purchase platform would provide a function to log into the Stream platform, typically using a standard like OpenID Connect (OIDC). After connecting to Stream through OIDC on the game’s official website, user purchase information is obtained through Stream’s APIs.

Let’s examine what problems this method has in terms of autonomy and privacy:

Autonomy

If Stream removes First Fantasy due to its age, or if there’s a conflict of interest between Alice and Stream (for example, Alice advertises for rival platform Epico) and Stream claims Alice “violated platform regulations” and suspends her account, “SE“‘s official website cannot obtain Alice’s data on Stream through other means.

This situation is just like when Facebook permanently suspended my account completely without reason—I don’t truly own my digital identity on Facebook.

Privacy

When the game’s official website needs to log in through Stream APIs and query purchase records for the Middle Fantasy discount sale, Stream will learn about Alice’s digital footprint on “SE“‘s official website store. If Stream is also a gaming platform that monetizes user digital footprints (for example, if they provide game advertising), they have a strong incentive to record users’ digital footprints.

Next, let’s see what the situation would be if W3C DIDs were adopted.

W3C DIDs Identity Verification Mechanism

When implementing a purchase proof mechanism using W3C DIDs, when Alice purchases the game First Fantasy, a game purchase proof in Verifiable Credential format will be issued to Alice based on Alice’s DID identity. This purchase proof will include Stream issuer’s signature, purchaser information, and game information.

When Alice wants to purchase the new version Middle Fantasy from “SE“‘s official game platform and needs to verify purchase eligibility on the Stream platform, she only needs to provide that game purchase credential VC to “SE“‘s official website. At that time, “SE“‘s official website will verify whether the credential was issued by Stream, whether it’s a correct game purchase credential, and verify through the purchaser’s signature whether Alice possesses the specific DID identity used during the purchase.

After verifying the VC-format purchase proof, “SE“‘s game official website can provide the discount to Alice. Let’s again examine autonomy and privacy.

Autonomy

After Stream provides the VC purchase credential to Alice, it will have Stream issuer’s signature on it. This signature is non-repudiable, proving that the Stream issuer definitely signed it.

The W3C DIDs standard actually provides a revocation mechanism, but this revocation mechanism only allows the issuer to mark this credential as revoked through a revocation list. The signature previously attached to the VC remains non-repudiable.

Even if Stream marks Alice’s purchase proof as revoked, the purchase information credential that Alice previously saved can still prove that she once purchased this game on Stream, because all the necessary information is in the credential. Although the revocation mechanism will mark this credential as revoked, it cannot deny that the Stream issuer previously signed this credential, so the issuer’s signature on the credential remains valid—it just has an additional revoked mark.

This way, “SE“‘s official website selling Middle Fantasy can decide for itself whether to accept such credentials, rather than having all power concentrated with the issuer.

Privacy

When Alice provides credentials to the game’s official platform, if Stream chooses to place the issuer’s public key information on the website, at most they can know that someone downloaded the public key information—they won’t know which user is trying to verify which game. If it’s placed on the Ethereum blockchain, Stream won’t even know that someone downloaded the public key information. In terms of privacy protection, this is better than current implementation methods.

The differences between these two characteristics in traditional verification mechanisms versus DID verification mechanisms are as follows:

Characteristic	Traditional Identity Verification	W3C DIDs Identity Verification
Autonomy	Platform has the authority to revoke users’ credentials or identities and refuse any data access	Platform can only mark credentials as revoked but cannot deny credentials it has previously signed
Privacy	When logging in or querying data through APIs, the platform can obtain users’ digital footprints	Platform cannot track users’ digital footprints through login behavior

Conclusion: Privacy and Autonomy Are Guaranteed, But What’s Still Missing?

As stated above, the W3C DIDs and Verifiable Credentials standards do indeed enhance users’ autonomy and privacy regarding identity verification. If this mechanism is so good, we should immediately implement DIDs—what are we waiting for?

DIDs is a recently formed standard protocol, and there are still many shortcomings. First, if we need better support for DIDs and VCs, we’ll need an app that can store various VC credentials and allow users to select which credential to use through this app when needed. This app will also need to manage users’ private keys. In essence, this app would be very similar to Apple Wallet or Google Wallet—apps used to store tickets and membership cards—but would additionally need to implement functionality for managing internal or external private keys.

In reality, there isn’t a mature, easy-to-use app to do this. Moreover, since DIDs are still in their early stages, whether to have a VC Wallet first or support DIDs first becomes a chicken-and-egg problem.

The next issue is motivation. As described above, after adopting DIDs, the power of identity providers and credential issuers will be greatly reduced, and it will be more difficult to track users’ digital footprints. Let’s think from their perspective: if Google or Facebook implementing a new identity verification protocol would significantly reduce advertising precision, thereby decreasing profits from their main revenue source, while also losing more control over users—what motivation would they have to switch to DIDs?

A better entry point might be from a regulatory perspective, with regulatory authorities like the EU requiring giant corporations to reduce their control over the digital world, or even having governments first adopt the DID standard for official credentials like ID cards or driver’s licenses. I believe this is a better approach.

Looking back, DIDs is still very early stage, and there are indeed many shortcomings to face. But conversely, it’s also a place full of hope. This standard reflects on the enormous control giant corporations currently have over the digital world and paints a blueprint for a more autonomous and privacy-respecting future, allowing us to consider whether there’s an opportunity to reclaim some power that rightfully belongs to users through standards.

Of course, our imagination for the future doesn’t have to stop here. We can push further: if we want even better privacy, what solutions are currently available? For example, when verifying whether a user has purchased First Fantasy on Stream, could we prove that the user indeed purchased the game without even revealing their DID identity?

The next article will explain how Semaphore, a zero-knowledge proof framework, achieves more advanced privacy applications. Stay tuned!

Additional Information

The Problem of Seamless Key Rotation in did:web

Luoh Ren-Shan pointed out in a Facebook comment that if the issuer Stream adopts did:web as its DID, the issuer could seamlessly change their key information to invalidate the credential in Alice’s hands.

This is indeed a problem, but when updating key information this way, other credentials issued by Stream using the original key will also become invalid—it cannot be limited to just Alice’s credential. This would create a crisis of trust for the Stream issuer. As an issuer using did:web, they would need to weigh the pros and cons before deciding whether to do this. Of course, when a major issue occurs, the issuer might still use this tactic to aggressively handle thorny problems, but compared to traditional methods where results can be easily manipulated, using did:web is still more trustworthy, though not perfect.

Looking back, if using did:ethr, when the DID owner updates key information, a historical record is left, and previous versions of the DID document can be retrieved through parameter queries, making it even more trustworthy than did:web.

Yuren's Blog - Tech

The Door Opened by OpenClaw

Making Claude Code Run Its Own Acceptance Tests

BDD + TDD

Asked AI to Write Code, But It Can't Understand Me?

Traditional Software Development Discussions

Use Rules to Define Direction

Break Down Specs and Progress Step by Step

Specs Should Have Acceptance Criteria

So Far…

Trading Tokens Directly Within Claude Desktop

Postscript

Before the Perplexity Comet Browser Release

ChatGPT as a Reflection and Extension of Curiosity

Footnotes

tw-did Additional Information

Proof of Concept: Privacy-First Digital Identity for Taiwan Residents

Mobile Natural Person Certificate

Autonomy

Privacy

TW-DID Experimental Project

W3C DIDs/VC Integration

Autonomy

Privacy

Semaphore Integration

Demo Video

Review and Discussion

Does the Prototype Provide Imagination of Future Scenarios

Digital Identity Autonomy and Privacy

Development Kits

Lack of Wallet

Lack of Exchange Protocol

Semaphore Improves Privacy, But Implementation Details Need Refinement

Conclusion

Semaphore: A Privacy-Enhanced Identity Solution

Example Scenario

Paper Tickets

Digital Tickets

Semaphore Identity Authentication

Reasons and Scenarios for Using Semaphore

Online Alcohol Purchase

Whistleblower Platforms

Medication or Poverty Assistance

Opinion Surveys

Conclusion

To Be Continued…

W3C DIDs: A Digital Identity Standard Dismantling Power Structures

Current State

Autonomy

Privacy

W3C DIDs

did:key

did:web

did:ethr

Verifiable Data (VC)

Example: Differences Between Current Identity Verification and DIDs

Current Identity Verification Mechanism

Autonomy

Privacy

W3C DIDs Identity Verification Mechanism

Autonomy

Privacy

Conclusion: Privacy and Autonomy Are Guaranteed, But What’s Still Missing?

Additional Information

The Problem of Seamless Key Rotation in did:web