Part 9: Cross-Cutting Technical Requirements

Implementation Decisions

Before the requirements in this part can be assessed, the Department must specify:

• Algorithm transition policy (SEDI-CRY-05): deprecation timelines and credential reissuance triggers.
• Set of concurrently supported algorithm suites (SEDI-CRY-05): The algorithm suites that may be in simultaneous use during a transition period.
• Retention periods for each lifecycle stage (SEDI-PRV-04): documented maximum retention durations for data at each stage (enrollment, identity proofing, credential issuance, holder storage, presentation, verification).
• Key types covered by the policy (SEDI-KMS-01): all cryptographic keys in active use in the SEDI system.
• Policy review cadence (SEDI-KMS-01): The frequency of policy review, which is at least annual.
• Minimum number of key custodians required (SEDI-KMS-02): The quorum for key generation, which is at least two.
• Ceremony script and procedures (SEDI-KMS-02): documented in advance of each ceremony.
• Minimum FIPS 140-3 validation level for each key type (SEDI-KMS-03): The required validation level (Level 2, Level 3, etc.) mapped to each category of signing key.
• Maximum validity periods for each signing key type (SEDI-KMS-04): The maximum duration a signing key may remain in active use before rotation.
• Minimum notification lead time (SEDI-KMS-04): The advance notice period before key rotation for ecosystem participants.
• Maximum time from compromise detection to key revocation (SEDI-KMS-05): The upper bound on the interval between detecting a key compromise and completing revocation.
• Notification timeline for affected holders and ecosystem participants (SEDI-KMS-05): The schedule and sequence for notifying stakeholders after a key compromise.
• Access control matrix (SEDI-ORG-01): role-to-privilege mappings for all administrative access to SEDI credential issuance and key management systems.
• Background screening criteria (SEDI-ORG-02): screening requirements mapped to each access level.
• Critical operations requiring separation of duties (SEDI-ORG-02): An enumerated list of operations (e.g., key ceremonies, credential issuance, system administration) requiring duty separation.
• Patch application timeline for each severity level (SEDI-ORG-03): maximum time from patch availability to deployment, by severity classification.
• Expedited window for critical-severity patches (SEDI-ORG-03): The accelerated timeline for applying critical-severity patches.
• Complete list of security-relevant event categories (SEDI-ORG-04): The event types to be logged across all SEDI infrastructure components.
• Log retention period (SEDI-ORG-04): The minimum duration logs must be retained, considering investigative, audit, and compliance needs.
• Critical security event categories (SEDI-ORG-05): The event types that trigger automated alerting.
• Response initiation timeline (SEDI-ORG-05): The maximum time from incident detection to initiation of response procedures.
• Breach notification timelines and recipient lists (SEDI-ORG-05): schedules and addressees for breach notifications.
• List of delegated third parties and their SEDI infrastructure functions (SEDI-ORG-06): An inventory of all third parties and the functions they perform.
• Specific KMS and ORG requirements applicable to each delegated function (SEDI-ORG-06): A mapping from each delegated function to the requirements the third party must satisfy.
• Criteria for what constitutes a "significant change" (SEDI-ORG-07): The threshold for triggering the full change management process.
• List of personnel authorized to approve changes (SEDI-ORG-07): The roster of individuals with change-approval authority.

Cryptographic Foundations

The statute uses "mathematically verified" (Utah Code § 63A-20-201(4)), "mathematically provable" (Utah Code § 63A-20-201(20)), and "mathematically verifies" (Utah Code § 63A-20-201(30)) to describe the core verification mechanism. Combined with the explicit exclusion of shared-secret authentication (Utah Code § 63A-20-201(4)(b)) and the open-standards mandate (Utah Code § 63A-20-301(2)(e)), these provisions establish public-key cryptography over open standards as the foundational verification technology of the SEDI program.

SEDI-CRY-01: Non-callback signature verification

Derived: A SEDI must be "mathematically verified" without reliance on shared secret authentication.

Utah Code § 63A-20-201(4), 201(30)

Requirement: All SEDI credentials SHALL be cryptographically signed by the Department such that verification requires only the Department's published verification key and the credential itself. Verifiers SHALL NOT be required to communicate with the Department or any third party in real time to verify the credential's authenticity or integrity. Status checking (revocation) MAY require external communication; signature verification MAY NOT.

Criticality: Critical — non-callback verification is foundational to the offline presentation requirement (SDI-06) and to the anti-surveillance requirement (SDI-17, PRV-03).

Roles: Department, Verifiers

Assessment Objectives

Determine if:

1. all SEDI credentials are cryptographically signed by the Department using a public-key signature scheme;
2. signature verification requires only the Department's published verification key and the credential itself;
3. verifiers are not required to communicate with the Department or any third party in real time to verify the credential's authenticity or integrity;
4. shared-secret authentication mechanisms are excluded from the signature verification path;
5. status checking (revocation) is architecturally separate from signature verification.

Verification Methods

Objective coverage: AUTO → 1, 2, 3, 4, 5; EXPT → 3, 4, 5

Assessment objects: Credential signature specification; Department public key distribution mechanism; verifier SDK source code and API documentation; network traffic captures during offline verification tests; protocol specification for signature verification flow; revocation service architecture documentation.

Statutory compliance: Automated verification is a fully testable cryptographic property and is therefore mandatory.

SEDI-CRY-02: Holder-controlled key binding

The personal digital identifier must be "mathematically provable to be under the holder's exclusive control."

Utah Code § 63A-20-201(20)

Requirement: The personal digital identifier component of a SEDI SHALL be cryptographically bound to a key or proof held under the exclusive control of the holder. The binding mechanism SHALL: (a) generate the holder secret on a holder-controlled device or holder-designated infrastructure; (b) prevent extraction or duplication of the secret during normal operation; (c) provide a mathematical proof of control over the secret without disclosing the secret itself; and (d) support migration of the binding to alternative holder-controlled infrastructure without requiring re-issuance of the underlying SEDI.

Criticality: Critical — failure permits credential theft, impersonation, or non-holder presentation, defeating the holder-control principle (BOR-02) and the definition of personal digital identifier.

Roles: Department, Wallet Providers

Assessment Objectives

Determine if:

1. the personal digital identifier is cryptographically bound to a key or proof held under the holder's exclusive control;
2. the holder secret is generated on a holder-controlled device or holder-designated infrastructure;
3. the secret cannot be extracted or duplicated during normal operation;
4. a mathematical proof of control over the secret can be provided without disclosing the secret itself;
5. the binding can be migrated to alternative holder-controlled infrastructure without requiring re-issuance of the underlying SEDI;
6. no server-side or issuer-side copy of the holder's private key material exists.

Verification Methods

Objective coverage: AUTO → 1, 2, 3, 4; EXPT → 3, 4, 5, 6

Assessment objects: Key generation source code and entropy analysis; key binding protocol specification; wallet key storage API documentation; HSM or secure element configuration; key migration protocol specification; proof-of-possession protocol implementation; server-side architecture documentation confirming absence of holder key escrow.

Statutory compliance: "Mathematically provable" is a cryptographic property; both automated testing and expert cryptographic review are required because the property must hold both implementation-wise and design-wise.

SEDI-CRY-03: Selective disclosure and predicate proofs

Derived: Selective disclosure and predicate proofs over attributes (including age) SHALL be supported.

Utah Code § 63A-20-301(1)(e)(i), 301(1)(e)(ii)

Requirement: The credential format SHALL cryptographically support: (a) selective disclosure of any attribute or subset of attributes without revealing the values of undisclosed attributes; and (b) predicate proofs over attributes (including age and date predicates) that yield only the predicate result without revealing the underlying attribute values. Mechanisms MAY include zero-knowledge proofs, derived credentials, salted attribute hashes with selective revelation, or equivalent constructions. The mechanism SHALL be cryptographically enforced; protocol-level filtering of disclosed fields without cryptographic enforcement does NOT satisfy this requirement.

Criticality: Critical — failure permits over-disclosure even when the verifier requests minimal data, defeating Bill of Rights principles BOR-08 and BOR-10.

Roles: Department, Wallet Providers

Assessment Objectives

Determine if:

1. the credential format supports selective disclosure of any attribute or subset of attributes without revealing undisclosed attribute values;
2. predicate proofs over attributes (including age and date predicates) yield only the predicate result without revealing the underlying attribute values;
3. selective disclosure is cryptographically enforced, not merely protocol-level field filtering;
4. undisclosed attributes are not recoverable from the disclosed presentation by any party;
5. predicate proofs do not leak additional information beyond the boolean result through any channel.

Verification Methods

Objective coverage: AUTO → 1, 2, 4, 5; EXPT → 3, 4, 5

Assessment objects: Credential format specification; selective disclosure construction documentation; predicate proof implementation source code; cryptographic proof of non-recoverability analysis; presentation protocol specification; test vectors for selective disclosure and predicate operations.

Statutory compliance: Cryptographic enforcement is a testable property; automated verification is mandatory.

SEDI-CRY-04: Open, royalty-free algorithms

Derived: All cryptographic algorithms SHALL be defined in open standards, free from licensing fees and patent restrictions.

Utah Code § 63A-20-301(2)(e)

Requirement: All cryptographic algorithms used in SEDI issuance, presentation, and verification SHALL be specified in publicly available standards published by a recognized standards body, and SHALL be available for implementation free of licensing fees and free of patent restrictions or available under royalty-free terms. The Department SHALL maintain and publish a catalog of all cryptographic algorithms in use in the SEDI ecosystem with a citation to the defining standard for each.

Criticality: High — proprietary or patent-encumbered cryptography would foreclose open implementation and would directly violate 63A-20-301(2)(e).

Roles: Department

Assessment Objectives

Determine if:

1. all cryptographic algorithms used in SEDI issuance, presentation, and verification are specified in publicly available standards published by a recognized standards body;
2. all algorithms in use are available for implementation free of licensing fees;
3. all algorithms in use are free of patent restrictions or available under royalty-free terms;
4. the Department maintains and publishes a catalog of all cryptographic algorithms in use in the SEDI ecosystem;
5. each catalog entry includes a citation to the defining standard.

Verification Methods

Objective coverage: AUTO → 1, 4, 5; ADMN → 2, 3, 4, 5

Assessment objects: Published cryptographic algorithm catalog; standards body publications for each cataloged algorithm; patent and licensing status documentation for each algorithm; SEDI system source code and configuration identifying algorithms in use; algorithm allowlist maintained by the conformance test suite.

Statutory compliance: Both catalog completeness and algorithm-level conformance are required; automated checking against a catalog is mandatory and administrative review of the catalog itself is mandatory.

SEDI-CRY-05: Cryptographic agility

Derived: The system should support transition to new algorithms without complete replacement.

Utah Code § 63A-20-301(2)(e), 301(1)(a)

Requirement: The SEDI system SHOULD support cryptographic agility: the ability to introduce, deprecate, and migrate to alternative cryptographic algorithms without replacing the credential format or the wallet and verifier ecosystem. Algorithm identifiers SHOULD be carried in credentials and presentation protocols. The Department SHOULD publish a transition policy covering algorithm deprecation timelines and credential reissuance triggers.

Criticality: Medium — agility is a forward-looking risk control; absence does not break current operations but increases the cost of responding to future algorithm deprecations.

Roles: Department

Assessment Objectives

Determine if:

1. the credential format carries algorithm identifiers sufficient to select the correct verification procedure;
2. presentation protocols carry algorithm identifiers enabling verifiers to determine the signature scheme in use;
3. the system can validate credentials signed under the concurrently supported algorithm suites during a transition period.

Verification Methods

Objective coverage: AUTO → 1, 2, 3; EXPT → 1, 2, 3; ADMN → 3, params

Assessment objects: Credential format specification showing algorithm identifier fields; presentation protocol specification; verifier SDK source code demonstrating multi-algorithm support; algorithm transition policy document; deprecation timeline schedule; test results from multi-algorithm validation scenarios.

Statutory compliance: Agility is a SHOULD-level best-practice obligation; expert architectural review is the most effective verification.

Privacy-Enhancing Technologies

Several Bill of Rights principles (BOR-08 selective disclosure, BOR-10 freedom from surveillance) and several SEDI requirements (SDI-03 cross-context correlation protections, SDI-08 age verification, SDI-17 anti-surveillance) presuppose specific privacy-enhancing technical capabilities. The PRV requirements specify those capabilities at a level of architectural detail that the statute itself does not. Where a PRV requirement refines a requirement that already exists in another Part, the cross-reference is made explicit.

SEDI-PRV-01: Protocol-level unlinkability

Derived: Cross-context correlation protections (refining SDI-03).

Utah Code §§ 63A-20-301(1)(a), 201(1)

Requirement: The presentation protocol SHALL implement specific mechanisms preventing cross-presentation linking. Conforming implementations SHALL: (a) randomize, blind, or single-use any signature value carried in a presentation; (b) eliminate static device, session, or holder identifiers from presentation payloads; (c) avoid deterministic ordering or timing patterns that enable fingerprinting; and (d) ensure transport-layer metadata (TLS session identifiers, network identifiers) is not bound to credential identity. SDI-03 establishes the outcome property; this requirement specifies the mechanisms that produce it.

Criticality: Critical — failure enables mass surveillance through cross-verifier collusion.

Roles: Department, Wallet Providers

Assessment Objectives

Determine if:

1. signature values carried in presentations are randomized, blinded, or single-use such that no two presentations share a static signature field;
2. presentation payloads contain no static device, session, or holder identifiers;
3. ordering and timing patterns in the presentation protocol do not enable fingerprinting;
4. transport-layer metadata (TLS session identifiers, network identifiers) is not bound to credential identity;
5. multiple presentations from the same holder to different verifiers cannot be linked through protocol-level artifacts.

Verification Methods

Objective coverage: AUTO → 1, 2, 5; EXPT → 1, 2, 3, 4, 5

Assessment objects: Presentation protocol specification; signature scheme documentation demonstrating randomization or blinding; presentation payload samples from multiple sessions; network traffic captures showing transport-layer metadata; protocol timing analysis results; wallet SDK source code for presentation generation.

Statutory compliance: Protocol-level unlinkability is a directly testable property; automated verification is mandatory.

SEDI-PRV-02: Leak-resistant predicate evaluation

Derived: Predicate evaluation must not leak the underlying attribute through side channels (refining SDI-08).

Utah Code § 63A-20-301(1)(e)(ii)

Requirement: Predicate evaluation (including but not limited to age predicates) SHALL be implemented such that: (a) the verifier learns only the boolean predicate result; (b) protocol metadata, including timing, response size, and error messages, does not vary in ways that reveal the underlying attribute value; (c) the holder retains control over which predicate is evaluated; and (d) repeated predicate evaluations against the same holder cannot be combined to narrow the underlying attribute beyond the union of the predicates explicitly evaluated. SDI-08 establishes the functional capability; this requirement specifies the privacy property.

Criticality: High — side-channel leakage would defeat the privacy purpose of predicate proofs.

Roles: Department, Wallet Providers

Assessment Objectives

Determine if:

1. the verifier learns only the boolean predicate result and no additional information about the underlying attribute;
2. protocol metadata, including timing, response size, and error messages, does not vary in ways that reveal the underlying attribute value;
3. the holder retains control over which predicate is evaluated;
4. repeated predicate evaluations against the same holder cannot be combined to narrow the underlying attribute beyond the union of the predicates explicitly evaluated.

Verification Methods

Objective coverage: AUTO → 1, 2; EXPT → 1, 2, 3, 4

Assessment objects: Predicate evaluation protocol specification; predicate proof implementation source code; timing analysis across varied attribute inputs; response payload size measurements; error message taxonomy; holder consent flow for predicate selection; formal analysis of information leakage across repeated predicate evaluations.

Statutory compliance: Boolean-only output is automatically testable; automated verification is mandatory.

SEDI-PRV-03: Architectural anti-surveillance

Derived: The Department must have no technical capability to monitor presentations (structural property of SDI-17).

Utah Code § 63A-20-301(3)

Requirement: The SEDI architecture SHALL be designed such that the Department has no technical position from which to monitor, surveil, log, or correlate presentations after issuance. Compliance with this requirement is a structural property: voluntary non-monitoring policies do not satisfy it. The architecture SHALL NOT include: (a) Department-bound traffic during presentation; (b) revocation or status-checking mechanisms that reveal presentation activity to the Department; (c) presentation transaction logs accessible to the Department; or (d) per-credential identifiers usable by the Department for correlation across presentations. SDI-17 establishes the prohibition; this requirement specifies the architectural property that satisfies it.

Criticality: Critical — failure converts the SEDI program into a surveillance infrastructure.

Roles: Department

Assessment Objectives

Determine if:

1. the architecture includes no Department-bound traffic during credential presentation;
2. revocation or status-checking mechanisms do not reveal presentation activity to the Department;
3. no presentation transaction logs are accessible to the Department;
4. no per-credential identifiers usable by the Department for correlation across presentations exist;
5. the anti-surveillance property is structural (enforced by architecture), not merely policy-based.

Verification Methods

Objective coverage: AUTO → 1, 2, 3; EXPT → 1, 2, 3, 4, 5

Assessment objects: System architecture diagrams and data flow documentation; presentation protocol specification; revocation service architecture and API documentation; network traffic captures during online and offline presentation; credential identifier scheme documentation; Department system access logs and monitoring configuration; infrastructure deployment topology.

Statutory compliance: Architectural review is mandatory because structural anti-surveillance is a design-time property; network observation is recommended as a runtime confirmation.

SEDI-PRV-04: Lifecycle data minimization

Derived: Data minimization SHALL apply across the entire credential lifecycle.

Utah Code §§ 63A-20-301(4), 302(7)(a)

Requirement: Data minimization SHALL be enforced at every lifecycle stage: enrollment, identity proofing, credential issuance, holder storage, presentation, and verification. At each stage, only the data strictly necessary for that stage's purpose SHALL be collected, processed, transmitted, or retained. Data collected for one stage SHALL NOT be retained beyond that stage's purpose unless an explicit and minimally-scoped retention obligation applies. The Department SHALL publish a data flow specification identifying, for each lifecycle stage, the data elements processed, their purpose, their retention period, and the deletion mechanism.

Criticality: High — accumulation of identity data across stages undermines holder privacy and increases breach impact.

Roles: Department, Identity Proofing Entities, Wallet Providers, Verifiers, Relying Parties

Assessment Objectives

Determine if:

1. at each lifecycle stage (enrollment, identity proofing, credential issuance, holder storage, presentation, verification), only data strictly necessary for that stage's purpose is collected, processed, transmitted, or retained;
2. data collected for one stage is not retained beyond the retention periods for each lifecycle stage unless an explicit and minimally-scoped retention obligation applies;
3. the Department publishes a data flow specification identifying, for each lifecycle stage, the data elements processed, their purpose, their retention period, and the deletion mechanism;
4. deletion mechanisms operate as specified in the data flow specification.

