VN vnlemanhthanh@gmail.com

SCITT derived identifiers derived subjects CWT subject claim supply chain transparency The Supply Chain Integrity, Transparency, and Trust (SCITT) architecture permits distinct Issuers to agree on a common CBOR Web Token (CWT) Subject Claim (sub). This document specifies a profile for independently deriving that claim from shared application-defined Subject semantics without a shared assigning authority. An application maps its Subject description to a structured Value. This profile defines the derivation domain, deterministic binding encoding, SHA-256 construction, text syntax, and candidate-to-claim comparison requirements. Optional JSON and Concise Binary Object Representation (CBOR) codecs exchange admitted Values. Subject descriptions and Statement payloads have separate roles; the construction derives sub from the complete mapped Value, while SCITT provides the signed binding and transparency evidence.

Introduction and Applicability Different Issuers can make different Statements about a common Subject. The SCITT architecture permits those Issuers to agree on the same CWT Subject Claim (sub) value to group their Statements. This profile defines one way to compute that value independently once the surrounding application has fixed the Subject semantics. An application maps its Subject description to a structured Value under . That Value contains exact context and content octets and a finite set of scoped opaque identifiers. This profile fixes a binding encoding, SHA-256 derivation, Subject text syntax, and a procedure for comparing a candidate against an observed sub. Independent implementations using equivalent Values and the same profile definition produce equal Subject text. The application determines what constitutes the Subject being compared. The Subject description and the Statement payload serve different purposes: two Issuers can describe the same Subject while asserting different facts about it. The construction takes the admitted Value as its complete input; SCITT protects the resulting sub together with the Issuer's other protected metadata and Statement payload. This profile is useful when a Subject combines local material with zero or more identifiers from independently governed schemes, or when accepted representations reconstruct the same structured Subject value. If an existing identifier already names the complete Subject under the application's semantics and is suitable as sub, the application can use it directly. Another hash does not itself add comparison semantics. The comparison-contract framework in describes the obligations linking source equivalence, derivation, and output interpretation. This profile instantiates that path for SCITT. Sections and define its input domain and construction; defines application mapping requirements; Sections and cover SCITT integration and Subject comparison. Optional codecs and a worked example follow in Sections and .

Conventions and Conformance The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. SCITT terminology follows , and CWT terminology follows . Value, ScopedIdentifier, structural admission, and model equivalence are imported from . An octet string is a finite sequence of octets. ASCII(x) denotes the exact ASCII octets of the displayed string x. The symbol || denotes octet concatenation, or text concatenation where the operands are text.

Conformance Roles The requirements apply to parties choosing to use this profile. They do not require all SCITT implementations to support it. Conformance has the following scopes:

• A core derivation implementation processes Values using the domain and algorithms in Sections and .
• An application mapping specification defines the source comparison and mapping required by . An implementation of that mapping applies its source and validation rules.
• An encoder or decoder claiming an optional interchange representation implements the applicable requirements in .
• A SCITT Issuer using this profile derives sub and places it in a Signed Statement as required by .
• A Subject verifier implements the comparison procedure in . An application relying on its result also applies the integrity and policy requirements of Sections and .

One implementation can perform several roles. These scopes do not require separate modules, APIs, or exposed intermediate objects. Core derivation conformance alone does not establish source mapping, codec, or Subject comparison conformance.

Processing Capabilities A core implementation MUST apply the domain and derivation semantics specified here. For every admitted Value it processes, it MUST produce the prescribed result. Local memory, time, parsing, encoding, or other resource limits MAY cause an operational refusal, but MUST NOT redefine model or profile admission, alter the logical Value, or change its SubjectText. An implementation MUST document fixed capability limits as implementation limits. It SHOULD distinguish resource refusal from malformed or out-of-profile input so that callers do not mistake capability for semantic admission. A refusal can occur during parsing, mapping, admission checks, sorting, or derivation; it does not establish that the candidate is outside the domain. A core implementation MUST process the positive Values in independently of optional codecs, reproduce every displayed intermediate and result for those Values, and MUST NOT refuse those baseline Values on resource grounds. A claimed codec MUST additionally meet its acceptance, rejection, and convergence expectations in that appendix. This corpus establishes a minimum exercised capability; it does not replace the normative algorithms or limit the semantic domain to the examples. A surrounding application profile claiming operational interoperability MUST specify minimum processing capabilities for its input range and any required interchange representations. An implementation claiming that application profile MUST meet those requirements. Passing the baseline vectors alone is insufficient. Temporary resource exhaustion remains an operational refusal.

Structured Value and Profile Domain

Model Dependency This profile normatively adopts the Value and ScopedIdentifier definitions, structural admission, and exact equivalence of . Its applicable mapping, profile-adoption, and security requirements also apply according to the conformance roles in . specializes the mapping requirements for common SCITT Subjects; Sections and instantiate the derivation profile. For orientation, the imported structures are summarized below. This synopsis does not replace their normative definitions: ScopedIdentifier := { scope : finite octet string, identifier : finite octet string } Value := { context : finite octet string, content : finite octet string, identifiers : finite set of ScopedIdentifier } Model equivalence, denoted by ~, compares exact context octets, exact content octets, and the complete mathematical identifier set under exact pair equality. Set presentation order and duplicate presentation are not Value distinctions. Empty octet strings and the empty set are admitted model values; the empty set differs from a set containing one pair of empty strings. Codec acceptance is specified separately in . A v1 implementation MUST use the model semantics fixed by the selected profile definition and MUST NOT substitute different or successor model semantics while claiming that definition. The model reference supplies no concrete application mapping, wire representation, resolver, registry, or trust mechanism. Revision pinning and succession are specified in .

Derivation Domain Every Value used for v1 derivation MUST first be structurally admitted by the model. This profile further restricts that domain to Values for which the framing operations and SHA-256 input are defined. For a structurally admitted Value v, define the mathematical integer L(v): L(v) = 56 + length(v.context) + length(v.content) + sum(16 + length(q.scope) + length(q.identifier)) The sum ranges over the distinct members q of v.identifiers, and length counts octets. constructs a preimage of exactly L(v) octets. The constant includes the framed 24-octet DST and the three top-level length or count fields. A structurally admitted Value is in the v1 profile domain if and only if all of the following hold: 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 L(v) < 2^61 The field and count bounds make every BE64 and lp64 operation in defined. The L(v) bound places the octet-aligned preimage within the SHA-256 message domain of fewer than 2^64 bits . These expressions use mathematical integers; an implementation MUST NOT wrap or truncate arithmetic when deciding admission. Profile domain membership depends only on the Value. It is closed under model equivalence: equivalent Values are either both admitted by v1 or both excluded. These bounds do not change model admission or equivalence and are distinct from local capability limits in .

