Part 4: Digital Wallet Providers¶
AI-Generated — Awaiting Review
This section was generated by AI and has not yet received human review. Remove this notice after subject-matter expert sign-off.
Section 63A-20-401 establishes requirements for digital wallet providers. The statute envisions a competitive wallet ecosystem where multiple providers offer compliant wallets and holders choose among them. Wallet providers bear significant obligations around security, transparency, and data minimization.
| Req ID | Cite | Requirement | Control | Governance |
|---|---|---|---|---|
| SEDI-WAL-01 | 401(1)(a) | Identity protection safeguards | AUTO | Rule |
| SEDI-WAL-02 | 401(1)(b) | Secure attribute processing | AUTO | Rule |
| SEDI-WAL-03 | 401(1)(c) | Technological compliance | EXPT | Statute |
| SEDI-WAL-04 | 401(1)(d) | Tamper resistance | AUTO | Rule |
| SEDI-WAL-05 | 401(1)(e) | Online and offline presentation | AUTO | Statute |
| SEDI-WAL-06 | 401(1)(f) | Secure presentation log | AUTO | Statute |
| SEDI-WAL-07 | 401(1)(g)(i) | Selective disclosure | AUTO | Statute |
| SEDI-WAL-08 | 401(1)(g)(ii) | Age predicate proof | AUTO | Statute |
| SEDI-WAL-09 | 401(1)(h) | Guardian presentation | AUTO | Rule |
| SEDI-WAL-10 | 401(2)(a) | Attribute processing limitation | AUTO | Statute |
| SEDI-WAL-11 | 401(2)(b) | Conspicuous notice | EXPT | Statute |
| SEDI-WAL-12 | 401(2)(c) | Per-transaction consent | AUTO | Statute |
| SEDI-WAL-13 | 401(3)(a) | Primary purpose limitation | EXPT | Statute |
| SEDI-WAL-14 | 401(3)(b) | No unauthorized retention or sharing | EXPT | Statute |
| SEDI-WAL-15 | 401(4) | Utah data protection law compliance | ADMN | Statute |
Implementation Decisions¶
Before the requirements in this part can be assessed, the responsible parties must specify:
- Security baseline (WAL-01): minimum set of safeguards, reviewed against current best practices at a defined frequency.
- Tamper-response actions (WAL-04): protective actions for each detectable tampering scenario.
SEDI-WAL-01: Identity protection safeguards¶
Incorporate state-of-the-art safeguards for protecting an individual's identity.
63A-20-401(1)(a)
Requirement: The wallet SHALL implement current best-practice security controls for protecting stored credentials, key material, and identity attributes.
Criticality: Critical — Weak identity protection safeguards would expose all holders' credentials to compromise.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- stored credentials are encrypted at rest using authenticated encryption;
- key material is protected using hardware-backed mechanisms where the platform supports them;
- secure boot or runtime integrity checking is implemented to detect unauthorized modification of the wallet application.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Mandatory | Conformance test suite | Per-release + CI | Cannot verify the strength of cryptographic implementations at the algorithm level; cannot detect side-channel attacks |
| EXPT | Recommended | Security assessor | Per-significant-change | Point-in-time; does not detect vulnerabilities introduced after review |
| ADMN | Recommended | Program auditor | Annual | Cannot verify runtime security posture |
Objective coverage: AUTO → 1, 2, 3; EXPT → 1, 2, 3; ADMN → 3
Assessment objects: wallet application source code; credential storage implementation and encryption configuration; key management architecture documentation; hardware security module integration code; secure boot and integrity verification mechanisms; wallet provider security certifications and third-party audit reports; security baseline policy document.
Statutory compliance: Automated testing is mandatory because encryption and key protection are deterministic technical properties verifiable through testing; expert review is recommended for deeper cryptographic analysis.
SEDI-WAL-02: Secure attribute processing¶
Process an individual's identity attributes in a secure manner.
63A-20-401(1)(b)
Requirement: The wallet SHALL encrypt identity attributes in transit and at rest. Attribute processing SHALL occur within a secure execution context.
Criticality: Critical — Insecure attribute processing exposes holder identity data to interception or theft.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- identity attributes are encrypted in transit during all presentation flows;
- identity attributes are encrypted at rest in wallet storage;
- no plaintext identity attributes are exposed in application logs, caches, or temporary files;
- attribute processing occurs within a secure execution context (e.g., isolated process, trusted execution environment).
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Mandatory | Conformance test suite | Per-release + CI | Cannot detect all possible plaintext exposure vectors across all platform configurations |
| EXPT | Recommended | Security assessor | Per-significant-change | Point-in-time; does not cover all deployment environments |
| ADMN | Recommended | Program auditor | Annual | Cannot verify technical enforcement |
Objective coverage: AUTO → 1, 2, 3; EXPT → 3, 4; ADMN → 4
Assessment objects: wallet application source code; transport layer security configuration; credential storage encryption implementation; application logging configuration and log output samples; cache and temporary file management code; secure execution context architecture documentation; wallet provider secure processing procedures.
Statutory compliance: Automated testing is mandatory because encryption in transit and at rest, and absence of plaintext logging, are deterministic properties verifiable through testing.
SEDI-WAL-03: Technological compliance¶
Comply with the requirements of this part through technological means where possible.
63A-20-401(1)(c)
Requirement: Compliance with Part 4 requirements SHALL be enforced through technical controls. Policy-only compliance SHALL be documented as an exception.
Criticality: High — Relying on policy-only compliance where technical controls are feasible creates preventable compliance gaps.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- compliance with each Part 4 requirement is enforced through technical controls where feasible;
- any requirement relying on policy-only compliance is documented as an exception with a justification for why technical enforcement is not feasible;
- policy-only exceptions are reviewed periodically to determine whether technical enforcement has become feasible.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Recommended | Conformance test suite | Per-release | Cannot determine whether a specific requirement could have been technically enforced |
| EXPT | Mandatory | Independent assessor | Per-significant-change | Point-in-time; new capabilities may make previously infeasible technical controls possible |
| ADMN | Recommended | Program auditor | Annual | Cannot verify technical implementation |
Objective coverage: AUTO → 1; EXPT → 1, 2, 3; ADMN → 2, 3
Assessment objects: wallet application source code and technical architecture documentation; policy-only exception register with feasibility justifications; prior assessment reports showing exception review history; conformance test suite coverage reports mapping tests to Part 4 requirements.
Statutory compliance: Expert review is mandatory because determining whether a requirement can be "technically enforced" requires judgment about technical feasibility that cannot itself be automated.
SEDI-WAL-04: Tamper resistance¶
Derived: Be tamper resistant.
63A-20-401(1)(d)
Requirement: The wallet SHALL implement tamper-resistance mechanisms that detect and respond to unauthorized access to or modification of stored credentials, key material, and presentation logs. The tamper-resistance approach SHALL be proportionate to the security capabilities of the underlying platform. On platforms offering hardware security modules, key material SHOULD be stored in those modules. On platforms without hardware security, key material SHALL be protected via encryption and integrity checking.
Criticality: Critical — Tamper-vulnerable wallets allow credential theft and forgery.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- key material is protected using the strongest mechanism available on the target platform (hardware security module where supported);
- credential storage uses authenticated encryption;
- integrity checks detect unauthorized modification of stored credentials, key material, and presentation logs;
- the wallet responds to detected tampering with the tamper-response actions;
- on platforms without hardware security, key material is protected via software encryption and integrity checking.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Mandatory | Conformance test suite | Per-release + CI | Cannot simulate all physical tampering scenarios; platform-specific hardware security varies |
| EXPT | Recommended | Security assessor | Per-significant-change | Point-in-time; new attack vectors emerge continuously |
| ADMN | Recommended | Program auditor | Annual | Cannot verify runtime security |
Objective coverage: AUTO → 1, 2, 3, 4; EXPT → 1, 3, 4, 5; ADMN → 5
Assessment objects: wallet application source code; key storage implementation and hardware security module integration code; authenticated encryption configuration; integrity check implementation; tamper-response logic and event handlers; wallet provider platform-specific tamper-resistance documentation; penetration test reports.
Statutory compliance: Automated testing is mandatory because tamper-resistance mechanisms (authenticated encryption, integrity checks, tamper response) are deterministic technical properties verifiable through testing.
SEDI-WAL-05: Online and offline presentation¶
Support online and offline presentation of a state-endorsed digital identity.
63A-20-401(1)(e)
Requirement: The wallet SHALL implement both online and offline presentation protocols. Offline presentation SHALL complete without any network connectivity.
Criticality: Critical — Inability to present offline would render the SEDI unusable in many real-world scenarios (e.g., rural areas, in-person interactions).
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- the wallet implements an offline presentation protocol that completes without any network connectivity;
- the wallet implements an online presentation protocol that completes successfully over a network connection;
- the offline presentation flow has no hidden network dependencies (no DNS lookups, no certificate revocation checks, no telemetry during the flow).
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Mandatory | Conformance test suite | Per-release + CI | Cannot test every possible network environment and device combination |
| EXPT | Recommended | Independent assessor | Per-significant-change | Point-in-time; does not detect regressions |
| ADMN | Recommended | Program auditor | Annual | Cannot verify runtime behavior |
Objective coverage: AUTO → 1, 2, 3; EXPT → 3; ADMN → 1, 2
Assessment objects: wallet application source code; online presentation protocol implementation; offline presentation protocol implementation; network traffic captures during offline presentation tests; wallet provider documentation of online and offline modes; conformance test results demonstrating network-isolated offline presentation.
Statutory compliance: Automated testing is mandatory because online and offline presentation are distinct technical pathways verifiable through protocol testing.
SEDI-WAL-06: Secure presentation log¶
Maintain a secure log with sufficient information for the holder to know: (A) what identity attributes were provided; and (B) the verifier or relying party the identity attributes were provided to; accessible only to the holder; exportable only by the holder; deletable only by the holder.
63A-20-401(1)(f)
Requirement: The wallet SHALL maintain a presentation log recording: (a) attributes disclosed, (b) recipient verifier/RP identity, (c) timestamp. The log SHALL be: (i) accessible only to the holder via the wallet UI, (ii) exportable by the holder in a standard format, (iii) deletable only by the holder, (iv) not accessible to the wallet provider, the Department, or any third party.
Criticality: Critical — A compromised or externally accessible presentation log would enable surveillance of holder activity.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- the presentation log records the attributes disclosed in each presentation;
- the presentation log records the identity of the verifier or relying party for each presentation;
- the presentation log records a timestamp for each presentation;
- the log is accessible only to the holder via the wallet UI, with no API or mechanism permitting non-holder access;
- the log is exportable by the holder in a standard, portable format;
- the log is deletable only by the holder, with deletion being complete and irrecoverable;
- the wallet provider, the Department, and third parties have no access to log data, including through telemetry or analytics pipelines.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Mandatory | Conformance test suite | Per-release + CI | Cannot verify absence of covert exfiltration channels at the OS or firmware level |
| EXPT | Recommended | Security assessor | Per-significant-change | Point-in-time; does not detect capabilities added after review |
| ADMN | Recommended | Program auditor | Annual | Cannot verify technical enforcement |
Objective coverage: AUTO → 1, 2, 3, 4, 5, 6, 7; EXPT → 4, 7; ADMN → 7
Assessment objects: wallet application source code; presentation log storage implementation and data schema; log access control mechanisms; log export functionality and output format; log deletion implementation and data remnant analysis; wallet provider telemetry and analytics configuration; wallet provider privacy policy.
Statutory compliance: Automated testing is mandatory because log content, access controls, export, and deletion are deterministic technical properties verifiable through testing.
SEDI-WAL-07: Selective disclosure¶
Enable a holder to selectively disclose an individual's identity attributes.
63A-20-401(1)(g)(i)
Requirement: The wallet SHALL support the selective disclosure mechanism specified in the credential format. The wallet UI SHALL allow the holder to review and approve the specific attributes being disclosed before each presentation.
Criticality: Critical — Without selective disclosure, every presentation would reveal all holder attributes, violating data minimization principles.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- the wallet presents an attribute selection interface allowing the holder to review attributes before each presentation;
- the holder can deselect individual attributes from the presentation;
- only holder-selected attributes are included in the presentation payload;
- non-selected attributes are cryptographically hidden, not merely omitted from the UI display.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Mandatory | Conformance test suite | Per-release + CI | Cannot verify the usability of the selection UI; cannot test all attribute combinations |
| EXPT | Recommended | Independent assessor | Per-significant-change | Point-in-time; does not detect regressions |
| ADMN | Recommended | Program auditor | Annual | Cannot verify runtime behavior |
Objective coverage: AUTO → 1, 2, 3, 4; EXPT → 4; ADMN → 1, 2
Assessment objects: wallet application source code; attribute selection UI implementation; selective disclosure cryptographic implementation; presentation payload samples showing attribute inclusion and exclusion; wallet provider selective disclosure documentation.
Statutory compliance: Automated testing is mandatory because selective disclosure is a deterministic cryptographic property verifiable through presentation payload analysis.
SEDI-WAL-08: Age predicate proof¶
Demonstrate that the individual meets a specified minimum age without disclosing the individual's age or birth date.
63A-20-401(1)(g)(ii)
Requirement: The wallet SHALL support predicate proof presentation for age-related claims. The wallet UI SHALL clearly indicate when a predicate proof (rather than full attribute disclosure) is being used.
Criticality: Critical — Disclosing exact birth date when only age threshold verification is needed violates data minimization and statutory requirements.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- the wallet supports age predicate proof presentation (demonstrating that the holder meets a minimum age threshold);
- the wallet UI clearly indicates when a predicate proof is being used rather than full attribute disclosure;
- only a boolean result (meets/does not meet threshold) is transmitted, with no birth date or exact age value disclosed;
- the predicate proof implementation does not leak age or birth date information through metadata, proof structure, or side channels.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Mandatory | Conformance test suite | Per-release + CI | Cannot verify all possible age threshold values; cannot test across all credential formats |
| EXPT | Recommended | Independent assessor | Per-significant-change | Point-in-time; cryptographic vulnerabilities may emerge over time |
| ADMN | Recommended | Program auditor | Annual | Cannot verify cryptographic correctness |
Objective coverage: AUTO → 1, 2, 3; EXPT → 3, 4; ADMN → 1, 2
Assessment objects: wallet application source code; predicate proof implementation and cryptographic library; presentation payload samples from age predicate proofs; wallet UI screenshots showing predicate proof indicators; wallet provider predicate proof documentation.
Statutory compliance: Automated testing is mandatory because predicate proof functionality and payload content are deterministic technical properties verifiable through testing.
SEDI-WAL-09: Guardian presentation¶
Allow a presentation of a state-endorsed digital identity by a digital guardian.
63A-20-401(1)(h)
Requirement: The wallet SHALL support digital guardian presentation mode, where a guardian can present the subject's SEDI on their behalf with appropriate authorization.
Criticality: High — Without guardian presentation support, minors and incapacitated individuals cannot use their SEDIs through authorized guardians.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- the wallet supports a guardian presentation mode allowing a digital guardian to present the subject's SEDI;
- guardian authorization is verified before any guardian presentation is permitted;
- guardian presentations are distinguishable from direct holder presentations in the presentation payload where required;
- expired or revoked guardian authorizations are rejected.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Mandatory | Conformance test suite | Per-release + CI | Cannot verify all guardian relationship types and edge cases |
| EXPT | Recommended | Independent assessor | Per-significant-change | Point-in-time; guardianship law may evolve |
| ADMN | Recommended | Program auditor | Annual | Cannot verify runtime behavior |
Objective coverage: AUTO → 1, 2, 3, 4; EXPT → 2, 4; ADMN → 1, 3
Assessment objects: wallet application source code; guardian presentation workflow implementation; guardian authorization verification logic; guardian credential and authorization data model; presentation payloads from guardian and direct holder presentations; wallet provider guardian presentation procedures documentation.
Statutory compliance: Automated testing is mandatory because guardian presentation is a distinct technical workflow verifiable through protocol testing.
SEDI-WAL-10: Attribute processing limitation¶
May only process attributes if processing is necessary for a presentation.
63A-20-401(2)(a)
Requirement: The wallet SHALL NOT process (access, read, transmit, or compute over) identity attributes except as necessary for a holder-initiated presentation. Background processing, indexing, or analytics of attribute data is prohibited.
Criticality: Critical — Unauthorized background processing of attributes would enable surveillance and violate the holder's control over their identity data.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- the wallet does not access, read, transmit, or compute over identity attributes except during a holder-initiated presentation;
- no background processing, indexing, or analytics of attribute data occurs outside presentation flows;
- no attribute data appears in analytics, telemetry, or diagnostic payloads sent to the wallet provider or third parties.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Mandatory | Conformance test suite | Per-release + CI | Cannot detect all possible covert processing channels; runtime monitoring coverage depends on instrumentation |
| EXPT | Recommended | Security assessor | Per-significant-change | Point-in-time; does not detect capabilities added after review |
| ADMN | Recommended | Program auditor | Annual | Cannot verify technical enforcement |
Objective coverage: AUTO → 1, 2, 3; EXPT → 1, 2, 3; ADMN → 2, 3
Assessment objects: wallet application source code; attribute access and processing code paths; runtime monitoring and instrumentation logs; telemetry and analytics configuration; network traffic captures during idle and background states; wallet provider privacy policy and data processing documentation.
Statutory compliance: Automated testing is mandatory because attribute access patterns are observable technical behaviors verifiable through runtime monitoring and API testing.
SEDI-WAL-11: Conspicuous notice¶
The holder has received conspicuous notice of: (i) what attributes are collected, (ii) how used, (iii) purpose, (iv) retention duration.
63A-20-401(2)(b)
Requirement: The wallet SHALL display conspicuous notice to the holder covering all four disclosure elements before any attribute processing occurs. Notice SHALL be presented in plain language.
Criticality: High — Without conspicuous notice, holder consent is not informed, undermining the statutory consent framework.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- conspicuous notice is displayed to the holder before any attribute processing occurs;
- the notice discloses what attributes are collected;
- the notice discloses how attributes are used;
- the notice discloses the purpose of attribute collection;
- the notice discloses the retention duration for collected attributes;
- the notice is presented in plain language that is readable and understandable to a general audience.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Recommended | Conformance test suite | Per-release | Cannot assess whether the notice is "conspicuous" or "understandable" to humans |
| EXPT | Mandatory | Independent assessor | Per-significant-change | Point-in-time; UI changes may affect conspicuousness |
| ADMN | Recommended | Program auditor | Annual | Cannot verify runtime display |
Objective coverage: AUTO → 1, 2, 3, 4, 5; EXPT → 1, 2, 3, 4, 5, 6; ADMN → 6
Assessment objects: wallet application source code; notice screen UI implementation and screenshots; notice text content; wallet application user flow documentation showing notice placement relative to first attribute processing; plain language review results.
Statutory compliance: Expert review is mandatory because "conspicuous" and "plain language" are qualitative standards requiring human judgment; automated testing is recommended for structural verification.
SEDI-WAL-12: Per-transaction consent¶
The holder consents to the processing.
63A-20-401(2)(c)
Requirement: The wallet SHALL obtain explicit, affirmative consent from the holder before each presentation. Consent SHALL be per-transaction, not blanket.
Criticality: Critical — Blanket or assumed consent would violate the statutory per-transaction consent requirement and undermine holder autonomy.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- an explicit, affirmative consent prompt is displayed to the holder before each presentation;
- consent is per-transaction, with no "remember my choice" or blanket consent mechanism that eliminates future consent prompts;
- the holder can revoke consent and cancel the presentation at any point before transmission;
- the consent UI does not employ dark patterns, pre-checked options, or other manipulative design that undermines voluntary consent.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Mandatory | Conformance test suite | Per-release + CI | Cannot verify that consent is truly "informed" from the holder's perspective |
| EXPT | Recommended | Independent assessor | Per-significant-change | Point-in-time; UI changes may introduce new patterns |
| ADMN | Recommended | Program auditor | Annual | Cannot verify runtime consent flows |
Objective coverage: AUTO → 1, 2, 3; EXPT → 4; ADMN → 1, 2
Assessment objects: wallet application source code; consent prompt UI implementation and screenshots; presentation workflow showing consent gate before data transmission; wallet application user flow documentation; consent design review documentation.
Statutory compliance: Automated testing is mandatory because the presence and per-transaction nature of the consent prompt are deterministic UI behaviors verifiable through testing.
SEDI-WAL-13: Primary purpose limitation¶
Information provided by a holder may only be processed for the primary purpose for which the holder disclosed the information.
63A-20-401(3)(a)
Requirement: The wallet provider SHALL NOT use information provided by the holder for any purpose beyond enabling the specific presentation the holder initiated. This includes but is not limited to: no profiling, no advertising, no analytics on holder behavior.
Criticality: Critical — Secondary use of holder data by the wallet provider would betray the holder's trust and violate statutory purpose limitations.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- the wallet provider does not use holder-provided information for profiling, advertising, or behavioral analytics;
- no data flows from the wallet application to advertising, analytics, or profiling endpoints;
- no secondary data stores exist for holder information beyond what is required for presentation;
- the wallet provider privacy policy explicitly limits data use to the primary purpose for which the holder disclosed the information;
- no data monetization pathways exist (e.g., data sales, data broker integrations, aggregated data products).
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Recommended | Conformance test suite | Per-release | Cannot detect all possible secondary use channels, especially server-side |
| EXPT | Mandatory | Independent assessor | Per-significant-change | Point-in-time; cannot detect future policy or code changes |
| ADMN | Recommended | Program auditor | Annual | Cannot verify technical enforcement |
Objective coverage: AUTO → 2, 3; EXPT → 1, 2, 3, 4, 5; ADMN → 4, 5
Assessment objects: wallet application source code; network traffic analysis for data flows to third-party endpoints; wallet provider server-side infrastructure documentation; wallet provider privacy policy; data processing agreements; wallet provider contractual commitments and business model documentation.
Statutory compliance: Expert review is mandatory because determining whether a data use constitutes "primary purpose" vs. secondary use requires contextual judgment; automated testing is recommended for detecting obvious violations.
SEDI-WAL-14: No unauthorized retention or sharing¶
Used, retained, sold, or shared: (i) as expressly authorized by the holder; or (ii) if required by law.
63A-20-401(3)(b)
Requirement: The wallet provider SHALL NOT retain, sell, or share holder data unless: (a) the holder has expressly authorized the specific use, or (b) a legal obligation requires it. "Express authorization" requires affirmative opt-in, not opt-out.
Criticality: Critical — Unauthorized retention or sharing of holder data would violate statutory protections and expose holders to privacy harm.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- the wallet provider does not retain holder data beyond what is necessary for the specific presentation;
- the wallet provider does not sell holder data;
- the wallet provider does not share holder data with third parties unless expressly authorized by the holder through affirmative opt-in;
- any data sharing requires explicit, affirmative opt-in (not opt-out) from the holder;
- data retention policies are documented and technically enforced (e.g., automatic purging after defined periods);
- any retention or sharing required by law is documented with specific legal citations.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | Recommended | Conformance test suite | Per-release | Cannot detect all possible server-side retention or sharing mechanisms |
| EXPT | Mandatory | Independent assessor | Per-significant-change | Point-in-time; cannot monitor ongoing data handling practices |
| ADMN | Recommended | Program auditor | Annual | Cannot verify technical enforcement |
Objective coverage: AUTO → 3, 4; EXPT → 1, 2, 3, 4, 5; ADMN → 5, 6
Assessment objects: wallet application source code; server-side data storage and retention implementation; data sharing APIs and integration points; wallet provider data retention policy; holder opt-in consent mechanisms; wallet provider contractual commitments and terms of service; data flow diagrams showing all holder data paths; legal obligation documentation for any required retention or sharing.
Statutory compliance: Expert review is mandatory because verifying the absence of unauthorized retention and sharing requires reviewing server-side infrastructure that is not fully observable through automated testing alone.
SEDI-WAL-15: Utah data protection law compliance¶
Nothing in this section relieves a digital wallet provider from complying with Title 13, Chapter 44 (Protection of Personal Information Act) or Title 13, Chapter 61 (Utah Consumer Privacy Act).
63A-20-401(4)
Requirement: Wallet providers SHALL comply with all applicable Utah data protection laws in addition to Chapter 63A-20 requirements.
Criticality: High — Non-compliance with existing data protection law exposes holders to privacy harm and the wallet provider to legal liability.
Roles: Wallet Providers
Assessment Objectives¶
Determine if:
- the wallet provider maintains a compliance program addressing Title 13, Chapter 44 (Protection of Personal Information Act);
- the wallet provider maintains a compliance program addressing Title 13, Chapter 61 (Utah Consumer Privacy Act);
- the wallet provider has current compliance attestations for both statutes;
- wallet provider data handling practices are consistent with both statutes' requirements.
Verification Methods¶
| Method | Applicability | Performed By | Frequency | Limitations |
|---|---|---|---|---|
| AUTO | N/A | — | — | Compliance with external data protection statutes involves organizational policies, legal interpretations, and multi-jurisdictional considerations that cannot be programmatically validated |
| EXPT | Recommended | Legal/compliance assessor | Per-significant-change | Point-in-time; legal requirements may be updated by the legislature |
| ADMN | Mandatory | Program auditor | Annual | Cannot verify all operational practices; relies on provider self-attestation |
Objective coverage: EXPT → 1, 2, 4; ADMN → 1, 2, 3, 4
Assessment objects: wallet provider compliance program documentation for Title 13 Chapters 44 and 61; compliance attestations and certifications; data breach notification procedures; consumer privacy rights implementation documentation; privacy impact assessments; wallet provider data handling policies and procedures; cross-reference mapping between SEDI requirements and existing compliance frameworks.
Statutory compliance: Administrative verification is mandatory because compliance with external data protection laws is a cross-cutting legal and organizational obligation; expert legal review is recommended for compliance assessment.