The Wallet versions 1.17 are in the pipeline and should be available in the app stores next week. With this release, the wallet enables or enforces security requirements of the Swiss Profiles 1.0.

• Enforce Payload Encryption
• Enforce Signed Metadata (see Change Dossier)
• Enablement of DPoP (for the enforcement on Issuer-side see Change Dossier)

Please note, that the Sandbox Wallets are now available (iOS: Link in the readme, Android: APK in latest release) and the onboarding to the sandbox environment is released (see below).

New Onboarding Flow

The onboarding for the Sandbox environment is open for organizations and gov actors in a first place. New DID’s must be created with new standard (and new toolbox version).

DID Toolbox and DID Resolver

The latest DID Toolbox 2.3.0 and DID Resolver 2.9.0 have been expanded to support EdDSA.

• Expand DID log creation and updating to support Ed25519 keys as verification material
• Expand cryptographic algorithms for proof of possession creation and verification with Ed25519
• Resolver now supports Ed25519 public keys as JWK as verification methods

Latest Generic Components

The latest versions of the generic components are swiyu Generic Issuer 4.1.0 and swiyu Generic Verifier 4.1.2. We recommend to update to the latest swiyu Generic Verifier where we fixed a security vulnerability. You’ll find an overview of new features and links to the migration guides for the 4.x versions in this earlier announcement.

Swiss Profile Proximity

The specification for peer-to-peer proximity verification “Swiss Profile Proximity” has been published.

Component Versions - New Overview

On the swiyu Technical Documentation Website we have recently started providing an overview of the lifecycle of the components from the swiyu Trust Infrastructure.

Generic Verifier Version 4.1.2

• 🚨 Critical vulnerability fix VC Authorization Bypass, upgrade ASAP
• Trust validation is now bound to the DID from the kid header (actual signer) instead of the iss claim
• See Change Dossier CD-008 for full details on the vulnerability, root cause, and timeline
• For more details, please refer to the changelog

There are no breaking changes associated with this fix, so no specific migration steps are necessary.

The swiyu Trust Infrastructure is a living ecosystem. As we continue to harden the protocol, close security gaps, and evolve the trust model, we will from time to time need to make changes that affect how generic Issuers, generic Verifiers, Wallet providers, and other integrators interact with the infrastructure. Some of these changes will be additive and non-breaking. Others, by necessity, will be breaking.

To make these changes transparent, predictable, and manageable for everyone building on swiyu, we are introducing Change Dossiers (CD): standardized announcements published to the ecosystem whenever a change to the Trust Infrastructure requires action on the part of integrators.

Each Change Dossier will clearly state:

• What is changing and why
• Which components are affected (DID Resolver, generic Issuer, generic Verifier, Wallet, Status Registry, Trust Registry, etc.)
• What action is required, and from whom
• The migration steps to follow
• The timeline, including key dates

Our approach: Expand, Migrate, Contract

Wherever technically possible, changes to the Trust Infrastructure will follow the EMC pattern (Expand, Migrate, Contract):

1. Expand the new behavior, field, endpoint, or capability is introduced alongside the existing one. Nothing is removed yet, and existing integrations continue to work unchanged.
2. Migrate the ecosystem is given a defined window to adopt the new behavior. This is the phase Change Dossiers are published for, and where we provide guidance, migration steps, and support.
3. Contract once the migration window has passed, the old behavior is retired.

This pattern allows us evolve the Trust Infrastructure without forcing integrators into rushed, unplanned rework. It allows us manage our own contracting work in a predicatble manner and avoids breaking the ecosystem.

Timelines: three months, by default

For changes of meaningful scope, anything that requires integrators to adapt their implementation, our standard commitment is to give the swiyu ecosystem at least three months between the publication of a Change Dossier and the point at which the old behavior is contracted (retired). This is intended to give teams enough time to plan, implement, test, and roll out their migration in a controlled way, rather than reacting under time pressure.

The exception: critical security vulnerabilities

There is one deliberate exception to this rule: critical security vulnerabilities. If we identify a vulnerability in the Trust Infrastructure that poses a serious risk to the ecosystem, we will not wait three months to fix it. In such cases:

