Skip to main content

Yivi Portal announcement

· 5 min read
Sara Vahdati Pour
Developer @ Caesar Groep

Yivi Portal is Yivi's new initiative to help with a smooth launch for the Trusted/Pretty verifier. Trusted Verifier is a pivotal part of the roadmap as mentioned in earlier blog posts and serves as part of our commitment to our users, as well as helps with transparency with our verifiers in covering the downstream costs of various verification sessions that our issuers bear.

In this blog post I will dive into what the portal exactly is, and what can you expect from the coming updates.

Yivi Portal

As part our core values, we want to make Yivi more accessible and easy to use. That also concerns developers and the business facing side of matters. In the portal you can see which organizations play a part and work with Yivi and search between the credentials information that is available.

As a verifier (referred to as relying party to adhere with the most recently used terminologies) you can register as an organization. You will then be able to set up your relying party. In doing so, you will need to specify which attributes (e.g. age, phone number) you will be requesting. You can add a few of these. You will also need to provide some context explaining why the combination of attributes is needed.

For example, an online liquor shop can add age, home and email address with the context of fulfilling orders, sending an email confirmation and posting the package. This helps us ensure legitimacy of these requests and protecting our user's privacy from sharing unnecessary information. You will then be given a DNS challenge, with which we verify your domain ownership.

When accepted, we will get started with publishing your relying party. Another feature now coppled with the portal is the new attribute index service which was previously hosted seperately here. You can also issue demo credentials as you did previously. This can help our consumers find all they need to know about organizations and credentials in one place. Starting 4th of July you can register your organization or request maintainer rights for your existing organization.

Yivi Portal first look

First look at the Yivi Portal

Trusted Verifier

Trusted Verifier is more than anything, rooted in enhancing user privacy through UX. This program is also known as pretty verifier program has been in the works as a way to further help our users stay safe and make informed decisions regarding sharing their information using Yivi. Yivi makes it easy for any party to set up a verification service and ask for user's data.

The decision to share this information then fully relies on the user, who may be uninformed about the source of this request. The goal is to guide the user to consent only when they are sure about it. Yivi already does this to some extent, with the help of the requestors scheme .

Parties have already been able to make themselves known to Yivi, by adding their branding and hostname, which would then be manually verified by our team. The app would read this and present user with the user friendly branding (name and logo). Otherwise users would be encountered with the raw url starting the session, which to most users will seem odd and unsafe.

The new initiative plans to take this a step further, making it an easier and more instantanious decision for the user that what seems trusted party to share information with and what is not. This is done through the use of colors. Green for trusted and red for untrusted. The new update will come out on 1st of September.

trusted-verifieruntrusted-verifier

The app visually distinguishes trusted (green) and untrusted (red) verifiers, helping users make informed decisions before sharing their data.

4th of July

Starting form the 4th of July maintainers from organizations can register their organization in the Yivi portal. Organizations that have existing and active verifiers are encouraged to register on the portal, so applying new changes, clarifying on your verification needs and their context as well as making agreements about the your usage needs can be facilitated.

1st of September

On the 1st of September we will release a version of the Yivi Mobile App that will:

  • Warn users that they are sharing data with an unknown party.
  • Assures users that they share data with a known and trusted party.

Relying parties are expected to have registered themselves and have an agreement with Yivi.

What changes now?

Now with the portal up and running, we kindly ask relying parties that are interested in providing a good user experience to their users to join by registering at the Yivi Portal, which makes participation easier than before. Want to start by joining to the portal?

This page in our Yivi documention goes through the steps on how to use the portal as a relying party. In the near future, we are adding support for registering as issuers (attestation providers) and providing assistance with key rollovers, verifying and including the new public key in the scheme in efforts to facilitate the process of becoming an issuer.

Post-mortem of the June 29th and 30th 2025 incident

· 6 min read
Dibran Mulder
CTO @ Caesar Groep

According to our mission, we are committed to transparency and accountability. This post-mortem is part of that commitment, detailing the events surrounding the issue with the Yivi app on iOS on June 29th and 30th 2025.

Summary of the impact

Some iOS users of the Yivi app were unable to open their Yivi app on June 29th and 30th, 2025, due to an issue with the Universal Links feature. This issue was caused by a domain migration of irma.app, resulting traffic to be redirected from irma.app to yivi.app. iOS devices however do not support redirection for Universal Links, which led to the app being unable to open Universal Links. This issue was resolved by changing the irma.app domain back to its original server.

Users that had the Yivi app installed prior to the incident were probably not affected, as the app was still able to open. However, users who installed the app after the domain migration were unable to open it due to the Universal Links issue.

Timeline of the incident

Date & TimeDescription
June 29th, 2025, 20:00 CESTReceived an email from DNS provider that the domain irma.app was migrated to the new provider and was starting to redirect traffic to yivi.app.
June 29th, 2025, 21:07 CESTReceived a report from a user that the Yivi app on iOS was not opening.
June 30th, 2025, 00:03 CESTReceived another report from a user that the Yivi app on iOS was not opening.
June 30th, 2025, 13:15 CESTStarted investigating the issue and found that the Universal Links feature was not working due to the domain migration.
June 30th, 2025, 14:00 CESTConfirmed the issue was caused by the redirection of traffic from irma.app to yivi.app. Issue affected only new installations of the Yivi app on iOS, not existing ones.
June 30th, 2025, 15:30 CESTChanged the irma.app DNS settings back to the old server allowing Apple devices to check the site association again.
June 30th, 2025, 16:00 CESTConfirmed that the issue was resolved; the Yivi app was able to open on iOS devices again.
July 1st, 2025, 11:45 CESTDelivered a workaround to affected users by providing a page that converts irma.app Universal Links to open.yivi.app Universal Links.
July 1st, 2025, 14:00 CESTDocumented the issue and resolution in a post-mortem on our blog and shared it with the community.

Customer impact

The incident affected a small number of iOS users who were unable to open the Yivi app, in a same deice flow, due to the Universal Links issue. The impact was limited to users who installed the app after the domain migration and to users of who's iOS rechecked the site association file after the migration. We have no reason to believe that it affected a large number of existing Yivi iOS users. According to our keyshare server registrations, the number of affected users, that installed the Yivi app in the time window mentioned above, was about 78 users including Android users, which is a small percentage of our total user base.

Root cause and mitigation

As part of our efforts to improve the Yivi app, we migrated the domain irma.app to yivi.app. This migration was intended to provide a more consistent branding experience for our users and to gain control over all domains originally maintained by SIDN. However, the migration inadvertently caused an issue with the Universal Links feature on iOS devices, which do not support forwarding for Universal Links.

