Issuer trust framework

Issuance policy and practice statement. Everything here describes what the shipped system does, so that a relying party, a reader vendor, a certification body or a regulator can decide whether to trust it and knows how to add it. How to add it is on the page for readers.

1. Who issues, and what

Issuer. KinshipVault, operated by legal entity name, registered address, Canada. Contact for relying parties, vendors and incident reports: contact email. Security reports: security email.

What is issued. Two mdoc credentials (ISO/IEC 18013-5 data model, COSE signatures), each bound to one holder device.

Credential	Doctype	Namespaces and claims
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 nationality and no biometric is ever issued. The Age credential carries two booleans and nothing that identifies the person. The holder discloses claims one by one at presentation and sees exactly what is asked.

What a credential attests. That, at issuance, the issuer checked a government identity document and, for the two higher levels, the person holding it, by the method the assurance_level claim names, and that the claims were read from that document. It does not attest that the person is who they say they are to any standard beyond that method, that the document was not later revoked by its own issuer, or anything about the person's right to act.

2. Assurance levels

The level is set by the issuer's signing service from the source it verified; the app's own value is only compared.

Level	What was checked	Source of the claims
document_verified	The document's chip (ICAO 9303): every data group read hashes to the signed value, the signature verifies under the Document Signer Certificate, and that certificate chains to a CSCA in the bundled master list; chip authentication did not fail (a cloned chip is never issued from). No check that the person presenting the document is its subject.	The chip. Names are not issued at this level.
person_verified	A document check and a selfie check by the identity vendor (Stripe Identity): the document's authenticity, a live capture and a selfie that matches the document's portrait. A report without a verified selfie is refused.	The vendor's verification report, read once.
person_verified_chip	Both of the above, and the chip's values (document number, date of birth, expiry) equal the vendor's reading; a disagreement is refused.	The vendor's report for the names; the chip and the vendor agree on the rest.

A credential can be re-issued from a previous one of the same kind, keeping its level and never raising it. A vendor check is good for one credential and for re-issuance within 365 days; after that the document is checked again.

3. How issuance works

The holder's app prepares the credential with a fresh holder key made in the device's hardware (the Secure Enclave on iPhone and Mac; StrongBox where the Android device has one, else the TEE). The private half never leaves that hardware; the credential carries the public half.
The app asks for a signature. The request holds the prepared bytes for at most 15 minutes and is deleted on acknowledgement.
The signing service is invoked by the database, not by the app: it redeems a single-use ticket under a short lease, then re-derives every claim from the source of truth and refuses on any difference. The sources are the vendor's report, the device-signed record of an earlier check whose values hash to the receipt kept at the time, the chip record, or the previous credential.
The signature is made by a hardware-backed key (AWS KMS) and returned; the signed credential lives only in the holder's encrypted vault. The issuer keeps a bookkeeping row (an id, the product, a status index, dates, revocation) and no claim; an automated test asserts the schema holds no column for a name, number or date.

Validity: 365 days from issuance. The Document Signer certificate is valid 730 days; a credential is never issued past its expiry. Consent: a consent screen precedes every chip read and every vendor capture and lists verbatim what leaves the device.

4. Keys and certificates

Key	Where it lives	Protection
Issuing Authority CA (IACA)	Self-signed P-256 root, CN=KinshipVault IACA (prod), O=KinshipVault, C=CA, CA:TRUE pathlen 0, keyCertSign and cRLSign, 10 years. An offline key file kept by the operator.	Never in a server, never in a function's environment, never in a repository; used only to issue Document Signer certificates. where the offline key is kept, who holds it, backup
Document Signer	P-256, CN=KinshipVault Document Signer (prod), extended key usage 1.0.18013.5.1.2 (mdlDS), 730 days, issued by the IACA for a key held in AWS KMS (ECC_NIST_P256, non-exportable).	The key policy allows signing only to the signing service's principal. Staging and production are separate keys, roots and chains.
Holder keys	The holder device's hardware.	One per credential; never synced, never backed up.
Status list signing	The Document Signer key.
VICAL signer	An offline key beside the IACA key; self-signed certificate, extended key usage 1.0.18013.5.1.7.	Signs the published list of roots.

