Says the strings matched, and queues the confirmation for the pump.
One of two confirmations on this surface.confirmScan is the
other, for a flow that finished by a scanned code rather than a compared
string. They ask a person the same question and carry the same
obligation; only this one has material to hand back, because only this
one showed a person something a product could get wrong.
data is the material you showed the person, exactly as
getVerificationMaterial returned it. It is checked against what
the flow currently holds, and a mismatch rejects with
'material_mismatch' rather than confirming.
What that argument does and does not guarantee. It guarantees the
confirmation names this flow's current string: the caller cannot
produce a passing data without having read the material, because the
digits and symbols are derived from keys only this flow has, and the
layer underneath checks only that a string exists. So the material a
product confirms is material it obtained, for the flow it is confirming.
It does not guarantee that anybody looked. confirmVerification(id, await getVerificationMaterial(id)) satisfies every check here while displaying
nothing, and no API can do better: whether a human read a string off a
screen and compared it with another human is not observable from inside
this process. That last step is yours, and it is the step the whole
protocol rests on. A product that confirms without asking a person has
verified nothing, however well-formed its arguments were.
'material_mismatch' therefore means one thing: data is not this
flow's current string. In practice that is material obtained from a
different flow, or a value constructed rather than read.
It is not what you get for a flow that ended while the string was on
screen -- cancelled by either side, timed out, or refused. A flow's
string does not change once the keys are exchanged, and a replacement
flow has a different id, so that case is caught one step earlier, by the
read this function makes before it compares anything: 'unknown_flow' or
'wrong_stage'. Worth knowing which check catches what, because the two
kinds tell a product different things -- ask the person again on a new
flow, versus you are holding the wrong string.
data was typed unknown up to 0.1.0-rc.2, on a function that had only
ever rejected with 'not_implemented', so no caller has ever passed
anything to it successfully.
Confirming is not verifying. When this resolves, the flow reads
'confirmed' and the other device is not verified: the other side has
still to say the same, and two more messages have to cross. Pump, and
watch for getVerificationStage to read 'done'.
Rejects with 'material_not_ready' if the string is not available (see
getVerificationMaterial), and with 'wrong_stage' if the flow is
over or never became a comparison. Both come from the read above, before
anything is confirmed.
Says the strings matched, and queues the confirmation for the pump.
One of two confirmations on this surface. confirmScan is the other, for a flow that finished by a scanned code rather than a compared string. They ask a person the same question and carry the same obligation; only this one has material to hand back, because only this one showed a person something a product could get wrong.
datais the material you showed the person, exactly as getVerificationMaterial returned it. It is checked against what the flow currently holds, and a mismatch rejects with'material_mismatch'rather than confirming.What that argument does and does not guarantee. It guarantees the confirmation names this flow's current string: the caller cannot produce a passing
datawithout having read the material, because the digits and symbols are derived from keys only this flow has, and the layer underneath checks only that a string exists. So the material a product confirms is material it obtained, for the flow it is confirming.It does not guarantee that anybody looked.
confirmVerification(id, await getVerificationMaterial(id))satisfies every check here while displaying nothing, and no API can do better: whether a human read a string off a screen and compared it with another human is not observable from inside this process. That last step is yours, and it is the step the whole protocol rests on. A product that confirms without asking a person has verified nothing, however well-formed its arguments were.'material_mismatch'therefore means one thing:datais not this flow's current string. In practice that is material obtained from a different flow, or a value constructed rather than read.It is not what you get for a flow that ended while the string was on screen -- cancelled by either side, timed out, or refused. A flow's string does not change once the keys are exchanged, and a replacement flow has a different id, so that case is caught one step earlier, by the read this function makes before it compares anything:
'unknown_flow'or'wrong_stage'. Worth knowing which check catches what, because the two kinds tell a product different things -- ask the person again on a new flow, versus you are holding the wrong string.datawas typedunknownup to0.1.0-rc.2, on a function that had only ever rejected with'not_implemented', so no caller has ever passed anything to it successfully.Confirming is not verifying. When this resolves, the flow reads
'confirmed'and the other device is not verified: the other side has still to say the same, and two more messages have to cross. Pump, and watch for getVerificationStage to read'done'.Rejects with
'material_not_ready'if the string is not available (see getVerificationMaterial), and with'wrong_stage'if the flow is over or never became a comparison. Both come from the read above, before anything is confirmed.