• A fix may need to be deployed on a significantly shorter timeline.
• The fix may, in some cases, be breaking, because the risk of leaving a critical vulnerability open outweighs the cost of a shortened migration window.
• We will still use a Change Dossier to communicate the change as clearly and as early as circumstances allow, but the standard three-month notice period does not apply.

We don’t take this exception lightly, and we’ll continue to give as much notice as the security situation reasonably allows, but the safety of the ecosystem as a whole takes priority over migration convenience in these cases.

What this means for you

Watch for Change Dossiers on this site, each one will tell you exactly what’s changing, whether it affects your component(s), and what to do about it. For standard (non-security) breaking changes, you can expect a minimum three-month runway from publication to the change taking effect. For critical security fixes, please treat Change Dossiers as high priority and act promptly.

We believe this approach gives the swiyu ecosystem the transparency and predictability it needs, while allowing us to keep the Trust Infrastructure secure and moving forward.

Generic Issuer Version 4.0.1

• Status list tokens (statuslist+jwt) now include a ttl claim and proper exp/iat timestamps derived from the application.status-list properties. This allows operators to control how long published status lists are considered valid and how long cached status list entries are retained by the wallet.
• Expanded enc_values_supported to allow A256GCM encryption in addition to A128GCM.
• Removed the vars SWIYU_TRUST_REGISTRY_CUSTOMER_KEY and SWIYU_TRUST_REGISTRY_CUSTOMER_SECRET as they are not required by the read-only trust registry.
• Removed support for claims in credential_configurations_supported details for claims can now be found in credential_metadata.claims instead as announced earlier. Please update your metadata accordingly.
• Removed vct#integrity from issuer metadata as it is no longer used -> use vct_metadata_uri and vct_metadata_uri#integrity instead.

Please refer to the Changelog for a complete overview of new features and changes and the Migration Guide 3.2 to 4.0 for more details.

Generic Verifier Version 4.0.1

• Removed the client_id_scheme from the application configuration as it is no longer used and replaced by the client_id_prefix configuration property with default value decentralized_identifier, which can be changed or set to null. Therefore, the client_id will be ${client_id_prefix}:${client_id}.
• Removed the vars SWIYU_TRUST_REGISTRY_CUSTOMER_KEY and SWIYU_TRUST_REGISTRY_CUSTOMER_SECRET as they are not required by the read-only trust registry.
• oauthState must be sent in verification response otherwise the verifier rejects the response.
• Fetching an expired Verification Management Object will now return an error instead of returning it one last time.
• Uses A256GCM instead of A128GCM for encryption.

Please refer to the Changelog for a complete overview of new features and changes and the Migration Guide 3.0 to 4.0 for more details.

Source Code and Changelog for latest swiyu Wallet Releases

• The source code for the latest swyiu Wallet releases for Android (hotfix) and iOS is published.
• The full changelog is available under the version 1.16.0 for Android and iOS.
• The new generic components are compatible with these versions.

New swiyu Wallet Releases Version 1.16.0

With this release, we have aligned the version numbers. This means that we have skipped Android 1.15 and both wallets are now on version 1.16. The most important changes are, as previously announced:

• EMC-Expand for new Credential Format “dc+sd-jwt”
• Enforce DCQL Presentation (DIF presentation exchange is no longer supported)
• EMC-Expand for new DID standard and Swiss Profile Versioning
• Invalid Credentials can no longer be presented

Both versions are compatible with the swiyu Generic Issuer version 3.1.1. and higher. If you are using the swiyu Generic Issuer version 3.2.x DPoP has to be deactivated manually (APPLICATION_DPOP_ENFORCE: false).

Beta Credential Service (BCS)

We have deployed a new version of the BCS to the Public Beta/Sandbox environment. The most relevant changes are:

• Integration of swyiu Generic Issuer 3.2.4
  • Payload encryption is configured to be mandatory
  • DPoP enforcement is deactivated
• Integration of swiyu Generic Verifier 3.0.2
  • Response mode for verifications has been changed from “direct_post” to “direct_post.jwt”, as a consequence, payload encryption is activated
• New vct “ch.admin.bcs.betaid” is activated

swiyu Generic Issuer Version 3.2.4

• Security fixes and updated dependencies
• For more details, please refer to the changelog

We provide a Migration Guide 3.1 to 3.2 and also as previously announced from 2.4 to 3.0.

