Repository navigation
feat: read did:webs (JsonWebKey) verification methods by relationship (VTI-KEY-003) - #429
Merged
Merged
Conversation
… (VTI-KEY-003) Every party must resolve did:webs (VTI-KEY-003). A did:webs document carries JsonWebKey methods (publicKeyJwk, ids <did>#<CESR key>), and a VTA with key roles (VTI-KEY-173) lists a different key under each relationship: the attestation key under assertionMethod, the operational key under authentication, and X25519 key agreement after a P-256 one. The plugin's own DID-document key readers assumed publicKeyMultibase, fell back to "any Ed25519 key", or matched ids by fragment suffix — each of which picks the wrong key for that document. One reader now serves every site: core/src/did/vm-key.ts (publicKeyOf, selectKey, x25519KeyAgreement), a port of vti-didcomm-js #39's verification-method module, to be replaced by that export when the plugin moves to the release that ships it (R4.1). It fails closed on an unknown or missing type, an encoding the type does not carry, both encodings, an unsupported curve, a JWK carrying d, or a revoked method. - trust-tasks/verify.ts: the proof key is read from the relationship the proof is for (the required purpose, else the proof's own proofPurpose), in either encoding; no endsWith fallback. - vta/tsp-vid.ts: the VID signing key is the authentication key only (tsp-enablement D5); no "any Ed25519" fallback, exact dereference, type checks; rawFromOkpJwk refuses d. - vtc/directory-card.ts assertionKeys and vtc/domain-linkage.ts assertionKey read assertionMethod through the same reader. - did/verify.ts didMethod knows webs (didWebsDomain, host guarded before resolution); deriveSigningKeyId offers no bare verificationMethod ids for a did:webs. Tests use vti-didcomm-js's did:webs party documents (VTA with key roles, mediator), with a did:webvh regression and fail-closed cases at each site. Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
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.
The VTI spec now requires every party to resolve did:webs (VTI-KEY-003). A did:webs document carries
JsonWebKeyverification methods, and a key-role VTA keeps a separate key for each relationship. This PR makes the plugin's own DID-document key reads handle that: keys are picked by verification relationship, never "any Ed25519" and never by fragmentendsWith.New:
packages/core/src/did/vm-key.ts, a rule-for-rule port of vti-didcomm-js#39 (publicKeyOf,selectKey,x25519KeyAgreement).d, or a revoked method.verification-methodexport once a release includes it (R4.1).Sites
trust-tasks/verify.ts: the key comes from the required purpose (authentication for step-up, consent and replies; assertionMethod for record bodies and domain linkage), or else the proof's ownproofPurpose. Both encodings are read and ids match exactly. Behaviour change: a proof whose key isn't listed under the purpose it claims no longer verifies.vta/tsp-vid.ts: the TSP signing key is the first Ed25519authenticationkey (tsp-enablement D5), with no fallback.derefVmis gone, and a JWK withdis refused.vtc/directory-card.tsandvtc/domain-linkage.ts: assertion keys come throughselectKey.did/verify.ts: knowsdid:webs; the host is checked before resolving (egress-guard.ts).derive-signing-key.tshas noverificationMethod[]fallback for did:webs. The extension's confirm screen shows "key event log verified".Tests:
packages/core/tests/did.webs-keys.mjs, using did:webs VTA and mediator fixtures with real signatures from vti-didcomm-js#39, plus a did:webvh regression and fail-closed cases for each site.tsp.vid.mjsis extended. Lint, build, tests, bundle assertions and the store package check all pass locally.After vti-didcomm-js ships #38/#39:
vm-key.ts.