After the ANTS data breach, identity alone is not enough.
When identity-related data is exposed, attackers can make sensitive requests look more credible. The missing layer is reviewable receipt state around sensitive requests.
The practical risk
After identity data exposure, the core risk is not only that personal data has leaked. The risk is that attackers can use that data to make sensitive requests look legitimate.
A message may contain real details. A request may reference a real agency, document, or account process.
Why identity alone is not enough
Identity can help answer: who is this person?
But a sensitive request also needs to answer who is requesting, for what purpose, what is being requested, how long it remains valid, whether it can be revoked, what receipt exists later, and who makes the final decision.
That is the gap Passpod is designed around.
Passpod-compatible workflow
A receipt-state workflow makes the request itself reviewable before action.
- A requester initiates a sensitive action.
- PassPal displays requester context in plain language.
- The user reviews purpose, scope, expiry, and source-labeled evidence.
- The user consents, rejects, or requests review.
- Passpod records limited receipt state.
- DIDX verifies limited receipt state.
- The responsible party makes the final decision.
What each layer does
Shows who is requesting, why the request exists, what is being asked, what evidence is referenced, when the receipt expires, whether it can be revoked, and what happens next.
Records limited receipt state: request type, requester context, purpose, scope, consent state, expiry, revocation state, source-labeled evidence references, and verification state.
Verifies limited receipt state without exposing private documents by default.
Makes the final decision. Passpod records receipt state; it does not act as the final authority.
Example receipt payload
A simplified receipt-state payload can make the workflow testable by developers, security teams, and policy reviewers.
{
"receipt_type": "sensitive_request_review",
"incident_context": "post_identity_data_exposure",
"requester_context": {
"type": "agency_or_service_request",
"verification_state": "source_labeled_review_required"
},
"purpose": "account_recovery_or_sensitive_document_action",
"scope": [
"requested_action",
"required_evidence",
"expiration",
"responsible_party"
],
"consent_state": "user_review_required",
"expires_at": "2026-06-15T00:00:00Z",
"revocation_state": "revocable",
"passpal_display": [
"who_is_requesting",
"why_it_is_requested",
"what_is_requested",
"how_long_it_lasts",
"what_can_be_revoked"
],
"passpod_records": [
"request_type",
"purpose",
"scope",
"consent_state",
"expiry",
"revocation_state",
"source_labeled_evidence"
],
"didx_verifies": [
"limited_receipt_state",
"receipt_status",
"expiry_state",
"revocation_state"
],
"private_documents_stored_by_default": false,
"final_decision_authority": "responsible_party_decides",
"guarantee": "not_a_guarantee"
}Console scenario
The matching console scenario is Post-breach sensitive request verification.
It models a sandbox Passpod receipt workflow for reviewing sensitive requests after identity data exposure, including identity exposure, phishing risk, requester impersonation, and account recovery abuse.
{
"scenario_id": "post_breach_sensitive_request_review",
"title": "Post-breach sensitive request verification",
"description": "A sandbox Passpod receipt workflow for reviewing sensitive requests after identity data exposure.",
"risk_context": [
"identity_data_exposure",
"phishing_risk",
"requester_impersonation",
"account_recovery_abuse"
],
"workflow": [
"requester_context",
"purpose_scope_review",
"policy_check",
"user_consent",
"receipt_state_recorded",
"expiry_revocation",
"didx_receipt_state_verification",
"responsible_party_decision"
],
"sample_payload": {
"receipt_type": "sensitive_request_review",
"incident_context": "post_identity_data_exposure",
"requester_context": {
"type": "agency_or_service_request",
"verification_state": "source_labeled_review_required"
},
"purpose": "account_recovery_or_sensitive_document_action",
"scope": [
"requested_action",
"required_evidence",
"expiration",
"responsible_party"
],
"consent_state": "user_review_required",
"expires_at": "2026-06-15T00:00:00Z",
"revocation_state": "revocable",
"passpal_display": [
"who_is_requesting",
"why_it_is_requested",
"what_is_requested",
"how_long_it_lasts",
"what_can_be_revoked"
],
"passpod_records": [
"request_type",
"purpose",
"scope",
"consent_state",
"expiry",
"revocation_state",
"source_labeled_evidence"
],
"didx_verifies": [
"limited_receipt_state",
"receipt_status",
"expiry_state",
"revocation_state"
],
"private_documents_stored_by_default": false,
"final_decision_authority": "responsible_party_decides",
"guarantee": "not_a_guarantee"
},
"safe_positioning": [
"does_not_claim_breach_prevention",
"does_not_replace_public_authorities",
"does_not_replace_wallets",
"does_not_make_final_decision",
"does_not_store_private_documents_by_default"
]
}How organizations can adopt this pattern
Layer 1 — Requester context
Before asking for sensitive action, show who is requesting, the claimed authority, the reason, and the evidence source.
Layer 2 — Consent and receipt state
Show purpose, scope, expiry, and revocation. Record limited receipt state instead of exposing unnecessary private documents.
Layer 3 — Verification and responsible-party decision
Verify receipt state before action. Preserve the boundary that the responsible party makes the final decision.
What is not guaranteed
- Passpod does not claim it would have prevented the ANTS / France Titres incident.
- Passpod does not replace ANTS, France Identité, EUDI wallets, identity providers, cybersecurity tools, or public authorities.
- Passpod does not certify that a requester is safe.
- Passpod does not make the final decision.
- The responsible party decides.
FAQ
Is Passpod an identity provider?
No. Passpod is not an identity provider. It is a trust receipt protocol for sensitive digital decisions.
Does Passpod replace wallets?
No. Passpod is wallet-complementary. Wallets can prove credentials. Passpod records what happened around a sensitive request.
Would Passpod have prevented the breach?
No. Passpod should not be described as a breach-prevention tool. It adds a receipt-state workflow layer that can make sensitive requests more reviewable after data exposure.
Is DIDX a score?
No. DIDX should be described as readable receipt-state context, not as a people-ranking system.
Who decides?
The responsible party decides. Passpod records limited receipt state.