Skip to content

id property validation inconsistency — SHOULD verify but MUST reject #86

@toderash

Description

@toderash

In the Metadata Document id property, the spec currently says:

Clients SHOULD verify this ID against the DID used to look up the metadata document. If the ID specified in the Metadata Document does not match the expected ID, clients MUST stop processing the document...

The SHOULD on the verification step and the MUST on the consequence are inconsistent. A Client that opts out of verification (permitted by SHOULD) never triggers the MUST, and is technically compliant while accepting metadata documents with mismatched IDs. This creates an exploitable gap: a malicious Repository could serve a different Package's metadata in response to a DID lookup, and a lenient or lazy Client could accept it without breaking the spec.

If the intent is that the check is mandatory, the first sentence should be MUST. If there is a legitimate reason for SHOULD (e.g., some resolution paths where the ID check is genuinely inapplicable), those carve-outs should be enumerated explicitly rather than implied by softening the whole requirement. The Publisher DID resolution path already has its carve-out defined explicitly in the paragraph below; the base check can be MUST without affecting that.

Proposed resolution: Change "Clients SHOULD verify" to "Clients MUST verify" in the base id check. The existing Publisher DID carve-out paragraph handles the one known exception explicitly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions