Start a record
Wallet Playground · public test

What do you want the wallet to do?

Choose a task. We prepare the exchange and show what happened.

Sample data only. No account. No production or legal effect.

Ask a test wallet for family name. The person can share it or refuse.

Selected test

Ask for family name

The wallet can review, share or refuse this sample request.

Runnable preset
Information
Family name
Credential
Sample EU personal identity credential
Wallet action
Open the request or scan its QR code
Cryptography
Wallet metadata; ECDH-ES; encrypted response
Test behaviour
Valid response; strict checks
Activity record
Identifiers and outcomes; disclosed values stay out of this browser log

Creates a wallet link and QR code.

Customize this test Credential, delivery, checks and expected-failure cases

Verifier request

Compose the exchange

Start with a real wallet's metadata, or pin exact settings for an interoperability or expected-failure test.

Runnable Core available Adapter pending Runtime pending Outside ARF 3.0

Public runnable slice: ES256, P-256 ECDH-ES, A128GCM or A256GCM, SD-JWT family_name, GET JAR and direct_post.jwt. Native adds mdoc and POST request retrieval. Ed448 is catalogue-only: no signing primitive is connected yet.

1 Information
Requested information
2 Wallet and delivery

Real-wallet mode does not pin a signing algorithm. The current public preset remains available while that adapter is connected.

ARF trust identifies the relying party, its service, intended use and registered attribute scope.
Custom wallet metadata
3 Cryptography
Request signing

ARF 3.0 permits only algorithms in ECCG ACM v2. ESB algorithms use Brainpool curves and SHA-2. Brainpool P-320, Ed25519 and Ed448 are outside that ARF 3.0 baseline; non-ARF entries remain here only for explicit interoperability or expected-failure tests.

Selection order
  1. Wallet metadata decides
4 Verification and simulation
Per-check policy
Input, IACA certificate and debug request

Connect your wallet

The wallet link, QR code and observed result will appear here.

Other wallet journeys ARF 3.0 coverage and one separate experiment
ARF 3.0 · runtime pending

Use a wallet through the browser

The Digital Credentials API is a separate mandatory remote-presentation lane. Configure it above; the browser execution adapter remains pending.

ARF 3.0 · runtime pending

Present nearby

Configure the ISO 18013-5 plan above. Device engagement and NFC or Bluetooth transport remain pending.

ARF 3.0 · connection pending

Wallet to wallet

Needs explicit proximity holder and verifier modes. DIDComm is a separate Verifable capability.

Verifable experiment · separate journey

Ligero age proof

This separate experiment sits outside the standard ARF personal-identity age-attribute journey.

ARF 3.0 journey trace · interoperability evidence · FCAF unassessed.

For wallet developers and interoperability reviewers Implementations, profiles, endpoints and evidence

Built for public interoperability.

We use the same useful pattern as the France Identité Playground: identify an implementation, link its documentation, run a real test and publish a dated result. Lumoin participates in the FIDES Community. Reference, participation, certification and external test results remain distinct evidence states.

Live here

Verifable Wallet Playground

Exercise the issuer and verifier now. The test tenant reports the live state.

Run the starter test
Reference environment

France Identité Playground

The French EUDIW Unfold Playground separates implementation listings, documentation and runnable tests. We use it as an interaction-design reference.

Open the French playground ↗
Community participation

FIDES Community

Lumoin participates in the FIDES Community. This public lab makes our wallet and credential interoperability work inspectable.

About FIDES participation ↗

Publication rule: an external result is named with its date, wallet and server builds, exact profile, trust material, and terminal outcome. Community participation remains a separate evidence state from an official listing, certification or test result.

Implementation and test directory

Know which side of the exchange you are using.

The issuer and verifier are public test services. Web and Native Wallet are listed as separate implementations because their storage, assurance and supported ceremonies differ; one result never proves the other.

FI
Verifable test issuerIssues into a compatible holder wallet
OID4VCI 1.0SD-JWT VC · mdoc · VC
Live
DocsTest
FI
Verifable test verifierRequests a claim from a compatible holder wallet
OID4VP 1.0 · DCQLEncrypted direct_post.jwt
Live
DocsTest
FI
Verifable Web WalletZero-install, session-only holder runtime
Browser · .NET/WASMOID4VCI receive · credential status
Live receive
Open Web Wallet
FI
Verifable Business WalletNative product for people and represented organisations
Windows pilot · public-source release trackSee the dated product status for current capabilities
Pilot
Product and status