Subject Construction

Binding Encoding BE64(n) is the eight-octet unsigned big-endian representation of n, for 0 <= n < 2^64. For an octet string x with length(x) < 2^64, define: lp64(x) := BE64(length(x)) || x ScopedIdentifierBytes(q) := lp64(q.scope) || lp64(q.identifier) A byte string is a valid ScopedIdentifierBytes encoding only if it consists of exactly two consecutive lp64 values and the second ends at the end of the string. Truncated encodings and trailing octets MUST be rejected. Encode every member of v.identifiers and sort the complete encodings by unsigned lexicographic octet order. This compares octets from the beginning; at a first difference, the lower octet sorts first, and a proper prefix sorts before a longer string. The input is already a mathematical set, so duplicate elimination is not an operation of BindingBytes. For the resulting sequence of distinct members q[0] through q[n-1], define: IdentifierSetEncoding(v.identifiers) := BE64(n) || ScopedIdentifierBytes(q[0]) || ... || ScopedIdentifierBytes(q[n-1]) BindingBytes(v) := lp64(v.context) || lp64(v.content) || IdentifierSetEncoding(v.identifiers) The field order, fixed-width count, pair framing, and complete-encoding sort order are part of the construction. Lengths and sorted membership must be known before their corresponding output is emitted; framing does not remove the cost of sorting a set.

Preimage and Digest The Domain Separation Tag (DST) is a fixed, version-specific octet string: DST := ASCII("scitt-derived-subject/v1") SubjectPreimage(v) := lp64(DST) || BindingBytes(v) SubjectDigest(v) := SHA-256(SubjectPreimage(v)) SHA-256 is specified in and produces exactly 32 octets. The DST is 24 octets. Domain separation terminology follows ; this profile does not use that document's hash-to-curve construction. The framed DST distinguishes this construction's preimage domain. It is separate from the semantic context in Value and the SubjectText prefix. Because lp64 is self-delimiting, distinct DSTs yield distinct framed preimages regardless of the following binding bytes: DST1 != DST2 => lp64(DST1) || B1 != lp64(DST2) || B2 Equal DST octets from independently selected definitions do not establish compatible semantics. Establishment is specified in , and rules for changing a profile are in .

Subject Text The Subject Claim value is the following CWT text string: SubjectText(v) := "scitt-derived-subject-v1." || base64url(SubjectDigest(v)) base64url uses the URL- and filename-safe alphabet of , with padding omitted. Throughout this document, canonical unpadded base64url means that decoding and then re-encoding with that encoder reproduces the exact input text. Encoders MUST omit = padding. A decoder enforcing this form MUST reject text that fails the round-trip condition. A well-formed v1 SubjectText consists of the exact scitt-derived-subject-v1. prefix followed by canonical unpadded base64url decoding to exactly 32 octets. The resulting text is ASCII and therefore also UTF-8. The prefix contains no colon; SubjectText is used as an ordinary CWT Subject text string, without claiming a URI scheme or globally allocated namespace. The output comparison boundary is exact SubjectText equality. The syntax rule identifies well-formed text under a selected definition; it does not by itself establish that the definition applies to an observed claim.

Comparison Properties The binding preserves exactly the distinctions in model equivalence. BE64 has a fixed width, and each lp64 value uniquely identifies its own extent and octets. Two consecutive lp64 values therefore recover exactly one scoped pair, including empty components. Canonical sorting gives one sequence for each mathematical set; the member count and self-delimiting elements recover that set. The first two framed fields recover context and content. Consequently, for Values in the v1 domain: BindingBytes(v1) = BindingBytes(v2) iff v1 ~ v2 The fixed framed DST preserves this property at SubjectPreimage. SHA-256 is the first many-to-one operation introduced by this profile. Equivalent Values produce equal SubjectText; distinct Values have distinct preimages but can have equal digests. Canonical base64url and the fixed prefix add no further merges. These properties concern Values already supplied to the construction. A source mapping or imported identifier can have lost distinctions earlier. specifies mapping obligations, states the conditions for source-level conclusions, and addresses the relevant hash security properties.

Application Mappings

Source Contract and Complete Inputs A surrounding application profile claiming that independent Issuers derive common Subjects from richer sources MUST define or reference its accepted source domain, source Subject equivalence relation, and mapping to Value. For fixed mapping semantics, the same source and explicit inputs MUST determine one admitted Value, including its complete identifier set. The mapping MUST specify:

• the exact context octets and their interpretation;
• the source information that becomes content, including any projection, canonicalization, or other transformation before model admission;
• each imported identifier system, the applicable (context, scope) interpretation, the exact identifier octets, native comparison adaptation, and participation handling under ;
• complete membership rules, including required and optional members, cardinality, aliases, successor forms, and the treatment of absence, unavailability, discovery, or validation outcomes; and
• every source distinction intentionally omitted or collapsed, together with the source relation under which that treatment is justified.

A mapping MAY be specified elsewhere. A dependency that can change the Value or its interpretation MUST be an explicit input or fixed unambiguously by the applicable rules. This includes relevant schema versions, imported definitions, resolver results, clocks, registries, ledgers, or discovery state. A mutable locator alone does not fix its relevant meaning. The model does not require a global registry or resolver, and comparison of an already obtained Value does not require its acquisition service to remain reachable. Information from a Statement payload can participate when the application explicitly maps that information into Value. A Statement payload, Issuer identifier, signing key or signature, Registration time or position, Receipt, or Transparency Service state MUST NOT be an implicit input to SubjectText. Any such information used in Subject construction is explicit mapping material governed by the source contract.

Imported Interpretation and Participation The mapping MUST fix how scope selects imported identifier semantics within each context and which identifier octets are carried, as required by . The imported interpretation is qualified by (context, scope, identifier) under those definitions. The same tuple MUST NOT acquire incompatible imported meanings through content or ambient state. The mapping MUST identify the imported comparison relation at the scoped-pair boundary. When that relation is not exact octet equality, the mapping defines the required adaptation. Under fixed imported interpretation and participation qualification, equivalent accepted native instances MUST produce equal pairs. A claim to preserve the imported comparison unchanged also requires reflection at that boundary. Copying native octets is sufficient only when they already represent the required comparison. Non-equivalence matching behavior requires an explicitly selected equivalence relation, as specified by the model. A role, relationship, position, or occurrence can affect how a member participates without changing its imported interpretation. The mapping MUST preserve every participation distinction required by its source relation in the complete Value. It can qualify the member's scope or carry participation and its unambiguous association with the member in content. Preserving separate sets of roles and identifiers is insufficient when their associations matter. One scoped pair can therefore participate in several roles when content preserves those associations. A scoped pair copied into another context does not automatically retain its imported meaning. Bare co-membership supplies no alias, controller, succession, or cross-system identity relation.

