Repository navigation
feat!: V4 Release - #295
Merged
Merged
Conversation
|
Coverage after merging v4-release into main will be
Coverage Report |
|
Coverage after merging v4-release into main will be
Coverage Report |
* feat: add support mldsa44 signatures for ldp VC * fix: add sec notice
* feat: add preferredNumalgo selector for DidPeerManager and DidPeer.getDid Backports the `preferredNumalgo` parameter from upstream commit 342c0a0, defaulting to DidPeerType.peer2. With this default, callers that previously relied on the implicit "single key + no service => did:peer:0" auto-pick must now opt in explicitly with `preferredNumalgo: DidPeerType.peer0`. The dedup-shaped `internalAddVerificationMethod` from b12ef59 is intentionally NOT included; the per-relationship VM creation in DidPeerManager remains identical to v3.6.2 / v3.8.0 to keep alignment with the Affinidi Rust mediator (affinidi-tdk-rs/.../resolve.rs) which cannot currently resolve did:peer:0 correctly. Tests updated to opt into peer0 explicitly: - DidPeerManager DID signer integration: normalizes fragment-only verificationMethodId to full DID URL and uses full ID in proofs - DidPeerManager Key retrieval: should retrieve DID key pair - DidPeerManager DID generation: generates a valid did:peer:0 document - DidPeerManager DID generation: generates a valid did:peer:0 document with secp256k1 key * feat: enforce strict did:peer:0 invariants in DidPeerManager When DidPeerManager is constructed with `preferredNumalgo: DidPeerType.peer0` the manager now enforces the same single-key, no-services constraints that DidKeyManager enforces, instead of silently falling back to `did:peer:2` when those constraints are violated. This treats `did:peer:0` as the `did:key`-equivalent encoding it is per spec: one multibase-encoded key, no services. The peer:2 default behavior is unchanged. Changes (all in lib/src/did/did_manager/did_peer_manager.dart): - Override `addVerificationMethod`: when `preferredNumalgo == peer0`, scan existing VMs in the store, look up their wallet keys, and reject with `tooManyVerificationMethods` if a *different* wallet key is already present. Same-key re-entry is allowed so multi-relationship adds and the ed25519→x25519 keyAgreement derivation continue to work. - Override `addServiceEndpoint`: when `preferredNumalgo == peer0`, throw `UnsupportedError` (mirror DidKeyManager.addServiceEndpoint). - Modify `getDidDocument`: when `preferredNumalgo == peer0` and there are no services, collapse multiple stored VMs that share a single wallet key (e.g. ed25519 + derived x25519) down to the single primary key before calling `DidPeer.getDid`. The `_buildEDDoc` resolver derives the keyAgreement entry the same way `did:key` does. `internalAddVerificationMethod` is unchanged — peer:2 remains identical to v3.6.2/v3.8.0, preserving alignment with the Affinidi Rust mediator. The `isDid0` gate in `DidPeer.getDid` is also unchanged so the static public API stays safe for direct callers. Adds 6 new tests in test/did/did_manager/did_peer_manager_test.dart (group: "Strict did:peer:0 semantics"): - rejects a second wallet key with tooManyVerificationMethods - allows re-entry for the SAME wallet key (multi-relationship adds) - rejects addServiceEndpoint with UnsupportedError - single ed25519 + keyAgreement still produces did:peer:0 (mirrors did:key) - single p256 + multiple relationships produces did:peer:0 - default (peer2) manager still allows multiple keys and services * test: assert default DidPeerManager produces did:peer:2 for minimal shapes Adds three regression tests in the existing DidPeerManager > "DID generation" group to lock in that the default peer:2 manager never auto-collapses single-key/no-service shapes down to did:peer:0. Pre-PR, the static `DidPeer.getDid` would have done so for the same inputs (b12ef59 / upstream-without-`preferredNumalgo`), so this guards the intent of the new `preferredNumalgo: DidPeerType.peer2` default at the manager level. Cases covered: - 1 key (p256) + 1 relationship (authentication) + 0 services -> did:peer:2 with a `.Vz` key entry (not did:peer:0). - 1 ed25519 key + auth+keyAgreement + 0 services -> did:peer:2 with `.Vz` and `.Ez` entries and 2 VMs (not collapsed to a did:key-style ed25519+derived-x25519 did:peer:0 doc). - 1 key + empty relationship set -> manager throws SsiException with code `invalidDidDocument`, asserting the manager neither silently produces a relationships-less did:peer:0 nor a relationships-less did:peer:2. * feat: update DidPeerManager to throw SsiException for unsupported operations and improve wallet key retrieval
DenisPopov15
force-pushed
the
v4-release
branch
2 times, most recently
from
July 23, 2026 09:47
57603c3 to
cd35151
Compare
|
Coverage after merging v4-release into main will be
Coverage Report |
|
Coverage after merging v4-release into main will be
Coverage Report |
preferredNumalgo (did:peer:2 by default)
preferredNumalgo (did:peer:2 by default)
deepak-affinidi
approved these changes
Jul 23, 2026
marco-a-affinidi
approved these changes
Jul 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.