The Universal Links feature allows the Yivi app to open directly from links in the browser, providing a seamless user experience. However, iOS requires that the associated domain file (apple-app-site-association) be hosted on the domain without any redirects. The redirection of traffic from irma.app to yivi.app caused the associated domain file to be redirected, which prevented the Yivi app from opening on iOS devices that installed the app after the migration.

https://fully qualified domain/.well-known/apple-app-site-association You must host the file using https:// with a valid certificate and with no redirects.

Link to Apple's documentation

The reason it was not breaking Android devices is that Android uses a different mechanism for handling Universal Links, which doesn't rely on the irma.app domain, as can be seen in our Yivi frontend packages code, its not using the irma.app domain for Android devices, but instead used an intent link that does not require the associated domain file to be hosted without redirects.

Yivi frontend packages code

  _getMobileUrl(sessionPtr) {
const json = JSON.stringify(sessionPtr);
switch (this._userAgent) {
case 'Android': {
// Universal links are not stable in Android webviews and custom tabs, so always use intent links.
const intent = `Intent;package=org.irmacard.cardemu;scheme=irma;l.timestamp=${Date.now()}`;
return `intent://qr/json/${encodeURIComponent(json)}#${intent};end`;
}
case 'iOS': {
return `https://irma.app/-/session#${encodeURIComponent(json)}`;
}
default: {
throw new Error('Device type is not supported.');
}
}
}

To mitigate the issue, we changed the DNS settings of irma.app back to the old server, allowing the Yivi app to open on iOS devices again. This was a temporary solution to ensure that users could continue to use the app while we worked on a more permanent fix.

The open.yivi.app domain was not affected by this issue, as it was not part of the domain migration. The open.yivi.app domain is an alternative Universal Link that can be used to open the Yivi app on iOS devices. We provided a workaround for affected users by creating a page on irma.app/-/session that converts the irma.app Universal Links to open.yivi.app Universal Links, allowing them to continue using the app without any issues.

This workaround will stay into place until we have fully migrated the irma.app domain to the new server and ensured that all Universal Links are working correctly. Apple states that it can take up to a week for devices to recheck the associated domain file, so we will monitor the situation closely and make any necessary adjustments as needed.

Affected users can decide to reinstall the Yivi app from the App Store, which will ensure that the app is able to open Universal Links correctly. However, this is not necessary for existing users who already have the app installed, as they will still be able to open the app without any issues.

Next steps

  1. Reevaluate domain migration strategy: We will review our domain migration strategy to ensure that future migrations do not cause similar issues with Universal Links or other features.
  2. Review App integrations: We will review the integration of the Yivi app with Universal Links and QR intents on both iOS and Android devices to ensure that it is robust and has fallbacks in place for any potential issues.

Post-mortem of the 1st of July outage

· 6 min read
Dibran Mulder
CTO @ Caesar Groep

According to our mission, we are committed to transparency and accountability. This post-mortem is part of that commitment, detailing the events surrounding the outage of the 1st of July 2025.

Summary of the impact

We experienced a significant outage on the 1st of July 2025, which affected our services for approximately 6 hours. During this time, users were unable to validate their pincodes and access their Yivi App, making the Yivi-App unusable. The issue was caused by an outage in the Scaleway data center AMS-1, where our database server is located. Scaleway preemptively shut down several services in the datacenter to prevent further issues such as hardware damage due to abnormal temperatures.

Timeline of the incident

Date & TimeDescription
July 1st, 2025, 16:30 CESTScaleway confirmed that they were experiencing issues due to abnormal temperatures in the data center AMS-1
July 1st, 2025, 16:45 CESTOur database server started spiking CPU usage and Total Connection, successively Scaleway preemptively shut down several services in the datacenter, to prevent it from further issues such as hardware damage.
June 1st, 2025, 16:57 CESTReceived a first report from a user that the user received errors validating the pincode in the Yivi app.
July 1st, 2025, 17:00 CESTStarted investigating the issue and found that the database server was experiencing high CPU usage.
July 1st, 2025, 17:10 CESTConfirmed that the issue was caused by Scaleway, our infrastructure provider.
July 1st, 2025, 17:30 CESTRestarted the Keyshare backend services to try to restore the database connections.
July 1st, 2025, 18:00 CESTStarted configuring a failover database server, for whenever the issue was not fixed over night.
July 1st, 2025, 23:25 CESTScaleway's Infrastructure provider resolved the issue, restarted the services and our system recovered accordingly.

See the full incident report from Scaleway for more details: Scaleway Status Page

Below are the metrics from the database server that show the CPU usage and Total Connections were spiking prior to the downtime.

Metrics from the database server

Customer impact

Users were unable to validate their pincodes and access their Yivi App during the outage. The impact was significant, as users were unable to use the app for approximately 6 hours.

Root cause and mitigation

Yivi uses Scaleway as its infrastructure provider, and the outage was caused by an issue in their data center AMS-1. The issue was due to abnormal temperatures in the data center, which led to Scaleway preemptively shutting down several services to prevent further issues such as hardware damage. Temperatures in the Amsterdam area were unusually high, the infrastructure cooling system couldn't keep up, which caused the data center to overheat.

note

An availability zone is a distinct location within a data center region, designed to be isolated from failures in other availability zones. This setup allows for high availability and fault tolerance.

Yivi uses a multi-availability zone setup, which means that if one availability zone goes down, the other availability zone can take over. We use this for our Kubernetes cluster, which is responsible for running the Yivi backend services, including the Keyshare backend services, serveral issuers, the portal, etc. This setup allows us to ensure high availability and fault tolerance for our services.

However, our database server which is configured as a High Availability (HA) database within Scaleway, was located in the affected data center. This meant that when Scaleway shut down the services in that availability zone, our database server was also affected, leading to the outage. As a team we were expecting that the failover database server would be automatically used, but this was not the case, apparently both of the racks that power our database server were affected by the outage.

Scaleway documentation Are my active and standby database nodes in a high-availability cluster hosted in the same data center? In a high-availability cluster, active and hot standby nodes are indeed located in the same data center but in two separate racks. The idea is to offer the best performance to our users by reducing latency between active and hot standby nodes, as we use a sync replication process between the nodes.

Next steps

We think that the best way to prevent this issue from happening again is to create an additional failover database server in a different availability zone or even on a different infrastructure provider. This way, if one availability zone goes down, the failover can take over and the database server will still be available. This is not a native feature of the Scaleway Managed Database service, so we will have to implement this ourselves. Our Kubernetes cluster is already set up to use multiple availability zones and during this issue the 2 other nodes in the cluster were still operational, servicing traffic and requests, but the database server was not available, which caused the outage.

