Conformance vector auth.brc31-handshake.1 does not match what the SDK emits, and two auth vector files are tagged BRC-31 but contain BRC-103

[mitch-burcham]

Summary

Two problems in the auth conformance vectors, found while wiring them into a Rust implementation at pinned commit 8b074a06481389edfcd4be624960d7849b0da59b.

1. auth.brc31-handshake.1 shows an initialRequest body the SDK does not produce

The vector's body includes nonce, payload: [], and signature: [].

Running the real @bsv/sdk 2.4.1 Peer.initiateHandshake, the emitted initialRequest is exactly:

{ version, messageType, identityKey, initialNonce, requestedCertificates }

No nonce, no payload, no signature — and JSON.stringify omits undefined members, so those keys are absent on the wire.

The vector's example also shows x-bsv-auth-* headers on the /.well-known/auth POST. SimplifiedFetchTransport.fetchAuthMessage sends only Content-Type: application/json for handshake messages; the x-bsv-auth-nonce / -signature headers belong to the general-message path (buildAuthMessageFromRequest in auth-express-middleware), which is a different message type on a different code path.

The vector appears to conflate the general-message header contract with the handshake body contract. Its reference_impl is the Express middleware, so it may be describing what the middleware tolerates rather than what a client emits — but as written it is a trap: we briefly changed our client's wire format to satisfy it before catching the mismatch against the SDK.

Suggested fix: regenerate the body from a real Peer.initiateHandshake, or mark the vector as describing middleware tolerance rather than client output.

2. auth/brc31-handshake.json and messaging/authsocket.json are tagged brc: ["BRC-31"] but contain BRC-103

Both carry messageType: initialRequest, version: "0.1", and the x-bsv-auth-* envelope — that is BRC-103 mutual authentication. messaging/authsocket.json's own vector text even says "BRC-103 handshake".

Genuine BRC-31 (Authrite) is distinguishable by protocol ID [2, 'authrite message signature']; BRC-103 uses [2, 'auth message signature']. messaging/brc31/authrite-signature.json is correctly tagged — it really is Authrite.

This matters for anyone selecting vectors by tag: filtering on brc: ["BRC-31"] pulls in 28 BRC-103 vectors alongside 28 genuinely deprecated Authrite ones. We nearly wired the Authrite set into a BRC-103 implementation on the strength of the label.

Suggested fix: retag the two files to BRC-103.