swiyu Generic Verifier Version 3.0.3

• Security fixes and updated dependencies
• For more details, please refer to the changelog

Test Application and Test Wallet

We provide two test repositories with components to validate the behavior of the swiyu Generic Issuer and swiyu Generic Verifier, without relying on a full trust infrastructure or real wallets.

• The Generic Application Test is a test system designed to run end-to-end (E2E) tests against the generic swiyu Issuer and Verifier components.
• The swiyu Generic Test Wallet is a web application that simulates a wallet to test credential issuance and verification flows based on OIDC4VCI and OIDC4VP.

Roadmap

Due to the postponement of the internal trial phase, the roadmap is being revised. We will announce the new dates as soon as possible on this channel.

Component Compatibility Overview

We adjusted the overview with the updated versioning of the swiyu Android Wallet:

• Enforce DCQL, Contract DIF presentation
  • swiyu Wallet 1.16
  • swiyu Generic Verifier 3.0
• Allow SD-JWT to contain structured nested data to selectively disclose a single element of an array
  • swiyu Wallet 1.16
  • swiyu Generic Verifier 3.0
• Expand-Migrate for new credential format
  • swiyu Wallet 1.16
  • swiyu Generic Issuer 3.2
• Enforcement of JWT-Secured Authorization Request (JAR)
  • swiyu Wallet 1.16
• DPoP implementation
  • swiyu Wallet 1.16
  • swiyu Generic Issuer 3.0 (for versions 3.2 and higher, please note the manual deactivation mentioned above)
• Contract OCA overlays
  • swiyu Wallet 1.17
• Expand-Migrate to Trust Protocol 2.0
  • swiyu Wallet 1.18
  • swiyu Generic Issuer 3.1
  • swiyu Generic Verifier 3.0
• Security Enforcements (Signed Metadata, Payload encryption, Status List)
  • swiyu Wallet 1.18
  • swiyu Generic Issuer 3.2
• Finalization Swiss Profiles 1.0 (Metadata, configurations)
  • swiyu Wallet 1.18
  • swiyu Generic Issuer 3.3
• Enforce Key Attestation for Hardware Binding
  • swiyu Generic Issuer 3.3

Generic Issuer Version 3.2.0

• OID4VCI Credential Format: Newly issued SD-JWT VCs now use typ: dc+sd-jwt
• Configuration: Some defaults have changed with the evolving ecosystem
  • Enabled signed metadata by default
  • Require Encryption to be used by default
  • Require DPoP to be used by default
• Hardened Docker Image

Please refer to the changelog for a complete overview of new features and changes.

We provide a Migration Guide 3.1 to 3.2 and also as previously announced from 2.4 to 3.0.

Generic Verifier Version 3.0.0

• EMC-Expand for Trust Protocol 2.0
• EMC-Expand: Documentation and examples updated to use dc+sd-jwt as the canonical SD-JWT VC media type
  • The verifier continues to accept vc+sd-jwt on the credential typ header during the migration window
• Renamed the configuration property application.accepted-status-list-hosts to application.accepted-registry-hosts
• Dropped support for unsigned request objects (not supported by Swiss Profiles 1.0 anymore)
• Dropped support for SWIYU-API-Version 1, which was using DIF Presentation Exchange. Now only DCQL can be used for verification as defined in OID4VP 1.0
• Migration to Spring Boot 4.0.6 (Spring Framework 7)

Please refer to the changelog for a complete overview of new features and changes.

Roadmap

The roadmap shows the current plan and is not binding. The dates and contents of new releases will be communicated on this channel as early as possible.

July

• Wallets ((Android 1.16 and iOS 1.17)¹)
  • Remove support for OCA Overlays label
  • Minimal version of Android will be Android 12

August

• New Onboarding Flow (later as previously announced)
• Wallets (Android 1.17 and iOS 1.18))¹
  • Finalization Swiss Profiles 1.0 (Metadata, configurations)
  • Security Enforcements (Signed Metadata, Payload encryption, Status List)
  • Trust Protocol 2.0

Component overview

