Issue Verifiable Credentials for the Swiss E-ID environment on the SAP Business Technology Platform

[matthias-beeler]

Setting Up the swiyu Generic Issuer on SAP BTP

Having your ID, drivers license, professional certification, insurance confirmation all on your phone can make your life easier. With the Swiss E-ID infrastructure, that’s possible. Both government bodies and non-government organizations (reads: companies or yourself) can use the trust infrastructure of the Swiss E-ID to issue their own certificates.

Building on our first blog post on verifying the Swiss E-ID, this article now explores the next step: how to issue your own digital credentials using the swiyu Generic Issuer. If you haven’t read the verification blog yet, we recommend starting there for background on the architecture and trust model.

In this post, we walk through how to deploy the swiyu Generic Issuer – the official reference implementation for issuing verifiable credentials – on the SAP Business Technology Platform (BTP). This allows your business applications to create and deliver swiyu-compatible credentials (such as identity proofs, age confirmations, or membership cards) directly into users’ wallets. The result: a streamlined, secure, and privacy-preserving alternative to traditional ID checks or manual credentialing workflows.

Business Relevance

Many business processes require issuing credentials. For example, companies issuing digital certificates to new employees (like an employee ID), to customers (membership cards or warranties), credentials of certifications, or to minors (age-restriction certificates). This involved validating pictures of paper documents with tedious validation steps. With swiyu’s infrastructure, the Generic Issuer can create signed digital credentials that go straight into a user’s swiyu wallet; these credentials are cryptographically signed, ensuring they are tamper-proof and digitally verifiable by anyone, and crucially, empower the certificate holder to selectively decide exactly which information they share with the verifier. This streamlines workflows like HR onboarding, verification of certificates, KYC (know your customer, the identification of legal or natural persons in the financial industry), or age checks: issuing is done via trusted digital channels without disclosing extra data, since the user’s identity attributes never leave their device

Architecture

The swiyu Generic Issuer is a government-provided reference implementation bundling all the core functionality needed for credential issuance. It runs as your own server (for example on SAP BTP) with a backing database, and it interacts with the swiyu trust infrastructure. The issuer service uses a Decentralized Identifier (DID) registered in the swiyu Base Registry (holding its public keys) and is listed in the Trust Registry (for trust statements). When issuing a credential, the issuer talks to a user’s swiyu wallet via standard APIs, and to the swiyu Trust Registry to publish status updates (e.g. revocation). The holder’s wallet only releases attributes to the issuer with user consent. The overall system is illustrated below:

Figure 1: Basic architecture of the swiyu-issuer implementation on SAP BTP

Setting Up Your Own Issuer on SAP BTP

Prerequisites:

• Cloud foundry space
• PostgreSQL Entitlement
• Registered application / business on the FOITTs platform (for details see here)

Now deploy the Generic Issuer service on SAP BTP:

1. Provision Database: In the SAP BTP Cockpit (or CF CLI), create a PostgreSQL service instance in your space. Once provisioned, generate a service key to retrieve credentials (host, port, username, password) for your application.
2. Prepare Environment Variables: On your local machine, create a manifest.yml for Cloud Foundry push and a .env file (or use cf set-env) defining the needed variables. (E.g. ISSUER_ID, EXTERNAL_URL, SWIYU_PARTNER_ID, etc.)
   1. Be aware that you specify the fields of your to-issue credential in the “issuer-metadata”.
3. Status Registry Credentials: the SWIYU_STATUS_REGISTRY_* keys, tokens and URLs obtained from the API portal (customer key/secret, refresh token, OAuth token URL, status API URL).
4. Verification Methods: the DID’s verification method identifiers for status and SD-JWT signing (from the DID log). For example, DID_STATUS_LIST_VERIFICATION_METHOD must match the DID assertion key used for the status list.

1. Deploy the Issuer App: Set the Docker image for swiyu-issuer. (FOITT provides ready images on Docker Hub.) Use cf push with your manifest to deploy the issuer. After pushing, the issuer’s management API and Swagger UI will be available.
2. Initialize Status List: Before issuing any credential, the issuer must initialize a status list slot. Call the issuer’s management API endpoint  – save this URL and ID for use when issuing credentials. This step creates the on-chain slot needed to track revocations.
3. Access and Secure the API: You can explore the issuer’s endpoints using its built-in Swagger UI (e.g. at https://<your-app>/swagger-ui.html). All calls for creating offers and checking status can be tested here. For any management or production deployment, secure the API (e.g. via a fixed asymmetric key or OAuth2) to prevent unauthorized issuance. (Note: The default configuration is for experimentation; for production-grade security consult FOITT’s deployment guide.)
4. Optional: Frontend Integration: For user convenience, you may build a simple front-end (e.g. a SAP UI5 or CAP service) that interacts with the issuer API. In a PoC we integrated JWT-based authentication with a UI5 app so end-users can easily trigger and view issuance. This is not strictly required, but can streamline the UX when customers interact with the issuance flow.

Issuing Credentials

With the issuer running and initialized, you can now issue credentials. The general flow is:

• Your application triggers a credential offer: call the issuer’s POST /management/api/credentials endpoint with the credential data. This includes fields like credential_subject_data (e.g. name, birthdate) and the "status_lists" array containing the statusRegistryUrl from before.

• The response will contain a management_id and an offer_deeplink URL. The latter is a QR-code deep link for the swiyu wallet. Render this (e.g. as a QR code in your web page). When the wallet scans it, the holder sees an issuance request (prompt to accept or decline).
• Revocation/Suspension: Later, if needed (e.g. a credential should be cancelled or suspended), update its status via PATCH with credentialStatus=REVOKED or SUSPENDED. This updates the public status list so verifiers know the credential is no longer valid.

To illustrate: after issuing an offer, the terminal shows something like

{"management_id":"abc123", "offer_deeplink":"swiyu-issue://?client_id=..."}

You turn that deep link into a QR code and scan it with the swiyu wallet. The wallet then prompts the user to accept the new credential. Once accepted, the issuer marks it as ISSUED in the registry. The user’s device now holds a signed verifiable credential (e.g. their new digital e-ID).

Figure 2: Credential offer on the users swiyu-wallet

Conclusion

By following these steps, you will have your own swiyu Generic Issuer running on SAP BTP, registered as a valid issuer in the Swiss trust registry, and ready to issue QR-based e-ID credentials. In practice, this lets you integrate trusted digital credential issuance into any business process – from HR identity checks, to age verification in e‑commerce, to verification of certifications, to KYC/AML flows – without costly manual ID or document scans. All credential data remains cryptographically protected and on the user’s device, while your service simply asks the swiyu trust infrastructure to verify the issuer’s identity and handle revocations.

Next Steps: Be sure to, if you haven’t yet, check out our blog post on setting up and deploying the swiyu Generic Verifier on SAP BTP. Together, these components complete the swiyu ecosystem on SAP BTP, enabling fully digital, privacy-preserving identity and credential workflows.