Accepting KinshipVault credentials

KinshipVault issues ISO/IEC 18013-5 mdoc credentials to people whose government identity document, and for the higher levels the person holding it, it has checked. This page is what a reader, a verification SDK or a website needs to trust them. The policy behind it is the issuer trust framework.

1. The issuer root (IACA)

One self-signed P-256 root signs every Document Signer certificate. Add it to your trusted issuers, or import the signed list in section 2.

Certificate: /identity/iaca.pem
Subject: CN=KinshipVault IACA (prod), O=KinshipVault, C=CA
SHA-256 fingerprint: E2:5C:B6:DF:F3:EA:48:14:04:3D:C1:95:9F:D8:C3:0D:9D:DC:D8:8B:0D:2E:31:AA:F5:98:09:3F:3C:9D:CC:C4
Subject key identifier: C3:08:BF:C0:EF:A0:45:73:91:FD:B4:D5:AE:B2:D8:28:C3:C4:6B:00
Valid: 2026-10-20 to 2036-10-17

Confirm the fingerprint out of band before trusting a download: openssl x509 -in iaca.pem -noout -fingerprint -sha256.

2. The signed list (VICAL)

ISO/IEC 18013-5 Annex C. A COSE_Sign1 (ES256) over the list of KinshipVault's issuer roots and the doctypes they sign for, for readers that take trust lists rather than single certificates. Pin the signer certificate once; later lists (a root roll, a new doctype) carry a higher vicalIssueID.

List: /identity/vical.cbor
Signer certificate: /identity/vical-signer.pem (extended key usage 1.0.18013.5.1.7)
Provider: KinshipVault
Refresh: On every certificate change, and at least every 180 days (nextUpdate)

3. What is issued

Credential	Doctype	Namespace	Elements
Identity	`org.iso.23220.photoid.1`	`org.iso.23220.1`	family_name, given_name, birth_date, document_number, expiry_date, issuing_country
		`app.kinshipvault.1`	document_type, assurance_level
Age	`eu.europa.ec.av.1`	`eu.europa.ec.av.1`	age_over_18, age_over_21
		`app.kinshipvault.1`	assurance_level

No portrait, no address, no biometric. Credentials issued before October 2026 used the doctypes app.kinshipvault.identity.1 and app.kinshipvault.age.1 with one namespace equal to the doctype; they are being re-issued and the list in section 2 still names them.

assurance_level is one of document_verified (the document's chip was authenticated; no check of the person; no names issued), person_verified (document and selfie check by the identity vendor) and person_verified_chip (both, and the chip agrees with the vendor). Decide per use case which level you require; the framework describes each.

4. Revocation

Every credential names its status list and index (IETF Token Status List, statuslist+jwt, one bit per entry, signed by the Document Signer key) at https://kinshipvault.app/identity/status/<n>. Lists are re-signed on every revocation and at least hourly (ttl 3600). Every credential shares a few lists, so fetching one says nothing about whose credential is checked. Report "could not be checked" rather than "valid" when a list is unreachable.

5. How credentials are presented

Channel	Standard	Notes
Website, same device	ISO/IEC 18013-7 Annex C over the W3C Digital Credentials API (`org-iso-mdoc`)	iPhone with iOS 26 or later (Safari), Android (Chrome). HPKE to the page's key.
Website or counter, cross device	OpenID4VP 1.0, `response_mode direct_post.jwt`, DCQL, JWE (ECDH-ES, A128GCM)	The holder scans a QR code; the answer is a JWE to the key the request carries in `client_metadata.jwks`.
In person, no internet	ISO/IEC 18013-5 over Bluetooth LE, mdoc peripheral server mode, QR engagement	Any 18013-5 reader. The reader's IACA list decides.

For OpenID4VP allow lists keyed by the issuer's signing certificate: the current Document Signer's subject key identifier is EF:97:70:CC:EF:62:34:42:E4:AC:F1:C1:BC:47:4E:17:42:80:E0:53 (valid 2026-10-20 to 2028-10-19; the next one is published here before this one expires). Prefer trusting the root in section 1, which does not roll with it.

6. What to check

The issuer signature, under a Document Signer certificate chaining to the root above (x5chain in the MSO's COSE_Sign1).
The validity window (validityInfo) and the Document Signer certificate's own dates.
Every disclosed element against its digest in the MSO.
The holder's device signature over the session transcript of the channel used, so an answer copied from another session fails.
The doctype you asked for, and the status list entry.

A reference verifier that does exactly this, in a browser, is kinshipvault.app/verify; its source is served unminified beside it. For a website, the same checks come as a package your server runs: Verify KinshipVault IDs on your site.

7. Contact

Trust, incident and certification questions: [CONTACT EMAIL]. Security reports: [SECURITY EMAIL].