Next to that we indentified the following next steps aswell:

  • If one of the nodes powering the kubernetes cluster goes down, the other nodes will still be operational. However if for some reason we want to change the configuration of for instance the keyshare server to point to a different database then we can't do that with Terraform since its blocks on shutting down pods that run on unavailable nodes. Leaving us with no way other then to manually change the configuration of the keyshare server, which is not ideal.
  • The Scaleway Managed Database service always for a ReadOnly replica which can be promoted to a primary database server. However, this is not automatically done in case of an outage, so we will have to implement this ourselves as well. This means that we will have to monitor the database server and if it goes down, we will have to promote the ReadOnly replica to a primary database server.
  • Our blog also runs on the same Scaleway infrastructure, which we couldn't update because the Terraform changes were blocked by the unavailable nodes in the Kubernetes cluster. This means that we couldn't update our blog to inform users about the outage and the progress we were making to resolve it. We will have to implement a way to update our blog in case of an outage, so that we can keep our users informed.
  • Our public website has to incident page that informs users about the outage and the progress we are making to resolve it. This page should be accessible even if the blog is down, so we will have to implement this as well.
  • We have no mechnism in place to inform users in the Yivi-app about the outage or scheduled maintenance. We will have to implement a way to inform users about the outage or scheduled maintenance, so that they are aware of the situation and can take appropriate action.

Age Verification in the EU, Ambitious goals, missed privacy opportunities

· 14 min read
Dibran Mulder
CTO @ Caesar Groep

Protecting minors, today and tomorrow

The European Commission is preparing a temporary age verification app, aimed at protecting minors on platforms where a minimum age is required—think of online pornography, gambling, alcohol sales, and certain social media services. In a digital world, it's legitimate to shield minors from harmful content. The Digital Services Act (DSA) already obligates large platforms to take protective measures, and the Commission is stepping in where compliance is lacking. A technical solution to verify age online is therefore urgently needed.

In May 2025, the European Commission launched formal investigations into major online pornography platforms for potentially breaching the DSA’s rules on protecting minors. Specifically, the Commission suspects that these platforms may not have effective age verification systems in place, allowing minors to access explicit content too easily. These investigations mark the first enforcement steps of this kind under the DSA, sending a strong signal that the EU intends to hold Very Large Online Platforms (VLOPs) accountable. In announcing the probes, the Commission also referenced its ongoing work on a temporary age verification solution. This tool, they noted, could help platforms meet their obligations while respecting users’ privacy and avoiding repeated identity checks.

The proposed app — a sort of mini European Digital Identity (EUDI) wallet — will allow users, starting in July 2025, to prove their age without repeatedly uploading ID documents. After installation, users verify their age once (e.g., through a passport scan, bank app, or eID login). From then on, the app can inform websites whether a user is over 18 without revealing personal data, according to the Commission. This temporary solution is meant to bridge the gap until the full rollout of EUDI wallets expected at the end of 2026. The initiative is understandable, the goal is to make the internet safer for minor while providing adults with a digital tool to prove age quickly and privately. Yet the implementation raises key concerns — especially in the realm of privacy. EDRI did a position paper on this topic and identified several risks on this topic, including privacy related risks such as : Violating children’s privacy and data protection rights and Making anonymity online difficult or impossible. Its important that these topics are addressed well by the solution.

A heavy tender favors large players

To build the age verification app, the Commission launched a public tender in October (with a deadline in mid-November 2024). The requirements were steep: only large entities or consortia with over substantial revenue, multiple large projects in their portfolio, and a stack of certifications were eligible. The winning team also had to include a privacy lawyer with at least seven years of experience, among others. This effectively excluded privacy-focused innovators—such as Yivi, the Dutch privacy-by-design identity wallet—from competing. Despite an attempt to qualify, Yivi could not meet the legal and bureaucratic criteria within the short timeframe. Ultimately, the contract went to a consortium of T-Systems and Scytales (“T-Scy”), who are delivering a white-label app.

While the Commission's choice of a well-established vendor is understandable from a risk-management perspective, it comes at a cost. In its requirements, the tender explicitly asked for experience with selective disclosure and zero-knowledge proofs (ZKPs)—advanced techniques to verify attributes (like age) without exposing identities. Solutions like Yivi are built around these principles, yet their lack of size and formal certifications ruled them out in advance. The result: a conservative implementation that checks the must have requirements, but fails to raise the bar on privacy.

A first look at the App

The Android version of the Age Verification App provides our first hands-on insight, as an iOS counterpart is not yet publicly available. Under the hood, the Android app heavily reuses components from the EUDI Wallet ecosystem. In fact, the codebase is a fork of the official EUDI Android Wallet reference application, built on the Architecture Reference Framework (ARF). This means the app consumes the EUDI Wallet Core SDK and integrates modular libraries for issuing credentials and creating verifying presentations. Essentially, the consortium didn’t start from scratch but repurposed the existing digital identity wallet architecture (Wallet Core, Issuer, Verifier modules, etc.), tweaking it for the specific use case of age attestation.

warning

The iOS version of the Age Verification App has not been developed or is not open sourced yet.

Being based on the EUDI reference wallet, the app benefits from an established architecture — but also inherits its complexity. Early interoperability testing suggests quite some instability and immature areas in the EU’s implementation. This isn’t surprising: the solution’s architecture is multi-layered and involves multiple programming languages and frameworks. Moreover, the standards it implements are still evolving. The app currently follows draft specifications for credential exchange, such as OpenID4VP draft 23, and OpenID4VCI draft 14 for issuance – versions that are already outdated as these specs continue to mature. With such a layered setup and moving targets in standards, bugs and inconsistencies were inevitable. Indeed, the project itself labels this release as a "foundational prototype" not ready for production use. The code comes with clear warnings about possible errors, missing features, and reduced security/privacy assurances in this initial version. All of this underscores that while the core concept works, it’s far from a polished, stable product in its current state.

comparison eudi wallet

On a positive note, the Android app is reasonably accessible in terms of device support. It runs on Android devices as old as API level 28 (Android 9 Pie, circa 2018), which means a wide range of smartphones – even some 5+ years old – can use it. This broad compatibility is important for an EU-wide tool. However, the app’s reliance on older draft standards may limit interoperability with newer or alternative wallets unless updates are made. Our testing with Yivi revealed integration challenges, hinting that the Commission’s wallet components are not yet fully spec-compliant or robust when interacting with non-official wallets. These findings point to a need for further refinement: streamlining the architecture, consolidating layers, and tracking spec updates to improve stability. The Commission and its developers are likely aware of these issues – the open-source project invites feedback and explicitly notes that many features will evolve before any real-world deployment.