Verification Methods

Objective coverage: AUTO → 4; EXPT → 1, 2, 4; ADMN → 3, params

Assessment objects: Published data flow specification; data inventory by lifecycle stage; retention schedules and deletion mechanism documentation; system database schemas and storage configurations; data processing agreements with ecosystem participants; audit logs demonstrating deletion execution; privacy impact assessments.

Statutory compliance: Lifecycle data minimization spans organizational boundaries and lifecycle phases; expert and administrative methods are jointly mandatory.

Interoperability and Open Standards

Utah Code § 63A-20-301(1)(c) requires interoperability "while maintaining strong privacy and security." Utah Code § 63A-20-301(2)(e) requires open standards for the SEDI itself. These two provisions, read together, create requirements that govern not only the credential format but every protocol, schema, and API used in the ecosystem.

SEDI-INT-01: Open standards for protocols and APIs

Derived: Open standards extend beyond the credential to all protocols, formats, and APIs in the ecosystem.

Utah Code § 63A-20-301(2)(e)

Requirement: All protocols, data formats, schemas, and application programming interfaces used in the SEDI ecosystem SHALL be specified in publicly available standards that: (a) are published by a recognized standards body or open community process; (b) are freely available for implementation; and (c) are free from patent restrictions or available under royalty-free terms. SDI-15 covers the SEDI credential format itself; this requirement extends the same constraint to every protocol and API surface in the ecosystem.

Criticality: High — proprietary protocols or APIs would foreclose open implementation and create vendor lock-in.

Roles: Department

Assessment Objectives

Determine if:

1. all protocols used in the SEDI ecosystem are specified in publicly available standards published by a recognized standards body or open community process;
2. all data formats and schemas used in the SEDI ecosystem are specified in publicly available standards;
3. all application programming interfaces used in the SEDI ecosystem are specified in publicly available standards;
4. all protocols, formats, schemas, and APIs in use are freely available for implementation;
5. all protocols, formats, schemas, and APIs in use are free from patent restrictions or available under royalty-free terms;
6. the Department maintains and publishes a catalog of all protocols, formats, and APIs in use with standards citations.

Verification Methods

Objective coverage: AUTO → 1, 2, 3, 6; ADMN → 4, 5, 6

Assessment objects: Published protocol, format, and API catalog; standards body publications for each cataloged entry; patent and licensing status documentation; SEDI system source code identifying protocol and API dependencies; ecosystem integration specifications; standards body membership and participation records.

Statutory compliance: Cataloged conformance is automatically testable; automated verification is mandatory.

SEDI-INT-02: Common format across presentation modes

Online and offline presentation share a common credential format.

Utah Code § 63A-20-301(1)(d)

Requirement: The SEDI SHALL define both an online presentation protocol and an offline presentation protocol that share a common credential format. Holders SHALL NOT be required to maintain separate credentials for the two presentation modes. The two protocols SHALL produce equivalent assurance levels and SHALL preserve the same privacy properties (selective disclosure per CRY-03, unlinkability per PRV-01, and predicate proofs per PRV-02).

Criticality: High — divergent formats would force holders to choose between offline capability and online capability or to maintain duplicate credentials.

Roles: Department, Wallet Providers, Verifiers

Assessment Objectives

Determine if:

1. the SEDI defines both an online and an offline presentation protocol;
2. both protocols share a common credential format such that holders do not maintain separate credentials for each mode;
3. online and offline presentation produce equivalent assurance levels;
4. selective disclosure (per CRY-03) is preserved in both presentation modes;
5. unlinkability (per PRV-01) is preserved in both presentation modes;
6. predicate proofs (per PRV-02) are preserved in both presentation modes.

Verification Methods

Objective coverage: AUTO → 1, 2, 4, 5, 6; EXPT → 3, 4, 5, 6

Assessment objects: Online presentation protocol specification; offline presentation protocol specification; credential format specification; test results demonstrating a single credential validates in both modes; privacy property comparison analysis across modes; assurance level documentation for each mode.

Statutory compliance: Common-format conformance is automatically testable; automated verification is mandatory.

SEDI-INT-03: Wallet portability

Derived: Holders may transfer a SEDI between conforming wallets.

Utah Code § 63A-20-301(2)(g)(i)(E), 301(1)(f)

Requirement: Credential formats and wallet interfaces SHALL support holder-initiated portability between conforming wallet implementations. A holder SHALL be able to export their SEDI from one conforming wallet and import it into another conforming wallet without requiring re-issuance, repeated identity proofing, or interaction with the Department. The portability mechanism SHALL preserve the holder's binding to the personal digital identifier (CRY-02) and SHALL NOT degrade any privacy or security property.

Criticality: High — without portability the wallet-choice right (BOR-02 and Utah Code § 63A-20-301(1)(f)) becomes nominal.

Roles: Department, Wallet Providers

Assessment Objectives

Determine if:

1. credential formats support holder-initiated export from a conforming wallet;
2. wallet interfaces support holder-initiated import of an exported SEDI into a different conforming wallet;
3. portability does not require re-issuance of the credential;
4. portability does not require repeated identity proofing;
5. portability does not require interaction with the Department;
6. the holder's binding to the personal digital identifier (CRY-02) is preserved after portability;
7. no privacy or security property is degraded by the portability mechanism.

Verification Methods

Objective coverage: AUTO → 1, 2, 3, 6; EXPT → 4, 5, 7

Assessment objects: Credential export/import specification; wallet interoperability test results across at least two distinct wallet implementations; key binding preservation verification after migration; privacy property analysis of the portability mechanism; wallet SDK documentation for export and import APIs.

Statutory compliance: Round-trip portability is automatically testable; automated verification is mandatory.

SEDI-INT-04: No privacy-degrading fallback

Derived: Interoperability shall not weaken privacy or security properties.

Utah Code § 63A-20-301(1)(c)

Requirement: Interoperability mechanisms SHALL NOT include compatibility modes, fallback paths, or downgrade negotiations that weaken selective disclosure, unlinkability, predicate proofs, holder control, or any other privacy or security property required elsewhere in this Guide. Where compatibility with an external system would require degrading a privacy or security property, conforming SEDI implementations SHALL refuse the interaction rather than degrade.