Source Equivalence and Complete Membership For accepted sources, the mapping MUST preserve its declared Subject relation: equivalent sources produce equivalent Values. It MUST also reflect that relation: sources that remain non-equivalent under the declared relation MUST NOT produce equivalent Values. These requirements concern the application's selected Subject relation, not every distinction in a richer source object. A source-level merge occurs when non-equivalent sources reach the same complete Value. Equality of the identifier set alone is insufficient: context or content may retain the required distinction. Such a merge occurs before BindingBytes and MUST NOT be attributed to a SHA-256 collision between distinct profile inputs. An imported identifier can already be lossy relative to its richer upstream source. Its declared comparison semantics establish the imported boundary; retaining its result exactly does not recover earlier distinctions. A mapping MUST NOT claim to preserve an upstream distinction absent from the complete Value. If that distinction is required, the mapping binds additional comparison material. This does not require the core derivation to reproduce the imported construction. With context and content fixed, changing the mathematical identifier set changes Value and its preimage. This can describe an intended update to a configuration or inventory snapshot. An application requiring identity continuity across changing descriptions selects stable identity-bearing inputs or defines a continuity relation. Whether an update is authorized does not change model equality. Repeating a member already in the set does not add an occurrence; codec rejection of a duplicate presentation is a separate condition.

Validation and Unavailable Inputs The mapping MUST define any imported-system and source validation required before producing Value. Structural model admission alone does not validate a digest reference, URI, account, or other imported instance. The application contract MUST identify validation prerequisites whose completion cannot be reconstructed from a supplied Value and how a verifier establishes that completion. A transient failure or different ambient view MUST NOT silently enlarge or shrink identity-bearing membership. If the required membership cannot be determined, the mapping MUST NOT emit a partial or fallback Value unless that outcome is explicitly part of its declared source semantics and mapping. Processing distinguishes a known validation or admission failure from inability to complete a prerequisite because necessary input or evidence is absent or unavailable. The former is an input error; the latter is an application prerequisite failure. Local processing limits produce resource refusal. places these conditions in the comparison procedure. None of them permits a silent substitution of another Value.

SCITT Integration

Signed Statements An Issuer using this profile MUST put SubjectText(v) in Claim Key 2 (sub) of the CWT Claims header parameter defined by . SCITT requires that parameter, including iss and sub, in the protected header . This profile derives sub; SCITT and the surrounding application govern Issuer credentials, signing, and authentication. Two conforming Issuers using equivalent admitted Values under the same v1 definition MUST derive equal sub values. Their payloads, Issuer identifiers, keys, signatures, Registration times, Transparency Services, or Receipts can differ without changing that result when those differences are outside the application mapping. The resulting sub does not uniquely identify an Issuer, signing key, Signed Statement, Registration event, or Receipt. The Statement payload is any payload permitted by the applicable SCITT application profile. A COSE signature binds that payload and protected metadata according to SCITT. How payload information enters the Subject description, if at all, is determined by . The optional Value codecs in are not SCITT Statement payload formats.

Transparency and Grouping Subject derivation precedes signing and any Registration or Receipt. A Transparency Service does not assign this derived Subject. Registration and Receipts provide the transparency evidence specified by and ; they do not establish the correctness of the application mapping. SCITT systems can index or provisionally group Statements by exact protected sub. Such syntactic grouping can be performed without the external semantics required by . A Relying Party MUST NOT merge trust, authorization, revocation, provenance, or other security state solely because sub strings are equal. It establishes the applicable interpretation and satisfies the reliance requirements in . Changes to identity-bearing Value material change the preimage and, absent a hash collision, change sub. A construction with a distinct text prefix produces syntactically distinct Subjects. Applications MUST NOT assume that mapping or construction successors remain in one sub-based grouping. describes the boundaries for an explicit continuity mechanism.

Subject Comparison This section defines candidate-to-claim comparison. It does not perform complete SCITT signature, Receipt, Registration, or trust verification. The results and the conditions for relying on them are specified separately below.

Invocation Inputs An invocation uses one explicitly selected, supported and permitted v1 definition, including its fixed model semantics. The invoking application MUST fix that definition and the candidate form independently of the observed Subject prefix. This selects the candidate construction; it does not establish that the observed claim uses compatible semantics. Unavailable or disallowed profile selection is handled without fallback under . The candidate form is one of:

• a directly supplied model Value;
• an encoded Value under the explicitly designated JSON or CBOR codec in ; or
• a source description governed by an identified application mapping and version.

The invocation also supplies the observed sub and the inputs required by the application's interpretation-selection rules. A source mapping can select an imported interpretation as a function of source material. Establishment fixes that selection rule before mapping validates a selected identifier instance. Bounded inspection of a source MAY locate the identified contract or its interpretation rule; it MUST NOT execute the source mapping or imported validation before the stage specified below.

Establishing Comparison Semantics A surrounding application profile using this procedure MUST define how it selects the application contract governing each side and decides whether those interpretations are compatible. Those rules MUST fix or unambiguously reference the candidate mapping, observed claim interpretation, imported-scope meanings, and their relationship to the selected v1 and model definitions. Local policy affecting this decision is an explicit establishment input. Availability or discovery of a definition is not establishment. A candidate mapping and recognizable text prefix do not identify the observed claim's interpretation. The prefix is syntax within a selected definition, not a globally allocated profile selector. A verifier MUST NOT report MATCH or NO_MATCH solely from prefix recognition or its ability to derive a candidate SubjectText. Missing or ambiguous interpretations, or interpretations that cannot be established as compatible under the application rules, produce NOT_ESTABLISHED. This applies before inspecting the observed text as a v1 syntax claim. It does not postpone candidate acceptance checks that use the independently selected construction and codec. For example, a surrounding profile can fix the exact v1 definition and model, mapping identifier and version, context octets, and imported-scope interpretation rules. Issuers operating under that profile then share a contract for independent derivation. How that profile is selected, distributed, and authenticated remains a surrounding protocol responsibility, subject to and .

