Default relationship communication to pairwise R-DIDs and govern P-DID fallback

[stormer78]

Surfaced by an external RAHP/DRARM assessment of the Cypress release
(sankarshanmukhopadhyay/rahp-toolkit#18, finding OVTC-RAHP-04). Confirmed as
reported.

Problem

Pairwise relationship identity is opt-in, and the fallback is the persona DID.

• TUI request form: generate_r_did defaults to false
  (openvtc/src/state_handler/relationship_actions.rs:1056); the user has to
  find and toggle the checkbox on field 3 to get privacy.
• TUI inbox accept: a accepts without an R-DID, A accepts with one
  (openvtc/src/ui/pages/main/mod.rs:914-930). The convenient key is the
  linkable one.
• CLI: requires --generate-did (docs/relationships-vrcs.md:60-66), which
  states plainly that without an R-DID, subsequent communication uses the P-DID.

So the safe path is the one the operator has to know to ask for, on a decision
whose consequences are invisible at the moment they make it.

Why this is worse here than the generic pattern

The assessment scores this as stable-identifier correlation. In our case the
stable identifier is a published, resolvable did:webvh that frequently
carries a verified agent name. Two counterparties do not need traffic analysis
to correlate the same persona across contexts — they compare a string, and can
then resolve it to a named identity. The linkage is not merely possible, it is
a lookup.

That argues for flipping the default rather than warning on the fallback.

Proposed change

1. Default generate_r_did to true on the request form and make the
   R-DID-generating accept the primary key binding in the inbox. Keep the
   P-DID path available, deliberately chosen, and labelled with what it costs.
2. CLI: make R-DID generation the default and introduce an explicit opt-out
   flag rather than an opt-in one. --generate-did becomes a no-op that warns,
   for one release, so existing scripts do not silently change meaning in the
   other direction.
3. No silent revert. Once a relationship has an R-DID, subsequent messages
   must not fall back to the P-DID — define the bootstrap-to-pairwise migration
   point and assert it. A fallback that can re-expose the P-DID mid-relationship
   defeats the default.
4. Test: given two relationships established from the same persona, assert
   that protocol-visible identifiers do not permit the two counterparties to
   correlate them.
5. Docs: update docs/relationships-vrcs.md — the current text presents the
   R-DID as an optional privacy extra rather than the norm.

Upstream question

Whether VTC should require pairwise identifiers for relationship
communication rather than leaving it to client defaults is a protocol question
for verifiable-trust-infrastructure. If it does, this issue reduces to
conformance. Raising it there separately; this change stands either way.

Acceptance

• A new relationship request and a new relationship acceptance both mint an
  R-DID with no extra keystroke.
• Choosing the P-DID path is possible and states the linkability cost at the
  point of choice.
• A relationship with an R-DID never emits the P-DID on a subsequent message.

[stormer78]

Scoped this against the current code and the current VTI stack. The core finding
holds — generate_r_did: false at openvtc/src/state_handler/relationship_actions.rs:1056,
and a accepts without an R-DID while A accepts with one
(openvtc/src/ui/pages/main/mod.rs:914-937). Proposal 1 is a small, clean
change. Three corrections to the rest.

The CLI flag no longer exists

There is no --generate-did and no relationships subcommand. The current CLI
(openvtc/src/cli.rs, 151 lines) has setup and health only. The flag lived
in the pre-0.2.0 openvtc-cli crate (05eac5d:openvtc-cli/src/cli.rs:106-112,
opt-in via default_value("false")) and went away in the TUI rewrite
(1f31455).

So proposal 2 has nothing to change. What it turns into is a docs fix:
docs/relationships-vrcs.md:53-70 still documents that CLI as live. The same
file also contradicts itself — the mermaid diagram at lines 9-31 shows both
sides minting an R-DID as the normal flow, while line 66 presents it as an
optional extra. Proposal 5 should cover both.

Acceptance criteria 3 and 4 are not achievable client-side

All three handshake messages deliberately go P-DID↔P-DID for mediator routing:

• request — relationship_actions.rs:519-546
• accept — inbox_actions.rs:313-318
• finalize — message_dispatch.rs:437-450

each carrying the comment that the handshake uses persona DIDs for routing and
the R-DID rides in the body. The R-DID takes over only post-establishment. And
the VRC issuer is the persona DID even when the message goes R-DID→R-DID
(inbox_actions.rs:730-741), so the credential correlates the pairwise channel
back to the persona.

That last one is not a client bug. The VTC requires it —
vtc-service/policies/default/relationships.rego requires VRC issuer and
subject to be current ACL-listed members, and routes/relationships.rs:97-107
pins issuer to the session DID. A VRC issued under a pairwise R-DID would be
rejected. The only enforcement upstream forbids pairwise identifiers rather
than requiring them. Raised as
OpenVTC/verifiable-trust-infrastructure#1054.

So criterion 4 ("protocol-visible identifiers do not permit the two
counterparties to correlate them") cannot be satisfied without a protocol
change. The upstream question the issue anticipated turns out to be load-bearing
for half the acceptance, not merely a conformance tidy-up.

Criterion 3 is already true, and worth keeping true

No path silently substitutes the persona DID for an established relationship
with a working R-DID. Relationship.our_did (openvtc-core/src/relationships.rs:97)
is the single sending identity and listener_id_for_did (openvtc-core/src/didcomm.rs:1311-1318)
routes on it; ping, VRC request, VRC issue and VRC reject all read it. A broken
or needs_reestablishment R-DID fails to send rather than falling back
(relationships.rs:334-380).

The one window is provisional: the record is inserted with our_did = persona_did
before the R-DID is minted (relationship_actions.rs:1185-1200) and overwritten
in apply (:713-717). On mint failure the record is removed; but if the mint
succeeds and the send fails, the record is dropped entirely. So the assertion
criterion 3 asks for is worth adding as a regression guard — there is currently
no test that an established relationship's outbound messages use the R-DID
(openvtc-core/tests/relationship_e2e.rs exercises the P-DID-only path).

Note for whoever flips the default

start_new_request_and_cancel_back (relationship_actions.rs:1992-2003) pins
generate_r_did: false and is what locks the current default in.

Suggested revision

Narrow to proposals 1 and 5 plus the criterion-3 regression test, and track
criterion 4 as blocked on #1054.

[stormer78]

Client half landed in #254 (3529cf4).

Proposal 1 — done. A new request defaults to minting an R-DID, and in the
inbox a now accepts pairwise. A stayed wired to the pairwise accept so
existing muscle memory keeps producing the private outcome; the persona-DID
accept moved to p. No keystroke that used to mint an R-DID now yields a
persona DID.

"Labelled with what it costs" — done. Both surfaces state the consequence at
the point of choice rather than offering a bare Yes/No: the request form's
toggle reads Contact you as: Pairwise R-DID (recommended) / Your persona DID
and renders the trade-off for whichever is selected; the inbox detail spells out
both outcomes above the footer.

Proposal 3 — guarded, and it already held. No path silently reverts an
established relationship to the persona DID. Added
established_pairwise_relationship_never_pings_from_the_persona_did, which pins
the message from, the recipient and the listener to the relationship record.
Confirmed it fails when prepare_ping is made to read persona_did_arc().

Proposal 5 — done. docs/relationships-vrcs.md gained a Choosing your
identifier comparison table and lost the --generate-did example.

Proposal 2 — withdrawn, nothing to change. The --generate-did flag and the
whole openvtc relationships subcommand have not existed since the v0.2.0 TUI
rewrite (1f31455). There is no CLI surface to invert, and therefore no
script-compatibility window to manage.

---

What remains, and why it is not closed

Proposal 4 / acceptance criterion 4 is blocked upstream. Two counterparties
can still correlate two relationships from the same persona, for two reasons
neither of which is a client defect:

1. The three handshake messages (request/accept/finalise) are routed
   persona-to-persona by design — the mediator has to route them before a
   pairwise channel exists.
2. The VRC issuer must be the persona DID, because the VTC's
   relationships.rego requires issuer and subject to be current ACL-listed
   members, and routes/relationships.rs:97-107 pins issuer to the session DID.
   A VRC issued under a pairwise R-DID is rejected today.

The second is the one that matters most: the VRC is the durable artifact both
parties keep and can publish to the trust graph, where
GET /v1/relationships/graph exposes the full member-to-member edge set. The
handshake persona DID is seen once; the VRC correlates forever.

Blocked on OpenVTC/verifiable-trust-infrastructure#1054. Keeping this open to
carry the client-side adoption work once that resolves — pairwise VRC issuance
is not a no-op here even after the protocol allows it.

A note on framing, for whoever picks that up. Criterion 4 as written may be
aiming slightly wide. You initiate a relationship by typing someone's persona
DID or agent name, so your counterparty knowing who you are is usually the
point, and on the recipient side correlation is unavoidable regardless. What
pairwise identifiers actually protect here is (a) the trust graph and (b) the
initiator's identity, if they want first contact to be pseudonymous. Worth
restating the criterion against those two before implementing anything.