Criticality: Critical — a single privacy-degrading fallback path can be used to systematically circumvent the entire privacy framework.

Roles: Department, Wallet Providers, Verifiers

Assessment Objectives

Determine if:

1. no compatibility mode, fallback path, or downgrade negotiation weakens selective disclosure;
2. no compatibility mode, fallback path, or downgrade negotiation weakens unlinkability;
3. no compatibility mode, fallback path, or downgrade negotiation weakens predicate proofs;
4. no compatibility mode, fallback path, or downgrade negotiation weakens holder control;
5. conforming SEDI implementations refuse interaction rather than degrade privacy or security properties when compatibility with an external system would require degradation.

Verification Methods

Objective coverage: AUTO → 1, 2, 3, 4, 5; EXPT → 1, 2, 3, 4, 5

Assessment objects: Interoperability protocol specifications; compatibility mode and fallback path inventory; protocol negotiation implementation source code; negative test results demonstrating refusal of privacy-degrading modes; architectural review report of all interoperability paths; wallet and verifier SDK documentation for protocol negotiation.

Statutory compliance: Identification of privacy-degrading paths requires architectural judgment; expert review is mandatory.

Key Management

The statute requires the Department to incorporate "state-of-the-art safeguards" (Utah Code § 63A-20-301(1)(a)), "comply with the requirements of this chapter through technological means where possible" (Utah Code § 63A-20-301(2)(b)), and use "best practices in collection, processing, storage, and disclosure" (Utah Code § 63A-20-301(2)(d)) for credential infrastructure maintained within a state-controlled data center (Utah Code § 63A-20-301(2)(c)). The KMS requirements specify what "best practices" mean for the cryptographic key material that anchors the entire trust chain. They are informed by NIST SP 800-57 Parts 1 through 3 (Recommendation for Key Management), FIPS 140-3 (Security Requirements for Cryptographic Modules), and the TSA mDL Final Rule Appendix A (see Annex F).

SEDI-KMS-01: Key lifecycle policy

Derived: The Department shall maintain a documented key management policy aligned with NIST SP 800-57.

Utah Code § 63A-20-301(1)(a), 301(2)(d)

Requirement: The Department SHALL maintain and publish a documented key management policy governing the generation, storage, distribution, rotation, revocation, and destruction of all cryptographic keys used in the SEDI system. The policy SHALL be aligned with NIST SP 800-57 Parts 1 through 3 and SHALL be reviewed and updated at least annually.

Criticality: Critical — the policy is the governing reference for KMS-02 through KMS-05; absence or staleness undermines all downstream key management controls.

Roles: Department

Assessment Objectives

Determine if:

1. the Department maintains a documented key management policy;
2. the policy is publicly published;
3. the policy covers generation, storage, distribution, rotation, revocation, and destruction of all key types covered by the policy;
4. the policy is aligned with NIST SP 800-57 Parts 1 through 3;
5. the policy has been reviewed and updated within the policy review cadence.

Verification Methods

Objective coverage: EXPT → 3, 4; ADMN → 1, 2, 3, 5, params

Assessment objects: Published key management policy document; NIST SP 800-57 alignment mapping; key type inventory; policy revision history and review records; cryptographic key usage register listing all active key types in the SEDI system.

Statutory compliance: Policy maintenance is administrative by nature; administrative review is mandatory.

SEDI-KMS-02: Key generation ceremonies

Derived: Credential signing keys shall be generated through a multi-party, auditable ceremony.

Utah Code § 63A-20-301(1)(a), 301(2)(d)

Requirement: Credential signing keys (root and operational) SHALL be generated through a documented, multi-party key generation ceremony. The ceremony SHALL: (a) require participation of at least two authorized key custodians under split-knowledge or multi-party control; (b) be witnessed by personnel independent of the custodians; (c) produce tamper-evident logs of all ceremony actions; and (d) take place inside the state-controlled data center (per SDI-13).

Criticality: Critical — single-party key generation enables undetected key copying at the moment of greatest risk.

Roles: Department

Assessment Objectives

Determine if:

1. credential signing keys (root and operational) are generated through the ceremony script and procedures;
2. the ceremony requires participation of the minimum number of key custodians under split-knowledge or multi-party control;
3. the ceremony is witnessed by personnel independent of the custodians;
4. tamper-evident logs of all ceremony actions are produced and retained;
5. the ceremony takes place inside the state-controlled data center (per SDI-13).

Verification Methods

Objective coverage: EXPT → 1, 2, 3, 4, 5; ADMN → 1, 2, 3, 4, 5, params

Assessment objects: Key generation ceremony script; custodian roster and authorization records; independent witness attestation records; tamper-evident ceremony logs; data center access records for ceremony dates; split-knowledge or multi-party control implementation documentation; ceremony video or photographic records where permitted.

Statutory compliance: Ceremony integrity is an organizational property; administrative verification is mandatory.

SEDI-KMS-03: Hardware security modules

Derived: Credential signing private keys shall be stored in FIPS 140-3 validated hardware security modules.

Utah Code § 63A-20-301(1)(a), 301(2)(d)

Requirement: Credential signing private keys SHALL be generated and stored in hardware security modules validated to at least FIPS 140-3 Level 2. Root and issuer keys SHOULD use FIPS 140-3 Level 3 or higher. Private keys SHALL NOT be exportable in cleartext from the HSM under any circumstances. The Department SHALL retain sole operational control of all HSMs used for SEDI signing.

Criticality: Critical — software-resident signing keys are recoverable from compromised systems and from forensic captures.

Roles: Department

Assessment Objectives

Determine if:

1. credential signing private keys are generated within hardware security modules;
2. credential signing private keys are stored in hardware security modules validated to the minimum FIPS 140-3 validation level for their key type;
3. root and issuer keys use FIPS 140-3 Level 3 or higher validated modules;
4. private keys are not exportable in cleartext from the HSM under any circumstances;
5. the Department retains sole operational control of all HSMs used for SEDI signing.

Verification Methods

Objective coverage: AUTO → 4; EXPT → 1, 2, 3, 4, 5; ADMN → 2, 5, params

Assessment objects: FIPS 140-3 validation certificates for all HSMs in use; HSM configuration records demonstrating non-exportability settings; HSM physical and logical access control documentation; Department operational control attestations; HSM inventory with serial numbers, locations, and validation levels; key type-to-HSM mapping register.

Statutory compliance: HSM validation and configuration require expert verification; expert and administrative methods are jointly mandatory.

SEDI-KMS-04: Key rotation

Derived: Signing keys shall be rotated before expiration without invalidating in-flight credentials.

Utah Code § 63A-20-301(1)(a), 301(2)(d)

Requirement: The Department SHALL define maximum validity periods for all credential signing keys and SHALL rotate keys before their expiration. Key rotation SHALL NOT invalidate previously issued credentials within their stated validity period. The Department SHALL publish a key rotation schedule and SHALL notify ecosystem participants of impending rotations with sufficient lead time for verifier trust store updates.

Criticality: High — failure to rotate increases the blast radius of key compromise; abrupt rotation that invalidates in-flight credentials disrupts holders.

Roles: Department

Assessment Objectives

Determine if:

1. maximum validity periods are defined for all credential signing keys;
2. keys are rotated before their expiration;
3. key rotation does not invalidate previously issued credentials within their stated validity period;
4. the Department publishes a key rotation schedule;
5. ecosystem participants are notified of impending rotations within the minimum notification lead time.

Verification Methods

Objective coverage: AUTO → 1, 3; ADMN → 2, 4, 5, params

Assessment objects: Published key rotation schedule; key expiration metadata in issued credentials; test results demonstrating continued validity of credentials signed under rotated-out keys; rotation event logs with timestamps; ecosystem notification records with lead time evidence; key validity period policy documentation.

Statutory compliance: Rotation behavior is partly testable and partly procedural; both methods are mandatory.

SEDI-KMS-05: Key compromise response

Derived: The Department shall maintain a key compromise response plan covering detection, notification, revocation, re-issuance, and review.

Utah Code § 63A-20-301(1)(a), 301(2)(d), 301(6)

Requirement: The Department SHALL maintain a documented key compromise response plan that includes: (a) detection mechanisms for suspected compromise; (b) internal and external notification procedures coordinated with the breach reporting obligations of SDI-24; (c) revocation procedures for compromised keys; (d) re-issuance procedures for affected credentials; and (e) post-incident review with publication of redacted findings. The plan SHALL be exercised at least annually.

Criticality: Critical — the speed and discipline of compromise response determines the blast radius of any key incident.

Roles: Department

Assessment Objectives

Determine if:

1. the Department maintains a documented key compromise response plan;
2. the plan includes detection mechanisms for suspected compromise;
3. the plan includes internal and external notification procedures per the defined notification timeline, coordinated with breach reporting obligations (SDI-24);
4. the plan includes revocation procedures for compromised keys within the defined maximum time from compromise detection to key revocation;
5. the plan includes re-issuance procedures for affected credentials;
6. the plan includes post-incident review with publication of redacted findings;
7. the plan is exercised at least annually.

Verification Methods

Objective coverage: EXPT → 2, 3, 4, 5, 6; ADMN → 1, 2, 3, 4, 5, 6, 7, params

Assessment objects: Key compromise response plan document; annual exercise records and after-action reports; compromise detection mechanism documentation; notification procedure documentation and templates; key revocation procedure documentation; credential re-issuance procedure documentation; post-incident review reports (redacted); exercise participant rosters and scenario descriptions.

Statutory compliance: Response capability is procedural; administrative verification is mandatory.

Organizational Security

The state-controlled data center requirement (Utah Code § 63A-20-301(2)(c)) and the best-practices mandate (Utah Code § 63A-20-301(2)(d)) generate organizational security requirements for the Department's SEDI infrastructure. These are informed by the NIST SP 800-53 Rev. 5 control families and the TSA mDL Final Rule Appendix A categories (see Annex F for the mapping). They apply to the Department and to any third party operating SEDI infrastructure on the Department's behalf (per ORG-06).

SEDI-ORG-01: Access management

Derived: Administrative access to SEDI infrastructure shall follow least privilege with multi-factor authentication.

Utah Code § 63A-20-301(2)(b), 301(2)(d)

Requirement: Administrative access to SEDI credential issuance and key management systems SHALL follow the principle of least privilege. Access SHALL require multi-factor authentication. Privileged access SHALL be revoked within 4 hours of personnel role change or termination. Access reviews SHALL occur at least quarterly. Controls SHALL align with the NIST SP 800-53 Rev. 5 Access Control (AC) family and TSA mDL Final Rule Appendix A Category 2.

Criticality: Critical — overprivileged or stale accounts are the most common path to credential issuance compromise.

Roles: Department

Assessment Objectives

Determine if:

1. administrative access to SEDI credential issuance and key management systems follows the principle of least privilege per the access control matrix;
2. administrative access requires multi-factor authentication;
3. privileged access is revoked within 4 hours of personnel role change or termination;
4. access reviews occur at least quarterly;
5. controls align with the NIST SP 800-53 Rev. 5 Access Control (AC) family;
6. controls align with TSA mDL Final Rule Appendix A Category 2.

Verification Methods

Objective coverage: AUTO → 2; EXPT → 1, 2, 3, 5, 6; ADMN → 1, 3, 4, params

Assessment objects: Access control matrix and role-to-privilege mapping; MFA configuration evidence for all administrative access points; deprovisioning records with timestamps; quarterly access review reports with remediation actions; NIST SP 800-53 AC family control assessment; personnel termination and role-change workflow documentation; identity and access management system configuration.

Statutory compliance: Access control configuration requires expert verification; expert and administrative methods are jointly mandatory.

SEDI-ORG-02: Personnel security

Derived: Personnel with access to SEDI infrastructure shall undergo background screening and annual security training.

Utah Code § 63A-20-301(2)(b), 301(2)(d)

Requirement: All personnel with access to SEDI credential issuance or key management systems SHALL undergo background screening commensurate with their access level. Annual security awareness training SHALL be required. Separation of duties SHALL be enforced for critical operations. Controls SHALL align with NIST SP 800-53 Rev. 5 Personnel Security (PS) family and TSA mDL Final Rule Appendix A Category 4.

Criticality: High — unscreened or untrained personnel are a residual risk to all other controls.

Roles: Department

Assessment Objectives

Determine if:

1. all personnel with access to SEDI credential issuance or key management systems undergo screening per the background screening criteria;
2. annual security awareness training is completed by all personnel with SEDI system access;
3. separation of duties is enforced for the critical operations requiring separation of duties;
4. controls align with NIST SP 800-53 Rev. 5 Personnel Security (PS) family;
5. controls align with TSA mDL Final Rule Appendix A Category 4.

Verification Methods

Objective coverage: EXPT → 1, 3, 4, 5; ADMN → 1, 2, 3, params

Assessment objects: Background screening records and completion status; security awareness training curriculum and completion records; separation-of-duties matrix; personnel roster with access levels and screening status; NIST SP 800-53 PS family control assessment; critical operations inventory with assigned duty separations.

Statutory compliance: Personnel security is procedural; administrative verification is mandatory.

SEDI-ORG-03: Vulnerability management

Derived: Vulnerability scanning and penetration testing shall be conducted on a defined cadence.

Utah Code § 63A-20-301(2)(b), 301(2)(d)

Requirement: The Department SHALL conduct vulnerability scans on all SEDI infrastructure components at least quarterly and SHALL conduct independent penetration testing at least annually. Security patches for vulnerabilities SHALL be applied within timelines defined in the Department's published patch management policy, with critical-severity patches applied within an expedited window. Scans and tests SHALL be performed by qualified personnel who are organizationally independent of system operations. Controls SHALL align with NIST SP 800-53 Rev. 5 Risk Assessment (RA) and System and Information Integrity (SI) families and TSA mDL Final Rule Appendix A Category 8.

Criticality: High — unmanaged vulnerabilities compound over time and create reliable exploitation paths.

Roles: Department

Assessment Objectives

Determine if:

1. vulnerability scans are conducted on all SEDI infrastructure components at least quarterly;
2. independent penetration testing is conducted at least annually;
3. security patches are applied within the patch application timeline for their severity level;
4. critical-severity patches are applied within the expedited window for critical-severity patches;
5. scans and tests are performed by qualified personnel organizationally independent of system operations;
6. controls align with NIST SP 800-53 Rev. 5 Risk Assessment (RA) and System and Information Integrity (SI) families;
7. controls align with TSA mDL Final Rule Appendix A Category 8.

Verification Methods

Objective coverage: EXPT → 2, 5, 6, 7; ADMN → 1, 3, 4, params

Assessment objects: Vulnerability scan reports with timestamps and scope documentation; penetration test reports with finding-to-remediation tracking; patch management policy; patch application records with severity classifications and timelines; organizational independence attestation for scan and test personnel; NIST SP 800-53 RA and SI family control assessments; remediation tracking database.

Statutory compliance: Independent penetration testing is the most reliable verification; expert and administrative methods are jointly mandatory.

SEDI-ORG-04: Logging and monitoring

Derived: Security-relevant events shall be logged with cryptographically protected integrity.

Utah Code § 63A-20-301(2)(b), 301(2)(d)

Requirement: All SEDI infrastructure components SHALL log security-relevant events including: authentication attempts, administrative actions, key lifecycle events, configuration changes, and system failures. Logs SHALL be retained for a minimum period defined in the log retention period. Log integrity SHALL be cryptographically protected and continuously monitored. Logs SHALL NOT contain holder-identifying information from individual presentations; doing so would conflict with SDI-17 and PRV-03. Controls SHALL align with NIST SP 800-53 Rev. 5 Audit and Accountability (AU) family and TSA mDL Final Rule Appendix A Categories 6 and 7.

Criticality: High — without trustworthy logs, post-incident analysis and routine monitoring are impossible.

Roles: Department

Assessment Objectives

Determine if:

1. all SEDI infrastructure components log the security-relevant event categories;
2. logs are retained for at least the defined log retention period;
3. log integrity is cryptographically protected;
4. logs are continuously monitored;
5. logs do not contain holder-identifying information from individual presentations (per SDI-17 and PRV-03);
6. controls align with NIST SP 800-53 Rev. 5 Audit and Accountability (AU) family;
7. controls align with TSA mDL Final Rule Appendix A Categories 6 and 7.

Verification Methods

Objective coverage: AUTO → 1, 2, 3, 5; EXPT → 4, 5, 6, 7, params

Assessment objects: Log configuration and event category definitions; log samples demonstrating coverage of defined event categories; cryptographic integrity protection mechanism documentation; log retention policy and storage configuration; monitoring and alerting system configuration; log content analysis confirming absence of holder-identifying data; NIST SP 800-53 AU family control assessment; SIEM or log management platform configuration.

Statutory compliance: Log conformance is partly automatable; automated verification is mandatory.

SEDI-ORG-05: Incident response

Derived: The Department shall maintain and exercise an incident response plan with breach notification.

Utah Code § 63A-20-301(1)(a), 301(2)(b), 301(2)(d), 301(6)

Requirement: The Department SHALL maintain a documented incident response and recovery plan that includes: (a) automated alerting on critical security events; (b) initiation of response within the defined response initiation timeline; (c) breach notification consistent with Utah Code §§ 63A-20-301(6) and 63A-19-405; and (d) post-incident review with corrective actions tracked to closure. The plan SHALL be reviewed and exercised at least annually. Controls SHALL align with NIST SP 800-53 Rev. 5 Incident Response (IR) family and TSA mDL Final Rule Appendix A Category 8.

Criticality: Critical — response capability is the difference between a contained incident and a systemic failure.

Roles: Department

Assessment Objectives

Determine if:

1. the Department maintains a documented incident response and recovery plan;
2. the plan includes automated alerting on the critical security event categories;
3. the plan requires initiation of response within the defined response initiation timeline;
4. the plan includes breach notification per the breach notification timelines and recipient lists and consistent with Utah Code §§ 63A-20-301(6) and 63A-19-405;
5. the plan includes post-incident review with corrective actions tracked to closure;
6. the plan is reviewed at least annually;
7. the plan is exercised at least annually;
8. controls align with NIST SP 800-53 Rev. 5 Incident Response (IR) family;
9. controls align with TSA mDL Final Rule Appendix A Category 8.

Verification Methods

Objective coverage: EXPT → 2, 3, 5, 8, 9; ADMN → 1, 2, 3, 4, 5, 6, 7, params

Assessment objects: Incident response and recovery plan document; automated alerting configuration and test results; exercise records and after-action reports; post-incident review reports with corrective action tracking; breach notification records and templates; plan revision history; NIST SP 800-53 IR family control assessment; critical event category definitions.

Statutory compliance: Incident response is procedural; administrative verification is mandatory.

SEDI-ORG-06: Third-party compliance

Derived: Delegated third parties shall meet equivalent KMS and ORG obligations.

Utah Code § 63A-20-301(2)(b), 301(2)(c), 301(2)(d)

Requirement: Where the Department uses delegated third parties for any SEDI infrastructure function (including hosting, key custody, credential issuance services, or identity proofing), the Department SHALL ensure that the third party complies with all applicable KMS and ORG requirements. Compliance SHALL be established through written agreements imposing equivalent obligations and SHALL be verified through independent audit at least annually. The Department SHALL retain ultimate accountability for the conduct of delegated third parties. Controls SHALL align with NIST SP 800-53 Rev. 5 System and Services Acquisition (SA) family.

Criticality: Critical — delegation transfers operations but not statutory accountability; gaps at third parties are gaps in the Department's compliance posture.

Roles: Department

Assessment Objectives

Determine if:

1. written agreements with delegated third parties impose the KMS and ORG requirements applicable to each delegated function;
2. third-party compliance is verified through independent audit at least annually;
3. the Department retains ultimate accountability for the conduct of delegated third parties;
4. controls align with NIST SP 800-53 Rev. 5 System and Services Acquisition (SA) family;
5. all delegated third parties are identified in the third-party inventory.

Verification Methods

Objective coverage: EXPT → 1, 2, 4; ADMN → 1, 2, 3, 5, params

Assessment objects: Third-party contracts and service agreements with KMS/ORG obligation clauses; independent audit reports for each delegated third party; third-party inventory register with function mapping; requirement applicability matrix by third party; NIST SP 800-53 SA family control assessment; Department accountability framework documentation; third-party incident notification records.

Statutory compliance: Third-party verification requires independent audit; expert and administrative methods are jointly mandatory.

SEDI-ORG-07: Change management

Derived: Changes to SEDI infrastructure shall follow documented change management with risk assessment, testing, approval, and rollback.

Utah Code § 63A-20-301(2)(b), 301(2)(d)

Requirement: Significant changes to SEDI issuance infrastructure, key management procedures, or security controls SHALL follow a documented change management process that includes: (a) risk assessment, (b) testing in a non-production environment that mirrors production, (c) approval by authorized personnel, and (d) documented rollback procedures. Emergency changes SHALL be subject to expedited review and post-implementation reconciliation. Controls SHALL align with NIST SP 800-53 Rev. 5 Configuration Management (CM) family and TSA mDL Final Rule Appendix A Category 1.

Criticality: High — undisciplined change is a leading cause of security regressions and outages.

Roles: Department

Assessment Objectives

Determine if:

1. changes meeting the significant change criteria follow a documented change management process;
2. the change management process includes risk assessment for each significant change;
3. changes are tested in a non-production environment that mirrors production;
4. changes require approval by the authorized change approvers before deployment;
5. documented rollback procedures exist for each significant change;
6. emergency changes are subject to expedited review and post-implementation reconciliation;
7. controls align with NIST SP 800-53 Rev. 5 Configuration Management (CM) family;
8. controls align with TSA mDL Final Rule Appendix A Category 1.

Verification Methods

Objective coverage: EXPT → 1, 2, 3, 5, 7, 8; ADMN → 1, 2, 3, 4, 5, 6, params

Assessment objects: Change management policy and procedures; change tickets with risk assessments, test evidence, approval records, and rollback documentation; non-production environment configuration documentation; emergency change records with post-implementation reconciliation; significant change criteria definition; authorized approver roster; NIST SP 800-53 CM family control assessment; configuration baseline documentation.

Statutory compliance: Change discipline is procedural; administrative verification is mandatory.

Technology Limitations (Informative)

This section documents areas where statutory requirements cannot be fully enforced through technical means alone. For each, the limitation explains why a technical control is not feasible and identifies the administrative or contractual controls that fill the gap. These classifications are intentionally open to challenge: if a party can demonstrate a feasible technical control, the classification should be upgraded.

Onward Sharing of Disclosed Attributes

Statutory requirement: Utah Code § 63A-20-702 restricts processing and sharing of presentation data to the primary purpose.

Technology limitation: Once identity attributes are disclosed to a verifier or relying party in plaintext (which is necessary for the relying party to act on them), no known technology can prevent the recipient from copying, forwarding, screenshotting, or sharing that data with a third party. This is a fundamental property of information rather than a gap in implementation.

Required administrative controls: Contractual terms of use for verifiers and relying parties; legal enforcement via Utah Code § 63A-20-801; audit logging of downstream data access where feasible.

"State-of-the-Art" Determination

Statutory requirement: Multiple sections require "state-of-the-art safeguards" (Utah Code §§ 63A-20-301(1)(a), 401(1)(a), 501(1)(a), 601(1)(a)).

Technology limitation: "State of the art" is a moving target that cannot be encoded in a static technical test. What constitutes state-of-the-art cryptography, tamper resistance, or security practices evolves continuously.

Required administrative controls: Periodic security assessments at minimum annually; tracking of CVEs and cryptographic deprecations; documented process for updating technical requirements when the state of the art advances.

Usability

Statutory requirement: Utah Code § 63A-20-301(1)(g) requires the SEDI to be "easy for a holder to adopt and use."

Technology limitation: Usability is inherently subjective and context-dependent. Automated testing can verify that specific anti-patterns are absent (for example, no command-line required, no multi-step key ceremony), but whether a system is "easy" requires human evaluation with representative users across diverse demographics, abilities, and technical literacy levels.

Required administrative controls: Usability testing program; accessibility compliance (WCAG 2.1 AA minimum); user feedback collection and response process.

Duty of Loyalty

Statutory requirement: Utah Code § 63A-20-701 requires ecosystem participants to refrain from practices conflicting with individuals' best interests, exploitation, disproportionate risk, detriment, or harm.

Technology limitation: "Best interests," "exploitation," and "harm" are contextual legal and ethical concepts that cannot be fully reduced to programmatic rules. Technology can enforce data minimization (a proxy for some loyalty obligations) but cannot evaluate whether a business practice "takes advantage of" an individual.

Required administrative controls: Code of conduct for ecosystem participants; complaint and enforcement process per Utah Code § 63A-20-801; periodic review of ecosystem participant practices.