Repository navigation
Only issue credentials based on verified chip data #85
Description
Summary
Restrict credential issuance and claim inclusion to data that has been cryptographically verified for authenticity.
Background
This is issue stems from a discussion in #84 regarding how data is read/validate for issuance:
FaceTec has to report an authenticated chip for every issuance, but we can still issue OCR values in three cases:
- a chip FaceTec authenticates but our own passive authentication can’t verify (only enforced as a refusal for passports with trust.required);
- chips we don’t parse, e.g. ISO 18013 driving licences;
- the legacy /v1/id-scan path.
Requiring chip-signed identity for every credential would close these, but would also exclude driving licences until we support ISO 18013 chips. That’s a team decision, so I’ll keep it out of this PR.
Problem description
Claim data read via OCR from an identity document is trivial to falsify. It is also trivial to fraudulently apply cryptographic signatures over forged data unless the validator has a list of trusted signers (typically through PKI). It would hence be a great liability to issue credentials based on this.
Suggested solution
Never use data that hasn't been cryptographically verified against a trust list in issued credentials.
Considerations
As stated in other discussions, this type of change would prevent usage of certain identity documents from certain countries. While that is a downside, I would argue that we can't let these cases compromise the trust in our validation process for issued credentials.
Activity
leifj commentedon Oct 14, 2026
I agree. This is what the emrtd-anchors repo is for basically.
s-jairl commentedon Oct 14, 2026
I believe that is used in cases where possible - this issue is more about a stance and guiding principles for the project.
jessevanmuijden commentedon Oct 14, 2026
Agreed. Here is a concrete implementation plan, for confirming the scope before I build it.
"Verified against a trust list" means the go-trust PDP trusts the document signer (
chip-trusted, emrtd-anchors). A valid chip signature on its own is not enough, since anyone can sign forged data with their own key.Plan
trust.requiredis enforced for passports only today (assessChip). Extend it to all documents, so ID cards also need a document signer that chains to a CSCA in emrtd-anchors. ID cards are ICAO 9303 documents too, and many states sign them under the same CSCA as their passports./v1/id-scan. It never receives chip data, so under this rule it can only refuse. I would remove/v1/session-token,/v1/livenessand/v1/id-scan, or have them always refuse. No working client uses them: the SDKs' FaceTec 9 delegate cannot run against FaceTec 10.To settle
chip_untrusted), ID cards included. Worth checking that list against the states we expect users from.trust.required: falseas an explicit opt-out for development stacks without a PDP, with a startup warning, and keep ittruein production. Is that acceptable, or should production builds refuse the opt-out entirely?chip_data_unverified) wanted, or should it reusechip_untrusted? A new code also means a message in the apps and SDKs.Order
#84 (identity from the chip) is a prerequisite and #80 (chip photo match) follows the same principle, so I would merge both first and then do this as its own PR.