• Enforce DCQL, Contract DIF presentation: iOS 1.16, Android 1.15, swiyu-verifier 3.0
• Allow SD-JWT to contain structured nested data to selectively disclose a single element of an array: iOS 1.16, Android 1.15, swiyu-verifier 3.0
• Expand-Migrate for new credential format: iOS 1.16, Android 1.15, swiyu-issuer 3.2
• Enforcement of JWT-Secured Authorization Request (JAR): iOS 1.16, Android 1.15
• DPoP implementation: iOS 1.16, Android 1.15, swiyu-issuer 3.0
• Contract OCA overlays: iOS 1.17, Android 1.16
• Expand-Migrate to Trust Protocol 2.0: iOS 1.18, Android 1.17, swiyu-issuer 3.1, swiyu-verifier 3.0
• Security Enforcements (Signed Metadata, Payload encryption, Status List): iOS 1.18, Android 1.17, swiyu-issuer 3.2
• Finalization Swiss Profiles 1.0 (Metadata, configurations): iOS 1.18, Android 1.17, swiyu-issuer 3.3
• Enforce Key Attestation for Hardware Binding: swiyu-issuer 3.3

New Wallet versions Android 1.15. and iOS 1.16.

With the upcoming wallet releases, we proceed further steps towards the Swiss Profiles v1.0:

• EMC-Expand for new Credential Format
• Enforce DCQL Presentation
• With the enforcement of DCQL, we also fix the issues “Prevent bypassing vct filter rule” and “DIF presentation can send wrong data”
• EMC-Expand for new DID standard and Swiss Profile Versioning (see below)
• Invalid Credentials can no longer be presented

Edit: the contract step for the OCA overlays will be in a future release

“Sandbox” Wallet available in App Stores

As the governance measures for the Public Beta differ from those for the future production environment, a dedicated “sandbox” wallet for the Public Beta environment will be available in the app stores. The present swiyu wallet will be restricted over the coming months to the productive environment. Existing credentials must be reissued into the sandbox wallet.

DID Toolbox

• New standard did:webvh as specified in the Swiss Profile Anchor 1.0
• Swiss Profile Version in DID Log
• New DID’s created with did:webvh must be resolved with the new DID-Resolver
• More details will be available in the changelog
• We’ll update our documentation accordingly

DID Resolver

• New standard did:webvh as specified in the Swiss Profile Anchor 1.0
• More details will be available in the changelog

New onboarding flow

By the end of June, we’ll provide new cookbooks and the new flows for the onboarding to our registries.

• New DID’s must be created with new standard (and new toolbox version)
• Old DID’s are still listed in the registries and VC’s still work
• The cookbook for the onboarding the swiyu Base & Trust registry will be updated

VC migration

Also by the end of June, we will provide new generic components (swiyu-issuer and swiyu-verifier) as well as a guide for the migration to the Swiss Profile VC 1.0.

Planned System Outages on 25 June

Due to internal system recovery tests, there may be disruptions of the swiyu Public Beta infrastructure on Thursday, 25 June 2026. You can find information about system outages in our System Status Channel.

Swiss Profile Trust and Trust Protocol

With the Swiss Profile Trust V1.0 we introduce Trust Artefacts for different use cases.

• The corresponding versions of the swiyu-issuer and swiyu-verifier should be available by end of May 2026
• The corresponding “Sandbox” wallet version (see below) should be available by beginning of June 2026

All related relevant issues are referenced in this roadmap feature.

Swiss Profile Anchor

Actors within the swiyu ecosystem will have to re-onboard with the DID method DID:webvh with JSON as described in the Swiss Profile Anchor V1.0.

• All newly created DID documents must contain JSON claim “profile version”.
• With the release of the new Onboarding Flow, old DIDs can no longer be created (estimated for end of June 2026).
• Old DID’s can no longer be updated (estimated for end of October 2026)

All the relevant steps for the migration are referenced in this roadmap feature.

Swiss Profile Issuance

The Swiss Profile Issuance V1.0 defines the capabilities required to issue Verifiable Credentials to a holder’s wallet supporting the OID4VCI V1.0 standard. Relevant changes include:

• The credential changes from vc+sd-jwt to dc+sd-jwt
• The enforcement of the security requirements (Payload Encription, Signed Metadata, DPoP)

All the relevant steps for the migration are referenced in this roadmap feature.

Swiss Profile Verification