Ordered Procedure A verifier MUST apply the following logical order. A terminal condition established in an earlier step ends the invocation before later steps are attempted. Local resource refusal can terminate processing at the step where work cannot be completed; it does not stand in for an unevaluated admission or comparison result.

Step 1.

Validate basic SCITT/CWT input syntax and types independently of assigning the observed text to v1. The observed sub MUST be a CWT text string. For a direct Value, check structural model admission and the v1 bounds in . For an encoded Value, apply the designated codec's complete acceptance rules, reconstruct Value, and check the same model and v1 bounds. Rejected input produces an input error. For a source description, mapping and candidate admission are deferred to Step 4.

Step 2.

Establish compatible comparison semantics for the observed claim and candidate under . If either interpretation or their compatibility cannot be established, return NOT_ESTABLISHED. This step establishes the application interpretation and mapping rules, without executing a source mapping or assigning the observed text to v1.

Step 3.

Check the observed sub under the established interpretation. If it does not begin with the exact v1 prefix, return NOT_ESTABLISHED. If it has that prefix but fails the SubjectText syntax of , return an input error.

Step 4.

Complete candidate processing. For a source description, apply the established mapping, including source and imported-system validation, and check structural model and v1 admission. Direct or decoded Values have already passed those admission checks in Step 1. For every candidate form, establish any remaining application prerequisites required by . A known source, imported-instance, model, profile, or prerequisite validation failure is an input error. Inability to complete required mapping or validation because necessary input or evidence is absent or unavailable is an application prerequisite failure. Neither outcome permits derivation from a substituted Value.

Step 5.

Compute BindingBytes, SubjectPreimage, SubjectDigest, and SubjectText as specified in . Compare the result with the observed protected sub using exact text equality. Return MATCH when equal and NO_MATCH when different.

The timing of candidate checks is summarized below. Candidate Processing Timing

Candidate form	Initial checks	Deferred checks
Direct Value	Step 1: model and v1 admission	Step 4: remaining prerequisites
JSON/CBOR Value	Step 1: codec, model, and v1 admission	Step 4: remaining prerequisites
Source	Step 1: no source mapping	Step 4: mapping, validation, model/v1 admission, and remaining prerequisites

Direct and encoded Values are checked against the v1 domain at Step 1, before comparison semantics are established or the observed prefix is interpreted. A source description cannot reach model/v1 admission until its established mapping executes at Step 4. This timing difference follows from candidate form; candidate acceptance alone does not establish compatibility with the observed claim.

Results and Terminal Conditions The three comparison results are: MATCH Applicable comparison semantics are established; candidate processing succeeded; the observed sub is well-formed for v1; exact candidate derivation equals the observed sub. NO_MATCH The same prerequisites hold, but exact candidate derivation differs from the observed sub. NOT_ESTABLISHED The required comparison semantics cannot be established, or the observed sub has another prefix. No semantic match or mismatch is established by this procedure. Input errors, resource refusals, and application prerequisite failures are terminal conditions, not comparison results. A prerequisite failure can occur for any candidate form: direct and decoded Values may need evidence of earlier validation, while a source mapping may require unavailable inputs. Successful derivation alone proves none of those prerequisites. These states and terminal conditions are abstract local outcomes. This document assigns them no CWT claim, COSE header, SCITT wire code, or registry value. An application requiring v1 comparison MUST NOT treat NOT_ESTABLISHED or any terminal failure as successful comparison. A NO_MATCH result does not describe two identifiers interpreted under incompatible schemes.

Meaning, Evidence, and Reliance MATCH establishes that the candidate's correctly recomputed SubjectText equals the observed claim under the established comparison rules. The procedure does not obtain an observed-side source merely by reading sub. A conclusion about two underlying Values also requires the binding between the observed claim and the claimed observed Value, and correct derivation under the same semantics, to be established. Under those conditions, unequal outputs imply non-equivalent Values by coherence. Equal outputs support Value equivalence subject to SHA-256's false match properties. A conclusion about two richer sources additionally depends on their declared relation and mapping properties in . These conditions follow . They do not recover distinctions already lost within an imported construction or mapping. An implementation MAY compute comparison before completing signature validation. Until the protected claims and any integrity- or authentication-protected information used to select their interpretation have been successfully validated, it MUST NOT rely on that result for trust, authorization, acceptance, or another security-relevant decision . Tentative processing MUST be resource-bounded and MUST NOT initiate unbounded external retrieval, recursive resolution, or other unbounded work solely from unvalidated claim contents. Successful signature processing authenticates the signed binding under the applicable SCITT policy; it does not by itself prove source mapping correctness, Statement truth, Artifact existence, or ownership. Receipt and trust processing remain separate evidence. Those operations can be performed before or after comparison subject to the reliance requirement above. Their failure does not convert a computed MATCH into NO_MATCH; it prevents the failed requirement from being treated as satisfied.

Optional Interchange Representations The JSON and CBOR codecs exchange Values in the v1 domain. An implementation MAY support either, both, or neither. An implementation claiming a codec MUST implement its requirements; an application profile MAY require a codec. These representations do not replace a richer-source mapping and their wire bytes are not hashed by Subject derivation.

Common Representation Rules Both representations contain exactly three members named context, content, and identifiers. The first two carry exact model octets. identifiers is an array whose elements carry complete ScopedIdentifierBytes encodings from . Encoders MUST emit those complete encodings in unsigned lexicographic octet order without duplicates. Decoders MUST reject missing or unknown members, duplicate member names or keys, wrong types, malformed scoped pairs, duplicate or out-of-order identifier encodings, and Values outside the model or v1 domain. Duplicate detection and sorting compare decoded complete pair encodings, not raw scopes, raw identifiers, or textual encodings. The array order rule narrows the codec's accepted representations. It does not add order to mathematical set equality. An application accepting a broader source representation can normalize it in its explicitly defined mapping before supplying Value; it cannot silently broaden a claimed codec's acceptance rules. Empty context and content octet strings and an empty identifiers array are valid. The three members remain required. Absence, null, wrong types, and sentinels MUST NOT be coerced or defaulted into empty values. An empty array element does not encode a scoped pair; the valid pair of two empty strings has the complete 16-octet encoding of two zero lengths.

JSON The JSON representation is one I-JSON object . context and content are canonical unpadded base64url strings. identifiers is an array of such strings, each encoding one complete scoped pair. The base64url rules in apply to each decoded string value. A decoder MUST reject non-canonical base64url and any other JSON type in place of the required strings or array. It MUST detect duplicate member names after JSON escape processing and before a host object model silently retains one occurrence. The ordering check in operates on decoded pair octets; lexicographic base64url text order MUST NOT be used. illustrates why these orders differ. Object member order, insignificant whitespace, and accepted JSON escape spellings do not change the represented Value. Canonical base64url constrains the JSON string value after JSON decoding, not its escape spelling on the wire. Empty context or content is the JSON string ""; empty membership is []. The JSON string "" inside identifiers is invalid because it carries no complete scoped pair.

