Conform auth/step-up/* payload to published schema (subject/sessionId/decision)

[stormer78]

Summary

The wallet's VTA step-up approval messages use a bespoke DIDComm body that does not match the published auth/step-up/approve-request/0.1 / approve-response/0.1 schemas. Reconcile (requires coordinated VTA changes).

Current (non-conformant) behaviour

packages/core/src/rp-login/step-up.ts (requestVtaApproval):

• Request emitted as a flat DIDComm body { rp_did, nonce } under type auth/step-up/approve-request/0.1.
• Response read as a flat DIDComm body { approval_token } under type auth/step-up/approve-response/0.1.

Published spec (dtgwg-trust-tasks-tf/specs/auth/step-up/...)

• approve-request payload: { subject, sessionId, challenge, reason, ... }.
• approve-response payload: { subject, sessionId, challenge, decision, ... } + Data Integrity proof (the proof is what the RP verifies to elevate the session ACR).

The wallet's { rp_did, nonce } → { approval_token } is a working bilateral wallet↔VTA contract that shares only the type URI with the spec — the payloads are unrelated.

Why this is cross-repo

This is a wallet↔VTA contract. The VTA has a typed approve-response/0.2 handler (signed payload) that expects the spec shape; the wallet's bespoke flow targets a different VTA endpoint/body. Reconciling means changing the VTA handler and the wallet together. There is no straightforward unilateral fix.

What to do

• Decide whether the VTA step-up approval should converge on the published approve-request/approve-response schema (subject/sessionId/challenge/decision + proof), or remain a documented bespoke flow.
• If converging: update verifiable-trust-infrastructure (VTA) and the wallet's step-up.ts together.

Acceptance

• Wallet ↔ VTA step-up uses the published schema, or the divergence is documented as intentional.