• Files/RSS Feed Subscribe >
• Technical Errata & Updates >
• Application & Criteria >

Technical Errata & Updates

Editing clarification: DSTU X9.100-172 Part 3 section 13.13.13 makes reference to the “ID of a VA”. Future drafts of the standard will clarify this usage refers to the Company ID. Similarly in Part 3 section 10.2.4, the “Known Validators” list of IDs refers to a list of Company IDs for companies that implement the Validator role.

Editing correction: DSTU X9.100-172 Part 3 section 11.4.2, the final parameter should be shown as “Validation Info” (not the current “Validation Information”)

Editing clarification: DSTU X9.100-172 Part 3 section 10.2.5 discusses the handling of a possibly duplicate check. There are a number of potential causes for duplicate testing of a check, and not all of them should cause a transaction to be flagged as a fraud suspect. For those where the Validator determines that the check is suspicious for reasons other than the security mark, Validators should set

Failure Reason = “Y”

and

Validation Summary = Indeterminate.

The application form collects information on multiple contact addresses and telephone numbers. Only one number or email address will be included in the ICSF Registry and used on the ICSF Registry website. The additional contact numbers and information will be used by the RA in the event that the primary contact information ceases to be effective.

Editing clarification: DSTU X9.100-172 allows one return reason code to be returned in a Validate Marks response message and includes the text “If provided, shall indicated the reason that the validation failed…”. Early implementations have indicated that it may be beneficial to return a Return Reason Code even when the validation is not set to a “failed” status. For example, to indicate that the item may be a duplicate even though the security mark validates correctly. The wording around return reason codes will be clarified.

 

Schema and Registry Changes to DSTU X9.100-172

The following changes have been made to one or more of the X9.100-172 XML Schema and ICSF Registry files as a result of problems encountered or uncovered during implementation of the DSTU. Note that, as of this writing, no corresponding changes have been made to the text of any of the DSTU documents.

[14 Feb 2008] GetMarkInformationResponse, MarkSecurity

The original IISCSFMessages.xsd XML Schema, as documented in Part 3, Section 13.3, requires for each Security Mark that the Mark Security indicate:

EncryptionAlgorithmID

EncryptionPublicKey (optional)

HashAlgorithmID

HashAlgorithmPublicKey (optional)

Thus each Security Mark appears to require BOTH an Encryption Algorithm and a Hash Algorithm. This was not the intention. Without introducing an additional level of XML tags, or introducing some new null algorithms whose code can be used, the simplest approach is to allow BOTH EncryptionAlgorithmID and HashAlgorithmID to be optional from an XML perspective, but (in the text of the DSTU) make it clear that at least one of the two must be provided. The schema has been changed accordingly.

[14 Feb 2008] Mark Entry, Allow Encryp Type

The original IISCSFRegistry.xsd XML Schema, as documented in Part 2, Section 6.3.4, requires every Security Feature to be defined with at least one SFEncryptionAlgorithm. In contrast, the SFHashAlgorithm is optional (to cover the case where a Security Feature does not employ a hash algorithm as part of its cryptographic protection).

The schema has been changed to make SFEncryptionAlgorithm optional, but of course a vendor will be prohibited from registering a Security Feature that does not employ any cryptographic protection, so that at least one Encryption Algorithm or one Hash Algorithm must be specified for each Security Feature.

[20 Feb 2008] As a result of this change, two Security Feature entries (each of which had used a bogus value of 65535 for <SFEncryptionAlgorithm> to allow the Registry to validate against the XML Registry Schema) have now had these values removed.

[14 Feb 2008] Get Mark Information Request

The original IISCSFMessages.xsd XML Schema, as documented in Part 3, section 12.1, mis-spelled the GetMarkInformationReq message as GetMarkInfomation. (And examples using that message also included the error).

The schema has been changed to correct the spelling mistake.

[28 Feb 2008]

The sample Get Mark Information Request example has been edited to correct the spelling mistake, and has been checked against the updated XML Schema.

[14 Feb 2008] Contact Type, URL

The original IISCSFRegistry.xsd XML Schema, as documented in Part 2, section 6.2.4, does not include a datatype for the URL element.

The schema has been changed to include the datatype xs:string consistent with other elements within ContactType.

Additionally, in order to catch some errors, a pattern restriction has been included (cf. xs:pattern under the EMail element as shown in section 6.2.4):
<xs:pattern value="|.*\..*"/>
which requires either an empty string, or a string that includes at least one period.

[14 Feb 2008] Bulk Get Mark Information Response

The original IISCSFMessages.xsd XML Schema, as documented in Part 3, section 11.3.2 allows the whole response to include an Error Status, but does not permit an error status for each “item” in the bulk response. Originally, the Error Status was only conceived as applying to the whole message, but a situation has been identified where the responder would wish to indicate an error for one or more items while still returning information for other items.

The schema has been changed to allow each item to be returned as:

Item ID

Followed by

Error Status

Or

Check Info

