Introduction

Normative Language

Terms used in this document are defined in Utah Code § 63A-19-201. This document also uses the rules of construction described in Utah Code § 68-3-12 for the interpretation of any statutory or legal requirements.

The capitalized key words "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," and "MAY" are used as specified in RFC 2119 to indicate technical 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

Each part corresponds to Title 63A, Chapter -20. Within each part, 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" (Utah Code §§ 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 (Utah Code § 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 (Utah Code § 63A-20-301(3))
• Digital Identity Bill of Rights (Utah Code § 63A-20-101)
• Mandatory selective disclosure and age predicate proofs (Utah Code § 63A-20-101)
• State data center residency requirements (Utah Code § 63A-20-101)
• Duty of loyalty obligations on all ecosystem participants (Utah Code § 63A-20-101)

Many other types of verifiable records and credentials exist or will exist in Utah's ecosystem, including birth records, property records, professional licenses, and more (see, e.g., Electronic Records Amendments, H.B. 319 (2026) 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 Utah Code Title  63A, Chapter- 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 Utah Code § 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 subject to Utah Code Title 63A,- Chapter 20. Any conflicts between this guide and the statute, shall be resolved in favor of the statute.

Requirement ID Domains

Purpose and Scope

This implementation guide 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.

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 (Utah Code § 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 (Utah Code § 63A-20-101(10)) combined with the prohibition on Department monitoring of presentations (Utah Code § 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 (Utah Code § 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 (Utah Code § 63A-20-101(3)), the right to not be compelled to use digital identity (Utah Code § 63A-20-101(4)), and the prohibition on conveying material benefits for digital over physical (Utah Code § 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 (Utah Code § 63A-20-101(8)), combined with the selective disclosure requirements (Utah Code § 63A-20-301(1)(e)) and the requirement for age verification without revealing age or date of birth (Utah Code § 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.