CBOR The CBOR representation is one map with the same three text-string keys. context and content are CBOR byte strings. identifiers is an array of CBOR byte strings, each carrying a complete scoped pair. Any other type in those positions MUST be rejected. An encoder MUST use the Core Deterministic Encoding Requirements of , in addition to the identifier-array ordering of . A decoder MUST detect duplicate map keys after key decoding and before constructing a host map, including equal keys carried in different valid serializations. It MUST NOT keep only the first or last duplicate or apply host-language coercions. A decoder MAY accept another well-formed CBOR serialization of the same closed map. Such acceptance preserves the common schema, type, member-order, framing, and admission rules. Derivation begins with the decoded Value, so a different accepted CBOR serialization does not change Subject identity.

Convergence Accepted JSON and CBOR representations that reconstruct equivalent Values MUST produce identical BindingBytes, SubjectPreimage, SubjectDigest, and SubjectText under the same v1 definition. Optional acceptance policies can differ, but a representation accepted by two implementations under that definition cannot acquire different model meanings from those policies. Representation rejection is not model inequality. Once a Value is reconstructed and admitted, derivation uses its exact fields and mathematical set, independently of the incoming representation.

Worked Application Example: Role-Bearing Participants This section is informative. It uses a fictional account system only to exercise a generic role-bearing source mapping; it does not define or imply an external application profile. AI-agent, trade-document, and other domain-specific source semantics belong in separate mapping specifications. retains the exact single-participant construction vectors, and gives additional results for participation carried in content.

Source Relation and Scope-Qualified Mapping A source contains a document string and a finite sequence of (role, account) pairs. A document is the exact ASCII string invoice: followed by one or more ASCII digits; its spelling, including leading zeros, matters. Roles are the exact ASCII strings issuer and controller. Account names are nonempty ASCII letter strings. Native account comparison ignores ASCII letter case. Source equivalence requires equal document strings and equal sets of (role, lowercase-account) pairs. Entry order and repetitions are irrelevant. No resolver, mutable alias state, or additional validation participates. The empty sequence is accepted by this example mapping. The first mapping uses context example.org/worked-map/v1. It places the exact document octets in content and maps each distinct normalized pair to: scope = ASCII("example-account/role/" || role) identifier = ASCII(lowercase-account) identifiers is the mathematical set of the resulting pairs. The fixed scope prefix and restricted role alphabet preserve role boundaries; exact identifier octets preserve the native account class. Together with exact content, the Value retains exactly the material defining source equivalence. This establishes preservation and reflection for this mapping, independently of the sample hashes. For document invoice:1234, the following entries illustrate the mapping: A: [(issuer, ALICE)] B: [(issuer, alice)] C: [(controller, alice)] D: [(issuer, ALICE), (controller, bob)] E: [(issuer, bob), (controller, alice)] F: [(issuer, alice), (controller, ALICE)] A and B produce the same Value and SubjectText. C changes the scope and produces the other single-participant vector in . D and E preserve different role/account associations. F has two different scoped members even though both identifier components are alice. Changing the document changes content; adding a distinct normalized pair changes membership. A duplicate or another accepted case spelling of an existing pair leaves Value unchanged.

Participation in Content A second mapping accepts the same sources and relation. It uses context example.org/worked-map/content/v1 and unqualified scope example-account/v1. identifiers contains one pair for each distinct lowercase account name. Content starts with the exact document string; sort the distinct normalized pairs by ASCII role and then account, and append each as ";" followed by role, "=", and lowercase account. The restricted alphabets make this encoding unambiguous. An empty pair set adds no suffix. D and E now have the same identifier set but different content: D: invoice:1234;controller=bob;issuer=alice E: invoice:1234;controller=alice;issuer=bob F has one identifier member, while content retains both participations: F: invoice:1234;controller=alice;issuer=alice The complete content recovers the document and normalized pair set, so this mapping also preserves and reflects source equivalence. The member itself need not repeat the participation information. D and E have different Values and BindingBytes despite equal membership; their calculated SubjectText values in are also different. These are two different mapping designs with different contexts and Values. They are not interchangeable representations of one Value, and this profile does not require their SubjectText values to converge. Accepted representations within either design still converge under .

Statements and Comparison Using the first mapping, two Issuers can put the common SubjectText for A and B in protected sub while choosing different iss values and Statement payloads: Issuer A: iss = "did:example:issuer-a" sub = SubjectText(Value(A)) payload = "measurement from site A" Issuer B: iss = "did:example:issuer-b" sub = SubjectText(Value(B)) payload = "independent statement from site B" These are illustrative claim and payload values, not complete Signed Statement encodings. The differing Issuers and assertions are outside this mapping and do not change the derived Subject. A verifier using source B as candidate can obtain MATCH against A's observed sub when the application interpretations are established and required candidate processing succeeds. The result demonstrates agreement with that claim. Reliance on an Issuer assertion additionally requires the signed binding and application evidence described in . A well-formed matching string alone does not establish those facts.

Evolution and Succession

Application Mapping Evolution Context qualifies application mapping semantics; it is not the cryptographic DST. A successor mapping MUST use new context octets if, for a predecessor source, it changes admission, validation, source equivalence, required distinctions, member selection, or resulting Value. New context is also required if it changes an existing scope meaning or its semantic binding rule, or admits a new meaning that can reach an old Value under incompatible source comparison semantics. A compatible domain extension can retain context when every predecessor source is treated exactly as before and each new source reaching a predecessor-reachable Value is equivalent, under the declared Subject relation, to the predecessor sources producing it. Adding another accepted representation of an existing meaning, increasing processing capability, or supporting a scope already covered by an unchanged deterministic interpretation rule does not alone require new context. For example, adding Scheme B to a mapping that previously accepted Scheme A can preserve old Subjects when these compatibility conditions hold. It cannot reinterpret an existing scope or make a new non-equivalent source collide at the Value boundary while reusing the old context. Extending the source domain is different from adding a distinct member to an already admitted Subject. The latter changes Value even under unchanged context. A description can be enriched without changing identity only when the new material stays outside the identity-bearing Value or is adapted under an existing rule without changing that Value. Correcting an implementation that violated an unchanged mapping is not a new mapping version. When mapping succession changes the preimage, SubjectText changes absent a hash collision; an application needing continuity uses an explicit surrounding relation between predecessor and successor Subjects.

Construction Versions and Selection Each pinned v1 definition fixes its model semantics, profile domain, binding encoding, DST, SHA-256, digest length, text syntax, and comparison behavior. A conforming implementation MUST NOT substitute different semantics while claiming that definition. During Internet-Draft development, v1 names the candidate first construction and does not promise compatible semantics across draft revisions. A later I-D revision MAY retain candidate v1 labels while revising semantics. Implementations exchanging or comparing draft-based Subjects MUST pin the exact I-D revision or an equivalently precise definition and MUST NOT infer compatibility from the DST or prefix alone. A revision label shared by unpublished working copies is not a precise pin; the actual applicable definitions must be fixed. Unchanged relevant semantics can support compatibility across revisions. A successor construction outside that development convention MUST use a different exact DST and SubjectText prefix when it changes result-producing semantics. Such succession is required for changes to the admitted profile domain, adopted model or equivalence, binding or preimage construction, primitive or digest length, Subject result semantics, or text produced for any common-domain Value. A successor specifies its domain, model, encoding, primitive, syntax, and comparison procedure explicitly and MUST NOT reinterpret predecessor Subjects. A document rename, WG adoption, RFC publication, additional vectors, editorial clarification, or correction of a non-conforming implementation does not alone require construction succession when the relevant semantics remain unchanged. A change to comparison terminal precedence must nevertheless be identified in the applicable comparison definition even when all valid SubjectText outputs remain unchanged. An implementation MAY support multiple versions, but selection MUST be exact. It MUST NOT fall back from an unsupported, disallowed, unavailable, or otherwise unestablished definition to v1 or another supported version. Failure to select a usable definition establishes no v1 comparison; the application reports NOT_ESTABLISHED for that selection failure. Once an available permitted definition is selected for an invocation, governs its input and comparison precedence. Subjects under different constructions do not acquire one comparison meaning from bare string equality. A separate succession or alias mechanism can relate them, but that relation is outside this version's MATCH/NO_MATCH procedure. A surrounding protocol exposing profile selection to attacker influence is responsible for integrity and downgrade protection consistent with .

Relationship to Existing Mechanisms Length framing and deterministic hashing are established techniques. TupleHash preserves tuple boundaries before hashing; deterministic CBOR can fix a structured preimage. This profile chooses a narrow encoding for three model fields, with explicit lengths, member count, and sorted complete pairs. The trade-off is fixed framing overhead and a profile-specific encoder. Substituting another encoding or primitive would change this construction and is subject to . COSE Key Thumbprint identifies COSE keys. This profile constructs a SCITT Subject from an application-mapped Value; an Issuer or Transparency Service key does not enter that Value implicitly. COSE Hash Envelope describes carriage of hashed payloads and associated metadata; it does not by itself define this Subject mapping. The work-in-progress versions cited here illustrate adjacent binding mechanisms. Canonical Payload Binding describes content-derived identifiers, digest contexts, and binding mechanisms, including exact as-transmitted byte boundaries. Those content-binding obligations operate under the selected digest context and do not replace this profile's declared source Subject relation or Value-to-sub construction. Protected Object Binding describes explicit object and Statement-relationship bindings; such relationships are not implicitly imported by this profile. The contribution here is the concrete path from a reusable structured comparison Value to independently recomputable protected sub, together with its domain, comparison prerequisites, and evidence limits. The broader framework is ; the model is .

Security Considerations Distinct admitted Values have distinct preimages under . A false match introduced by this construction therefore depends on SHA-256. Collision resistance is relevant when an adversary chooses both Values; second-preimage resistance is relevant when one target Value is fixed . These properties do not establish mathematical uniqueness over the full input domain. A strong hash cannot repair a source distinction absent from the complete Value. Incorrect normalization, scope interpretation, or participation handling can cause mapping loss before BindingBytes. Conversely, inconsistent mapping of equivalent sources can create different preimages and potentially different Subjects. These are assessed against the source contract, separately from hash behavior. An unauthorized omission, insertion, or substitution that changes mathematical membership changes the derivation input when other fields are fixed. It is an integrity failure when it violates the mapping or the source binding required by the consuming protocol. Authorized membership changes also change Value. A repeated member that leaves the abstract set unchanged is governed separately by codec acceptance. The surrounding application MUST make applicable semantics unambiguous and protect attacker-influenced selection of models, profiles, mappings, and imported interpretations against substitution or downgrade as appropriate to its threat model. Authenticating a fetched definition does not alone prove that it is the applicable definition; fixing a mutable locator does not fix its meaning. specifies the resulting establishment and reliance boundaries. Independently governed applications can use equal context octets with incompatible meanings. This is a semantic naming conflict, not a SHA-256 collision. Cross-governance deployments SHOULD establish context values whose conflicts are acceptably unlikely for their threat model, using authenticated coordination or collision-resistant allocation, such as binding context to immutable mapping material, when appropriate. Neither context, DST, nor text prefix supplies global semantic authority by itself. requires the intended interpretation of header claims to be known unambiguously and limits use of those claims to their afforded integrity or authentication. The reliance requirements in therefore cover interpretation-selection inputs as well as the protected claim. Implementations SHOULD complete cryptographic validation before expensive or externally visible discovery when practical; all tentative processing remains subject to the mandatory resource bounds there. Syntactic grouping and comparison success MUST NOT replace Issuer authentication, required mapping evidence, application authorization, freshness, revocation, or transparency verification. An application requiring this profile enforces that requirement even when processing ends with NOT_ESTABLISHED or a terminal failure. Registration does not prove a Statement true or make an incorrect mapping correct.

Privacy Considerations Independent derivation makes equivalent Subject Values converge to a stable identifier. This can correlate Statements across Issuers, Transparency Services, and time. Applications SHOULD avoid unnecessary identifying material and SHOULD assess the intended scope of Subject stability. Hashing predictable or low-entropy values does not make them secret. An observer able to reconstruct candidate Values can test guesses offline. Composite membership can expose linkage between imported systems even when the model assigns no relationship semantics to co-membership. An opaque digest can retain that linkability without revealing each member directly. Syntactic grouping by equal sub can associate Statements before compatible application meanings are established. Indexers and applications need to assess whether such provisional associations expose relationships that a semantic comparison would not justify.

IANA Considerations This document has no IANA actions. It defines no new CWT claim, COSE header parameter, media type, content-format number, or registry. The SubjectText prefix is profile syntax, not an allocated URI scheme or globally unique profile selector. Its interpretation is established under .