Test credential catalog.

Every configuration listed here is available under the test tenant. Pass the exact credentialConfigurationId string to the issue widget or directly to POST /connect/test/oid4vci/offer.

Browse all test credential configurations 5 identity · 6 product and supply-chain

Identity (PID)

Credential Format Profile / standard Selected attributes
PID — SD-JWT VC (dc+sd-jwt) verifable.identity.sdjwt.1 dc+sd-jwt SD-JWT VC / EUDI PID
  • family_name
  • given_name
  • birth_date
  • issuing_country
  • issuing_authority
PID — HAIP SD-JWT VC, key attestation (dc+sd-jwt) verifable.identity.haip.pid.1 dc+sd-jwt HAIP SD-JWT PID — key attestation required
  • family_name
  • given_name
  • birth_date
  • issuing_country
  • key_attestation (proof header)
PID — ISO 18013-5 mdoc (mso_mdoc) verifable.identity.mso_mdoc.pid.1 mso_mdoc ISO 18013-5 PID (eu.europa.ec.eudi.pid.1)
  • eu.europa.ec.eudi.pid.1 / family_name
  • eu.europa.ec.eudi.pid.1 / given_name
  • eu.europa.ec.eudi.pid.1 / birth_date
  • eu.europa.ec.eudi.pid.1 / issuing_country
PID — SD-CWT (dc+sd-cwt) verifable.identity.sd_cwt.pid.1 dc+sd-cwt SD-CWT PID (draft-ietf-spice-sd-cwt)
  • family_name
  • given_name
  • birth_date
  • issuing_country
Identity — W3C Data Integrity (ldp_vc) verifable.identity.di.1 ldp_vc W3C VC 2.0 — eddsa-jcs-2022 Data Integrity
  • name
  • description
  • issuanceDate
  • issuer (did:web)

Product passports (DPP/UNTP)

Credential Format Profile / standard Credential type
Battery passport — EU 2023/1542 (ldp_vc) verifable.dpp.battery.1 ldp_vc EU Battery Regulation (EU) 2023/1542 — eddsa-jcs-2022 Digital Product Passport (battery)
Battery passport — UNTP (vc+jwt) verifable.dpp.battery.untp.1 vc+jwt UNTP DigitalProductPassport (vc+jwt) UNTP-shaped battery DPP with BitstringStatusListEntry
Conformity credential — UNTP DCC (vc+jwt) verifable.dcc.1 vc+jwt UNTP DigitalConformityCredential (vc+jwt) Conformity attestation referencing a product
Traceability event — UNTP DTE (vc+jwt) verifable.dte.1 vc+jwt UNTP DigitalTraceabilityEvent (vc+jwt) EPCIS supply-chain event referencing a product
Identity anchor — UNTP DIA (vc+jwt) verifable.dia.1 vc+jwt UNTP DigitalIdentityAnchor (vc+jwt) Register authority binds an organisational DID
Facility record — UNTP DFR (vc+jwt) verifable.dfr.1 vc+jwt UNTP DigitalFacilityRecord (vc+jwt) Facility registrar binds facility id to location and operator

DPP credentials (verifable.dpp.*) require a product to be issued first through the Playground — the credential is issued from an existing passport record. Identity credentials issue with synthetic test subject data.

Endpoints and trust artefacts.

All URLs below are relative to this origin. In the sandbox the segment is always test; substitute your own segment when you onboard a dedicated tenant.

Open the complete endpoint reference Discovery · issue · present · status · DID · OpenAPI
  • /connect/test/.well-known/openid-credential-issuer OID4VCI §12.2 Credential Issuer Metadata — lists all supported configurations.
  • /connect/test/.well-known/oauth-authorization-server RFC 8414 Authorization Server Metadata — token and nonce endpoint addresses.
  • /connect/test/jwks RFC 7517 JWKS — the tenant's public signing keys.
  • /connect/test/oid4vci/offer POST — start an OID4VCI Pre-Authorized Code issuance. Body: {"credentialConfigurationId":"…"}
  • /connect/test/oid4vp/request POST — start an OID4VP presentation. Body: {} (only pid_family_name profile available).
  • /connect/test/oid4vci/offer/{offerId}/status GET — coarse offer status: {"status":"pending"|"claimed"|"completed"}. No tokens or credential material.
  • /connect/test/oid4vp/request/{parHandle}/status GET — coarse presentation status: {"status":"pending"|"claimed"|"completed"|"failed"}.
  • /connect/test/credential_offer?id=… OID4VCI §4.1.3 Credential Offer Endpoint — fetches a stored offer by id (GET).
  • /connect/test/token RFC 6749 Token Endpoint — exchanges the pre-authorized code for an access token.
  • /connect/test/credential OID4VCI §8 Credential Endpoint — issues the credential given a valid access token and proof.
  • /connect/test/nonce OID4VCI §7 Nonce Endpoint — returns a fresh c_nonce for the holder proof.
  • /.well-known/did.json did:web resolution target — the server's own DID document (did:web:verifable.eu).
  • /openapi/verifable-server.json Full OpenAPI 3.1.1 contract — every endpoint rendered live in Documentation.

