BRC-103 Authentication and Identity

[KarlTheProgrammer]

I think we should separate authentication and identification. Authentication should just be providing a public key, proving you own it with a signature of challenge data provided by the other party, and then performing actions based on that key. Identify can be linked to authentication keys via certificates if necessary, but I think that will often be optional. For instance if I initiate communication with a friend then we can do identity verification out of band without any certificates.

Replay issues should be resolved naturally. For a payment the recipient should provide unique locking scripts to receive the tokens so the receiving keys don’t need to be derived from the nonce. Re-using locking scripts is not a good idea for many reasons. For authentication the other party should create a unique challenge to sign based on the current time so that the other party has to prove they can generate a new signature. I believe this removes the need for tracking previous nonces to ensure they aren’t reused.

For simple HTTP calls after initial authentication a hash from the auth process can simply be used in the http request “Authorization” header. For more complex communication, data can be signed with the same key used during authentication to link the messages to one “identity”. Timestamps can be included in the data to ensure it is fresh, but other than that specific methods to the actions being performed might be necessary to prevent replaying messages.

[ty-everett]

On the point about certificate exchange, in this protocol the exchange of certificates is optional. People can exchange certificates if they want, but there is no requirement to do so. If either party is unsatisfied, they will not proceed. Someone can do identity verification out of band if they so choose, but the protocol enables people to request certificates if desired. Authentication signs a counterparty-provided nonce along with the message, in a way that links it with the key.

For any messages where replay is a concern, a timestamp, block hash, or counter can be included in the signed payload. Any attempts to replay the message can be detected as part of the higher layer protocol.

Session nonces are cryptographically verifiable as having been generated by the party who sent them. Message nonces are generated by the sender. These are communicated alongside the message payload and used in the key derivation process to derive child keys for signing and verification. The cryptographic implementation can be found in the createNonce and veriyNonce functions of the @bsv/sdk TypeScript reference implementation. Because replay protection is an application-specific concern, and not always enforced, we don't strictly require unique message nonces on every messages. However:

• If the sender does not use the YourNonce (counterparty nonce) for the current session (maybe they had a previous session), the recipient can choose to drop the message.
• If the sender does not use a unique message nonce every time, the recipient could track which nonces were already used and reject them.
• As part of some higher layer protocol, the recipient could even require point 1, and also require that the message-specific nonce comes from the hash of the message itself (potentially in conjunction with some other value, like a timestamp, which could potentially also be included as part of the message)

This protocol is designed to be an extensible base layer and a starting place on which to build. It is extensible enough to support applications that include all of the above. However, we have not included them because, like message encryption, they are not always required. The strategy is "let's get everyone on board with something extensible at the base layer, then build upwards from there, without building monolithically."

BRC-103 is not concerned with payments at all, that's another layer (BRC-105, which relies upon BRC-29 to generate unique locking scripts for every payment). The TypeScript reference implementation is in @bsv/payment-express-midddleware. We describe our approach to HTTP-based authentication in BRC-104: in short, after an initial handshake over a well-known endpoint, we sign the critical components of all HTTP requests and responses, encapsulating them within BRC-103 messages. Headers include signatures, keys, and nonces as appropriate. The @bsv/auth-express-middleware is the TypeScript reference implementation. The TS-SDK's AuthFetch is the unified client-side for both HTTP (BRC-104) and payments (BRC-105).

I hope this helps and we look forward to continued collaboration on building interoperable base-layer systems.