References Normative References National Institute of Standards and Technology Informative References

Test Vectors and Comparison Cases The exact positive Values and displayed construction results, together with the acceptance and rejection expectations for each claimed codec, form the minimum exercised corpus required by . Hexadecimal lines within one value are concatenated without whitespace. These cases do not replace the normative algorithms or establish external interoperability. Derivation vectors establish expected arithmetic and representation behavior. Their equality is not a semantic MATCH until the applicable comparison prerequisites are established. The conditional comparison cases in describe the ordered procedure separately.

Fully Empty Value This vector exercises typed empty context and content values and the empty identifier set. 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 : JSON: {"identifiers":[],"content":"","context":""} CBOR (hex): a367636f6e74656e744067636f6e74657874406b6964656e7469666965727380

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: 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

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: 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

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: 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 : JSON: { "identifiers":[ "AAAAAAAAAAgAZnV0dXJl_wAAAAAAAAABAg", "AAAAAAAAAAtlY29zeXN0ZW0tQQAAAAAAAAABAQ" ], "content":"dg", "context":"Yw" } CBOR (hex): a367636f6e74656e74417667636f6e7465787441636b6964656e746966696572 73825819000000000000000800667574757265ff000000000000000102581c0000 00000000000b65636f73797374656d2d41000000000000000101

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. JSON (REJECT): { "context":"", "content":"", "identifiers":[ "AAAAAAAAAAFhAAAAAAAAAAEx", "AAAAAAAAAAFhAAAAAAAAAAEx" ] } CBOR (hex, REJECT): a367636f6e74656e744067636f6e74657874406b6964656e74696669657273 82520000000000000001610000000000000001315200000000000000016100 0000000000000131

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

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. 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" ] }

Comparison State and Precedence Cases These informative cases apply to an invocation with an available, supported and permitted pinned v1 definition under . Unless a case states otherwise, basic input validity, candidate admission, compatible semantics, observed v1 syntax, required validation, and processing capability are established; candidate derivation equals the observed sub. Conditions at later steps are not evaluated after an earlier terminal outcome. INPUT_ERROR, RESOURCE_REFUSAL, and PREREQUISITE_FAILURE below are compact labels for local terminal conditions, not new comparison states or wire codes. Cases involving v1 size exclusion are mathematical boundary cases; they do not require allocating inputs of that size or applying small local limits as profile bounds. Comparison State and Precedence Matrix

Case	Condition	Expected
V-01	Observed sub has the wrong CWT type; comparison semantics are unavailable.	INPUT_ERROR Step 1
V-02	A direct Value is structurally invalid; comparison semantics are unavailable.	INPUT_ERROR Step 1
V-03	An admitted direct Value is supplied; semantics are unavailable; observed text has a v1 prefix with malformed suffix.	NOT_ESTABLISHED Step 2
V-04	A source mapping contract cannot be established.	NOT_ESTABLISHED Step 2
V-05	Both application interpretations are known but incompatible.	NOT_ESTABLISHED Step 2
V-06	Semantics are established; observed text has another prefix; source mapping would fail.	NOT_ESTABLISHED Step 3
V-07	Semantics and observed v1 syntax are valid; a source candidate cannot be processed within local limits at Step 4.	RESOURCE_REFUSAL Step 4
V-08	An admitted direct Value and established semantics are supplied; observed text has another prefix.	NOT_ESTABLISHED Step 3
V-09	Candidate admission and semantics succeed; observed text has the v1 prefix but non-canonical base64url or wrong digest length.	INPUT_ERROR Step 3
V-10	All prerequisites succeed; recomputed SubjectText equals the observed sub.	MATCH Step 5
V-11	All prerequisites succeed; recomputed SubjectText differs from the observed sub.	NO_MATCH Step 5
V-12	Comparison succeeds with equality, but signature or interpretation-integrity validation is incomplete. The result cannot yet support a security decision.	MATCH Step 5
V-13	A valid direct Value has all required prior-mapping evidence; comparison equals the observed sub.	MATCH Step 5
V-14	A valid direct Value lacks evidence required to establish completion of prior source or mapping validation.	PREREQUISITE_FAILURE Step 4
V-15	Evidence establishes a required source or mapping validation failure after candidate admission and observed syntax checks succeed.	INPUT_ERROR Step 4
V-16	The candidate interpretation is known but the observed interpretation is unknown; observed text has a v1 prefix and malformed suffix.	NOT_ESTABLISHED Step 2
V-17	Known application interpretations are incompatible; the observed text is well-formed v1.	NOT_ESTABLISHED Step 2
V-18	Both interpretations are established and compatible; observed text has a v1 prefix and malformed suffix.	INPUT_ERROR Step 3
V-19	An explicitly selected JSON candidate fails codec acceptance; comparison semantics are unavailable.	INPUT_ERROR Step 1
V-20	A direct Value is structurally valid but outside the v1 domain; comparison semantics are unavailable.	INPUT_ERROR Step 1
V-21	A JSON candidate has valid representation structure but reconstructs a Value outside v1; comparison semantics are unavailable.	INPUT_ERROR Step 1
V-22	A CBOR candidate has valid representation structure but reconstructs a Value outside v1; comparison semantics are unavailable.	INPUT_ERROR Step 1
V-23	A source would map outside the v1 domain, but comparison semantics cannot first be established.	NOT_ESTABLISHED Step 2
V-24	A source would map outside v1; semantics are established but the observed prefix is not v1.	NOT_ESTABLISHED Step 3
V-25	A source maps to a structurally valid Value outside v1 after establishment and observed v1 syntax succeed.	INPUT_ERROR Step 4
V-26	Step 1 cannot finish candidate processing within local resource limits; comparison establishment has not been attempted.	RESOURCE_REFUSAL Step 1
V-27	All earlier steps succeed; local resource exhaustion prevents construction or comparison in Step 5.	RESOURCE_REFUSAL Step 5
V-28	An admitted decoded Value lacks required evidence of prior mapping validation.	PREREQUISITE_FAILURE Step 4
V-29	A source mapping cannot determine required membership because necessary input is unavailable; earlier comparison checks succeeded.	PREREQUISITE_FAILURE Step 4
V-30	A source mapping would fail, but the established observed claim first fails v1 text syntax.	INPUT_ERROR Step 3
V-31	A direct Value is outside v1; the observed text has another prefix and semantics are established.	INPUT_ERROR Step 1
V-32	A source mapping would fail, but comparison semantics are unavailable.	NOT_ESTABLISHED Step 2

