Repository navigation
feat!: did peer strict peer0 v2 - #285
Merged
Merged
Conversation
Base automatically changed from
feat/did-manager-multi-key-support-did-web-did-peer-v2
to
main
April 28, 2026 08:19
oleksiipiliugin
force-pushed
the
feat/did-peer-strict-peer0-v2
branch
from
April 28, 2026 12:12
25f5222 to
93bf51a
Compare
|
Coverage after merging feat/did-peer-strict-peer0-v2 into main will be
Coverage Report |
|
Coverage after merging feat/did-peer-strict-peer0-v2 into main will be
Coverage Report |
oleksiipiliugin
force-pushed
the
feat/did-peer-strict-peer0-v2
branch
from
June 30, 2026 15:27
262fd1c to
89a4602
Compare
|
Coverage after merging feat/did-peer-strict-peer0-v2 into main will be
Coverage Report |
…tDid 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
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
…hapes 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.
…rations and improve wallet key retrieval
oleksiipiliugin
force-pushed
the
feat/did-peer-strict-peer0-v2
branch
from
June 30, 2026 15:36
89a4602 to
0744924
Compare
|
Coverage after merging feat/did-peer-strict-peer0-v2 into main will be
Coverage Report |
linn-affinidi
approved these changes
Jul 3, 2026
marco-a-affinidi
approved these changes
Jul 3, 2026
DenisPopov15
pushed a commit
that referenced
this pull request
Jul 23, 2026
* 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
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.
BREAKING(4.X.X release candidate)
BREAKING CHANGE:
preferredNumalgo(did:peer:2by default)did:peer:0as per spec(followingdid:keybehavior)This pull request introduces a formal mechanism for selecting the DID peer algorithm ("numalgo") when generating
did:peeridentifiers, providing strict support for bothdid:peer:2(default) anddid:peer:0semantics. The changes ensure thatdid:peer:0is only produced when explicitly requested and only under its strict invariants (single key, no services), whiledid:peer:2remains the default and supports multiple keys and service endpoints. The update also includes comprehensive tests to verify correct behavior for both modes and prevent unintentional fallback todid:peer:0.DID Peer Algorithm Selection and Enforcement
preferredNumalgoparameter toDidPeerManager, defaulting toDidPeerType.peer2. When set toDidPeerType.peer0, the manager enforces strictdid:peer:0invariants (single wallet key, no service endpoints) and throws exceptions if violated. (lib/src/did/did_manager/did_peer_manager.dart)DidPeer.getDidto accept apreferredNumalgoparameter. Now,did:peer:0is only generated ifpreferredNumalgois set topeer0and the input meets the constraints; otherwise, it always producesdid:peer:2. (lib/src/did/did_peer.dart) (F9928bebL394R409)Manager and Encoder Logic Updates
DidPeerManager.getDidDocumentto use the newpreferredNumalgologic and added a fast path for collapsing todid:peer:0when appropriate. (lib/src/did/did_manager/did_peer_manager.dart) [1] [2]Test Suite Enhancements
did:peer:2(default) and strictdid:peer:0scenariosdid:peer:0in the default modedid:peer:0mode rejects multiple keys and service endpoints, but allows multiple relationships for the same keytest/did/did_manager/did_peer_manager_test.dart) [1] [2] [3] [4] [5] [6] [7] [8]DidPeer.getDidto specifypreferredNumalgo(test/did/did_peer_test.dart)Documentation and Imports
lib/src/did/did_manager/did_peer_manager.dart,lib/src/did/did_peer.dart) [1] [2]These changes make DID peer algorithm selection explicit, robust, and predictable, preventing accidental generation of
did:peer:0identifiers and aligning with the latest specifications and design plans.