The Swiss Profile Verification V1.0 concerns itself with how a wallet is presenting VCs to a verifier. Upcoming “contract”-steps are:

• Support Client ID Prefixes & Remove ‘client_id_scheme’
• Enforce DCQL in iOS and Android wallet (DIF Presentation Exchange is no longer supported)
  • For interactions with the BCS: the parameter “vct_values” must contain the old and new values of the vct-claims (“betaid-sdjwt” und “urn:vct:ch.admin.bcs.betaid”)
• Enforce Payload Encryption and Signed Metadata in iOS and Android wallet

All the relevant steps for the migration are referenced in this roadmap feature.

Wallets: Separation of Public Beta/Sandbox and Production

As the governance measures for the Public Beta differ from those for the future production environment, a dedicated ‘sandbox’ wallet for the Public Beta environment is expected to be available from the beginning of June 2026.

Swiss Profile VC

The new generic issuer and generic verifier for the Swiss Profile VC 1.0 should be available by the end of June 2026. The respective wallet version should be released by September 2026. Together with the new components we will adjust our documentation and provide guidance for the VC migration.

Roadmap, Status Board and Release Notes

Our roadmap shows a high-level overview of the upcoming features. The status board provides a more detailed overview of which tasks are still in the backlog, which are currently being worked on, and which are ready for rollout. In the release notes (in this channel) you’ll find the concrete EMC-steps and links to migration guides.

We will provide a component-related view for the migration for issuers and verifiers in the next participation meeting on 4 June 2026.

A new version of the Beta Credential Service (BCS) is expected to be installed in the first week of May. This new version includes the next steps in the development of ‘Swiss Profile 1.0’. This release requires the upcoming swiyu Wallet versions iOS 1.15.0 and Android 1.14.0 and is not backwards compatible with older versions of the swiyu Wallet. To avoid breaking changes, we ask the community to migrate to the latest components.

As various adjustments to the infrastructure will also be made during the installation of the new release, the Beta Credential Service will only be available to a limited extent on that day. We will announce the date in the System Status channel page.

Release Notes BCS:

• New vct metadata claims: (vct_version, vct_metadata_uri, vct_metadata_uri#integrity)
• Issuer metadata extended to include a new element ‘credential_metadata’, which contains the information ‘display‘ and ‘claims’ (more details here)
• Major upgrade to swiyu-issuer 3.0.3
  • for more details, please refer to the notes about the swiyu Generic Issuer below
• Minor upgrade to swiyu-verifier 2.3.3
• Optional payload encryption during issuance

Please note our prior announcement about the potential breaking change with the next wallet releases. You’ll find more details about the changes in the changelog.

swiyu Generic Issuer Version 3.0.3

New major release for the swiyu Generic Issuer for the implementation of the OID4VCI specifications.

• Contract Steps (potentially breaking changes):
  • Removed c_nonce from OAuthTokenDto the nonce can be retrieved from the nonce endpoint.
    • The nonce column from credential_offer table is also removed.
  • Removed Deprecated OID4VCI Draft 13 Endpoints
  • Removed support for did:jwk, as it is not part of the swiss-profiles anymore
• Use OID4VCI 1.0 compliant error codes for credential_endpoint and deferred_credential_endpoint error responses.
• Validation uses now the credential_metadata.claims as default for the validation and the claims as fallback amd don’t check surplus.
• Contracted cnf to now only provide the correct shape as defined in RFC 7800.
• When not providing any key attestation provider, no key attestations are accepted instead of all.
• For further fixes and new functions please refer to the changelog.

We provide a migration guide for the upgrade from version 2.4.x to 3.0.x.

New Specifications (available as draft)

We have updated our specifications e.g. with reference to the Versions 1.0 from OID4VCI and OID4VP, our Trust Protocol 2.0, and OCA 1.0. In order to better distinguish the different standards and versions, the initial “Interoperability Profile” has been divided into different new Swiss Profiles:

• Swiss Profile Anchor
• Swiss Profile VC
• Swiss Profile Trust
• Swiss Profile Issuance
• Swiss Profile Verification

We recommend to read the introductions for the new Swiss-Profiles and the new trust artefacts.

These specifications are a first draft, which we wanted to publish at an early stage. Once the versions are finalised, we will outline the next steps in the roadmap and announce them in this channel.