Status-list credentials are hosted at /connect/{segment}/status/{listId} — the credentialStatus field of every UNTP credential points here. A verifier fetches this URL to check whether a credential has been revoked.

The server describes itself as did:web:verifable.eu. The full DID document is linked above; the full API reference is at Documentation.

Frequently asked questions.

Wallet users

Can I use a sandbox credential in a real service?

No. Sandbox credentials are issued under ephemeral keys that are not listed on any production trust list. A verifier that checks trust-chain membership will reject them. They exist for testing wallet implementations and integration patterns only.

Why does my credential disappear after a server restart?

The sandbox tenant's keys are regenerated on every server start. A credential issued in a previous session was signed by a different key than the one now served at the JWKS endpoint, so verification will fail. This is expected sandbox behaviour — use the issue widget to create a fresh credential after each restart.

Relying parties

How do I verify a presentation from a sandbox wallet?

Use the verify widget above to start a presentation flow. The widget creates a fresh OID4VP request signed by the sandbox verifier. Point your wallet at the returned deep link or QR code. Your relying party receives the presentation at the direct_post callback configured for the test segment. Note that the sandbox verifier is not listed on a production trust list.

Which credential profile does the presentation request ask for?

Only the pid_family_name profile is wired — it requests the family_name claim from an SD-JWT PID credential using a DCQL query. Additional claim and DPP presentation profiles are not available yet.

Issuers

Can I issue my own credential type in the sandbox?

The sandbox tenant's credential catalog is fixed — it covers the identity and DPP families listed in the catalog section above. Custom credential types require a dedicated tenant, which is not yet self-service. Contact hello@lumoin.com to discuss a pilot.

Where does the issuer metadata live?

At /connect/test/.well-known/openid-credential-issuer. That document lists every supported credential configuration, the formats, and the proof types each configuration requires. The full OpenAPI contract at /openapi/verifable-server.json documents every request and response shape.

Developers and integrators

How do I start an issuance flow programmatically?

POST to /connect/test/oid4vci/offer with a JSON body containing credentialConfigurationId (required) and optionally subject. The response carries the by-value credential offer object, the by-reference credentialOfferUri, the preAuthorizedCode, and an offerId. Your wallet client constructs the openid-credential-offer:// deep link from the credentialOfferUri.

How do I start a presentation request programmatically?

POST to /connect/test/oid4vp/request with {}. The response carries the verifier clientId, the requestUri (a GET on this returns the signed JAR the wallet consumes), and the full authorizationRequestUri in the openid4vp:// scheme. The wallet deriving from that URI presents via the direct_post response mode.

Is there a full API reference?

Yes — the Documentation page renders the full OpenAPI 3.1.1 contract live. The raw JSON is at /openapi/verifable-server.json for tooling, code generation, or any agent that wants the full shape at once.

Changelog.

Significant Sandbox additions are recorded here. The server repository carries its own release log.

Open the Sandbox changelog Dated interface changes

  1. Scenario framing, Open-in-Wallet, live flow status

    The issue widget's configuration picker now leads with credential scenarios (grouped as Identity (PID) and Product passports (DPP/UNTP)) with the raw configuration id shown alongside; both widgets gained an Open in wallet same-device link next to the QR; and both flows now report live status — the page polls the new read-only …/status endpoints and tells you when a wallet picks a flow up and when it completes.

  2. Sandbox documentation pages — S6

    Added the /sandbox/ section: getting started guide, complete credential catalog (identity and DPP families), live issue-a-credential and verify-a-presentation widgets with QR and deep-link output, endpoints and trust artefacts reference, FAQ for four audiences, and this changelog. The credential catalog documents the exact configuration IDs the seeded test tenant supports; the QR encoder is a dependency-free inline module.