| Formats Supported |
- IETF SD-JWT VC (
dc+sd-jwt), with selective disclosure as per SD-JWT (RFC 9901), including nested objects and array elements - ISO/IEC 18013-5 mdoc (
mso_mdoc), for example mDL, PID and Photo ID - W3C VC (JWT,
jwt_vc_json), presented with OpenID4VP (Draft 18)
|
| Issuance Protocols |
OpenID4VCI 1.0 with HAIP 1.0
EWC RFC001: Issue Verifiable Credential - v2.0 |
| Issuance Features |
- Pre-authorised code flow with transaction code (
tx_code), and authorisation code flow with Pushed Authorisation Requests (PAR) and PKCE - Issuer-initiated issuance (credential offer by value or by reference) and wallet-initiated issuance
- Credential offer reuse per credential definition: one credential offer can start several issuances
- Interactive Authorisation Request (IAR), including OpenID4VP presentation during issuance
- Sender-constrained tokens with DPoP (RFC 9449) and wallet authentication with OAuth 2.0 Attestation-Based Client Authentication
- Proof types
jwt and attestation, with key attestation requirements set per credential definition and per proof type - Batch issuance, deferred issuance, nonce endpoint and notification endpoint
- Credential refresh (re-issuance with a refresh token)
- Encrypted credential requests and responses
- Dynamic credential request (the issuer requests a presentation before it issues)
- External authorisation servers: user authentication at an external OpenID Connect provider, set per credential definition
|
| Key Managements |
Cryptographic key formats supported are: X.509, JWK, Decentralised Identifier (DID) did:key
The key storage can be:
- iGrant.io secure storage vault
- Bring your HSMs via Hashicorp Vault
- Use a Qualified Trust Service Provider (QTSP) through the Cloud Signature Consortium (CSC) API v1.0.4.0 or v2.2.0.0
|
| Presentation Protocols |
OpenID4VP 1.0 with HAIP 1.0, OpenID4VP (Draft 18)
ISO/IEC 18013-7 Annex C and the W3C Digital Credentials API (see DC API overview)
EWC RFC002: Present Verifiable Credentials - v1.0 |
| Presentation Features |
- Digital Credentials Query Language (DCQL), including credential sets, claim sets and trusted authorities (
aki, etsi_tl) - Transaction data, including the TS12 payment, e-mandate, account access and login and risk types, and qualified electronic signature data
- Response modes
direct_post, direct_post.jwt, dc_api and dc_api.jwt - Client identifier prefixes
x509_san_dns, x509_hash, decentralized_identifier (did:key), verifier_attestation and redirect_uri - Signed request objects, passed by value or by reference (
request_uri, including request_uri_method=post)
|
| Signing Algorithms |
ECDSA (secp256r1/P-256) with SHA-256 (ES256) |
| Revocation Management |
IETF Token Status List:- Status List Token in JWT format for SD-JWT VC, and in CWT format for mdoc as per ISO/IEC 18013-5, served from the same status list URL (the format is selected with the HTTP Accept header)
- A status list signing key per credential configuration; for mdoc, a revocation list signer certificate as per ISO/IEC 18013-5 Table B.9
|
| Trust Managements |
X.509 certificate chains, EU Trusted Lists as per ETSI TS 119 612 (XML), Lists of Trusted Entities as per ETSI TS 119 602 (JSON and XML), and trust anchors configured per organisation. See Trust in the Wallet Ecosystem |
| Wallet Provider |
- Wallet Unit Attestation (WUA) as per TS3: Wallet Unit Attestation, with a Wallet Instance Attestation (WIA) and a wallet-provider-signed key attestation
- Wallet unit management and statistics
- Revocation of WUAs and key attestations through the Token Status List
|
| Holder (Organisation Wallet) |
- Receive and store credentials over OpenID4VCI 1.0, including deferred and batch issuance, DPoP and credential refresh (see Receive and Store Credential)
- Present credentials over OpenID4VP 1.0 (see Receive and Present Credential)
- Holder keys in a separate holder key store, apart from the issuer and verifier signing keys
- Organisational identity with Legal Person Identification Data (LPID)
|
| Payments (TS12) |
Strong Customer Authentication (SCA) attestations as per TS12: Electronic payments, SCA implementation with the wallet: payment card, payment account, payment service user (issued without user claims, as the rulebook defines), and Strong User Authentication (SUA) user and IBAN credentials. SCA transaction data is validated at presentation. See the payment extensions below. |