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.

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!

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.

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.

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.

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.

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.

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

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.

*) 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 14^th.

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

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​

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.

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​

Introduction​

On the 4th of February 2025, version 1.5 of the Architecture Reference Framework (ARF), a crucial document guiding the development and implementation of the European Digital Identity Framework, was released. Given its significance, we conducted an initial review to assess the impact of the changes, particularly in relation to Yivi’s implementation and alignment with the evolving EUDI Wallet ecosystem.

The changes from ARF 1.4 to ARF 1.5 are substantial, introducing new concepts and refining existing ones. Additionally, the list of topics planned for the next version is extensive, covering various key aspects of interoperability, privacy, and security. Looking further ahead, ARF 2.0 is expected to introduce major architectural shifts, likely setting the stage for more definitive long-term structures within the ecosystem.

At Yivi, we are closely following the developments of the ARF and the broader EUDI Wallet ecosystem, ensuring that our roadmap remains aligned with emerging standards and regulatory requirements.

Authentication and identification are critical components of digital services. This can be done with Yivi, our privacy-friendly ID-Wallet. It provides multiple options for verifying user identities. However, a significant challenge in implementing Yivi is the identifier used for authentication. Government and healthcare organizations can use the BSN (Burger Service Nummer), but private entities must explore alternative options. Below, we discuss potential authentication methods using Yivi, their advantages, and their limitations.

Authentication and Activation Using BRP Data​

For registration purposes organizations often need a set of data to match the user to their own administration, this is often done by matching on data from the Dutch Personal Records Database (BRP). The data in the BRP is of such quality that it can be trusted to be correct. The challenge often is that the data of the user in the administration of verifing organization is not of the same quality. Resulting in the proces that when a user discloses its BRP information to an organization it sometimes results in a dropout. These dropsouts are a problem, because it blocks the user from identifying and thereby registering or authenticating itself. To circumvent this problem organizations often choose to either: request more data from the user, for instance an contractnumber or change the data in their adminstration to match the data from the BRP so that in a next match the user is matched correctly.

Governmental and/or Health care organizations can simply use the identifying BSN from the BRP to match a user to their administration. We often see that only the BSN is requested from the user and that the BSN is then used to call the BRP for name and address details. We are not a fan of that approach, because we think that the amount of backchannel communication about users should be reduced and that the user should be in control of what personal data is being shared with which organizaiton.

Pros​

• In most cases, unique identification is achievable.
• High quality data for registration purposes.
• No unique identifier available for non governmental/health care organizations.
• BRP data can be used to increase data quality in the administration of organizations.

Cons​

• Dropouts require additional data or manual processes which may negatively influence the user experience.
• No unique identifier is available for private sector.
• Name and/or address scans can have negative effects on performance.

Attribute Index of Municipality​

Below is the attribute index of the BRP disclosed by the municipality.

Adding email address or phone number​

In addition to BRP data organizations may want to request users to disclose their email address and/or phonenumber. It's a common practice for authentication purposes to have the email address as a unique identifier of the user. The same goes for phone number, while it has to be said that phone numbers are more often transfered to other users, especially in a business setting. In that sense an email address is more stable. In the context of registration and authentication Yivi supports the combination of multiple data sources being disclosed, this can be done with the so called condiscon feature. Verifing organizations can make a composition of attributes that they request the user to disclose. In the context of registration/identification organizations may want to compose the following session request:

{
  "@context": "https://irma.app/ld/request/disclosure/v2",
  "disclose": [
    [
      [ "pbdf.pbdf.email" ],
      [ "pbdf.pbdf.mobilenumber" ]
    ],
    [
        "pbdf.gemeente.personalData.firstnames",
        "pbdf.gemeente.personalData.familyname",
        "pbdf.gemeente.personalData.fullname",
        "pbdf.gemeente.personalData.surname",
        "pbdf.gemeente.address.street",
        "pbdf.gemeente.address.houseNumber",
        "pbdf.gemeente.address.zipcode",
        "pbdf.gemeente.address.city"   
    ]
  ]
}

