How to avoid non-in-person "handshakes" and spoofing due to compromised URL data on NFC card

How to avoid non-in-person "handshakes" and spoofing due to compromised URL data on NFC card

I am designing a system that allows users to purchase my NFC cards and sign up for an account on my online SaaS website.

The System

For the sake of explanation, assume the website is hosted at domain test.com.

Think of this system as a "Secret Society of Card Holders": every customer has an account on my website. Put another way, a customer has an account if and only if they have at least one card. These are the steps for the first-time buyer/user:

1. The customer buys an NFC card from me.
2. After they purchase the card, I create the card, create a unique URL for the card, and write the URL to the card.
   1. The URL is of the format https://test.com/card/<unique-code-for-card>/
3. I create an account for the customer on test.com
4. The customer receives the card.

Every customer is expected to stay signed in to test.com on their smartphones; this makes it possible to create a spontaneous "handshake" between two members of this secret society when they meet in person. Here is my desired flow for this "handshake":

1. Let Alice and Bob be members of the secret society. Both have NFC-capable smartphones on them and are both signed into their secret society accounts on their phones.
2. Alice and Bob meet in person.
3. They both learn that they are part of the secret society.
4. At this point, it ought to be that at least one of Alice or Bob has their NFC card with them.
5. Without loss of generality, assume Alice has her card with her and wants to initiate a "handshake" with Bob.
6. Bob brings out his NFC-capable smartphone and taps his phone against Alice's card to scan it.
7. Bob's phone scans Alice's card and his phone opens his browser to https://test.com/card/<alice's-card-code>/
8. Because Bob is signed into his account on his browser, the SaaS backend records a "handshake" between Bob and Alice.

What makes this "handshake" special is that it confirms that Bob and Alice meet each other in person and both happen to be a part of the secret society.

The Problems

This first obvious problem is that if Alice's card URL data were to be stolen, anyone who is part of the secret society can "handshake" with Alice regardless of geographical location.

The second problem is masquerading. If Alice's card URL were to be stolen and then be written onto Carol's own NFC card, then Carol can masquerade as Alice when Carol tries to "handshake" with anyone else.

There could be more problems that I am not aware of.

Possible Solutions

One solution is to remind users to regularly change the URL on their card. This requires the user to log into their secret society account, generate a new URL for their card, then re-write their NFC card. This requires the user to have the ability to write to NFC cards. It inconveniences the user. It requires a notification system to ensure that the user updates their card URL regularly.

A second solution is to challenge Bob, as in the "handshake" flow, to prove that his is in the physical presence of Alice. This would require Alice to take out her phone, ensure she is signed in, go to test.com/handshake/one-time-time-based-code/, and show Bob this code so that Bob can pass the challenge. This inconveniences Alice and at a non-ideal time if in-person interaction time is valued.

My Question

Is there a better solution for these problems that maintains security from online and in-person attacks? A better solution would impose minimal inconvenience, require little effort from the users, and not interfere with critical moments such as in-person interaction. At the end of the day, the goal is to record these in-person "handshakes" reliably.