Major upgrade: RN 0.81 / React 19 / credo-ts 0.6.3, VC 2.0, RCE v3 + eddsa-rdfc-2022 Data Integrity, witnessed exchange

[albertoleon7794]

📖 Reviewing this PR? Start with the runbook: docs/REVIEWING_THE_UPGRADE.md — setup, static gates, the E2E ladder (and what each run proves), security invariants, and a suggested review order.

Consolidates the full upgrade effort into one branch for review. Supersedes
the stacked upgrade PRs #13 and #14 (closed in favor of this).

Scope (29 commits; see each ticket for design/details):

• Phase 1 — Appium two-wallet E2E harness. Closes Upgrade Phase 1: Appium two-wallet E2E harness for VRC exchange #8
• Phase 2 — RN 0.73→0.77, drop BCSC. Closes Upgrade Phase 2: React Native 0.73.11 → 0.77.3, drop BCSC integration #9
• Phase 3 — bifold 3.0.16, credo-ts 0.6.3, React 19, RN 0.81. Closes Upgrade Phase 3: bifold 3.0.16 + credo-ts 0.6.3 + React 19 + RN 0.81 #10
• Phase 4 — app-layer sync with bc-wallet-mobile. Closes Upgrade Phase 4: app-layer sync with bc-wallet-mobile #11
• Phase 5 — W3C VC Data Model 2.0 for VRC/RCard. Closes Upgrade Phase 5: move VRC to W3C VC Data Model 2.0 #12
• RCE v3 + eddsa-rdfc-2022 Data Integrity issuance (capability-gated,
  dual-verify with 2018), witnessed-exchange DI + VWC. Closes VRC: migrate DIDComm JSON-LD proof to DataIntegrityProof (eddsa-rdfc-2022) #15
• Google/Apple attestation root rotation. Closes Bump keyring-bifold for Google attestation root rotation #3

Proven on real devices: VC 2.0 credential, eddsa-rdfc-2022 DI-signed,
hardware-attested, and witnessed (both contact shields).

Companion bifold PR: berkmancenter/keyring-bifold#31

Known follow-up (non-blocking): DIDComm perf regression since 0.6 — #16.

Reviewer note: the app diff is the review target. The bifold submodule is a
fork-swap (old fork -> bifold-3.x), ~2,257 commits of fork history, not new code.

[bmiller59]

DRY follow-ups in the VRC module (non-blocking)