Requesting a Proof of Age

One of the first questions for any age verification system is: How does a user actually obtain an age credential? According to the technical documentation, the app should ultimately support a mix of methods to request and generate a proof of age. These include:

  • National eID schemes – e.g. using your country’s electronic identity (online ID card or digital ID login) to confirm your age. Document-based verification – scanning a physical ID document (passport, driver’s license, national ID card) via the app to extract and confirm your date of birth.
  • Open banking / bank KYC – leveraging your bank or payment provider (which has done Know-Your-Customer identity checks) to attest that you are over a certain age. For instance, linking the age-check app to a banking app that can confirm you’re an adult.
  • Mobile network SIM authentication – using mobile operator data (since getting a SIM card often requires age identification) to issue an age attribute.
  • Third-party attestations – other avenues like notaries or certified age-proof providers could issue an attestation of age.
requesting a proof of age

This sounds comprehensive, but the current beta falls short of covering any of these. As of now, the only fully implemented method is the eID-based flow. In practice, that means a user must authenticate with a supported national digital identity provider to retrieve an age credential. If your country issues citizen eIDs or has an eIDAS-notified scheme, the app can redirect you to that system for login, and then receive proof of your date of birth or an "Over 18" attribute. However, almost no EU country currently has a usable national eID for this purpose. The Netherlands, for instance, has no notified eID scheme under eIDAS yet. In such cases, the Age Verification app has no government-issued ID to tap into.

The lack of document scanning or other alternatives is a glaring gap, considering that the tender specs explicitly call for support of physical ID cards and open-banking methods. Those features simply haven’t been built yet in this prototype. As a result, many users would have no way to get an age proof with the current app. The developers acknowledge this limitation: additional issuance methods beyond the initial eID route are slated for future releases.

It’s worth contrasting this with Yivi, a homegrown European alternative that is already operational in production environments. Yivi is a privacy-by-design identity wallet that can issue and share age attestations today. It supports multiple verification methods that the EU app is still missing. For instance, a Dutch user can use Yivi to pull personal data from their municipality records via DigiD and instantly get a verified date of birth – enabling an "over 18" proof without storing anything centrally. Yivi also supports bank-mediated verification and other attributes through its open ecosystem. In short, the technology to privately prove one’s age exists and is being used in practice. Futhermore in contrast to the EU app Yivi implements a crypto-agile vision enabling users to choose the most privacy friendly technology out there, leveraring an Idemix Zero Knowledge Proof identity system that has unprecented features like relying party unlinkability and issuer unlinkability. In other words, even if the issuer of the personal data and the verifier (such as a porn website) collude, they still cannot profile users. This ensures that minors can use a privacy-by-design app without worrying about their anonymity being compromised. This raises a key point onm the Commission’s solution, while commendably emphasizing privacy, is essentially catching up to approaches already pioneered by privacy-first identity tools. The hope is that as the EU app expands to support document scans and bank IDs, it will do so in a way that’s interoperable – so that proven solutions like Yivi or others could plug in or be recognized as legitimate age verification providers in the ecosystem.

Whitelabel implementation by Member States and Age Verification App Providers

The European Commission’s plan is not to directly publish one app for all EU citizens, but to offer a white-label solution that Member States (or their appointed providers) will customize and deploy. The open-source code and technical specs have been published as a toolbox, and now governments or authorized parties in each country are expected to take it from beta to production. In theory, this means each Member State would add their branding, language, and integrate their national eID systems or databases, then release the app to their residents. This distributed implementation strategy respects national differences – each country can adapt the age verification app to "its national circumstances", as well as integrate with whatever local ID infrastructure is available. However, here lies a challenge: many Member States are behind schedule on even the broader EUDI Wallet rollout, let alone this niche age-checker. The EUDI Wallet is only mandated by 2026 and is still under design debate. Few countries have advanced digital ID apps ready now, expecting them to implement the Age Verification App in 2025 may be optimistic.

Screenshot of Age verification app

So, who will actually provide and run these apps? In some cases, governments might build and operate them via internal digital agencies. In others, they might outsource to companies – the Age Verification App Providers in practice. The term "Age Verification App Provider" isn’t formally defined in public docs, but we can infer it means any entity (public or private) that stands up an instance of the age-check app for users. Given the tight timeline and technical complexity, we might see countries piggyback on existing digital identity providers or national partners. For instance, a country without a ready eID might enlist a bank consortium or telecom companies to issue age credentials (since banks and mobile operators have KYC data on citizens).

A missed opportunity for privacy by design

The developed Android application does not use Zero-Knowledge Proofs, despite being mentioned in the tender as a specification. Instead, it falls back on more conventional mechanisms like hashed attributes and batch issuance — where age attestations are issued in large batches to reduce traceability. This may provide some unlinkability, but it’s far from the level of privacy that ZKPs offer.

And that’s a missed opportunity. The EU presents itself as a global leader in privacy — think of the GDPR — and the new eIDAS 2.0 regulation explicitly mandates selective data disclosure and unlinkability as foundational principles. In public debates on digital rights, there is growing concern over surveillance. The age verification app could have been a flagship example of how the EU protects children without undermining civil liberties. Unfortunately, in its current form, it falls short of that ambition.

A group of cryptographers who analyzed the underlying cryptografy of the EUDI-wallet specifications concluded that the design choices do not meet the privacy standards set by the EU itself, and recommended a major overhaul. Their verdict: hashed attribute mechanisms are insufficient to meet the legal and ethical standards embedded in eIDAS 2.0. The technology exists to do better — so why settle for less?

Yivi: A Privacy-First European Alternative

This is where Yivi enters the picture. Yivi is an open-source identity wallet developed in the Netherlands. It’s already capable of issuing and verifying selective attributes like "age over 18" based on the user’s control. Yivi has a comprohensive Zero-Knowlegde-Proof identity scheme that has unique features like issuer and relying party unlinkability, selective disclosure, and user consent by design. In short, it's a working proof that privacy and utility can coexist.

Yivi is also actively preparing for interoperability with the upcoming European Digital Identity (EUDI) Wallet. It is aligning with emerging technical standards such as the eIDAS 2.0 architecture, while staying true to its privacy-by-design. This forward-looking approach makes Yivi a strong candidate for crypto-agile, modular identity frameworks — exactly the kind of architecture the EU should be fostering. Supporting projects like Yivi ensures that Europe doesn't just follow but leads in the development of citizen-friendly digital identity.

