Negotiator / token state

[SmartLayer]

Previously we discussed the use-case of attestation on an identifier instead of a public key:

A pattern repeatedly observed in business use of blockchain was transactions on identifiers. So in today’s Etherum world, your key is your identifier - addresses are hashed public keys. But this doesn’t work when business is involved. Reasons:

• Accountability of keys. If an employee leaves, you can’t be sure that he didn’t copy the key. What you do is to keep the role but associate it with new keys.
• Business process. Usually, you have customer_id, member_id, supplier_id already, and these are designed not to mutate; replacing them with hashed pub_key breaks too many databases.
• Integration. Many systems have to work without blockchain and plugin at a certain point. It may generate a key when it needs blockchain. It may leave the key generation to a lower-level process than it’s core business flow (consider opening a service account for a customer - he has no keys before he installs the service app).

So many transactions have to be on an identifier, not on a key, and these identifiers have to be cryptographically hidden.

This topic on the protocol level was discussed and documented. This post discusses a higher-level concept, what is the state of the attestation (on an identifier) when the identifier attestation is missing?

Let's say, and a user receives an attestation (on an identifier) through a magic link. Before she has the identifier attestation, this attestation itself useless on the blockchain. So there are 2 states: the user has a valid attestation, meaning that the dependent identifier attestation is also valid and the user possesses all needed keys and secrets.

But, if the attestation is used on the web, there are more shades of greys.

Let's say a Devcon ticket. The user purchases a ticket and opens the link which contains the attestation. He clicks that link and sees the ticket details. At this moment the ticket is not owned by her, since she hasn't got the identifier attestation; but its content would display just fine. This is like in 2018 the FIFA experiment when someone sends a FIFA ticket deal; the website would display the content of the ticket for anyone who clicked the link, but it becomes "yours" only when you paid the amount quoted in the deal and finalised the transaction.

In Devcon ticket's case, the ticket can become "owned" by following a simple identifier attestation acquisition process, but should we ask the users to do so on the spot? Probably no. Speaking from the UX perspective, before the user uses the ticket to authenticate against a website (to access web services only available to legit ticket holders) or on a smart contract, there is no reason the user must go through an identifier attestation generation status. authenticate himself. Imagine that you clicked a magic link and was immediately asked to type your email address (again) and receive a verification code. It makes no sense to the user.

Hence only the smart contract use or web authentication would trigger the process to obtain the dependent identifier attestation. Therefore, between the "valid" and "invalid" states, there is another "unowned" state.

Down to the flow chart level, that means out of the token negotiation, there might be unowned tokens.

(Currently, it's not clear how do we inform the users of Negotiator about the unowned state. Maybe through operational attribute, that is, represented by ownerAddress==null but let's leave that to be decided later. For now, the flow is more important.)

Observe the flow chart of the negotiator: