Standards and interoperability
Nothing in the SDK is proprietary at the protocol level. Every credential, presentation and trust decision follows a published standard, which is what makes the SDK’s wallet and verifiers work with other vendors’ products.
| Standard | Used for | In the SDK |
|---|---|---|
| ISO/IEC 18013-5:2021 | the mdoc credential format, the mobile driving licence data model, QR + Bluetooth presentation, issuer trust | every credential; in-person checks; the issuer list (VICAL) |
| ISO/IEC 18013-7 | presenting an mdoc online (the session transcript for OpenID4VP and the Digital Credentials API) | the web box and the Verify API |
| ISO/IEC 23220-2 and the Photo ID profile | generic identity data elements and the Photo ID document type | the Emirates ID |
| OpenID for Verifiable Presentations (OpenID4VP) | a website asking a wallet for a presentation | the web box, the Verify API, the wallet’s deep-link entry point |
| OpenID for Verifiable Credential Issuance (OpenID4VCI) | an issuer putting a credential in a wallet | the wallet’s offer scanner and issueFromOffer |
| W3C Digital Credentials API | the browser’s native “share your ID” sheet | dc-api on the box; the wallet’s provider extension (iOS 26) and Credential Manager activity (Android) |
| COSE / CBOR (RFC 9052, 8949) | signatures and encoding inside every mdoc | everywhere |
| IETF Token Status List | revocation | the verifier’s revocation check |
The credential pages state which parts are the standard schema (mDL, Photo ID) and which are project-defined (the competition licence, the Emirates ID field choices). Nothing here is certified or approved by any authority; the demo credentials carry fictional data.
Interoperability
Section titled “Interoperability”The SDK’s wallet with other verifiers
Section titled “The SDK’s wallet with other verifiers”| Verifier | Channel | Result |
|---|---|---|
| Third-party online mDL verifiers (OpenID4VP, cross-device QR) | the wallet scans the QR, presents over OpenID4VP | verified; the wallet names the requester when its reader certificate is trusted |
Safari on iOS 26, Digital Credentials API (org-iso-mdoc) |
the wallet’s provider extension appears in the system sheet | works for mdoc requests |
Chrome on Android, Digital Credentials API (openid4vp) |
the wallet’s Credential Manager activity | works |
The SDK’s verifiers with other wallets
Section titled “The SDK’s verifiers with other wallets”| Wallet | Channel | Result |
|---|---|---|
| Any ISO 18013-5 wallet | in person, QR + Bluetooth | supported by design; the reader accepts any credential whose issuer is on your trust list |
| Any OpenID4VP wallet | the web box’s QR or deep link | supported by design; the request is a signed OpenID4VP request with DCQL |
Bring your own wallet to a pilot and we will run it through the same checks.
Known limits
Section titled “Known limits”- iOS wallets cannot present over NFC. Apple restricts card emulation for identity; iOS wallets present over QR + Bluetooth. An iOS verifier can still read NFC.
- Digital Credentials API support differs by browser. The box always keeps the QR and deep-link paths, so a check never depends on the API being present.
- One Bluetooth role per phone. A phone either presents or reads in a session, not both.
- Reader names come from trust, not from the request. A wallet shows a verifier’s name only when it trusts that verifier’s certificate.