How to enable a stranger to sign a static contract?

If I want to have potential business lead sign a Non Disclosure (static tokenized contract) Agreement, how to provide the new client a key on the spot for signing the transaction? It needs to be a private key linked back to the client since that is the purpose of the NDA. Who would hold onto the key after the signing? Is some kind of Blind Signature or Diffie Hellman process needed to allow us to blindly email the new private key to the client without us knowing the private key? But we need to persist the public key with us as well, just not the private key. Only the signer should know the private key of course. But we are the party generating the new private key “on the spot” for the new prospective client lead. Of course we would email the matching public key to the client. Also we have to magically fund the transaction so that it is free for the client.

What to do about not disclosing the new private key to ourselves?

Private keys must be generated by the owners otherwise they are not private. If you want someone to sign something on chain, then they must generate a wallet. You can then send them a request on chain containing the contract to sign and the funding needed to sign it. The request and contract can of course be encrypted so it is only readable by you and the recipient. Their wallet software would then need to be able to display the contract to them and allow them to post it on chain with a signature from their key. The public key will then be in the tx so that it is recorded as well.

Identity oracles can be used to identify that the key belongs to the person that you want signing the document.

Thankyou for the detail logic.
I am not clear what object in Tokenized is a “request on chain”?
Do you mean a Message?
How can the “contract to sign and the funding needed to sign it” be bundled in such a request? In what format, what data members?

It can get complicated and all of the details are not worked out yet, but the basics are as follows.

You establish an on chain relationship with someone, which involves providing proof of identity. This provides you a way to know which keys belong to who and a way to send encrypted messages.

Then you send them a tx containing an Offer message and some bitcoin. This message will be a partial tx containing the static contract.

They receive the tx and unpack the Offer. If they approve they complete the partial tx embedded in the Offer by adding an input using a key from the relationship (so you know who it is), then broadcasting the tx.

We are currently working on the details of the relationship protocol.

Maybe a Zero Knowledge Proof will help. The Client mentally selects the secret key K “On the Spot”, and then also generates the matching Public Key also “On the Spot” and then only supplies the ZKP and Public Key to the Offering Party (party who wrote the NDA). No Identity Oracle is needed.

Off chain methods can also be used. Like public keys can be exchanged in person. In person identification like a passport or something would also need to be verified though. Identity oracles are a more secure option. They allow a professional service to do the identity verification and provide you with a signature that can be traced back to them if necessary.

Another approach is to persuade the prospective client to go to to generate a private / public key pair for his/herself. That web page is for BTC addresses but I guess it can be used for BSV as well since it is a fresh key.

I wouldn’t recommend using a website to generate keys/addresses. Any wallet that supports signing a contract can also generate keys/addresses. You will also likely want on chain evidence of both of your identities. Signatures on a contract from unidentified keys will mean very little in the real world.

Thanks for those points. I need to be able to have a potential investor who does not have a crypto wallet sign the NDA on the spot on his/her mobile phone.
So a public / private key generator accessible to the investor is needed on the spot and it must enable the investor to gen the key pair while being sure that I do not see the private key.