Skip to content

Separate Reference into SigningReference and ValidationReference #517

@coderabbitai

Description

@coderabbitai

Summary
Using a single “Reference” type for both signing and validation overloads responsibilities and leads to confusing/unsafe state (e.g., ambiguity around fields like uri and their mutability during signing).

Problem

  • The same Reference object is currently used across signing and validation flows.
  • This can cause API confusion and accidental mutation (see linked PR and comment for a concrete case and discussion).
  • It makes it harder to reason about field semantics (what is input vs. output, mutable vs. immutable).

Proposal (for discussion)

  • Conceptually split the current Reference type into two roles:
    • SigningReference (inputs to the signing pipeline)
    • ValidationReference (outputs/observations from parsing and validation)
  • Initial hypothesis for field grouping (to be validated during design):
    • Likely signing-only: xpath, isEmptyUri, id, type
    • Likely validation-only: uri, digestValue, validationError, signedReference
    • Shared (applied differently across flows): transforms, digestAlgorithm, inclusiveNamespacesPrefixList
  • Goals:
    • Clearer API and stronger typing around what’s provided vs. what’s produced.
    • Avoid mutation of shared objects across stages; explicitly define mutability/immutability expectations.

Compatibility considerations

  • This would likely be a breaking change for consumers that directly access Reference fields.
  • Plan: discuss design and migration path, then deprecate the old shape over a major version bump with a clear upgrade guide.

Links and attribution

Next steps

  • Drive a short design discussion to finalize the split, field mapping, and migration path.
  • Track acceptance criteria: types defined and documented, tests updated, migration notes prepared.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions