Howdy,
Below I show some ways in which the STT message formats are flawed
and thus are in need of improvement, and I point out areas where the
STT specification would benefit from clarification. In what follows I
did not search hard to find the errors, so I would venture to guess
that other more severe bugs lay in hiding.
Severe problems
===============
1. On page 55 of the STT specification the low-level composite "TLV"
is defined as having three meta-data descriptions - (<tag> <length>
<value>), (<tag> <value>) and (<tag>), and at the top of page 56 it
states:
"On the wire, all TLVs appear as follows:
((DWORD dwTag)
(DWORD dwLength)
(BYTE[dwLength] rgbValue))"
However, STT is silent as to the value of dwLength and rgbValue in the
case where the meta-data TLV format is simply (<tag>). I would
venture to guess that dwLength should be set to 0 and that rgbValue
should be omitted, but if so this needs to be stated, otherwise there
are sure to be interoperability problems.
2. On page 56, section F, it states:
"The notation
(<Tag> <Value>)
suffices for TVs, with a possible name as a comment.
On the wire, TVs appear as follows:
((DWORD dwTag)
(BYTE[knownLength] rgbValue))"
However, on pages 69 and 70 we see the definitions:
(TV_XID)
Where is the mandatory value component? Should just the tag TV_XID be
encoded? If so, this would be illegal, given the definition of TV.
Should this be "(TV_XID XID)"? If so, it needs to be stated, for as
it stands the notation suggests that only TV_XID should be encoded - a
sure formula for interoperability problems. Note that on page 71 it
refers to "(TV_XID (XID OfOriginalAuthRequest))"; is this what it
should be?
3. On page 60 where the TLV/TV Tag Space is listed it is declared that
"STT-compliant software should not use (tag) values that do not appear
in this table". However, on pages 71 and 72 reference is made to
TV_CRDRSP_CODE. That TV_CRDRSP_CODE is not among the tags listed in
the TLV/TV Tag Space would suggest that STT-compliant software should
never issue Merchant Credential Response or Cardholder Credential
Response messages.
4. TLV_SIGNATURE (see page 73) is not defined in the TLV/TV Tag Space.
According to page 60 this means that STT-compliant should never use
signatures since TLV_SIGNATURE is not listed in the tag space.
5. On page 73 there is the definition "(BYTE[105] 0xff) ;padding".
Does this mean that the first byte is 0xff and the remaining 104 bytes
are 0x00, or that the 0xff is to be repeated for all 105 bytes? The
STT specification is silent in this regard. In protocol descriptions
such ambiguities are errors.
Probable errors
===============
1. As stated on page 56 of the STT document, TV formats are used when
"the length of a TV is either statically known or can be determined by
another method, as with CStrings" (because CStrings carry their own
lengths. Thus, on page 63 the definition "(TV_CREDOWNER Cstring)"
makes sense, but the definition on the next line,
"(TLV_ALTERNATE_NAME Cstring)", is probably erroneous. My guess is
that TLV_ALTERNATE_NAME should really have been defined as
TV_ALTERNATE_NAME, for with the current definition the it results
in 4 bytes for the tag and 4 bytes for the length, followed by the
CString value that is prefixed with a second length that is 1, 3 or 7
bytes, followed by the actual string data. Two sets of lengths when
one will do suggests to me an error.
2. Presumably the reason for STT defining a unique tag for each type
of value is that it is hoped that this will make it easy for software
to determine the nature of each value (e.g., its type, length, etc.).
However, this is made impossible in some cases, such as on page 64 of
the STT specification where under "Cardholder signature credentials"
and "Merchant signature credentials" we see "(TV_CARDTYPE WORD)", but
under "Acquirer, Issuer, and Credential Authority credentials" we see
defined "(TV_CARDTYPE DWORD)". Either this is an error (since
TV_CARDTYPE is 1 word in one case and two words in another) or it
reuses the tag TV_CARDTYPE in a way that defeats what I believe was
the intention behind giving every type a unique tag.
Minor errors, typos, etc.
=========================
1. Towards the bottom of page 64 "(TV_CARDTYPED WORD)" should be
"(TV_CARDTYPE DWORD)".
2. Towards the top of page 68 "TV_DATA FLAG" should be "TV_DATA_FLAG".
3. In many places (e.g., p. 68) "TV_CRDHDR_XIDXID" should be
"TV_CRDHDR_XID XID".
---
My comments above are not meant to suggest that the STT specification
is fatally flawed, but to make it clear that the STT specification is
too immature and in need of work before there can be serious
implementations of it. Those who are interested in implementing STT
should take a much closer look at STT to uncover the other bugs that I
am pretty sure exists (based on the ease with which I discovered the
bugs mentioned above without trying). In other words, the bugs
mentioned above may be easily fixed, but how many others remain? It
will probably be a lot cheaper to take a little while longer and get
the specification for electronic payments right than to rush to market
with products that do not interoperate because they are based on a
busted specification.
Bancroft Scott
Open Systems Solutions, Inc.