A common argument against privacy-preserving identity schemes such as those based on zero-knowledge proofs (ZKPs) is the supposed reliance on secure hardware like Hardware Security Modules (HSMs). However, this objection loses relevance at the "substantial" assurance level defined under eIDAS. In this category, the use of HSMs is not a strict requirement, and the practical deployment of credential issuers—such as those offering Proof of Age — does not necessarily involve them. This opens the door for lightweight, software-based implementations that still meet the regulatory bar, without compromising user privacy or accessibility.

Rather than sidelining such innovation, the EU should engage and integrate these ideas during the next development phases. Let this “temporary” app be a learning platform — not the final form. Involve developers, privacy watchdogs, and user representatives early. Evaluate usability, fix real-world challenges (e.g., sharing of age credentials among teens), and evolve the system based on that feedback. Only then can we build a solution that inspires confidence rather than skepticism.

Conclusion

In conclusion, while the European Commission’s Age Verification App reflects a commendable intent to protect minors online while respecting privacy, its current trajectory appears unrealistic. The core requirement — Proof of Age Attestation Providers — is not yet fulfilled, and with Member States already struggling to meet EUDI Wallet deadlines, this initiative risks adding unmanageable pressure. Though the political will is evident and the bar for assurance has been lowered to accelerate adoption, the infrastructure simply isn’t there. Without viable providers and operational frameworks, the timeline is not feasible.

In contrast, Yivi offers a proven, privacy-respecting solution that’s already operational in the Netherlands and can be readily adapted for use across Europe. Rather than pushing a fragile and overly ambitious prototype, the Commission would do well to consider building on working implementations like Yivi to deliver on its goals more effectively and sustainably.

Yivi adds an IBAN issuer

· 2 min read
Dibran Mulder
CTO @ Caesar Groep

We’re excited to introduce a new feature in Yivi: IBAN Issuance via verified iDEAL payments. This addition brings secure, self-sovereign proof of bank account ownership right into the hands of Yivi users.

How it works

The IBAN issuer enables users to receive a verifiable credential containing their bank account information, simply by completing a €0.01 iDEAL transaction. This small payment serves as proof of account ownership.

After a successful payment, the following information is extracted and issued as an IBAN credential:

  • Full name of the account holder
  • IBAN
  • BIC

This credential can then be used in any Yivi-enabled service that needs proof of bank account ownership, such as financial onboarding, gig-economy platforms, or trusted peer-to-peer transactions.

IBAN credential

Backed by CM’s IBAN Verification

Yivi’s IBAN issuer is powered by CM.com's IBAN Verification service, a reliable and widely-used system for verifying account ownership via a €0.01 transfer. CM ensures that the account details are validated and returned in a privacy-respecting way, fitting seamlessly into Yivi’s selective disclosure model.

Try it now

The IBAN issuer is live and available at: 👉 https://iban-issuer.yivi.app/en

Users can visit the page, initiate the iDEAL verification process and add an IBAN credential in just a few clicks.

Why this matters

Verifying a bank account typically requires sharing large amounts of personal data or uploading sensitive documents. With this new IBAN issuer, Yivi brings a privacy-by-design, user-controlled alternative that fits modern digital interactions — no oversharing, no intermediaries, and cryptographically verifiable.

We're proud to keep extending Yivi’s ecosystem with trusted, reusable digital credentials. Let us know what you think or how you'd like to integrate IBAN verification into your workflows!

Yivi’s Strategic Roadmap to EUDI-Wallet Compliance

· 8 min read
Dibran Mulder
CTO @ Caesar Groep

As we enter a pivotal phase in digital identity development across Europe, Yivi is committed to becoming a compliant EUDI-wallet. This strategic decision is driven by a broader vision: to ensure that privacy-first identity solutions remain viable in a landscape increasingly shaped by regulation and standardization.

Our mission has always been clear: with Yivi, you are in charge of your digital data. And while regulatory alignment with eIDAS 2.0 and the EUDI-wallet may challenge some of our architectural preferences, it is a necessary step to bring privacy-preserving identity to the masses.

Yivi's vision

Privacy by design, still at the core

Yivi was built from the ground up to respect user privacy. The emergence of the EUDI-wallet framework is a positive step for digital autonomy and self sovereignty of users. However, we are concerned about the current lack of native support for core privacy mechanisms such as issuer unlinkability and relying party unlinkability.

We are actively engaged in community discussions like Topic G on Zero Knowledge Proofs, which highlight the limitations of the current specifications. While we appreciate that these topics are on the agenda, we remain cautious about both the timeline and the effectiveness of proposed solutions.

Yivi Today: A Mature Ecosystem

Yivi is a set of open source software project implementing the Idemix attribute-based credential scheme, allowing users to safely and securely authenticate themselves as privacy-preserving as the situation permits. Users receive digitally signed attributes from trusted issuers, storing them in their Yivi app, after which the user can selectively disclose attributes to others.

Yivi is more than just a mobile app, in fact we have all the software to build up an ID-Wallet ecosystem, much like the ARF prescribes. Obviously, some components are missing but Yivi has got some production-grade technology, such as:

  • an implementation of the Idemix credential scheme.
  • an open and transparent implementation of a Trust Scheme.
  • an implementation of a proprietary IRMA protocol for issuance and selective disclosure, respecting core features such as: selective disclosure, issuance, revocation based on accumulators and that with respect to core privacy features such as: issuer unlinkability and relying party unlinkability.
  • a set of open-source software tooling to host Attestation Providers (Issuers) and Relying Parties (Verifiers).
  • a multi-platform, multi-language and accessible mobile App.

As you can see Yivi is and was way ahead of its time, but now has come the time to align with the broader European ecosystem. We believe our work in the past decade has been fundamental to the new way of attribute-based credential thinking.

Key Challenges Ahead

Despite our maturity, there are significant gaps to bridge to achieve full EUDI-wallet compliance. We should work on interoperability and adopting industry standards. Our Idemix credential scheme has challenges such as its not Elliptic Curve based and it lacks hardware binding support.

note

Yivi should be able to adopt new credential schemes, such as BBS+ or Post Quantum implementations of Zero Knowledge Proof credential schemes.

Yivi builds upon our own IRMA protocol, we build this because there were no alternatives and no standards available, however reality caught up with us and now protocols like OpenID for Verifiable Presentations and OpenID for Verifiable Credential Issuance are now approaching a first stable version.

note

Yivi should be able to use industry standard protocols to improve interoperability.

Yivi's has an open-source trust scheme, with the Privacy By Design Foundatation as trust anchor. Yivi users should be able to use other trust schemes as well, in such as way that credentials from multiple trust schemes can be used to selectively disclose information.

note

Yivi should be able to be part of the Dutch EDI-stelsel, which will provide PID and PUB EAA credentials.

Europe should make the right move

We think that the adoption of BBS+ signature schemes need more attention. We acknowledge the fact that hardware binding of these signature schemes within Trusted Execution Environments or HSM's is a challenge, but workarounds are available.

There have been modifications of BBS+ such as BBS# that make BBS Anonymous Credentials eIDAS 2.0 Compliant. Lots of effort is put into this from Orange Open Source. Essentially BBS# is a modification of BBS+ allowing group signatures and selective disclosure based on ECDSA.

However, there is a long road ahead of integrating these signature schemes within the ARF, but we greatly support the work Orange has been doing.

Vision - The road ahead

We have intentionally waited for the ARF and related standards to stabilize. Premature adoption would have resulted in duplicated investment. Now, with a more concrete and interoperable profile emerging we think the time is right to take action.

Vision

Yivi has to become crypto agile, in the sense that Yivi supports multiple credential schemes, protocols and credential formats. We think this is the right move ahead, we preserve our privacy first implementation and make Yivi compatible with EUDI-wallet standards. It allows us to innovate together with academia on for instance Post Quantum ZKP, Digital voting, Digital watermarking, etc.

Becoming crypto agile is a multi-year effort. It will be a long-term investment which will significantly increase the interoperability of Yivi and thereby increase the usability of Yivi for organizations. We set the following milestones as a first step towards becoming an crypto agile and EUDI-wallet compliant ID-wallet.

In our continued efforts we will maintain our core principles which are:

  • We will always work open source.
  • We will always prefer the most privacy friendly solution.
  • We will never ask users to pay for the App.
  • We will stand for ethical usage of Yivi.

1. Disclose SD-JWT VC credentials over OpenID4VP.

Our first milestone is to enable the disclosure of SD-JWT VC credentials using the OpenID for Verifiable Presentations (OpenID4VP) protocol. This is a key step in becoming interoperable with the broader EUDI-wallet ecosystem. OpenID4VP is designed as a flexible carrier for multiple credential formats, and we believe it will ultimately support Idemix-based credentials as well—especially given its close relation to AnonCreds.

In fact, Yivi aims to introduce its own credential format over OpenID4VP. While Idemix remains central to our stack, we will also embrace SD-JWT VCs and eventually other formats. Issuance in the early phases will still be handled via the IRMA protocol, with enhancements including:

  • Same-device and cross-device disclosure flows
  • Key binding support using Yivi’s keyshare server

This approach allows us to retain Yivi’s strengths while offering compatibility with modern standards.

2. Issue SD-JWT VC credentials over OpenID4VCI

Once disclosure is in place, the next step is standardizing issuance. We will adopt OpenID for Verifiable Credential Issuance (OpenID4VCI) to enable issuance of SD-JWT VCs in line with Dutch and European expectations.

This will be essential for integrating with emerging national and sectoral ecosystems, such as:

  • The Dutch PID Provider
  • PuB EAA issuers like the KVK, Belastingdienst, and others

While IRMA will remain the initial method for issuance, we will build bridges to support new flows and allow identity brokers to mediate across formats. Yivi must support multiple issuance standards to remain relevant and inclusive.

3. Multi trust scheme support

The third milestone is the integration of multiple trust schemes. Currently, Yivi operates under the trust scheme of the Privacy by Design Foundation. But in a European context, users must be able to present credentials from various ecosystems—public and private—without friction.

To do this, we’ll begin aligning with the EUDI trust model, closely observing the architectural direction of the NL Public Reference Wallet. Topics under research include:

  • Relying Party (RP) registration and attribute catalog publishing
  • RP authentication using X.509 certificates
  • Lifecycle management of wallet instances and binding to specific devices
  • Compatibility with Dutch and EU-level schemes, including integration with EDI-stelsel for PID and PuB credentials

Trust scheme pluralism is critical to maintaining Yivi’s openness, and we will ensure that users can fluidly operate across ecosystems while remaining in full control of their data.

Conclusion: Privacy First, Future Ready

Our journey toward EUDI-wallet compliance is a long-term commitment. It is not merely about ticking regulatory checkboxes rather it's about preserving the right to privacy in a digitized European society. Yivi will continue to lead by example—through open innovation, ethical technology, and a relentless pursuit of user empowerment.

By becoming crypto-agile and aligning with emerging European standards, we reaffirm our founding belief: Digital identity should not come at the cost of privacy.

References

OpenID for Verifiable Presentations - Editor's draft https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html

OpenID for Verifiable Credential Issuance - Editor's draft https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html

OpenID4VC High Assurance Interoperability Profile https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0-03.html

SD-JWT-based Verifiable Credentials (SD-JWT VC) https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/

Topic G: Zero Knowledge Proof #408 https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/408

Privacy shall be at the heart of ARF #192 https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/192

BBS# and eIDAS 2.0 https://csrc.nist.gov/csrc/media/presentations/2024/wpec2024-3b3/images-media/wpec2024-3b3-slides-antoine-jacques--BBS-sharp-eIDAS2.pdf

The BBS# protocol https://github.com/user-attachments/files/19198669/The_BBS_Sharp_Protocol.pdf

Scheme manager Migration Announcement

· 3 min read
Martijn Kamphuis
Lead Developer @ Caesar Groep

We want to inform you about a slight change in the planning, with the following impact for IRMA-server administrators:

  • 30-04-2025: The scheme URL inside the scheme itself will be updated. If automatic scheme update is enabled on your server, this will automatically switch your server to use the new URL.
  • If you are behind a firewall, please make sure the new domain and/or IP is whitelisted before April 30th and keep the old Privacy By Design domain and/or IP whitelisted until at least May 14th.

Scheme manager migration announcement

We would like to inform our community of an upcoming change with regards to the Yivi/IRMA scheme manager. This change will impact every IRMA-server currently running. Please read below for further details.

As part of our ongoing efforts to enhance resiliency and reliability, we will migrate the scheme manager to our next-generation infrastructure. Currently, all IRMA-server instances and mobile apps rely on the Yivi scheme manager, which forms the foundation of our trust model. At present, the scheme manager is hosted on infrastructure without failover capabilities. To improve robustness, we will move it to our reliable, European sovereign cloud hosting environment.

