# Conflicts:
#	src/oid4vc/REVOCATION_PLAN.md
#	src/oid4vc/status/oid4vc-status.service.ts

# Conflicts:
#	src/oid4vc/REVOCATION_PLAN.md

Two deviations from draft-ietf-oauth-status-list-13, found reviewing the
branch against the spec.

Section 13.3 requires the Status Issuer to prevent any unintended double
allocation. Allocation and revocation were serialised only by an in-process
promise chain, so a second Nest instance could hand out an index that was
already taken, or lose a revocation outright. Vault KV-v2 supports
compare-and-set, so:

- `VaultService.kvReadVersioned` returns an entry with its KV version, and
  `kvWrite` takes an optional `cas`, raising `VaultCasConflictError` when the
  conditional write loses. An unrelated 400 still surfaces as a 400.
- `StatusListRepository.load` / `saveIfUnchanged` expose that pair for status
  lists, and `Oid4vcStatusService.mutate` re-reads and re-applies on conflict.

The in-process queue stays, but only to keep the common case off the retry
path and to preserve the token-cache guarantee. It is no longer what makes
the writes correct.

Separately, the issuance session held a single `statusListId` /
`statusListIndex` pair. A session that issues more than one credential —
several `credential_configuration_ids` in the offer, or a repeated credential
request — overwrote the first entry, leaving that credential live with
nothing pointing at its bit. Replaced with a `statusEntries` array the mapper
appends to; revocation now flips every entry the session holds.

`ttl` and `exp` on the Status List Token (RECOMMENDED by sections 5.1 and
13.7) stay deferred, recorded in the plan's shortcuts table.

Exposes the Falcon-1024 accounts the previous two commits made reachable.
`POST /v1/wallet/user/` gains one optional `account_type` field; omitting it
produces exactly the ed25519 account it produced before. No other endpoint
takes a new parameter — every route keys off `user_id`, and the service works
out the rest.

Which mount holds a `user_id` is the only record of its account type, so
nothing can drift out of step with Vault. `resolveUserAccount` probes transit
first and falls through to the PQ mount on a 404, which means accounts that
exist today resolve in exactly the request they take now and only PQ accounts
pay for the miss. A non-404 from transit propagates instead of falling through:
"cannot tell" is not the same answer as "not an ed25519 account". `getUserInfo`
is reimplemented on top of the resolver with its signature and response shape
unchanged, so its eight call sites are untouched.

Creation refuses a `user_id` that already exists in the other mount, with a
409. Without that guard the same `user_id` would resolve to two different
addresses depending on probe order — funds to whichever account the resolver
happened to find first. Account type is therefore fixed at creation: the two
schemes derive different addresses, so there is no conversion to offer.

Listing now covers both mounts, and returns real addresses. The internal
`UserInfoDto.public_address` had been carrying a base64 public key that the
wallet layer converted on the way out, which is meaningless for a 1793-byte
Falcon key; both branches now produce the address directly and the conversion
is gone. The transit LIST also stops turning Vault's 404-on-empty-mount into a
500, which becomes reachable for the first time here — a deployment can hold PQ
users and no transit users at all.

`account_type` is additive on the wire but not invisible: it appears in every
user response, so a caller asserting an exact body shape will see it. The
existing `User detail` end-to-end case did, and was updated.

Signing and fees are not part of this change. `signTxAsUser` and
`addSignatureToTxn` are untouched, so no ed25519 transaction can regress; a PQ
account can be created and read but not yet spent from, which needs the `pqsig`
envelope and algod v5.

Unit tests cover the create branch and both 409 directions, transit-first
resolution, the fall-through, the 404 when neither mount holds the user, and
that a non-404 error is not swallowed. The end-to-end suite drives the
endpoints: a falcon1024 create returns the address the plugin derived, reading
the user back resolves it with no hint from the caller, a default create is
still ed25519, both types appear in the listing, and an unknown account_type is
rejected.

Bumps [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) from 22.20.1 to 26.4.1.
- [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases)
- [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node)

---
updated-dependencies:
- dependency-name: "@types/node"
  dependency-version: 26.4.1
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [eslint](https://github.com/eslint/eslint) from 9.39.5 to 10.9.1.
- [Release notes](https://github.com/eslint/eslint/releases)
- [Commits](https://github.com/eslint/eslint/compare/v9.39.5...v10.9.1)

---
updated-dependencies:
- dependency-name: eslint
  dependency-version: 10.9.1
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>