While reviewing the VRC exchange flow (bifold/packages/core/src/modules/vrc/**), a few duplications are worth cleaning up in a follow-up — none affect correctness, they're maintainability/DRY notes:

1. counterpartySpeaksVc20 / counterpartySpeaksDi in vrc-manager.ts are near-identical: same RelationshipDidRepository lookup, same ?? 1 default, differing only in the version threshold (>= 2 vs >= 3) and both swallowing errors to false. Suggest collapsing into a single counterpartyRceVersionAtLeast(agent, counterpartyRelationshipDid, minVersion: number) helper.

2. buildVrcCredential (vrc-manager.ts) and buildRCardCredential (services/rCardCredential.ts) duplicate the same useVc20/useDi → @context array selection logic (VCDM2+DI vs VCDM2+Ed25519-suite-context vs legacy VCDM1.1), each with its own copy of the "why" comment. A shared selectCredentialContexts({ useVc20, useDi }, ...) helper would remove the duplication and the risk of the two credential builders drifting on proof-context rules as the DI/VC2.0 rollout continues.

3. credential.encoded raw-JSON extraction (getting the credential JSON out of a W3cCredentialRecord, tolerating both plain objects and class instances with .toJSON()) is implemented independently four times: utils/rcardDisplayUtils.ts (toRawCredential — the most careful version, added in this PR), utils/witnessCredentialUtils.ts (six inline copies, no .toJSON() handling), utils/vrcNameHelper.ts (two more inline copies), and hooks/useDeleteContact.ts (one more). Since the robust toRawCredential helper is new code in this very PR, it'd be worth exporting it and pointing the other three files at it rather than keeping their own inline credential.encoded reads.

Happy to file these as a follow-up issue if that's preferred over addressing inline.

[bmiller59]

vrc-reference doesn't exercise the app's new capability-negotiation surface

Comparing bifold/packages/core/src/modules/vrc/** (the app) against bifold/packages/vrc-reference/** (the reference/conformance package) across this PR (main@74ac281d → this branch@1755fbb):

Aligned: the credo-ts 0.6 migration (agent.connections → agent.modules.didcomm.connections, CredentialEventTypes → DidCommCredentialEventTypes, etc.), relationship-DID creation (PeerDidNumAlgo.InceptionKeyWithoutDoc + the same credo-0.6 KMS key-lookup re-import fix), the VCDM 2.0 shape swap (issuanceDate→validFrom + v2 context), and the witnessed-flow proof-family mirroring (Witness.getMirroredJsonLdProofOptions mirrors whatever proof type it's shown, same design as the app's getVrcJsonLdProofOptions) are all consistently applied in both packages. These parts look like a safe, faithful upgrade relative to vrc-reference's pre-PR behavior — no leftover old-API calls, no shape mismatches found.

Gap — the app's new headline feature isn't represented in vrc-reference at all:

1. No RCE version negotiation. The app announces/stores a capability version (vrc:rceVersion:<n>) per counterparty and gates VC2.0/DataIntegrity issuance on it (counterpartySpeaksVc20/counterpartySpeaksDi in vrc-manager.ts). Participant.ts has no equivalent — it unconditionally builds VCDM 2.0 and unconditionally signs with 'Ed25519Signature2018' at all three call sites. It never issues a v1-legacy credential and never issues a DataIntegrityProof credential from the peer-to-peer issuer path.
2. No RCard. RelationshipCard/buildRCardCredential — the contact-info credential the app now exchanges separately from the VRC — doesn't exist anywhere under packages/vrc-reference (zero grep hits outside the app module).
3. Handshake format diverged further. The app's basic-message handshake gained an rceVersion field this PR; Participant.ts's JSON.stringify({ rDid: did }) handshake has no field to carry it, so vrc-reference can't even represent the new capability announcement, let alone negotiate on it.
4. DI issuance is only proven in isolation. The new diConformance.test.ts is a single in-memory-agent crypto round-trip (sign → verify → tamper-check), not an end-to-end DIDComm exchange. Because Participant.ts never sends a DI-signed VRC, the Witness's vrcUsesDi branch is unreachable from any of the real integration tests (connectionFlow, witnessedFlow, credentialIssuance, etc.) — only from that synthetic single-agent test.

Why this matters: vrc-reference tests passing is good evidence the credo 0.6 migration and the DI cryptosuite adapter are correct in isolation, but it is not evidence that the app's actual new feature — RCE v1/v2/v3 capability negotiation driving dual-stack proof selection over a real DIDComm exchange, plus the RCard split — works end-to-end, since vrc-reference doesn't implement or test that surface. Given vrc-reference is likely to become the foundation of a conformance test suite, this seems worth closing before relying on it for that purpose.

Suggested follow-up: update vrc-reference's Participant to negotiate rceVersion and issue DI-proof VRCs the same way the app does, and add an RCard-equivalent exchange — bringing it to full parity with the app's negotiated capability surface, while keeping the already-confirmed-safe parts (0.6 migration, VC2.0 shape, proof mirroring) as-is. If vrc-reference is meant to deliberately stay v1/v2-only for now, that scope limitation should be stated explicitly in BIFOLD_FLOW_ALIGNMENT.md so reviewers don't read "vrc-reference tests pass" as end-to-end conformance proof for the RCE v3 / RCard rollout.

[bmiller59]

Credential display architecture: the RCard split needs a cross-credential composition path

Looking at how VRC/RCard content is displayed (ContactDetails.tsx, ListContacts.tsx, CredentialOffer.tsx, ListCredentials.tsx), the original intent — that a credential type's display data is assembled into one object regardless of which underlying credential(s) it comes from — has only partially survived the RCard split, and the gap has already produced a concrete inconsistency worth fixing.

What exists today

Two separate, non-communicating systems answer "what should this contact/credential look like":

1. CredentialDisplayHandler registry (display/displayRegistry.ts, RelationshipCredentialHandler, WitnessCredentialHandler) — a clean per-type strategy pattern, but canHandle/extractFields operate on exactly one credential JSON at a time. There's no way for a handler to look at sibling credentials.
2. resolveContactDisplayInfo (utils/rcardDisplayUtils.ts) — a hand-rolled function that scans all w3cCredentialRecords, re-implements its own DTGCredential/RelationshipCredential/RCard type-matching (duplicating isDTGCredential/isRelationshipCredential from the registry file), and merges name/email/organization from whichever credential (RCard or legacy embedded issuer object) has them. It's called ad hoc from four separate screens (ContactDetails.tsx, ListContacts.tsx, CredentialOffer.tsx, chat-messages.tsx).

The RCard split introduced a genuinely new requirement — one contact's display identity now legitimately spans two W3C credentials (the VRC + the RCard) — but instead of extending the registry to handle that, a parallel resolver was bolted on beside it. Concretely, this already causes drift: in CredentialOffer.tsx, the header name is resolved via resolveContactDisplayInfo (RCard-aware) while the field list below it is resolved via RelationshipCredentialHandler.extractFields (not RCard-aware — reads the embedded issuer object only). For a new-style (v2/v3) offer, the header shows the right name while the field list's "Issuer Name/Email/Organization" rows simply don't render. Not a data-correctness bug, but a symptom of the same information being computed two different ways in the same screen.

Recommended fix

Extend the existing handler architecture rather than working around it, so there's one doorway instead of two:

1. Add cross-credential context and a subject output to the handler interface (display/types.ts):

export interface CredentialDisplayContext {
  /** Sibling W3C records in the wallet, for handlers that need to cross-reference
   *  (e.g. RelationshipCredentialHandler resolving a contact's RCard). */
  relatedRecords: W3cCredentialRecord[]
}

export interface CredentialDisplaySubject {
  id: string
  name?: string
  email?: string
  organization?: string
}

export interface CredentialDisplayHandler {
  extractFields(credential: W3cCredentialJson, context: CredentialDisplayContext): Field[]
  /** Optional: canonical display identity for this credential's issuer/subject —
   *  used for headers, chat messages, contact screens. Handlers with no notion
   *  of "subject" (e.g. WitnessCredentialHandler) simply omit it. */
  extractSubject?(credential: W3cCredentialJson, context: CredentialDisplayContext): CredentialDisplaySubject
  // ...unchanged
}

2. Thread it through CredentialDisplayResult / getDisplayInfo (display/displayRegistry.ts):

export interface CredentialDisplayResult {
  fields: Field[]
  buttonText: CredentialButtonText
  matched: boolean
  credentialTypeName?: string
  subject?: CredentialDisplaySubject   // NEW
}

getDisplayInfo(credential: W3cCredentialJson, context: CredentialDisplayContext): CredentialDisplayResult {
  const handler = this.findHandler(credential)
  if (!handler) return { fields: [], buttonText: DEFAULT_BUTTON_TEXT, matched: false }
  return {
    fields: handler.extractFields(credential, context),
    subject: handler.extractSubject?.(credential, context),
    buttonText: handler.getButtonText(),
    matched: true,
    credentialTypeName: handler.getCredentialTypeName?.(),
  }
}

3. Move (not delete) the RCard-resolution logic into RelationshipCredentialHandler:

extractSubject(credential: W3cCredentialJson, { relatedRecords }: CredentialDisplayContext): CredentialDisplaySubject {
  const issuer = extractIssuerObject(credential)
  const rcardInfo = resolveContactDisplayInfo(relatedRecords, issuer.id) // existing, tested logic — just relocated
  return {
    id: issuer.id,
    name: rcardInfo.name ?? issuer.name,
    email: rcardInfo.email ?? issuer.email,
    organization: rcardInfo.organization ?? issuer.organization,
  }
}

rcardDisplayUtils.ts's jCard parsing and its existing test suite stay as-is — only the entry point moves.

4. Update the four call sites (CredentialOffer.tsx header, ContactDetails.tsx, ListContacts.tsx, chat-messages.tsx) to read .subject off the one getDisplayInfo() call instead of separately calling resolveContactDisplayInfo. Header and field list become structurally guaranteed to agree, since they're now sourced from the same function call.

Why this shape