In this example we request users to disclose either their email address or phone number and their name and address details, which are often required in a registration process. Once the identifying data has been added to the administration of the verifying organization a subsequent authentication request might look like this:

{
  "@context": "https://irma.app/ld/request/disclosure/v2",
  "disclose": [
    [
      [ "pbdf.pbdf.email" ],
      [ "pbdf.pbdf.mobilenumber" ]
    ]
  ]
}

There is no need to request the user's personal data for authentication purposes once the organization has stored the identifier which can be the phone number or the email address.

Pros​

• Having a separate registration and subsequent authentication flow is a well known practise in the field. It's a familiar user experience.
• Working with identifiers reduces the amount of potential login failures to nearly zero, causing practically no dropouts.

Cons​

• Disclosing data from multiple sources may result in a more complex user experience when the user does not have the data already issued at their Yivi app.

Issuing a unique identifier to the Wallet​

Organizations can enhance user authentication by issuing a unique identifier, such as a membership card, directly to users’ Yivi wallets. This approach allows users to authenticate seamlessly without repeatedly disclosing sensitive personal data. The unique identifier can be tied to an internal identifier known only to the organization, ensuring a smooth authentication experience while maintaining user privacy.

This process can be facilitated using chained Yivi sessions. Users first disclose the necessary information for registration. If any mismatches arise that prevent automatic registration, additional identifying information, such as a contract number, can be requested to complete the registration. Once a user is successfully registered, the organization can issue a Yivi credential containing the unique identifier, which can be used for subsequent authentications.

A notable example of this implementation is PubHubs, where users are issued a club membership credential that allows seamless authentication for entry and participation.

Pros​

• Provides a privacy-preserving authentication method without requiring repeated data disclosures.
• Reduces user friction in subsequent login attempts.
• Can be tied to existing internal identifiers within the organization.
• Enables a high level of security with minimal backchannel verification.

Cons​

• Chained Yivi sessions are not yet widely supported by many identity brokers such as Signicat and Ver.iD.
• Having organization specific credentials in a Wallet and using them on a subsequent authentication is not a well-known user experience yet.

Authentication Using the Yivi Wallet Instance Identifier​

Every Yivi wallet instance is associated with a unique app-ID, which is issued by the Yivi keyshare server. This identifier provides an alternative authentication mechanism that does not rely on personal attributes.

Organizations can use the app-ID as a pseudonymous identifier to authenticate users across sessions. This method provides a straightforward way to recognize returning users without requesting sensitive personal data. However, the app-ID has limitations that make it less suitable for long-term authentication.

Pros​

• Functions as a pseudonymized identifier for users, maintaining privacy.
• Enables quick and easy authentication without requiring additional attributes to be issued.

Cons​

• The app-ID is not unique across different devices or installations. For example, an iOS and an Android installation of the same user will generate distinct appid values.

Final Thoughts​

Each authentication method using Yivi presents unique strengths and challenges. The choice depends on factors such as regulatory compliance, infrastructure readiness, and user experience. Organizations must carefully assess their needs and available resources before implementing an authentication solution with Yivi.

In our effort to invest in the long-term sustainability of Yivi, we are migrating all Yivi components, including core components, away from SIDN to our reliable hosting environment. Along the way, we are addressing technical debt and implementing improvements where possible.

Additionally, we are collaborating with the Privacy By Design Foundation to migrate critical components, essential to the Yivi ecosystem, away from their servers to our hosting environment. Caesar Groep is taking charge to ensure the foundation no longer runs critical components essential to the Yivi ecosystem.

This blog post outlines the migration's impact. If you are affected in any way or have questions, feel free to contact us.

Hey everyone!

As we approach the end of 2024, our team is working hard to deliver as much progress on the project as possible. In keeping with our commitment to the community, we’re excited to share some of the improvements we’ve been working on. A lot of work has been put into getting a production grade hosting environment, but next to that we also delivered on some other areas.