Jurisdiction Profiles
Review status: This foundation page requires specialist review before public approval. Its claims must remain within the scope stated here.
A single global identity technology does not create one global legal configuration. UbID uses jurisdiction profiles to apply local policy without redesigning the underlying credential and trust architecture for every deployment.
The profiles described here are implementation baselines, not legal opinions. Current official sources, local counsel, sector rules, regulator guidance, and deployment-specific facts remain authoritative.
Profile composition
A versioned profile should identify:
| Field | Purpose |
|---|---|
| Jurisdiction and sector | Country, state, province, region, public or private sector, and regulated domain |
| Participants and legal roles | Controller, joint controller, processor, issuer, verifier, holder service, custodian, orchestration provider, or trust-service role |
| Lawful purpose and basis | Permitted processing purpose, legal basis, special-category condition, and prohibited secondary use |
| Claim minimisation | Allowed claims, derived facts, prohibited combinations, and verifier retention |
| Notice and authorization | Required notice version, consent or authorization evidence, withdrawal, and renewal conditions |
| Authentication and assurance | Approved methods, step-up, device, proofing, and human-review conditions |
| Biometrics | Necessity, alternatives, capture, template protection, vendor role, retention, deletion, and review |
| Rights and complaints | Access, correction, deletion, restriction, objection, portability, appeal, and regulator routing |
| Retention and records | Credential, evidence, security, fraud, legal hold, and public-record schedules |
| Transfers and residency | Processing location, recipient, subprocessor, transfer mechanism, and onward-use constraints |
| Incident obligations | Assessment, notification, evidence preservation, and communication timelines |
| Regulated status | Registration, certification, conformity assessment, notification, or prohibited claims |
| Version control | Official sources, effective date, approvers, test evidence, supersession, and review date |
Comparative public baseline
The following table identifies the principal baseline used in the UbID institutional regulatory study. It is intentionally concise and must not be treated as a complete statement of local law.
| Jurisdiction | Principal baseline | Deployment focus |
|---|---|---|
| European Union | GDPR and the European Digital Identity Framework | Lawful basis, minimisation, rights, DPIA, transfers, and regulated wallet or trust-service roles |
| United Kingdom | UK GDPR, Data Protection Act 2018, Data (Use and Access) Act 2025, and DVS Trust Framework | Privacy by design, complaints, assurance, conformity assessment, certification, and service registration |
| Canada | PIPEDA, Privacy Act, provincial regimes, and public-sector digital identity guidance | Appropriate purposes, consent, safeguards, access, breach records, federal/provincial scope, and assurance interoperability |
| United States — federal | FTC and sector-specific frameworks such as health, finance, and children's privacy | Unfair or deceptive practices, reasonable security, sector applicability, contracts, and incident procedures |
| New York State | SHIELD Act and NYDFS cybersecurity rules where applicable | Safeguards, breach governance, MFA, cybersecurity program, testing, and reporting |
| California | CCPA/CPRA and implementing regulations | Consumer rights, sensitive information, assessments, cybersecurity audits, automated decision controls, and opt-out mechanisms |
| Mexico | Federal and general personal-data protection frameworks | Legality, purpose, proportionality, ARCO rights, sensitive data, security, notices, and transfers |
| El Salvador | Personal-data protection and cybersecurity legislation | Emerging authority and procedures, consent, rights, security, transfers, and incident controls |
| Colombia | Law 1581, Decree 1074, and electronic-commerce framework | Authorization, purpose, restricted circulation, habeas data, policies, registration where applicable, and regulator procedures |
| Peru | Law 29733 and its current regulation | Consent, ARCO rights, data-bank governance, sensitive data, security, incidents, and international processing |
| Brazil | LGPD and ANPD regulations | Legal bases, rights, sensitive and children's data, accountability, impact reporting, incidents, and transfers |
| Chile | Law 19.628 as amended by Law 21.719, cybersecurity law, and electronic-signature framework | Transition to the modernized privacy regime, rights, oversight, security, biometrics, transfers, and institutional readiness |
| Paraguay | Law 7593/2025 and implementing transition | New comprehensive baseline, authority and procedure confirmation, rights, transfers, and versioned implementation |
| Argentina | Law 25.326 and implementing rules | Consent, habeas data, security, database obligations, rights timelines, and transfer safeguards |
| Hong Kong | Personal Data (Privacy) Ordinance and six Data Protection Principles | Collection, purpose, retention, security, openness, access, correction, processors, and direct marketing |
| South Korea | PIPA and PIPC guidance | Granular consent, sensitive and unique identifiers, biometrics, transfers, security, foreign-operator duties, and sector certification |
| Japan | APPI plus the separate My Number and JPKI ecosystem | Purpose, security, transfers, rights, authorized JPKI use, and strict separation of the Individual Number |
Important transition examples
- Chile: Law No. 21.719 has a deferred effective date of 1 December 2026. A Chilean deployment should treat 2026 as an implementation transition and maintain evidence of readiness, not assume that a technical profile alone satisfies the new regime.
- United Kingdom: the DVS Trust Framework 1.0 is final, but its statutory commencement depends on accreditation of the first conformity-assessment body and is no earlier than 1 September 2026. Technical compatibility is not equivalent to certification or registration.
- European Union: use of verifiable-credential standards does not by itself make a product a notified European Digital Identity Wallet or a qualified trust service under the European Digital Identity Framework.
These examples illustrate why effective dates, transition conditions, certifications, and regulator procedures belong in versioned profiles.
Profile evaluation
The selected profile should be evaluated before and during:
- collection or proofing;
- credential creation;
- biometric processing;
- presentation and disclosure;
- verifier retention;
- automated or assisted decision-making;
- device registration or recovery;
- cross-border transfer;
- rights or complaint handling;
- incident, revocation, deletion, or legal hold.
Combining overlays
A deployment may require multiple overlays at once:
Global baseline
+ country or regional profile
+ state or provincial profile
+ sector profile
+ institutional role profile
+ credential or transaction profile
The result should be deterministic and versioned. Conflicts must be resolved by the accountable institution; the platform must not silently choose the least restrictive rule.
Change and historical evidence
When a source changes, the institution should:
- assess the legal and operational impact;
- update the profile under change control;
- test affected issuance, presentation, recovery, rights, and retention flows;
- define migration for existing credentials and evidence;
- preserve the previous version for historical explanation;
- review public claims, contracts, notices, and partner documentation.
See Privacy and Regulatory Alignment and Assurance, Assessment, and Certification.