• Additive, not a breaking rewrite — extractSubject/context are optional/new parameters; handlers that don't need cross-referencing are unaffected.
• Preserves the registry's real strength (the core/VRC decoupling via ICredentialDisplayRegistry) rather than introducing a second architecture alongside it.
• Closes the existing duplication — isDTGCredential/isRelationshipCredential vs. the type-matching re-implemented in resolveContactDisplayInfo collapse into one call path.
• Regression-proofs itself — a test asserting getDisplayInfo(vrcCredential, { relatedRecords }).subject.name matches what a screen renders as its header would fail immediately if a future change reintroduces a second, drifting path.

Scope: display/types.ts, display/displayRegistry.ts, RelationshipCredentialHandler.ts, and the four call sites above, plus tests. A moderate, well-scoped follow-up — not something that should block this PR, but worth filing before more fields or another related-credential-type need the same cross-referencing.

[bmiller59]

witness-server: dual-stack design is sound, but the test suite doesn't exercise the changed behavior

Compared bifold/packages/witness-server/** between main@74ac281d and this branch@1755fbb (7 commits, WitnessService.ts is the bulk of it at 462 changed lines).

The good news: backward compatibility holds

Dual-verify for Ed25519Signature2018 vs DataIntegrityProof/eddsa-rdfc-2022 was implemented by registering a new signature suite into Credo's existing suite-resolution machinery (DataIntegritySuiteModule), not by rewriting verification logic — so the verification path for old-style VRCs is untouched. Issuance mirrors the same way: getMirroredJsonLdProofOptions explicitly defaults to the old hardcoded Ed25519Signature2018/VC1.1 options for anything that isn't a recognized DI proof, so an old client's VRC still produces a byte-identical old-shape VWC (WitnessService.ts VC2.0 branch is gated on vrcContexts[0] === CREDENTIALS_V2_CONTEXT_URL; legacy VRCs fall through to the pre-existing @context/issuanceDate/expirationDate shape unchanged). The freshness-window widening (5→10 min) is a coordinated fix matching a backdating allowance already present on the app side (vrc-manager.ts), not an arbitrary loosening. This is genuine dual-stack support, not a bolt-on.

Finding 1 (moderate-high): the test suite doesn't test the changed code

WitnessService.test.ts (2524 lines) wasn't touched in this PR despite the 462-line source diff. On inspection, it's not just stale — it's structurally decoupled from the real implementation:

• The "Freshness Check" tests hardcode the old 5-minute window and assert a 6-minute-old credential is rejected. That assertion is now false against the shipped code (which accepts up to 10 minutes) — but the test still passes because it only checks its own local arithmetic, never handlePresentationSubmission's actual freshness logic.
• The "VWC Building" tests call a local buildMockVWC() helper that still canonicalizes with the old JSON.stringify(vrcJson, Object.keys(vrcJson).sort()) (pre-jcsCanonicalize) and builds issuer as a bare string, while the real buildWitnessCredential now emits issuer: { id, name }. Neither a digest-algorithm regression nor an issuer-shape regression would be caught by this test.
• Nothing in the file references getMirroredJsonLdProofOptions, CREDENTIALS_V2_CONTEXT_URL, vrcIsVc20, or DI at all.

The mirroring helper itself is well-covered elsewhere (vrc-reference/__tests__/unit/mirroredProofOptions.test.ts, imported directly from @bifold/vrc-shared), and DI sign/verify round-trips are covered in isolation by diConformance.test.ts — but neither touches WitnessService.ts's two call sites (offer-side proof options, VWC-build data-model branch). Net: a real behavioral change to the core witness flow shipped with a test file that looks like coverage (parallel "VWC Building"/"Freshness Check" describe blocks) but wouldn't fail if this exact diff were wrong.

Suggestion: either add tests that call WitnessService's real methods directly for the mirroring/freshness/digest changes, or at minimum fix the now-incorrect 5-minute freshness assertion so it doesn't quietly assert stale behavior.

Finding 2 (minor): stale, self-contradicting comment

WitnessService.ts (added in the DI-verify commit) still has a comment reading "Witness ISSUANCE stays 2018 until the peer matrix is proven" — directly contradicted two commits later in the same PR when DI issuance via mirroring was added. Low functional risk (it's a comment), but likely to mislead the next reader into assuming issuance never emits a DI proof.

Everything else checked out clean: TlsManager/LocalityService diffs are mechanical type/lint fixes with no TLS-behavior change, index.ts's askar-nodejs import-order fix is a well-explained narrow correctness fix, and CredentialRegistry.ts (unchanged) doesn't need anything the new mirroring code doesn't already provide.

Non-blocking overall — the design itself is sound — but the test-coverage gap in particular seems worth closing before relying on this suite as a regression guard for the witnessed-exchange flow going forward.

[bmiller59]

app/src/services/attestation.ts: unrelated to hardware attestation — but the DRPC removal leaves a silent dead-end

Worth clarifying scope first: despite the name and directory, this file has nothing to do with hardware/biometric attestation (Secure Enclave, StrongBox, App Attest, useHardwareAttestation) — all of that lives in bifold/packages/core/src/modules/vrc/* and has already been covered in earlier review passes. This file is a separate, older subsystem inherited from the upstream BC Wallet fork lineage: AttestationMonitor auto-detects and auto-handles proof requests asking for a remote attestation credential from BC Government's Traction service, gated by hard-coded credDefIDs/invitation URLs per environment in app/src/constants.ts:14-30 (pointing at traction-acapy-*.apps.silver.devops.gov.bc.ca). It's live-wired, not dead code: registered in the DI container (app/container-imp.ts:111), started/stopped on every agent lifecycle transition (app/src/hooks/useBCAgentSetup.ts:63-69), and subscribed to by Connection.tsx/ProofRequest.tsx for loading/toast UI.

Finding (medium): notification filter and failure path are now out of sync

Diffed against main: this PR deliberately strips the entire remote-attestation fetch/generate flow (connectToAttestationAgent, fetchNonceForAttestation, generateAttestation, requestAttestation, plus the associated @bifold/react-native-attestation and react-native-device-info imports) — a reasonable simplification, with a comment explaining there's no stable @credo-ts/drpc for Credo 0.6 and that Keyring doesn't run the BC service. requestAttestationCredential (attestation.ts:188-204) now unconditionally logs a warning and fails.

The problem: useNotifications (app/src/hooks/notifications.ts:110-120) still unconditionally filters proof requests matching isProofRequestingAttestation out of the notification list, regardless of whether they can be resolved. Combined with the now-guaranteed failure, any live proof request matching those credDefIDs becomes invisible to the user and permanently unresolvable — not shown as a notification, not auto-completed. The user only learns something went wrong if they happen to have Connection.tsx or ProofRequest.tsx mounted at the exact moment the FailedRequestCredential event fires; otherwise it's a silent dead end.

Whether this is actually reachable depends on whether Keyring still talks to real BC Government/Traction verifiers gated on these specific credDefIds — the repo still carries BC "Person credential" flow code (keyring-theme/features/person-flow, BCIDHelper.ts, CRED_HELP_ACTION_OVERRIDES in app/container-imp.ts), so this isn't provably dead, just unclear.

Suggested resolution — pick one:

1. If Keyring still needs this flow, restore a real handler (or an explicit "not supported, tell the user" UI) rather than a silent failure.
2. If Keyring no longer talks to BC's Traction instance at all, remove AttestationMonitor/AttestationRestrictions and the notification-hiding filter wholesale, rather than leaving a stubbed, dead-ended version wired live in the container.

Everything else checked out clean

The Credo 0.6/@credo-ts/didcomm migration in this file itself is mechanically solid: agent.proofs.* → agent.modules.didcomm.proofs.*, proofRecordId/credentialRecordId → proofExchangeRecordId/credentialExchangeRecordId, ProofState/CredentialState → DidCommProofState/DidCommCredentialState, event payload key rename — all consistent with the same pattern used elsewhere (app/src/utils/credentials.ts). Lint is clean, no leftover unused imports from the stripped code path. Two low-priority items not worth a blocking discussion: six of nine AttestationErrorCodes are now unused dead code left over from the removed flow, and a pre-existing (not introduced by this PR) theoretical stuck-spinner edge case if handleProofRequest ever returns false with an undefined agent — practically unreachable today, just worth a follow-up ticket if anyone's doing cleanup in this area.

Non-blocking, but the notification/failure mismatch in particular seems worth a deliberate decision rather than leaving as-is.