fix: fallback to verificationMethods if capabilityInvocation or capabilityDelegation silent#39
Merged
Conversation
…ilityDelegation silent
There was a problem hiding this comment.
Pull request overview
This PR adjusts signature verification to treat capabilityInvocation / capabilityDelegation as optional: when a DID document is silent about those relationships, validation should fall back to using all verificationMethod entries instead of failing verification.
Changes:
- Update token signature verification to fall back to
verificationMethodentries when the relevant capability relationship is absent/empty. - Add tests covering successful verification against “plc-shaped” documents without capability relationships, plus regression coverage for nil relationship fields.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
validator/validator.go |
Implements fallback selection of verification methods when capability relationships are not expressed. |
validator/validator_test.go |
Adds regression tests for relationship fallback behavior across invocation/delegation scenarios. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Fall back to verificationMethod only when the relationship is absent or empty, not when its entries fail to resolve — a populated relationship referencing missing methods must not widen authorization. - Stop reusing err across verification-method loop iterations, which caused valid methods to be skipped after one unsupported VM type. - Add test covering a relationship that references a missing method. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
frrist
approved these changes
Jul 13, 2026
alanshaw
added a commit
to fil-forge/sprue
that referenced
this pull request
Jul 17, 2026
This PR allows `did:plc` accounts to provision spaces. This requires a `did:plc` resolver. Context: Hilt uses the `/customer/add` method to add it's tenants to Sprue. Hilts tenants are `did:plc` addressed, so that their keys can be rotated easily. Unfortunately the addition of `/customer/add` to Sprue did not also include this change to allow the kinds of DID that were going to be used (`did:plc`) to provision spaces. Hence this PR. Depends on: * fil-forge/ucantone#38 * fil-forge/ucantone#39
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.
If the document is silent about
capabilityInvocationorcapabilityDelegationthen fallback to allverificationMethods, do not fail signature verification entirely.Context:
did:plcdocuments from the official DID PLC server do not carry these properties and so the signatures are currently unverifiable.