Introduction¶

Version History¶

Normative Language¶

This document uses the capitalized key words "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," and "MAY" as specified in RFC 2119 to indicate requirement levels.

In addition, lowercase "must" indicates an external constraint (e.g., a requirement imposed by a referenced standard rather than by this document). The word "can" indicates a capability. Other words such as "will" and "is" are statements of fact.

How to Read This Document¶

This document translates statutory requirements from Utah Code Chapter 63A-20 (enacted via S.B. 275, 2026 General Session) into technology-neutral technical requirements suitable for implementation, evaluation, and certification.

Each Part chapter corresponds to a Part of Chapter 63A-20. Within each chapter, a requirements table maps:

• Req ID: A unique identifier for the requirement (format: SEDI-{DOMAIN}-{SEQ})
• Statutory Cite: The specific subsection of Utah Code being implemented
• Statutory Text: Verbatim or summarized statutory language
• Technical Requirement: The technology-neutral technical interpretation, using RFC 2119 keywords
• Control Type: How the requirement is enforced (see below)
• Governance Instrument: Whether the requirement is implemented through statute, administrative rule, or programmatic policy
• Evaluation Criteria: How conformance would be assessed
• Applicable Roles: Which ecosystem actors bear responsibility

Requirements marked [TBD] require further technical analysis.

Three Layers of Governance¶

The statute establishes requirements at the statutory level but delegates significant implementation detail to two additional layers:

For each statutory requirement, this guide identifies which governance layer carries the implementation detail. The statute itself identifies eight topics that explicitly require administrative rulemaking (see Rulemaking Requirements).

Verification Methods¶

The statute mandates compliance "through technological means where possible" (63A-20-301(2)(b), 401(1)(c), 501(1)(b), 601(1)(b)). This creates a legal presumption favoring technological enforcement, but does not mean automated testing is always sufficient or superior.

This guide specifies verification methods for each requirement. A verification method is how compliance is assessed. Each requirement can have one or more methods across three types:

These are not ranked. Different methods catch different failure modes. Critical requirements typically need methods from multiple types.

Key rules:

• If an Automated method is feasible, it is mandatory under the statute's "technology where possible" mandate. Expert and Administrative methods may supplement but cannot substitute for Automated when Automated is feasible.
• Each requirement also has an independent criticality rating (Critical / High / Medium) based on blast radius if the control fails. Criticality determines audit frequency and remediation timelines.
• Every verification method must specify its limitations: what it does NOT catch. No method is complete on its own.
• Automated specs SHOULD reference existing conformance test suites (ISO 18013-5, W3C VC, NIST SP 800-63, FIDO, etc.) rather than defining new tests from scratch.

Assessment Structure¶

This guide's assessment structure is informed by NIST SP 800-53A Rev. 5, adapted for the digital identity context. Each requirement includes three assessment components:

Assessment Objectives decompose the requirement into individually assessable "Determine if:" statements. Each statement is a single claim that can be independently verified as satisfied or not satisfied. Assessment objectives define what to verify, independent of how to verify it.

Implementation Decisions, listed at the top of each chapter, identify values, thresholds, or policy decisions that the implementing organization must specify before assessment can proceed. Each decision links to the requirement it supports, and assessment objectives that depend on a decision link back to it by name.

Verification Methods (AUTO, EXPT, ADMN) define how each objective is assessed. Multiple methods may apply to the same objective. Where automated verification is feasible, it is mandatory under the statute's "technology where possible" mandate. An Objective coverage line below the table maps each method to the numbered objectives it assesses. AUTO must always appear as a table row; when automated testing is infeasible, the Limitations column explains why.

Assessment Objects identify what artifacts, systems, or documentation the assessor examines or tests against. These correspond to 800-53A's "potential assessment objects" and ensure assessors know where to look, not just what to check.

Example of an inherent technology limitation: Once identity attributes are disclosed to a verifier or relying party in plaintext, no known technology can prevent the recipient from copying, forwarding, or sharing that data with a third party. The statutory requirement to limit onward sharing (63A-20-702) must therefore rely on contractual and legal obligations, not technical prevention. This is a fundamental property of information, not a gap in implementation.

Scope: SEDI vs. General Verifiable Credentials¶

This guide addresses the State-Endorsed Digital Identity (SEDI) credential specifically. SEDI is one type of verifiable credential, but it carries additional statutory constraints that other credentials do not, including:

• Anti-surveillance protections (63A-20-301(3))
• Digital Identity Bill of Rights (63A-20-101)
• Mandatory selective disclosure and age predicate proofs
• State data center residency requirements
• Duty of loyalty obligations on all ecosystem participants

Many other types of verifiable records and credentials exist or will exist in Utah's ecosystem, including birth records, land records, professional licenses, and more (see, e.g., H.B. 319 regarding county records). These may reuse parts of the SEDI technical infrastructure (credential formats, wallet standards, verification protocols) but are not SEDI credentials and are not governed by Chapter 63A-20.

This guide does not address non-SEDI credentials directly. However, the verification methods framework (AUTO/EXPT/ADMN) and organizational security requirements (KMS, ORG) are designed to be reusable across other verifiable digital credential (VDC) programs established under adjacent legislation, such as Section 63A-16-108 (Verifiable Digital Credentials). Future companion guides may extend these controls to cover additional credential types without duplicating the framework.

Relationship to Utah Code¶

This implementation guide is subordinate to Utah Code Chapter 63A-20 ("State-Endorsed Digital Identity") as enacted by S.B. 275 (2026 General Session, effective May 6, 2026). Where any conflict exists between this guide and the statute, the statute controls.

S.B. 260 (2025 General Session) established foundational state policy in Sections 63A-16-1201 through 63A-16-1203. S.B. 275 repeals those sections and supersedes them with the comprehensive Chapter 63A-20 framework. The policy principles from S.B. 260 are preserved and expanded in Chapter 63A-20, Part 1 (Digital Identity Bill of Rights) and Part 3 (State-Endorsed Digital Identity requirements).

Requirement ID Domains¶

Purpose and Scope¶

This implementation guide provides a technology-neutral framework for implementing Utah's State-Endorsed Digital Identity (SEDI) program as established by Utah Code Chapter 63A-20. It serves three functions:

1. Translation: Restating each statutory requirement in technical terms that implementers can act on.
2. Evaluation: Defining criteria by which compliance with each requirement can be assessed.
3. Conformance: Establishing a profile mechanism by which specific technologies can demonstrate they satisfy the requirements without the base document naming those technologies.

This guide does not mandate specific protocols, credential formats, cryptographic algorithms, or software architectures. Instead, it specifies the properties, capabilities, and constraints that any compliant implementation must satisfy.

Audience¶

• Primary: Technical implementers, system architects, standards engineers, and conformance assessors responsible for designing, building, or evaluating SEDI-compliant systems. Familiarity with digital identity concepts (identity proofing, verifiable credentials, selective disclosure, cryptographic key management) is assumed.
• Secondary: Policymakers, program managers, legislative staff, and oversight bodies who need to understand the technical direction of the SEDI program and assign work to technical staff. The Introduction, Part 1, and the Conformance chapter provide sufficient high-level context; the requirements tables in each Part provide traceability to statutory intent.

Legal Authority¶

• S.B. 260 (2025 General Session): Enacted Sections 63A-16-1201 through 63A-16-1203, establishing foundational definitions, state policy, and Department study duties. Effective May 7, 2025.
• S.B. 275 (2026 General Session, 1st Substitute): Creates Chapter 63A-20 with 9 Parts and 18 sections. Repeals Sections 63A-16-1201 through 63A-16-1203. Effective May 6, 2026.
• Chief Sponsor: Senator Kirk A. Cullimore. House Sponsor: Representative Paul A. Cutler.
• Administering Agency: Utah Department of Government Operations.

For the complete authority table, see the Overview.

Design Principles¶

Five principles derived from the statute guide all technical decisions in this implementation guide:

Principle 1: Individual Sovereignty

An individual possesses an identity innate to the individual's existence and independent of the state (Section 63A-20-101(1)). The state does not create identity; it may only endorse identity that the individual already possesses. All design decisions must preserve the individual's ultimate control over their identity and its digital representation.

Principle 2: Privacy by Architecture

The right to be free from surveillance, profiling, tracking, or persistent monitoring (Section 63A-20-101(10)) combined with the prohibition on Department monitoring of presentations (Section 63A-20-301(3)) requires that privacy protections be structural, not merely policy-based. The system architecture must make surveillance impossible by design, not just prohibited by rule.

Principle 3: Technology Neutrality through Open Standards

The mandate to select open technological standards that are publicly available and free from licensing fees and patent restrictions (Section 63A-20-301(2)(e)) ensures that no single vendor or technology captures the ecosystem. This guide specifies outcomes and properties; conformance profiles supply specific technology choices.

Principle 4: Equivalence with Physical Identity

The right to choose physical identity (Section 63A-20-101(3)), the right to not be compelled to use digital identity (Section 63A-20-101(4)), and the prohibition on conveying material benefits for digital over physical (Section 63A-20-304(1)(a)) establish that SEDI complements, never replaces, physical identity. Every service pathway must accommodate physical identity holders without penalty or diminishment.

Principle 5: Holder-Directed Disclosure

The right to choose which identity attributes are disclosed (Section 63A-20-101(8)), combined with the selective disclosure requirements (Section 63A-20-301(1)(e)) and the requirement for age verification without revealing age or date of birth (Section 63A-20-301(1)(e)(ii)), mandate that the holder alone determines what information is shared, with whom, and when. The system must support granular, attribute-level disclosure decisions.

Relationship to Other Standards¶

This guide is informed by, but does not depend on, existing digital identity frameworks. The guide specifies required properties and capabilities (selective disclosure, predicate proofs, offline verification, etc.) without mandating specific protocols, credential formats, or cryptographic schemes. Specific technology choices are delegated to conformance profiles (see Conformance).

Normative and informative references:

Candidate technologies for conformance profiles. Inclusion does not constitute endorsement, selection, or preference. Any technology that can satisfy the base requirements may be the subject of a conformance profile.

Annex D provides a non-normative mapping between SEDI requirements and capability categories addressed by these and other frameworks.