Summary
The vta/passkey-vms/* Trust-Task family is now being published in the Trust-Tasks registry (trustoverip/dtgwg-trust-tasks-tf#80) at version 0.1 (draft, framework 0.2). This plugin currently emits /1.0 URIs (packages/core/src/vta/protocol.ts) and needs to align to the published specs once they merge.
This is a deliberate breaking change — we are tightening loosely-specced production contracts to match the registry's 0.x scheme.
Required change
packages/core/src/vta/protocol.ts:
const PASSKEY_VMS = "https://trusttasks.org/spec/vta/passkey-vms";
export const PasskeyVmTask = {
enrollChallenge: `${PASSKEY_VMS}/enroll-challenge/1.0`, // → /0.1
enrollSubmit: `${PASSKEY_VMS}/enroll-submit/1.0`, // → /0.1
list: `${PASSKEY_VMS}/list/1.0`, // → /0.1
revoke: `${PASSKEY_VMS}/revoke/1.0`, // → /0.1
} as const;Repoint all four task URIs from /1.0 to /0.1.
Because both sides route by exact URI, this must cut over in lockstep with the VTA change — see the companion issue on OpenVTC/verifiable-trust-infrastructure (#308).
Things to verify against the published schemas
- Field naming — the published payloads are lowerCamelCase (
ceremonyId, rpId, publicKeyMultibase, coseAlgorithm, attestationObject, clientDataJson, authenticatorData, webauthnCredentialId, webauthnTransports, webvhVersion). Confirm the @pnm/core payload interfaces and PasskeyVerificationMethod type match byte-for-byte.
publicKeyMultibase is advisory — the spec is explicit that the browser-supplied value is re-derived and may be rejected (vta/passkey-vms/enroll-submit:publicKeyMismatch); the plugin should treat the response verificationMethod.publicKeyMultibase as authoritative.- Error handling — the VTA will emit framework-standard codes plus slug-namespaced extended codes (
unknownCeremony, ceremonyDidMismatch, invalidAttestation, publicKeyMismatch, alreadyEnrolled, didNotFound, fragmentNotFound). Surface these in the passkey-management UX rather than treating all failures generically.
Acceptance
Blocked on: registry publication of the four specs.
Summary
The
vta/passkey-vms/*Trust-Task family is now being published in the Trust-Tasks registry (trustoverip/dtgwg-trust-tasks-tf#80) at version0.1(draft, framework 0.2). This plugin currently emits/1.0URIs (packages/core/src/vta/protocol.ts) and needs to align to the published specs once they merge.This is a deliberate breaking change — we are tightening loosely-specced production contracts to match the registry's
0.xscheme.Required change
packages/core/src/vta/protocol.ts:Repoint all four task URIs from
/1.0to/0.1.Because both sides route by exact URI, this must cut over in lockstep with the VTA change — see the companion issue on
OpenVTC/verifiable-trust-infrastructure(#308).Things to verify against the published schemas
ceremonyId,rpId,publicKeyMultibase,coseAlgorithm,attestationObject,clientDataJson,authenticatorData,webauthnCredentialId,webauthnTransports,webvhVersion). Confirm the@pnm/corepayload interfaces andPasskeyVerificationMethodtype match byte-for-byte.publicKeyMultibaseis advisory — the spec is explicit that the browser-supplied value is re-derived and may be rejected (vta/passkey-vms/enroll-submit:publicKeyMismatch); the plugin should treat the responseverificationMethod.publicKeyMultibaseas authoritative.unknownCeremony,ceremonyDidMismatch,invalidAttestation,publicKeyMismatch,alreadyEnrolled,didNotFound,fragmentNotFound). Surface these in the passkey-management UX rather than treating all failures generically.Acceptance
PasskeyVmTaskURIs repointed to/0.1, cut over in lockstep with the VTAPasskeyVerificationMethodverified against the published0.1schemasBlocked on: registry publication of the four specs.