[28 Feb 2008]

An error was detected with the initial change, and has been corrected. (An <xs:sequence> had inadvertently been changed to an <xs:choice>.)

[14 Feb 2008] Bulk Validate Marks Response

The original IISCSFMessages.xsd XML Schema, as documented in Part 3, section 11.4.2 allows the whole response to include an Error Status, but does not permit an error status for each “item” in the bulk response. Originally, the Error Status was only conceived as applying to the whole message, but a situation has been identified where the responder would wish to indicate an error for one or more items while still returning information for other items.

The schema has been changed to allow each item to be returned as:

Item ID

Followed by

Error Status

Or

Validation Info

[20 Feb 2008] Additional Error Code in ICSF Registry

One situation not anticipated during the original message definition work (in FSTC or X9) was how to handle the case where a message is received by a system that is not the correct system to process the request – for example, if a Validate Marks is sent to a Validator that is not responsible for, or capable of supporting, validation of security marks for a specific RT number.

An additional error code has been added to the ICSF Registry – Error Code 8 – “RT Not Known” – “The responder is not responsible for the RT”.

Now, any implementation receiving a message that should not have been sent to it can respond indicating that it does not support that RT. Note that in concert with the changes above to the Bulk Get Mark Information response and to the Bulk Validate Marks response, this error code can be returned for individual items in the request, and normal responses returned for other items in the request.

[28 Feb 2008] Updated Datatype for IDs

Due to a misinterpretation, the datatype used for many IDs in the ICSF Registry was set to xs:unsignedInt (32 bits) whereas it was intended to be 16 bits (allowing values 0 to 65535) – i.e., xs:unsignedShort.

ICSF Registry Changes

No IDs have been allocated that are >65535 so there is no compatibility problem in recasting the IDs from xs:unsignedInt to xs:unsignedShort. The following elements of the ICSF Registry schema have been changed from xs:unsignedInt to xs:unsignedShort:

<IRVersion> in <IISCSFRegistry>
<CID> in <Company>
<SFID>, <SFVersion>, <SFCRef>, <SFSymbology>, <SFAllowEncryp>, and <SFAllowHash> in <SecurityFeature>
<SID> in <Symbology>
<EAID> in <EncryptionAlgorithm>
<HAID> in <HashAlgorithm>
<SCLID> in StandardCheckLayout
<SCLFERef> in <SCLField> in <StandardCheckLayout>
<FEID> in <FieldEntry>
<ECCode> in <ErrorCode>

The ICSF Registry has been validated against the updated XML schema for the ICSF Registry.

ICSF Message Changes

As a result of the Registry changes, consequential changes have been made to the ICSF Messages XML Schema (to reflect the datatype change for these IDs). As no Registry codes where assigned that were >65535, there is no compatibility problem in changing these datatypes. The following elements of the ICSF Messages schema have been changed from xs:unsignedInt to xs:unsignedShort:

<MarkID> in MarkParametersType
<SecurityFeatureID>, <SecurityFeatureVersion>, and <SymbologyID> in <SecurityFeature> in MarkParametersType
<FieldCode> in <MarkField> in <MarkFields> in MarkParametersType
<EncryptionAlgorithmID> and <HashAlgorithmID> in <MarkSecurity> in MarkParametersType
<VID> in <KnownValidators> in MarkParametersType
<FieldCode> in FieldDetailsType
<VAId> in VAsType
<FieldCode> in <Field> in FieldDataType

The complete set of sample messages from the DSTU has been validated against the updated XML schema for the ICSF Messages.

Account Directory Changes

As a result of the Registry changes, consequential changes have been made to the Account Directory XML Schema (to reflect the datatype changes for these IDs). The following elements of the Account Directory schema have been changed from xs:unsignedInt to xs:unsignedShort:

<StandardLayout> and <PrivateLayout> in AELayoutType
<AEMark> in <AEMarksType> in <AccountEntry>
<MEID>, <MECRef>, <MESFRef>, <MESFVer>, <MESymbology>, <MECryptAlg>, and <MEHashAlg> in <MarkEntry>
<MEField> in <MEFields> in <MarkEntry>
<Validator> in <MEKnownVRefs> in <MarkEntry>
<CLID> in <CheckLayout>
<CLFERef> in <CLField> in <CLFields> in <CheckLayout>

The sample Account Directory from the DSTU has been validated against the updated XML schema for the Account Directory.

RT Feature List Changes

As a result of the Registry changes, consequential changes have been made to the RT Feature List XML schema (to reflect the datatype changes for these IDs). The following elements of the RT Feature List schema have been changed from xs:unsignedInt to xs:unsignedShort:

<SFRef> in <RTFESFRef> in <RTFeatureEntry>
<RTFECRef> in <RTFeatureEntry>

The sample RT Feature List from the DSTU has been validated against the updated XML schema for the RT Feature List. (Additionally, the RT Feature List used at the recent tradeshow demo was also validated against the updated schema.)