The IACA is published at /identity/iaca.pem and bundled in the apps. Rotation: the Document Signer certificate is re-issued before its expiry with a new key; credentials signed under the old one stay valid until their own expiry and the old certificate stays published until then. The IACA is rolled by publishing the new root beside the old for at least one credential validity (365 days), bundling both in the apps, and listing both in the VICAL.

5. Revocation and status

Format: IETF Token Status List, one bit per entry, DEFLATE-compressed, in a statuslist+jwt signed by the Document Signer key. Each credential carries its list URI and index.
Where: https://kinshipvault.app/identity/status/<n>, a static file on this site. The signer republishes it, through the site's own pipeline, whenever the copy here is behind (its revocations differ from the newly signed token's, or it is older than 6 hours).
Freshness: a list is rebuilt and re-signed when a revocation dirties it, at every issuance, and in any case every hour; the token's ttl is 3600 seconds and it expires 24 hours after signing. A verifier that cannot fetch the list, or finds it expired, reports "could not be checked" rather than "valid".
Who revokes: the holder, from the app, at any time (the row is marked, never deleted); the operator, on a report of fraud, a key or vendor incident, or a holder's request through support the support path and the identity check it applies. A revocation takes effect at the next list rebuild, at most one hour later.
Nothing in the status list or its fetch identifies the holder: every credential shares the same few lists, and the fetch is of a whole list.

6. Presentation and what a verifier must check

Channel	Standard
Website, same device	ISO/IEC 18013-7 Annex C over the W3C Digital Credentials API; the response encrypted with HPKE to the page's key.
Website or counter, cross device	OpenID4VP 1.0, `direct_post.jwt`; the response a JWE (ECDH-ES, A128GCM) to a key the verifier made for that session. KinshipVault's relay carries ciphertext only, for at most five minutes, and deletes it on the first read.
In person, no internet	ISO/IEC 18013-5 over Bluetooth LE, mdoc peripheral server mode, QR engagement.

A verifier must check: the issuer signature under a certificate that chains to the published IACA; the validity window; the doctype; every disclosed item against its digest in the signed MSO; the status list; and the holder's device signature over the session transcript (so a response copied from another session fails). There is no registry that trusts KinshipVault on a relying party's behalf: the decision is each relying party's, and this document is what it is made on.

7. The VICAL

ISO/IEC 18013-5 Annex C. KinshipVault publishes a signed list of its own roots at /identity/vical.cbor, signed by the certificate at /identity/vical-signer.pem, re-issued on every certificate change and at least every 180 days.

8. Privacy

The issuer's servers never hold a claim in readable form: issuance rows hold prepared ciphertext for minutes; verification rows hold a JWE to a key the server never sees; bookkeeping rows hold no personal column.
The identity vendor's session (images, selfie) is redacted when the session ends, acknowledged or not. KinshipVault keeps no image and no biometric template.
The browser verifier at /verify sends no claim and no key anywhere.
Age verification discloses booleans only, and KinshipVault learns nothing about a presentation: there is no issuer call at presentation time.

9. Incident handling

Event	Action
Document Signer key compromise suspected	Disable the key, issue a new Document Signer certificate for a new key, revoke every credential issued under the old certificate, re-issue holders from their records, withdraw the old certificate from the published chain.
IACA offline key compromise	Roll the IACA (section 4), revoke everything under it, re-issue, publish a notice on this page.
Vendor incident (a wrong verification reported)	Revoke the affected credentials; re-check the document.
Status list hosting down, or the copy here past its expiry	Verifiers report "could not be checked" meanwhile; the signer's next hourly pass republishes; the operator redeploys the site if the hosting itself is down.
A relying party reports a suspected false credential	Verify the presentation's transcript and signature from the party's record; revoke if confirmed. Reply within N business days.

10. Liability and terms

What the attestation is: a statement that the process in sections 2 and 3 ran and passed, signed by the issuer. What it is not: a guarantee of the person's identity beyond that process, a check of the document with its own issuer, or advice. The liability position and the relying-party agreement, to be settled by counsel. A relying-party agreement states which assurance level a use case requires.

11. Certification

Certifications held, with their scheme, body and date, once obtained: the UK Digital Verification Services trust framework, ISO/IEC 27566-1 age assurance, and others.

12. Change log

Date	Change
2026-10-22	0.1, first draft from the shipped system, for counsel.