DISCUSS: under-specification

[chris-wood]

(a) There is guidance in the architecture and issuance documents; and this
document to construct an end-to-end solution. However, for the purposes of
these document, those other are only informative. There appears to be a few
places of under-specification or implicit assumptions.

** Section 2.2
For token types that support public verifiability, origins verify the
token authenticator using the public key of the issuer, and validate
that the signed message matches the concatenation of the client nonce
and the hash of a valid TokenChallenge.

-- Please explain what “public verifiability” means. I didn’t see this term in
the architecture document.

-- Implementation details of the authenticator/token seem to be leaking into
this text (i.e., properties of the nonce || hash TokenChallenge). Does this
suggest requirements for the construction of the token? Put in another way,
where is the normative guidance that requires that construction? I couldn’t
find other language in this document on the cryptographic properties of the
Token.

** Section 2.2. Since this section is describing the redemption process, I
missed something obvious -- how does the origin know it got a “good” token”. I
was expecting to see language which say that there is a token-specific
verification steps of the Token’s cryptographic assurances.