Single-Participant Mapping Vectors sources A and B use the first mapping and reconstruct the following Value. These bytes retain the earlier single-participant vector; the source presentation in the worked example is not a wire format. Value = { context: h'6578616d706c652e6f72672f776f726b65642d6d61702f7631', content: h'696e766f6963653a31323334', identifiers: { (h'6578616d706c652d6163636f756e742f726f6c652f697373756572', h'616c696365') } } BindingBytes = 00000000000000196578616d706c652e6f72672f776f726b65642d6d61702f 7631000000000000000c696e766f6963653a31323334000000000000000100 0000000000001b6578616d706c652d6163636f756e742f726f6c652f697373 7565720000000000000005616c696365 SubjectText = scitt-derived-subject-v1.0K46bi3ohMmE4dPuxIDIJUQttjVsqkUsj5vCgxd-fyA Source C changes only the role, producing the controller-scoped Value. The Subject result is: role = "controller" SubjectText = scitt-derived-subject-v1.5Odmz2E6jvFsZ8oG8aWYm0StmUl2nBK1pS2s1UFoBfo

Participation in Content Vectors These Values use the second mapping of and the exact document invoice:1234. The common context is ASCII("example.org/worked-map/content/v1"); each member has scope ASCII("example-account/v1"). The following content, membership, and construction results fully specify the three Values. Case D: content = ASCII("invoice:1234;controller=bob;issuer=alice") Identifier components (ASCII): alice, bob. Each uses the common scope stated above. BindingBytes(D) = 00000000000000216578616d706c652e6f72672f776f726b65642d6d61702f63 6f6e74656e742f76310000000000000028696e766f6963653a313233343b636f 6e74726f6c6c65723d626f623b6973737565723d616c69636500000000000000 0200000000000000126578616d706c652d6163636f756e742f76310000000000 000003626f6200000000000000126578616d706c652d6163636f756e742f7631 0000000000000005616c696365 SubjectPreimage(D) = 000000000000001873636974742d646572697665642d7375626a6563742f7631 00000000000000216578616d706c652e6f72672f776f726b65642d6d61702f63 6f6e74656e742f76310000000000000028696e766f6963653a313233343b636f 6e74726f6c6c65723d626f623b6973737565723d616c69636500000000000000 0200000000000000126578616d706c652d6163636f756e742f76310000000000 000003626f6200000000000000126578616d706c652d6163636f756e742f7631 0000000000000005616c696365 SubjectDigest(D) = 0a42753615da87d2e9a6e4010317d954099a11f01901f101c2c329cfe96b1593 SubjectText(D) = scitt-derived-subject-v1.CkJ1NhXah9LppuQBAxfZVAmaEfAZAfEBwsMpz-lrFZM Case E: content = ASCII("invoice:1234;controller=alice;issuer=bob") Identifier components (ASCII): alice, bob. Each uses the common scope stated above. BindingBytes(E) = 00000000000000216578616d706c652e6f72672f776f726b65642d6d61702f63 6f6e74656e742f76310000000000000028696e766f6963653a313233343b636f 6e74726f6c6c65723d616c6963653b6973737565723d626f6200000000000000 0200000000000000126578616d706c652d6163636f756e742f76310000000000 000003626f6200000000000000126578616d706c652d6163636f756e742f7631 0000000000000005616c696365 SubjectPreimage(E) = 000000000000001873636974742d646572697665642d7375626a6563742f7631 00000000000000216578616d706c652e6f72672f776f726b65642d6d61702f63 6f6e74656e742f76310000000000000028696e766f6963653a313233343b636f 6e74726f6c6c65723d616c6963653b6973737565723d626f6200000000000000 0200000000000000126578616d706c652d6163636f756e742f76310000000000 000003626f6200000000000000126578616d706c652d6163636f756e742f7631 0000000000000005616c696365 SubjectDigest(E) = 37cb6e15b4489fccdd0b40fda0e9a54eefbed1ff7816477529196efa52e9ee52 SubjectText(E) = scitt-derived-subject-v1.N8tuFbRIn8zdC0D9oOmlTu--0f94Fkd1KRlu-lLp7lI Case F: content = ASCII("invoice:1234;controller=alice;issuer=alice") Identifier components (ASCII): alice. Each uses the common scope stated above. BindingBytes(F) = 00000000000000216578616d706c652e6f72672f776f726b65642d6d61702f63 6f6e74656e742f7631000000000000002a696e766f6963653a313233343b636f 6e74726f6c6c65723d616c6963653b6973737565723d616c6963650000000000 00000100000000000000126578616d706c652d6163636f756e742f7631000000 0000000005616c696365 SubjectPreimage(F) = 000000000000001873636974742d646572697665642d7375626a6563742f7631 00000000000000216578616d706c652e6f72672f776f726b65642d6d61702f63 6f6e74656e742f7631000000000000002a696e766f6963653a313233343b636f 6e74726f6c6c65723d616c6963653b6973737565723d616c6963650000000000 00000100000000000000126578616d706c652d6163636f756e742f7631000000 0000000005616c696365 SubjectDigest(F) = 0eb878260759394d520a60f1808e4f5a94e08b2f7808f3a3abd9167580cd6627 SubjectText(F) = scitt-derived-subject-v1.Drh4JgdZOU1SCmDxgI5PWpTgiy94CPOjq9kWdYDNZic

Implementation and Interoperability Evidence This appendix is informative. Useful tests expose the admitted Value, complete pair encodings, BindingBytes, SubjectPreimage, SubjectDigest, and SubjectText. Tests beginning from richer sources additionally identify the source relation, exact mapping, explicit dependencies, and any required validation evidence. Representation cases exercise syntax, types, canonical base64url, pair framing, duplicate handling, ordering, and reconstruction. Comparison cases distinguish candidate forms and terminal precedence. In particular, direct and encoded Values outside v1 are checked before semantic establishment, while a source is mapped only at Step 4. Resource refusal is tested separately from semantic size exclusion. Application evidence varies Issuer identity and Statement payload independently while holding Value fixed, and distinguishes claim-surface checks from complete Signed Statement and Receipt verification. It covers unavailable validation inputs and evidence as well as known failure. Successful derivation or comparison does not establish application acceptance. Differential tests can reveal implementation disagreement; agreement alone does not establish that the shared interpretation follows the specification. An evidence record distinguishes mathematical arguments, finite fixture results, independently implemented producers and consumers, and actual external use. Synthetic fixtures or agreement among project runtimes do not establish external adoption.