Repin to dpp-core 0.13.0: moved crates, JSON-LD context, catalog retention

[LKSNDRTMLKV]

dpp-core 0.13.0 is published — all ten crates. This is no longer blocked and resolves from crates.io.

Three changes, all forced by 0.13.0 rather than chosen here.

1. Crate boundaries

dpp-core split AAS and the trust layer into their own crates and moved the disclosure contract into the domain. Every edit here is an import path or a dependency line — no engine behaviour changes.

Symbols	From	To
SectorAccessPolicy, filter_by_audience, PolicyDecision	dpp_crypto::access	dpp_domain::access
Credentials, status lists, TrustedIssuerRegistry, verify_credential_*	dpp_crypto	dpp_vc
did_builder, local_service, LocalIdentityService, PassportCredential	dpp_crypto::identity	dpp_vc

dpp-vc is added to dpp-identity, dpp-node and dpp-vault. dpp-crypto stays for jws and keystore. No dpp-aas dependency — the engine has no AAS references; serving that projection is separate work.

Also absorbed: the sector axis opened on the wire, so Sector is no longer Copy and Sector::Other carries a String. Five sites — one unit-variant construction, two bind-then-move borrows, a metrics label needing an owned key, and one tuple pattern.

2. The resolver consumes core's JSON-LD context

resolve_json.rs built its own @context referencing https://odal-node.io/schemas/dpp/v1 — which returns 404. dpp-vc had a second, different definition referencing https://ref.gs1.org/standards/digital-link/context/, which also 404s.

A string entry in an @context array is fetched by the consumer at expansion time, so a dead one fails a conforming processor outright and makes a lenient one drop every term it cannot define. Since passport payloads use bare keys, the ld+json door — which is this resolver's default response — conveyed no linked data at all.

The handler now calls dpp_vc::context_value(). One definition, one place to check.

3. Retention reads from the catalog

dpp-core deleted Sector::minimum_retention_years. It was a hardcoded all-10s match, and it was what this engine actually applied when sealing Passport::retention_until at publish — while the catalog manifests and two doc comments presented SectorDescriptor::retention_years as authoritative.

All three call sites — the seal in publish.rs, the deletion guard in lifecycle.rs, and the Art. 13 archive call — now read one resolver, retention_years_for: the catalog's value for the sector, else a ten-year floor.

Corrected — this started as fail-closed and was reversed on the branch; the body described the earlier behaviour until now. The first pass refused to publish a sector with no catalog entry and blocked its deletion outright, on the argument that an obligation of unknown length has no safe default. What that missed is that the case is reachable in ordinary use rather than exotic: a passport carrying no sector data at all resolves to Sector::Other, and the sector axis opening in 0.13.0 means a passport can now name a product group this build has never seen. Refusing to publish those is a larger behaviour change than sourcing a retention period warrants.

Ten years is not a number invented for the occasion — it is what every sector in the catalog declares, and docs/legal/DPP-RETENTION.md records it as the floor across all of them, pending delegated acts included. Applying it keeps data at least as long as any known obligation requires. Applying the same resolver at all three sites also means the deletion guard and the sealed retention_until cannot disagree, which the fail-closed version did not guarantee: u32::MAX in the guard against a ten-year seal is a contradiction, and the guard was the side that would have won.

Verification

just check exit 0 against the published 0.13.0, not path overrides: 586 tests run, 586 passed, 0 skipped.

Cargo.lock is committed in this PR — held back deliberately until publish, since it could not be generated correctly while the versions were unresolvable. It now records registry+https://github.com/rust-lang/crates.io-index for every core crate.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}