-
Notifications
You must be signed in to change notification settings - Fork 189
Open
Description
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
- Requested by: @shunkica
- Context: Add support for inserting and signing Object elements inside the Signature #506 and specific discussion: Add support for inserting and signing Object elements inside the Signature #506 (comment)
- PR backlink: Add support for inserting and signing Object elements inside the Signature #506
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
Labels
No labels