Network Working Group T. Le Internet-Draft 22 August 2026 Intended status: Informational Expires: 23 February 2027 SCITT Profile for Independently Derived Subjects draft-le-scitt-derived-subjects-00 Abstract The Supply Chain Integrity, Transparency, and Trust (SCITT) architecture permits distinct Issuers to agree on the same CBOR Web Token (CWT) Subject Claim (sub) value for a common Subject. This document specifies one profile by which those Issuers can independently compute that common value from the same application- defined Subject semantics without relying on a shared assigning authority. A surrounding application maps its Subject description to an admitted structured Value. This profile defines an exact deterministic binding encoding, SHA-256 derivation, a text representation, and verification requirements for deriving sub from that Value. Optional JSON and Concise Binary Object Representation (CBOR) forms are provided for exchanging an admitted Value; they are not SCITT Statement payload formats. The SCITT Statement payload, signature, Registration, Receipt, Transparency Service state, and Issuer identity are not implicit inputs to Subject derivation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 February 2027. Le Expires 23 February 2027 [Page 1] Internet-Draft SCITT Derived Subjects August 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Profile Scope and Layering . . . . . . . . . . . . . . . . . 4 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 4. Structured Value Input . . . . . . . . . . . . . . . . . . . 6 4.1. Application Mapping to Value . . . . . . . . . . . . . . 7 4.2. Application Mapping Evolution . . . . . . . . . . . . . . 9 5. Deterministic Binding Encoding . . . . . . . . . . . . . . . 9 5.1. Primitive Binding Encodings . . . . . . . . . . . . . . . 9 5.2. Injectivity of the Binding Encoding . . . . . . . . . . . 10 6. Subject Derivation . . . . . . . . . . . . . . . . . . . . . 11 7. Optional Structured Value Interchange Representations . . . . 13 7.1. JSON Representation . . . . . . . . . . . . . . . . . . . 13 7.2. CBOR Representation . . . . . . . . . . . . . . . . . . . 15 7.3. Cross-Representation Convergence . . . . . . . . . . . . 16 8. SCITT Integration . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Signed Statement Requirements . . . . . . . . . . . . . . 16 8.2. Transparency Boundary . . . . . . . . . . . . . . . . . . 17 8.3. Interaction with Existing SCITT and COSE Mechanisms . . . 17 9. Verification . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Establishing Applicable Comparison Semantics . . . . . . 18 9.2. Verification Procedure . . . . . . . . . . . . . . . . . 19 9.3. Comparison Results and Input Errors . . . . . . . . . . . 19 9.4. Meaning and Limits of MATCH . . . . . . . . . . . . . . . 20 10. Profile Succession . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 14. Normative References . . . . . . . . . . . . . . . . . . . . 24 15. Informative References . . . . . . . . . . . . . . . . . . . 26 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 27 A.1. Fully Empty Value . . . . . . . . . . . . . . . . . . . . 27 Le Expires 23 February 2027 [Page 2] Internet-Draft SCITT Derived Subjects August 2026 A.2. Empty Set Versus One Empty Scoped Identifier . . . . . . 28 A.3. ScopedIdentifier Pair Framing . . . . . . . . . . . . . . 29 A.4. Identifier Set Ordering and Convergence Across Representations . . . . . . . . . . . . . . . . . . . . . 30 A.5. Negative Vector: Duplicate Identifier Representation . . 31 A.6. Negative Vector: Non-Canonical Identifier Ordering . . . 32 A.7. Negative Vector: Base64url Text Ordering . . . . . . . . 32 Appendix B. Implementation and Interoperability Testing . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction [RFC9943] permits distinct Issuers to agree to use the same CWT Subject Claim (sub) value so that Statements about a common Subject can form a coherent collection. This specification defines one deterministic way to realize that agreement: Issuers using the same application-defined Subject semantics can independently compute the same sub value without requiring one party to assign that value to the others. The profile separates that interoperability problem into two boundaries. A surrounding application maps its richer Subject description to one exact structured comparison value. This document defines the SCITT-specific deterministic binding, SHA-256 derivation, text representation, and verification behavior that turns that admitted value into the protected CWT sub value. The reusable model semantics for the comparison-value boundary are imported normatively from [I-D.le-structured-value-model]. Optional JSON and CBOR forms can exchange an admitted Value, but they are not inputs to the derivation algorithm and are not SCITT Statement payload formats. This profile does not derive the Subject from the SCITT Statement payload. Different Issuers can make different Statements about the same Subject and still independently produce the same sub value. It does not define a generic payload binding mechanism, an identifier scheme for protected objects, or a Statement relationship graph. Signing, Registration, Receipts, Transparency Service behavior, Issuer authentication, and trust evaluation remain as defined by SCITT and related specifications. This document defines no new CWT claim, CBOR Object Signing and Encryption (COSE) header parameter, media type, content-format number, algorithm registry, identifier registry, or runtime naming service. Le Expires 23 February 2027 [Page 3] Internet-Draft SCITT Derived Subjects August 2026 2. Conventions and Terminology The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. These requirement keywords define conformance for an implementation or application that chooses to use this profile. They do not make support for this profile mandatory for SCITT implementations in general. SCITT terminology is used as defined by [RFC9943]. CWT terminology is used as defined by [RFC8392]. The terms Value and ScopedIdentifier are imported from [I-D.le-structured-value-model]. The surrounding application defines how its source Subject description maps to an admitted Value. Semantic comparison also requires the applicable profile, the structured value model semantics fixed by that profile, and the interpretation of imported (context, scope) values used by the Value. This document does not define a discovery, negotiation, registry, or trust protocol for obtaining that information. 3. Profile Scope and Layering [RFC9943] defines Subject as an Issuer-defined identifier by which Statements about the same organization, device, user, entity, or Artifact can be grouped, and permits distinct Issuers to agree to use the same sub value for a common Subject. This profile addresses only how those Issuers can independently compute that common value once the surrounding application has fixed the Subject semantics they share. It does not standardize how the application reaches that agreement. The profile boundary is: Le Expires 23 February 2027 [Page 4] Internet-Draft SCITT Derived Subjects August 2026 Application source object | | mapping v admitted Value | v BindingBytes(v) | SHA-256 | SubjectText(v) | CWT Subject Claim (sub) | SCITT Signed Statement | optional Registration/Receipt The optional JSON and CBOR forms in this document can carry a structurally admitted model Value that also lies in this v1 profile domain. They sit beside the core path shown above: they are not SCITT Statement payload formats, are not hashed by the derivation, and do not replace the mapping from a richer application source object to that Value. The Subject description is distinct from the Statement payload. A Receipt, Transparency Service state, registration time, Statement signature, Issuer identifier, Statement payload, or Statement position MUST NOT be an implicit input to SubjectText(v). 3.1. Applicability This profile is not required merely because a Subject can be independently identified. If one existing identifier already names the complete Subject under established semantics and is suitable for direct use as the CWT sub value, an application can use that identifier directly. Wrapping such an identifier solely to obtain another hash does not add comparison semantics. This profile is intended for cases in which the Subject is defined by a composition of exact local material and zero or more identifier results from independently governed schemes, or in which multiple accepted representations need to reconstruct the same structured Subject value before derivation. The profile supplies one deterministic SCITT Subject construction for that composed value without requiring the imported schemes to share a canonicalization, hash construction, registry, or identifier syntax. Le Expires 23 February 2027 [Page 5] Internet-Draft SCITT Derived Subjects August 2026 4. Structured Value Input This profile normatively imports from [I-D.le-structured-value-model] the definitions of Value and ScopedIdentifier and the model semantics needed to determine their structural admission and exact equivalence. The dependency is limited to that comparison-value boundary. This document does not import a wire representation, identifier scheme, resolver, registry, trust semantics, relationship model, or application mapping from that specification. For reader orientation, the following is a non-normative synopsis of the imported structures. It does not restate or replace the normative model definition: ScopedIdentifier := { scope : finite octet string, identifier : finite octet string } Value := { context : finite octet string, content : finite octet string, identifiers : finite set of ScopedIdentifier } The model dependency is normative because disagreement on structural admission or exact Value equivalence can change the input to BindingBytes and therefore the resulting Subject. This profile version adopts the structured value model semantics specified by its normative reference and inherits that model's exact equivalence relation. An implementation MUST NOT substitute successor or otherwise different structured value model semantics while continuing to claim conformance with this v1 profile. In particular, identifier order and duplicate presentation are not semantic distinctions, while complete identifier membership is relevant to comparison. Structural admission to the model and admission to this v1 derivation profile are distinct. Every Value derived by this profile MUST first be structurally admitted under the model. This profile then restricts derivation to the construction-specific bounds in Section 6. Those bounds do not redefine model admission or equivalence. Profile-domain membership is closed under model equivalence: if v1 ~ v2, either both Values satisfy the v1 profile bounds or neither does. Semantic Subject comparison under this profile requires the applicable comparison semantics to be established. Those semantics identify the profile version, the structured value model semantics Le Expires 23 February 2027 [Page 6] Internet-Draft SCITT Derived Subjects August 2026 fixed by that version, and a compatible mapping for the candidate Value, including the interpretation of every imported (context, scope) used by that Value. How parties discover, distribute, authenticate, pin, negotiate, or otherwise obtain that information is outside this profile. If a verifier cannot establish the applicable comparison semantics, the Subject comparison result is NOT_ESTABLISHED. This is an abstract result of the comparison procedure in this document; it is not a new CWT claim, COSE header parameter, SCITT error code, registry value, or wire protocol element. 4.1. Application Mapping to Value A surrounding SCITT application profile that claims independent Issuers can derive the same Subject from an application object, Artifact, or other richer source MUST define the mapping from source input to Value completely enough for independent implementations to produce equivalent admitted Values from source inputs that the application intends to identify as the same Subject. The mapping MUST also define or reference the Subject equivalence at the source level that this projection is intended to represent. That mapping MUST specify at least: * the exact context octets and the interpretation they have for comparison; * which source information becomes the exact content octets, including any canonicalization, projection, or other transformation applied before admission; * each imported identifier system, its exact (context, scope) mapping, the exact identifier octets carried, including any adaptation required when the imported identifier system does not already use exact octet equality for the relevant comparison, and any role, version, parameter, position, occurrence, or other qualification for an identifier that affects comparison and that the surrounding mapping places in the applicable scope under the structured value model; Le Expires 23 February 2027 [Page 7] Internet-Draft SCITT Derived Subjects August 2026 * the complete rule that determines membership of the mathematical identifiers set, including which imported identifier systems can contribute members, the required or optional membership and cardinality rules for each, and, when applicable, how absence, unavailability, discovery or validation failure, aliases, and version or successor forms affect membership, including whether multiple forms are adapted to one member, coexist as distinct members, or cause the source input to be rejected; and * every source distinction intentionally omitted, normalized, projected, or otherwise collapsed before the Value is formed. The mapping MAY be defined by another specification and MAY use independently governed identifier schemes. It also defines any validation required by the imported identifier system before identifier octets are imported; model structural admission alone does not validate a digest reference, URI, or other imported identifier. Discovery, validation, registry, resolver, clock, ledger, network, or other external state that can change whether a member is present in identifiers is comparison-relevant mapping input and MUST be supplied as a defined input or fixed unambiguously by the mapping. A transient failure or different ambient view MUST NOT silently enlarge or shrink the set. If membership required by the established mapping cannot be determined, the source input MUST be rejected rather than mapped to a different set, unless that outcome is itself explicitly part of the source semantics and mapping. The mapping does not require a global registry or resolver. Information from a Statement payload can participate only when the surrounding application explicitly makes that information part of the mapping from source input to Value; the Statement payload is never an ambient or implicit derivation input. A source distinction that changes the resulting Value cannot remain only in ambient application state while the same Value is supplied to this profile. If the mapping from source input to Value omits or collapses such a distinction, that loss occurs before BindingBytes and cannot be repaired by this profile's hash. If source inputs that are non-equivalent under the Subject relation that the mapping defines at the source level can nevertheless produce equivalent admitted Values, the mapping has introduced source-projection loss before profile derivation. That behavior MUST be explicit and characterized as part of the mapping rather than described as a false match introduced by this profile over non-equivalent admitted Values or attributed to SHA-256, consistent with [I-D.le-comparing-derived-identifiers]. Le Expires 23 February 2027 [Page 8] Internet-Draft SCITT Derived Subjects August 2026 4.2. Application Mapping Evolution The context octets selected by the mapping qualify the mapping semantics that affect comparison. They are a semantic comparison input carried in the Value; they are not the cryptographic Domain Separation Tag (DST) used by the Subject digest construction. The accepted semantic source domain is part of those mapping semantics. A successor mapping that admits a newly in-domain source meaning, changes which source meanings pass admission or validation required by the imported identifier system, changes the complete identifier- set membership or selection rule, changes which source distinctions participate, changes the resulting Value for a source already covered by the mapping, changes the meaning of an existing scope, or changes the rule by which scopes bind imported semantics MUST select new context octets. Reusing the old context for such a change would allow the same Value or SubjectText value to be interpreted under incompatible source semantics. New context octets are not required solely because an implementation accepts an additional JSON, CBOR, or application representation of a source meaning already covered by the mapping that reconstructs the same Value; gains capability without changing the admitted Value or its semantics; or gains support for an additional scope whose meaning was already determined by an unchanged deterministic rule that binds scopes to imported semantics. Changing an existing scope meaning or the binding rule itself is a mapping change and requires successor context octets. Correcting an implementation that previously failed to follow an unchanged mapping does not create a new mapping version; the earlier output was not produced according to that mapping. 5. Deterministic Binding Encoding 5.1. Primitive Binding Encodings BE64(n) is the eight-octet unsigned big-endian representation of integer n, for 0 <= n < 2^64. lp64(x) is: BE64(length(x)) || x where length(x) is the number of octets in x. lp64(x) is defined only when length(x) < 2^64. || denotes octet concatenation. Le Expires 23 February 2027 [Page 9] Internet-Draft SCITT Derived Subjects August 2026 For a scoped identifier q, define: ScopedIdentifierBytes(q) := lp64(q.scope) || lp64(q.identifier) A byte string is a valid ScopedIdentifierBytes value only if it consists of exactly two consecutive lp64 values, yielding scope and identifier, and the second value ends at the end of the byte string. Truncated encodings and trailing octets MUST be rejected. For every scoped identifier q in the mathematical set identifiers, compute ScopedIdentifierBytes(q) and sort the complete encodings by unsigned lexicographic order. Because identifiers is already a mathematical set, duplicate elimination is not an operation of BindingBytes. For the resulting sequence of distinct set members q[0] ... q[n-1], define: IdentifierSetEncoding(identifiers) := BE64(n) || ScopedIdentifierBytes(q[0]) || ... || ScopedIdentifierBytes(q[n-1]) The exact profile binding representation is: BindingBytes(v) := lp64(v.context) || lp64(v.content) || IdentifierSetEncoding(v.identifiers) The field order is part of this profile. On the admitted profile domain, this encoding preserves every distinction in the model equivalence relation before cryptographic compression. 5.2. Injectivity of the Binding Encoding The preservation claim above follows from the framing, rather than from SHA-256. BE64 has one fixed width. lp64(x) is self-delimiting because its first eight octets determine exactly how many following octets belong to x; therefore equal lp64 encodings imply equal input octets. A ScopedIdentifierBytes value is the concatenation of two such self-delimiting values and is therefore uniquely parseable back into exactly one (scope, identifier) pair, including when either component is empty. Le Expires 23 February 2027 [Page 10] Internet-Draft SCITT Derived Subjects August 2026 Canonical identifier set encoding first maps mathematical set membership to one sorted sequence of distinct ScopedIdentifierBytes values. Because each element encoding is injective and self- delimiting, the element count and sequence uniquely reconstruct the same mathematical set. Finally, the first two lp64 values in BindingBytes uniquely reconstruct context and content, after which the remaining bytes uniquely reconstruct the identifier set. Consequently, for Values in the admitted v1 profile domain: BindingBytes(v1) = BindingBytes(v2) if and only if v1 ~ v2 where ~ is the structured value model equivalence relation. The fixed profile prefix in SubjectPreimage does not change that property. SHA-256 is therefore the first many-to-one operation introduced by this profile; any earlier merge must have occurred in the surrounding mapping from source input to Value or inside an imported identifier before it entered the model. 6. Subject Derivation The fixed, version-specific octet string used for hash-input domain separation in the v1 Subject digest construction is the Domain Separation Tag (DST). This use of DST follows the established domain separation terminology described in [RFC9380]; it does not import the hash-to-curve construction from that document. The DST is distinct from the semantic context carried in a Value and from the textual SubjectText prefix. The DST does not by itself establish semantic compatibility between independently obtained profile definitions, authenticate such a definition, or authorize use of a profile version. DST := ASCII("scitt-derived-subject/v1") The identifier preimage is: SubjectPreimage(v) := lp64(DST) || BindingBytes(v) Because lp64 is unambiguous, distinct DSTs produce distinct framed Subject preimages before SHA-256 is applied, regardless of the following binding bytes: Le Expires 23 February 2027 [Page 11] Internet-Draft SCITT Derived Subjects August 2026 DST1 != DST2 => lp64(DST1) || B1 != lp64(DST2) || B2 Within a pinned profile definition, the exact DST is part of the hash-input domain for that definition. A successor profile with different derivation or Subject result semantics MUST NOT silently reuse the predecessor DST. The DST is not a global registry identifier and reuse of the same octets by another specification does not by itself establish compatible comparison semantics; compatibility depends on establishment of the complete applicable derivation and comparison semantics. Revision handling while this document remains an Internet-Draft is described in Section 10. The profile admits a value for derivation only when all profile encodings are defined and the final preimage is within the SHA-256 message length domain. Concretely: length(v.context) < 2^64 length(v.content) < 2^64 number_of_identifiers(v) < 2^64 for every q in v.identifiers: length(q.scope) < 2^64 length(q.identifier) < 2^64 length(SubjectPreimage(v)) < 2^61 octets The first five conditions make every BE64 and lp64 operation total on the admitted profile domain. The last condition ensures that the message, measured in octets, lies within the SHA-256 message length domain. These conditions define the v1 profile-domain restriction on structurally admitted model Values. Because they are functions only of the exact Value fields and set membership, they are invariant under model equivalence. They do not redefine model admission or model equivalence. They are also not local implementation resource limits. An implementation MAY impose smaller parsing, encoding, memory, or denial-of-service limits. Such a local capability policy MUST NOT change whether a Value is admitted by this profile and MUST NOT change SubjectText for a Value that the implementation processes. An implementation that reports a local resource refusal SHOULD distinguish it from malformed input or input outside the profile so that callers do not mistake capability for semantic admission. Define: SubjectDigest(v) := SHA-256(SubjectPreimage(v)) Le Expires 23 February 2027 [Page 12] Internet-Draft SCITT Derived Subjects August 2026 SHA-256 is specified by FIPS 180-4. The digest is exactly 32 octets. [FIPS180-4] The CWT Subject Claim value is the UTF-8 text string: SubjectText(v) := "scitt-derived-subject-v1." || base64url(SubjectDigest(v)) where base64url(x) is the canonical unpadded base64url encoding of x. The prefix contains no colon, and the complete value is used as an ordinary CWT text string for the Subject Claim. This profile does not claim that the prefix is a URI scheme or a globally allocated namespace outside the applicable profile semantics. A text value is a well-formed SubjectText for this profile version only when it consists of the exact scitt-derived-subject-v1. prefix followed by canonical unpadded base64url that decodes to exactly 32 octets and re-encodes to the same text. This syntax check is distinct from establishing the applicable comparison semantics. The transition from the injective profile binding encoding to SHA-256 is the first deliberately lossy operation defined by this profile. Loss in a mapping from source input to the model is not a SHA-256 collision. 7. Optional Structured Value Interchange Representations The JSON and CBOR representations in this section are optional codecs for exchanging an admitted Value; they are not mandatory SCITT wire formats and are not required when an implementation obtains the admitted Value by another means. An implementation MAY support either representation, both representations, or neither representation. An encoder or decoder that claims support for one of these representations MUST conform to the requirements for that representation below. A surrounding application profile MAY separately require support for one or both representations. 7.1. JSON Representation The JSON representation is an interoperable interchange form of a structurally admitted Value that is also within this v1 profile domain; it is not the mapping from a richer source object and is not a SCITT Statement payload format. It is one I-JSON object, as constrained by [RFC7493], with exactly these members: Le Expires 23 February 2027 [Page 13] Internet-Draft SCITT Derived Subjects August 2026 context content identifiers * context and content are canonical unpadded base64url strings carrying the exact model octets. * identifiers is an array of canonical unpadded base64url strings, each carrying one complete ScopedIdentifierBytes value. In this document, base64url means Base 64 encoding with the URL- and filename-safe alphabet from Section 5 of [RFC4648], with padding omitted as required by this profile. Encoders MUST omit = padding and MUST emit identifiers in the canonical order defined in Section 5.1 without duplicates. A decoder enforces canonical unpadded base64url by decoding the text and requiring that re- encoding the resulting octets with this profile's encoder reproduces the input text exactly. For duplicate detection and canonical ordering, a decoder MUST compare the decoded complete ScopedIdentifierBytes values using the unsigned lexicographic octet ordering defined in Section 5.1. An implementation MUST NOT determine that ordering by lexicographically comparing the base64url text representations. Decoders MUST reject non-canonical base64url, duplicate object member names, missing or unknown members, malformed scoped identifiers, duplicate or non-canonically ordered identifiers, and values outside the model domain or this v1 profile domain. JSON member order and insignificant whitespace are not Subject identity distinctions. The canonical ordering requirement for the identifiers array is a profile conformance rule for interchange; it does not make presentation order a model equivalence distinction. Empty and absent values are not interchangeable in this representation. context: "" and content: "" are canonical base64url encodings of empty octet strings, and identifiers: [] represents the empty identifier set. The three members are nevertheless mandatory. A missing member or JSON null MUST be rejected rather than defaulted to an empty value. An empty string inside identifiers is also invalid because it does not carry a complete ScopedIdentifierBytes value; the valid scoped identifier whose scope and identifier are both empty is represented by its complete 16-octet length-prefixed encoding. Le Expires 23 February 2027 [Page 14] Internet-Draft SCITT Derived Subjects August 2026 The JSON member types above are exact. A decoder MUST reject a value of any other JSON type where a base64url string or the identifiers array is required, and MUST NOT coerce, default, or otherwise reinterpret a wrong-typed value as an empty or valid model value. A decoder MUST detect duplicate object member names before any last- wins or first-wins behavior in a host object model, including names that become equal after JSON escape processing. 7.2. CBOR Representation The CBOR representation is an interoperable interchange form of a structurally admitted Value that is also within this v1 profile domain; it is not the mapping from a richer source object and is not a SCITT Statement payload format. It is one map with exactly the same three text string keys: context content identifiers * context and content are CBOR byte strings. * identifiers is an array of CBOR byte strings, each containing one complete ScopedIdentifierBytes value. An encoder MUST use the core deterministic encoding requirements of Section 4.2.1 of [RFC8949] and MUST emit identifiers in canonical order without duplicates. A decoder MUST reject duplicate map keys, missing or unknown members, wrong member types, malformed scoped identifiers, duplicate or non-canonically ordered identifiers, and values outside the model domain or this v1 profile domain. As with JSON, typed emptiness is distinct from absence or a sentinel. A zero-length CBOR byte string is a valid empty context or content, and a zero-length array is the valid empty identifiers set. A decoder MUST reject any other CBOR type where a byte string or the identifiers array is required. An empty byte string inside identifiers is not a complete ScopedIdentifierBytes value and MUST be rejected. Duplicate map keys MUST be detected after key decoding and before construction of a host map/object, even when two equal text keys use different valid CBOR serializations. Implementations MUST NOT apply last-wins, first-wins, defaulting of null values, or other coercions by the host language to recover such input. Le Expires 23 February 2027 [Page 15] Internet-Draft SCITT Derived Subjects August 2026 A decoder MAY accept another well-formed CBOR serialization of the same closed map. Such acceptance does not change Subject identity because derivation begins from the decoded model value, not from incoming CBOR bytes. 7.3. Cross-Representation Convergence If a JSON representation and a CBOR representation decode to equivalent Values in the admitted v1 profile domain, they MUST produce the same BindingBytes, digest, and SubjectText. Thus: DecodeJSON(j) ~ DecodeCBOR(c) => BindingBytes(DecodeJSON(j)) = BindingBytes(DecodeCBOR(c)) => SubjectText(DecodeJSON(j)) = SubjectText(DecodeCBOR(c)) JSON or CBOR wire bytes are not hashed directly by this profile. 8. SCITT Integration 8.1. Signed Statement Requirements A conforming Issuer that uses this profile for a SCITT Signed Statement MUST place SubjectText(v) in Claim Key 2 (sub) of the CWT Claims header parameter defined by [RFC9597]. [RFC9943] requires the CWT Claims header parameter, including iss and sub, to be in the protected header of a SCITT Signed Statement. This profile derives only sub; it does not derive iss, select an Issuer credential or signing key, or define Issuer authentication. The Statement payload can be any Statement payload permitted by the applicable SCITT application profile. It is not an input to SubjectText(v) unless the surrounding application separately maps information from that payload into the Subject value before derivation. Two conforming Issuers that use equivalent admitted Subject values MUST derive equal sub values even when their Statement payloads, Issuer identifiers, signing keys, signatures, registration times, Transparency Services, or Receipts differ. Consequently, the derived sub is not a unique identifier for an Issuer, signing key, Signed Statement, Registration event, or Receipt. Le Expires 23 February 2027 [Page 16] Internet-Draft SCITT Derived Subjects August 2026 A Relying Party MUST establish the applicable comparison semantics for the observed sub and candidate Subject value before interpreting exact string equality as semantic Subject equality. Bare string equality without a compatible profile/application interpretation is not an identity bridge between schemes or deployments. Even after semantic Subject equality is established, the iss Claim and SCITT authentication processing remain separate evidence about the Issuer, and the Signed Statement remains a distinct signed object whose payload and protected metadata are bound by its COSE signature. 8.2. Transparency Boundary Subject derivation precedes SCITT Registration and Receipts: Subject value -> SubjectText -> Signed Statement -> optional Registration -> Receipt / Transparent Statement A Transparency Service does not assign the Subject identifier. Ledger position, receipt bytes, registration time, and current Verifiable Data Structure (VDS) state are not derivation inputs. This keeps Subject recognition independent from later evidence about publication, ordering, or non-equivocation. Because SCITT groups Statements by the protected sub value, a successor mapping that selects new context octets or a successor profile produces a distinct sub-based grouping. This profile does not supply continuity across those profile versions; an application that needs to relate predecessor and successor Subjects requires an explicit surrounding succession or alias mechanism. 8.3. Interaction with Existing SCITT and COSE Mechanisms SCITT uses the protected CWT Subject Claim as the grouping and correlation key for Statements associated with a Subject [RFC9943]. This profile defines one reproducible way to obtain that key. Equal sub values do not by themselves prove that independently governed Issuers refer to the same real-world Subject; that interpretation requires the applicable comparison semantics and surrounding application agreement. This profile does not change SCITT Registration, Receipt, or Transparency Service semantics. Le Expires 23 February 2027 [Page 17] Internet-Draft SCITT Derived Subjects August 2026 COSE Key Thumbprint [RFC9679] provides a deterministic identifier construction for COSE keys. That is a mechanism for identifying keys. This profile instead derives the SCITT Subject Claim from an admitted structured Subject value and does not derive sub from an Issuer or Transparency Service key. COSE Hash Envelope [RFC9995] signals that a COSE payload is a hash output and carries metadata about the payload hash and discovery hints. It addresses carriage of a hashed payload. This profile does not replace Subject derivation with hashing the Signed Statement payload. Related SCITT work explores adjacent boundaries. Canonical Payload Binding [I-D.mih-sokolov-scitt-payload-binding] defines payload canonicalization and content-derived identifiers; Protected Object Binding [I-D.nobuo-scitt-protected-object-binding] defines object binding and Statement relationship structures; the Agent Action Capsule profile [I-D.mih-scitt-agent-action-capsule] defines a profile-specific CWT sub; and Agent Accountability Composition [I-D.mih-sato-agent-accountability-composition] defines profile-owned subject-digest contexts for cross-profile composition. This document does not claim novelty for deterministic hashing, profile-defined subjects, payload binding, or relationship graphs. Its narrower contribution is a reusable path from an admitted representation- independent Subject Value to an independently recomputable protected CWT sub, with the comparison semantics and binding boundary explicit. The adjacent mechanisms can compose with this profile through the source-to-Value mapping or at later SCITT layers. Their canonicalization, namespace, relationship, and lifecycle semantics are not implicitly imported by this profile. 9. Verification 9.1. Establishing Applicable Comparison Semantics Subject comparison first performs basic input validity checks. An observed CWT Subject text that begins with the exact v1 prefix identifies a claimed v1 SubjectText and MUST satisfy the v1 syntax before the verifier considers whether the applicable comparison semantics are established. This syntax check depends only on the self-contained v1 text syntax and MUST NOT be skipped merely because comparison semantics are unavailable. Subject comparison then determines whether the applicable comparison semantics can be established for the candidate Value and observed sub value. Mere availability or discovery of candidate model, mapping, profile, or other comparison material does not establish those semantics. Establishment for this profile version includes compatibility with the profile version indicated by the observed Subject text. An Le Expires 23 February 2027 [Page 18] Internet-Draft SCITT Derived Subjects August 2026 observed CWT Subject text that does not use the exact v1 prefix is not malformed merely for that reason; this v1 comparison procedure returns NOT_ESTABLISHED for that text. A separately specified succession mechanism between profiles or schemes can define another relation, but it does not turn such a comparison into a v1 MATCH or NO_MATCH. This document does not prescribe how the required comparison information is discovered or authenticated. Security requirements for attacker-controlled model, profile, or mapping selection are described in Section 12. A verifier MUST NOT report MATCH or NO_MATCH solely because it can derive a candidate SubjectText; those results are available only after the applicable comparison semantics are established. For an observed sub value that purports to use this v1 profile, the exact v1 prefix identifies that claim. A text beginning with that prefix but violating the v1 SubjectText syntax is an input error. A text that does not begin with that prefix can still be a valid CWT sub; it yields NOT_ESTABLISHED under this v1 comparison procedure rather than a v1 syntax error. 9.2. Verification Procedure Once the applicable comparison semantics are established for this profile version, a verifier: 1. obtains or reconstructs the candidate Subject value under the mapping established for the comparison; 2. verifies that the value is structurally admitted by the model and admitted by this profile and, when the observed sub uses the v1 prefix, verifies that it is a well-formed v1 SubjectText; 3. computes BindingBytes, SubjectPreimage, SubjectDigest, and SubjectText exactly as specified; 4. compares the resulting text string with the protected CWT Subject Claim (sub) using exact text equality; and 5. separately performs the SCITT signature, Registration, Receipt, and policy checks required by its application. 9.3. Comparison Results and Input Errors For the Subject comparison operation defined by this profile, a verifier distinguishes at least these states: Le Expires 23 February 2027 [Page 19] Internet-Draft SCITT Derived Subjects August 2026 NOT_ESTABLISHED Required comparison semantics are unavailable or incompatible. No semantic match or mismatch conclusion is available. MATCH Required comparison semantics are established. The candidate Value is admitted. The observed sub is well-formed for the selected profile. Exact derivation equals the protected CWT sub. NO_MATCH Required comparison semantics are established. The candidate Value is admitted. The observed sub is well-formed for the selected profile. Exact derivation differs from the protected CWT sub. Malformed Statements, malformed candidate representations, candidate source inputs rejected by the source domain rules or by validation required by the imported identifier system under the established mapping, or out-of-domain candidate Values MUST be rejected as input errors rather than converted into NOT_ESTABLISHED or NO_MATCH. An observed sub that uses the exact v1 prefix but violates the v1 SubjectText syntax is likewise an input error whether or not the applicable comparison semantics can be established. An observed text that does not use the v1 prefix does not become NO_MATCH under this v1 comparison procedure; it returns NOT_ESTABLISHED. Any separately specified relation between profiles or schemes is outside this comparison procedure. Determining whether the applicable comparison semantics are established does not bypass basic SCITT/CWT input validity. A local resource refusal is also not a comparison result, but it does not by itself establish that the candidate is outside the model or profile domain. In particular, NOT_ESTABLISHED is not a weak match and NO_MATCH is not evidence that two strings produced under incompatible semantics denote different real-world Subjects. 9.4. Meaning and Limits of MATCH The MATCH and NO_MATCH states describe only this Subject comparison operation. When the observed sub is taken from a SCITT Signed Statement, an implementation MAY compute the comparison before completing signature validation. Until cryptographic validation of the protected CWT Claims and of any integrity- or authentication- protected information used to establish their intended interpretation has completed, a comparison result MUST NOT be used to make a trust, authorization, acceptance, or other security-relevant decision, consistent with [RFC9597]. Before that validation completes, claim- derived profile or mapping selectors and any comparison inputs obtained through them are untrusted. Tentative comparison processing Le Expires 23 February 2027 [Page 20] Internet-Draft SCITT Derived Subjects August 2026 MUST be subject to local resource limits and MUST NOT cause unbounded external retrieval, recursive resolution, or other unbounded work solely because of unvalidated claim contents. A matching derived Subject establishes only the comparison result defined by this profile under the applicable comparison semantics. It does not by itself authenticate an Issuer, identify a unique Signed Statement, prove that a Statement is true, prove that an Artifact exists, establish ownership, or provide transparency evidence. Successful SCITT signature and trust processing can establish an authenticated signed binding among an Issuer, protected metadata, and Statement payload according to the applicable SCITT policy, but it does not by itself prove that the application source- to-Value mapping was semantically correct or that the Statement is true. A verifier also cannot infer source distinctions that were already collapsed by an imported identifier or by a mapping before admission to the structured value model. 10. Profile Succession For a given pinned profile definition, this v1 construction fixes the adopted structured value model semantics, SHA-256, and the exact scitt-derived-subject/v1 DST. An implementation claiming conformance to that definition MUST NOT substitute different structured value model semantics, another hash function, another binding encoding, another digest length, or changed Subject semantics. While this document remains an Internet-Draft, the token v1 names the candidate first profile version and does not promise wire-compatible semantics across I-D revisions. A later I-D revision MAY revise result-producing or comparison semantics while retaining the candidate v1 labels during development. Implementations or test deployments that exchange or compare Subjects produced from an Internet-Draft MUST therefore pin the exact I-D revision, or an equivalently precise profile definition, and MUST NOT infer cross- revision compatibility from the DST or SubjectText prefix alone. If the relevant normative result-producing and comparison semantics are unchanged between two revisions, those revisions are compatible for this purpose. A successor profile that explicitly claims succession from a pinned profile definition MUST use a different exact DST and a different SubjectText prefix when the successor changes result-producing semantics. Succession is required when a normative change alters the admitted profile domain, the adopted structured value model or equivalence semantics, the binding or preimage construction, the cryptographic primitive or digest length, the Subject result semantics, or the SubjectText produced for any Value in the common Le Expires 23 February 2027 [Page 21] Internet-Draft SCITT Derived Subjects August 2026 admitted domain. A document rename, WG adoption, publication as an RFC, an editorial clarification, additional test vectors, or correction of a non-conforming implementation does not by itself define succession when the normative result-producing semantics remain unchanged. This is the succession strategy chosen here for construction changes that alter the result; it is not a claim that every identifier architecture must replace an identifier when cryptographic or control mechanisms evolve. Implementations MAY support multiple profile versions, but profile selection MUST be exact. A syntactically valid SubjectText prefix identifies the profile version claimed by that text; it does not by itself authorize that version for a surrounding protocol or application. An unsupported or disallowed profile MUST NOT be processed by falling back to v1 or to another supported profile; under this v1 comparison procedure, a Subject text from another profile remains NOT_ESTABLISHED. This document does not define an algorithm negotiation protocol or global profile registry. A successor profile defines a new profile version. It specifies the structured value model semantics it adopts, its DST, binding encoding, cryptographic primitive, digest length, input bounds required by the construction, SubjectText syntax, and verification procedure independently rather than inheriting changed parameters implicitly from this version. It MUST NOT reinterpret a Subject produced under an earlier profile version. The same admitted Value can therefore produce different SubjectText values under different profile versions. SubjectText values from different versions are not compared by bare string equality as though they were outputs of one profile version. Comparison semantics established for one profile version do not establish MATCH or NO_MATCH under another profile version. A separately specified succession mechanism can relate predecessor and successor Subjects, but that relation is outside the comparison procedure for that version defined here. If a surrounding protocol lets an attacker influence profile version selection, that protocol is responsible for integrity and downgrade protection consistent with [RFC7696]. 11. IANA Considerations This document has no IANA actions. The literal SubjectText prefix defined by this profile is part of the profile syntax; it is not an IANA-allocated URI scheme, CWT claim, COSE header parameter, or registry entry. Le Expires 23 February 2027 [Page 22] Internet-Draft SCITT Derived Subjects August 2026 12. Security Considerations For distinct admitted values with distinct BindingBytes, false matches after the profile binding rely on the security properties of SHA-256. If an attacker can choose both compared Values, collision resistance is the relevant property. If one target Value is already fixed and the attacker searches for a distinct Value with the same result, second-preimage resistance is the relevant property. These distinctions follow the hash security terminology discussed in [RFC4270]. A strong hash does not repair loss before BindingBytes. Ambiguous source mapping, lossy normalization, or incorrect imported scope semantics are upstream failures and MUST NOT be attributed to SHA-256 collision behavior. Identifier-set member injection, omission, or substitution changes the admitted Value and therefore changes the derivation input. Attacker influence over discovery, validation, or member selection can fragment source inputs intended by a mapping to identify the same Subject across different sub values. Conversely, a mapping that collapses non-equivalent source inputs to the same complete identifier set can conflate Subjects before BindingBytes. These are source-mapping failures, not SHA-256 collisions. Failure to establish the applicable comparison semantics is outside SHA-256. A mutable locator or label can be useful for discovery but does not by itself establish that two parties are using compatible mappings. When interpretation depends on external model or mapping material or other dependencies that affect comparison, the surrounding application MUST make the applicable semantics unambiguous for the comparison. If an attacker can influence profile, structured value model, or mapping selection, that selection MUST be protected against substitution or downgrade appropriate to the application threat model. If the applicable comparison semantics cannot be established, the result is NOT_ESTABLISHED, not MATCH or NO_MATCH. Where application policy requires use of this v1 profile, a NOT_ESTABLISHED result does not satisfy that requirement. The surrounding application MUST enforce its required profile independently of the comparison result and MUST NOT interpret NOT_ESTABLISHED as successful v1 comparison. Equal context octets do not by themselves prove that mappings defined by independently governed applications assign compatible semantics to those octets. Accidental or adversarial reuse of the same context value for incompatible mappings is a semantic namespace collision in Le Expires 23 February 2027 [Page 23] Internet-Draft SCITT Derived Subjects August 2026 the mapping, not a SHA-256 collision. Deployments that compare Subjects across independently governed mappings SHOULD choose and establish context values so that such collisions are acceptably unlikely for their threat model. This document does not require a particular allocation, registry, or self-certifying context mechanism. [RFC9597] requires the intended interpretation of CWT Claims in COSE headers to be known unambiguously and limits their use to the integrity protection or authentication afforded to the claims and the information used to derive that interpretation. A Relying Party therefore MUST NOT treat an unverified or ambiguously selected mapping as semantic authority merely because the protected sub string is well formed. Implementations that perform tentative comparison before cryptographic validation SHOULD validate before initiating expensive or externally visible discovery when practical, and in all cases MUST bound work triggered by unvalidated claim contents. A derived Subject does not authenticate Statement content or the Issuer and does not identify a unique Signed Statement. SCITT signature validation, Issuer trust processing, and application policy remain separate requirements. Registration additionally provides transparency evidence according to [RFC9943] and [RFC9942]; it does not make the Subject derivation or the application mapping more correct, and it does not prove the Statement content true. SHA-256 does not provide confidentiality for low-entropy Subject values. Stable sub values can enable correlation across Statements, Issuers, Transparency Services, and time. 13. Privacy Considerations Independent derivation intentionally makes equivalent Subject values converge to a stable text identifier. This can facilitate correlation across otherwise unrelated Statements and Issuers. Applications SHOULD avoid including unnecessary identifying material and SHOULD consider whether a globally stable Subject is appropriate for the deployment. Hashing predictable values does not make them secret. Subject values built from guessable imported identifiers or low-entropy content can be tested offline when an observer can reconstruct candidate Subject values. 14. Normative References Le Expires 23 February 2027 [Page 24] Internet-Draft SCITT Derived Subjects August 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC7493] Bray, T., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9597] Looker, T. and M. Jones, "CBOR Web Token (CWT) Claims in COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, NIST FIPS 180-4, August 2015, . [I-D.le-structured-value-model] Le, T., "A Structured Value Model for Derived Identifiers", Work in Progress, Internet-Draft, draft-le- structured-value-model-00, August 2026, . Le Expires 23 February 2027 [Page 25] Internet-Draft SCITT Derived Subjects August 2026 15. Informative References [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, DOI 10.17487/RFC4270, November 2005, . [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, . [RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and C. Wood, "Hashing to Elliptic Curves", RFC 9380, DOI 10.17487/RFC9380, August 2023, . [RFC9679] Isobe, K., Tschofenig, H., and O. Steele, "CBOR Object Signing and Encryption (COSE) Key Thumbprint", RFC 9679, DOI 10.17487/RFC9679, December 2024, . [RFC9995] Steele, O., Lasker, S., and H. Birkholz, "CBOR Object Signing and Encryption (COSE) Hash Envelope", RFC 9995, DOI 10.17487/RFC9995, July 2026, . [I-D.le-comparing-derived-identifiers] Le, T., "Principles for Comparing Independently Derived Identifiers", Work in Progress, Internet-Draft, draft-le- comparing-derived-identifiers-00, August 2026, . [I-D.mih-sokolov-scitt-payload-binding] Mih, S. and A. Sokolov, "Canonical Payload Binding: A Signed Statement Construction Profile", Work in Progress, Internet-Draft, draft-mih-sokolov-scitt-payload-binding- 01, July 2026, . Le Expires 23 February 2027 [Page 26] Internet-Draft SCITT Derived Subjects August 2026 [I-D.nobuo-scitt-protected-object-binding] Aoki, N., "SCITT Statement Relationship and Protected Object Binding", Work in Progress, Internet-Draft, draft- nobuo-scitt-protected-object-binding-00, July 2026, . [I-D.mih-scitt-agent-action-capsule] Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action- capsule-02, July 2026, . [I-D.mih-sato-agent-accountability-composition] Mih, S., Sato, T., Schrock, I., Bu, S., and A. Sokolov, "Agent Accountability: Composition and Conformance", Work in Progress, Internet-Draft, draft-mih-sato-agent- accountability-composition-01, August 2026, . Appendix A. Test Vectors This appendix is informative. It provides known-answer vectors for the normative encodings and derivation procedure in this document. All octet strings shown as hexadecimal use lowercase hexadecimal. Where a hexadecimal value is split across multiple lines, the lines are concatenated without whitespace before interpretation. These vectors exercise representation decoding, model binding, and Subject derivation. They do not establish a mapping or the applicable comparison semantics, and equality with a vector output is not a semantic MATCH unless the applicable comparison semantics have been established. This set is representative rather than exhaustive. It is intended to provide compact interoperability checks for framing, derivation, representation convergence, and required rejection behavior. Implementations can compare the intermediate values below stage by stage to localize divergence. Normative behavior is defined by the body of this document, not by coverage of these examples. A.1. Fully Empty Value This vector exercises typed empty context and content values and the empty identifier set. Le Expires 23 February 2027 [Page 27] Internet-Draft SCITT Derived Subjects August 2026 context = h'' content = h'' identifiers = {} The exact profile intermediates are: BindingBytes = 000000000000000000000000000000000000000000000000 SubjectPreimage = 000000000000001873636974742d646572697665642d7375626a6563742f7631 000000000000000000000000000000000000000000000000 SubjectDigest = 0d06c23223da76324e4675f6dfed69e88146cdc6fa6ced2b965b98c68c14dd14 SubjectText = scitt-derived-subject-v1.DQbCMiPadjJORnX23-1p6IFGzcb6bO0rlluYxowU3RQ The following JSON and CBOR representations of the same admitted Value conform to this profile; the CBOR form follows the Core Deterministic Encoding Requirements of [RFC8949]: JSON: {"identifiers":[],"content":"","context":""} CBOR (hex): a367636f6e74656e744067636f6e74657874406b6964656e7469666965727380 A.2. Empty Set Versus One Empty Scoped Identifier An empty identifier set is distinct from a set containing one complete ScopedIdentifier whose two components are empty. left: context = h'' content = h'' identifiers = {} right: context = h'' content = h'' identifiers = { (h'', h'') } The complete empty ScopedIdentifier encoding is 16 zero octets. The bindings and Subjects are therefore distinct: Le Expires 23 February 2027 [Page 28] Internet-Draft SCITT Derived Subjects August 2026 BindingBytes(left) = 000000000000000000000000000000000000000000000000 SubjectText(left) = scitt-derived-subject-v1.DQbCMiPadjJORnX23-1p6IFGzcb6bO0rlluYxowU3RQ ScopedIdentifierBytes(empty-pair) = 00000000000000000000000000000000 BindingBytes(right) = 000000000000000000000000000000000000000000000001 00000000000000000000000000000000 SubjectText(right) = scitt-derived-subject-v1.aFuDQ4EGtUuQbSLL65f6zB6IvhpdaKM2DB5J1Wm-cIo A.3. ScopedIdentifier Pair Framing This pair demonstrates that the two components of a ScopedIdentifier are framed independently. Raw concatenation would make both pairs spell the ASCII octets abc, but their complete ScopedIdentifier encodings are distinct. left = (h'6162', h'63') ; ("ab", "c") right = (h'61', h'6263') ; ("a", "bc") ScopedIdentifierBytes(left) = 00000000000000026162000000000000000163 ScopedIdentifierBytes(right) = 00000000000000016100000000000000026263 Using the same context and content for both Values produces distinct bindings and Subjects: Le Expires 23 February 2027 [Page 29] Internet-Draft SCITT Derived Subjects August 2026 context = h'73636f7065642d6672616d696e672f7631' content = h'6c6f63616c' BindingBytes(left) = 000000000000001173636f7065642d6672616d696e672f76310000000000000005 6c6f63616c000000000000000100000000000000026162000000000000000163 SubjectText(left) = scitt-derived-subject-v1.Sry_1GPju02wO5KezhHlMk8HNB2vTPUkzRw7uGisV1o BindingBytes(right) = 000000000000001173636f7065642d6672616d696e672f76310000000000000005 6c6f63616c000000000000000100000000000000016100000000000000026263 SubjectText(right) = scitt-derived-subject-v1.sLXvSqBxUgde22sAaY_IPqYqS5nuVHRAQChw2LSv9_Q A.4. Identifier Set Ordering and Convergence Across Representations This vector exercises two distinct ScopedIdentifier pairs in the same mathematical set. Presentation order before construction of the mathematical set is not a model distinction; conforming JSON and CBOR profile representations use the canonical order of the complete encodings shown below. context = h'63' content = h'76' identifiers = { (h'65636f73797374656d2d41', h'01'), (h'00667574757265ff', h'02') } The complete ScopedIdentifier encodings, in unsigned lexicographic order, are: q[0] = 000000000000000800667574757265ff000000000000000102 q[1] = 000000000000000b65636f73797374656d2d41000000000000000101 The common profile intermediates and result are: Le Expires 23 February 2027 [Page 30] Internet-Draft SCITT Derived Subjects August 2026 BindingBytes = 0000000000000001630000000000000001760000000000000002000000000000 000800667574757265ff000000000000000102000000000000000b65636f7379 7374656d2d41000000000000000101 SubjectPreimage = 000000000000001873636974742d646572697665642d7375626a6563742f7631 0000000000000001630000000000000001760000000000000002000000000000 000800667574757265ff000000000000000102000000000000000b65636f7379 7374656d2d41000000000000000101 SubjectDigest = 35c3b0568e89a1b740e86f18049d29b7a25e11cb8d609f1242db02cc5f07738b SubjectText = scitt-derived-subject-v1.NcOwVo6JobdA6G8YBJ0pt6JeEcuNYJ8SQtsCzF8Hc4s The following JSON and CBOR representations reconstruct that same admitted Value and conform to this profile; the CBOR form follows the Core Deterministic Encoding Requirements of [RFC8949]: JSON: { "identifiers":[ "AAAAAAAAAAgAZnV0dXJl_wAAAAAAAAABAg", "AAAAAAAAAAtlY29zeXN0ZW0tQQAAAAAAAAABAQ" ], "content":"dg", "context":"Yw" } CBOR (hex): a367636f6e74656e74417667636f6e7465787441636b6964656e746966696572 73825819000000000000000800667574757265ff000000000000000102581c0000 00000000000b65636f73797374656d2d41000000000000000101 A.5. Negative Vector: Duplicate Identifier Representation A mathematical set contains each complete pair at most once. Profile JSON and CBOR representations therefore reject duplicate complete identifier encodings rather than silently normalizing them. Le Expires 23 February 2027 [Page 31] Internet-Draft SCITT Derived Subjects August 2026 JSON (REJECT): { "context":"", "content":"", "identifiers":[ "AAAAAAAAAAFhAAAAAAAAAAEx", "AAAAAAAAAAFhAAAAAAAAAAEx" ] } CBOR (hex, REJECT): a367636f6e74656e744067636f6e74657874406b6964656e74696669657273 82520000000000000001610000000000000001315200000000000000016100 0000000000000131 A.6. Negative Vector: Non-Canonical Identifier Ordering Profile representations sort complete ScopedIdentifierBytes encodings, not raw scopes or raw identifiers. The following representations place two valid complete encodings in a non-canonical order and MUST be rejected. JSON (REJECT): { "context":"", "content":"", "identifiers":[ "AAAAAAAAAAJhYQAAAAAAAAABMQ", "AAAAAAAAAAF6AAAAAAAAAAEx" ] } CBOR (hex, REJECT): a367636f6e74656e744067636f6e74657874406b6964656e74696669657273 8253000000000000000261610000000000000001315200000000000000017a 000000000000000131 A.7. Negative Vector: Base64url Text Ordering Canonical identifier ordering is defined on decoded complete ScopedIdentifierBytes octets, not on their base64url text. For the two valid pairs below, the complete encoding ending in 0c sorts before the complete encoding ending in 0d as octets, while the corresponding base64url strings sort in the opposite order as text. Le Expires 23 February 2027 [Page 32] Internet-Draft SCITT Derived Subjects August 2026 q0 = (scope = h'', identifier = h'0c') q1 = (scope = h'', identifier = h'0d') ScopedIdentifierBytes(q0) = 000000000000000000000000000000010c ScopedIdentifierBytes(q1) = 000000000000000000000000000000010d base64url(ScopedIdentifierBytes(q0)) = AAAAAAAAAAAAAAAAAAAAAQw base64url(ScopedIdentifierBytes(q1)) = AAAAAAAAAAAAAAAAAAAAAQ0 JSON (ACCEPT): { "context":"", "content":"", "identifiers":[ "AAAAAAAAAAAAAAAAAAAAAQw", "AAAAAAAAAAAAAAAAAAAAAQ0" ] } JSON (REJECT - text-sorted but octet-unsorted): { "context":"", "content":"", "identifiers":[ "AAAAAAAAAAAAAAAAAAAAAQ0", "AAAAAAAAAAAAAAAAAAAAAQw" ] } Appendix B. Implementation and Interoperability Testing This appendix is informative. Test suites benefit from exposing intermediate values so failures can be attributed to admission, framing, hashing, or text encoding rather than only to the final Subject string. * the admitted Value and, where a test begins before model construction, any distinct source/constructor presentation with that layer identified explicitly; * canonical ScopedIdentifierBytes values, BindingBytes(v), SubjectPreimage(v), SubjectDigest(v), and SubjectText(v); Le Expires 23 February 2027 [Page 33] Internet-Draft SCITT Derived Subjects August 2026 * equivalent JSON and CBOR representations where applicable; and * negative cases that isolate syntax, schema/type admission, base64url decoding, ScopedIdentifier framing, duplicate handling, canonical ordering, and local resource policy boundaries. Useful interoperability evidence varies Issuer identity and Statement payload independently while holding the admitted Subject value fixed, demonstrating that neither is an input to Subject derivation. Accepted alternate JSON or CBOR wire encodings should be shown to reconstruct the same Value rather than being hashed directly. Differential tests across runtimes and semantic mutation tests can strengthen confidence in an implementation corpus, but agreement among implementations is evidence of reproducibility under their interpretations and does not by itself establish that those interpretations match the specification. Author's Address Thanh Le Viet Nam Email: vnlemanhthanh@gmail.com Le Expires 23 February 2027 [Page 34]