Because of this change, the URL and IP to the scheme manager will change in the near future and we ask you to update your instance(s) of the IRMA-server.

Timeline overview

The complete timeline of this change will look like this:

  • Setup Yivi hosting environment for scheme manager. (done)
  • 08-04-2025 (today): Setup proxy from the old environment to the new environment. (this change will have no impact on current IRMA-server installations)
  • 09-04-2025: IRMA-server release with new scheme manager URL. At the same time, a mobile app update will be released for the beta program.
  • 14-05-2025: The old URL will no longer be available. All IRMA-servers and mobile apps need to have been updated to the latest release.

Because of the change in URL and IP, we ask you to take the steps written out below.

1. Add whitelisted domain/IP-addresses

If your organization uses firewalls with whitelisted domains and/or IP-addresses for outbound traffic, please add the domain and/or IP-addresses below. If you are not sure if this is the case for you, please contact your network administrator. If you are sure you don’t need whitelisting, you can skip this step. Please make sure to have both settings active before upgrading the IRMA-server. Once the updated IRMA-server is running steadily for a while, you can remove the old settings.

Old settingsNew settings
Domainhttps://privacybydesign.foundation/schememanager/https://schemes.yivi.app/
IPv437.97.206.7051.158.130.42
IPv6*n.a.2001:bc8:1640:3c32::

*) Note: the IPv6 address is already reserved, however it is not in active use yet. Once it is, we will notify about it on our blog.

2. Update the IRMA-server

After you’ve made sure you can reach the new domain (after the firewall changes, in case you require them), you are ready to update the IRMA-server to version v0.18.0. Please review the release notes in case you need to skip one or more version for this update.

We kindly ask you to plan this update and execute the update to v0.18.0 before May 14th.

Should you have any questions regarding this update, please feel free contact us at support@yivi.app.

📢 Important notice Keyshare server migration

· 3 min read
Dibran Mulder
CTO @ Caesar Groep

In the night of March 17th to 18th, 2025, at 01:00 CET, we will complete the final phase of the migration from SIDN to Caesar Groep. The last two components that require temporary downtime are the Keyshare Server and MyYivi. These systems play a crucial role in Yivi's authentication and identity management services, and we want to ensure a smooth transition with minimal disruption.

Migration Plan

To ensure a seamless transition, we have prepared the following steps:

  • Yivi App Update - March 11th, 2025
    • A Yivi App release will update the Keyshare Server endpoint from https://irma.sidn.nl/tomcat/irma_keyshare_server to https://keyshare.yivi.app.
    • The trust scheme will be changed to use the new Keyshare Server.
    • During this transition, https://keyshare.yivi.app will act as a reverse proxy to the existing SIDN Keyshare Server, ensuring uninterrupted service.
  • Final Migration - March 18th, 2025
    • At 01:00 CET, the SIDN Keyshare Server will be shut down.
    • The Keyshare database will be migrated to our new infrastructure.
    • The reverse proxy at https://keyshare.yivi.app will be removed and traffic will be routed to , and the new Keyshare Server will be brought online.
    • The DNS for irma.sidn.nl will be updated to redirect users who have not yet updated their app to the new environment.

Expected Impact

There is no expected impact regarding the Yivi App update on the 11th of March.

There is approximately 1 hour of expected downtime for users in the night of the 17th-18th of March Users will receive errors when entering the pin in Yivi.

What can you do?

Organizations using Yivi should take the following steps to mitigate potential issues:

  • Verify Integrations: Ensure all integrations with Yivi services continue to function correctly after the migration.
  • Inform Users: Notify your users about the scheduled downtime to manage expectations and reduce support requests.

Contact and Support

If you have any questions or experience issues during the migration, please reach out to us:

📧 Email Support: support@yivi.app

📢 Status Updates: We will post updates on this blog.

We appreciate your cooperation and patience during this transition. Thank you for using Yivi

Overview of migrated services

ResourceOld LocationNew LocationMigration Date
Mailyivi@caesar.nl and noreply@sidn.nlsupport@yivi.app and noreply@mail.yivi.app✅ Ready
SMS Issuerhttps://sidnsmsissuer.yiviconnect.nl/issuance/smshttps://sms-issuer.yivi.app🚀 Live
Email Issuerhttps://sidnemailissuer.yiviconnect.nl/issuance/emailhttps://email-issuer.yivi.app🚀 Live
iDIN Issuerhttps://privacybydesign.foundation/uitgifte/idin/https://idin-issuer.yivi.app🚀 Live
Attribute Indexhttps://privacybydesign.foundation/attribute-index/en/https://attribute-index.yivi.app🚀 Live
Atumd Serverhttps://irma.sidn.nl/atumd/https://atumd.yivi.app🚀 Live
Docshttps://irma.app/docshttps://docs.yivi.app🚀 Live
Demoshttps://privacybydesign.foundation/demo/https://demos.yivi.app🚀 Live
YiviConnectURL remains unchangedURL remains unchanged🚀 Live
open.yivi.appURL remains unchangedURL remains unchanged🚀 Live
Keyshare Serverhttps://irma.sidn.nl/tomcat/irma_keyshare_serverhttps://keyshare.yivi.app⚠️ 18th of March
MyYiviURL remains unchangedURL remains unchanged⚠️ 18th of March

User experience improvements in Yivi

· 5 min read
Wouter Ensink
Developer @ Caesar Groep
Jasper van der Linden
Developer @ Caesar Groep

One of the main goals for Yivi is to become the worlds most user friendly identity wallet. We've already done a lot to help this cause, like allowing the user to directly start issuing missing credentials while they're trying to dislose so they stay in the flow.

In this blog we'll look ahead at some of the plans we have for the near future to improve the user experience.

Our four values for UX

To keep our goals clear and keep an eye on the usefulness of new features, we've written down our main values for the UX. These values are:

  • Accessible
  • Understandable
  • Trustworthy
  • Beautiful

Accessible means that we're committed to making Yivi a good experience for everyone.

Understandable means that Yivi should feel familiar and usable to everyone.

Trustworthy is not just about using the most reliable protocols. It's also about conveying that to the user and letting them feel like they can trust Yivi, issuers and verifiers. Things that fall into this category are imagery, colors and clear explanations.

Beautiful is not as important as the others, but the eye wants something too. Things like consistent color, fonts and styling combined with fluid animations is what gives Yivi just that extra touch.

Our plans for the near future

There are four UX improvements that we want to work on over the next couple of months:

  • Getting compliant with European Accessibility Act
  • QR code scanner button on the login page
  • Easier card organisation and navigation
  • Brand extensions

Let's have a look at each of them.

Getting compliant with European Accessibility Act (EAA)

The EAA is a directive that aims to improve the functioning of the internal market for accessible products and services, by removing barriers created by divergent rules in member states of the European Union.

It applies to products and services that have been identified as being most important to people with disabilities. Yivi aims to be one of those products and therefore should comply with this act.

For digital products, like Yivi, this means having to comply with the Web Content Accessibility Guide (WCAG) version 2.1 level AA.

Requirements include:

  • Big enough touch targets
  • Big enough contrast ratios
  • Support for screen readers
  • Alt text for visual media
  • Support for large text
  • And more

A complete overview can be found here.

We plan to adhere to these standards by assessing our current state and make improvements accordingly. Recently we've improved our screen reader support by adding better descriptions and hiding some distracting items from the screen reader with this pull request.

Automatic tests will be introduced to make sure our Flutter code adhears to the touch target and contrast ratio requirements set by WCAG.

We encourage users to let us know what they think and how we can improve the experience for them.

QR code scanner button on login page

For Yivi to be understandable it helps to feel familiar to some degree. Lots of banking apps, at least in The Netherlands, have a quickly accessible QR code scanner button on the login page that users can press even before entering their pin. The pin code then needs to be entered to confirm the action the user wants to take based on the scanned QR code. For banking apps that would most likely be transfering money.

Our plan is for Yivi to also support this flow. The user can quickly scan a QR code by pressing the button on the login page and then enter the pin afterwards to continue with the issuance or disclosure.

Progress on this feature can be followed here.

Easier card organisation and navigation

We've received feedback from some of our users that the navigation and organisation of the cards inside the wallet is not optimal. Right now there's just a list of cards, categorized based on the Category field in the scheme and nothing more. There's no way to sort, organize or navigate these cards.

When a user has just a few credentials this is not a big issue, but when the list grows larger, finding the card you're looking for becomes harder and harder.

To solve this problem, we're planning to make the list editable and add search functionality. Editable means the user will be able to select, move and delete credentials.

Sorting based on time and name is also something we're looking at, but it's important to not let that interfere too much with custom ordering.

Brand extensions

To build a level of trust, imagery and branding is important. As of now, credentials inside the Yivi app are plain, white cards with a name and a small logo for the issuer. To feel more authentic, it would be nice if issuers had more control over what their card will look like. The credential containing your ID information could for example look like your actual ID card.

We do need to consider what this means for usability, as the cards will most likely be taller than they are now and that could make the list a lot longer.

The card image itself could contain some of your personal data in the form of some kind of SVG template. We need to keep in mind that not all of your data may fit on the card itself and not everyone will be able to read those details from the image itself.

As for the technology, we're considering using the SD-JWT VC SVG template system as a basis.

We would like to get feedback from our issuers to see if this is something they would want, and if so, what features they'd want out of it.

Closing up

So that's it for now. We'd love to hear from you about what you think about these plans and what other features you'd like to see in Yivi.

📢 Important notice Keyshare server migration

· 3 min read
Dibran Mulder
CTO @ Caesar Groep

In the night of March 17th to 18th, 2025, at 01:00 CET, we will complete the final phase of the migration from SIDN to Caesar Groep. The last two components that require temporary downtime are the Keyshare Server and MyYivi. These systems play a crucial role in Yivi's authentication and identity management services, and we want to ensure a smooth transition with minimal disruption.

Migration Plan

To ensure a seamless transition, we have prepared the following steps:

  • Yivi App Update - March 11th, 2025
    • A Yivi App release will update the Keyshare Server endpoint from https://irma.sidn.nl/tomcat/irma_keyshare_server to https://keyshare.yivi.app.
    • The trust scheme will be changed to use the new Keyshare Server.
    • During this transition, https://keyshare.yivi.app will act as a reverse proxy to the existing SIDN Keyshare Server, ensuring uninterrupted service.
  • Final Migration - March 18th, 2025
    • At 01:00 CET, the SIDN Keyshare Server will be shut down.
    • The Keyshare database will be migrated to our new infrastructure.
    • The reverse proxy at https://keyshare.yivi.app will be removed and traffic will be routed to , and the new Keyshare Server will be brought online.
    • The DNS for irma.sidn.nl will be updated to redirect users who have not yet updated their app to the new environment.

Expected Impact

There is no expected impact regarding the Yivi App update on the 11th of March.

There is approximately 1 hour of expected downtime for users in the night of the 17th-18th of March Users will receive errors when entering the pin in Yivi.

What can you do?

Organizations using Yivi should take the following steps to mitigate potential issues:

  • Verify Integrations: Ensure all integrations with Yivi services continue to function correctly after the migration.
  • Inform Users: Notify your users about the scheduled downtime to manage expectations and reduce support requests.

Contact and Support

If you have any questions or experience issues during the migration, please reach out to us:

📧 Email Support: support@yivi.app

📢 Status Updates: We will post updates on this blog.

We appreciate your cooperation and patience during this transition. Thank you for using Yivi

Overview of migrated services

ResourceOld LocationNew LocationMigration Date
Mailyivi@caesar.nl and noreply@sidn.nlsupport@yivi.app and noreply@mail.yivi.app✅ Ready
SMS Issuerhttps://sidnsmsissuer.yiviconnect.nl/issuance/smshttps://sms-issuer.yivi.app🚀 Live
Email Issuerhttps://sidnemailissuer.yiviconnect.nl/issuance/emailhttps://email-issuer.yivi.app🚀 Live
iDIN Issuerhttps://privacybydesign.foundation/uitgifte/idin/https://idin-issuer.yivi.app🚀 Live
Attribute Indexhttps://privacybydesign.foundation/attribute-index/en/https://attribute-index.yivi.app🚀 Live
Atumd Serverhttps://irma.sidn.nl/atumd/https://atumd.yivi.app🚀 Live
Docshttps://irma.app/docshttps://docs.yivi.app🚀 Live
Demoshttps://privacybydesign.foundation/demo/https://demos.yivi.app🚀 Live
YiviConnectURL remains unchangedURL remains unchanged🚀 Live
open.yivi.appURL remains unchangedURL remains unchanged🚀 Live
Keyshare Serverhttps://irma.sidn.nl/tomcat/irma_keyshare_serverhttps://keyshare.yivi.app⚠️ 18th of March
MyYiviURL remains unchangedURL remains unchanged⚠️ 18th of March