Re: Points for the April 30 deadline

[Arshad Noor <arshad.noor@strongauth.com>]

My apologies for responding so late on John's e-mail; I was caught
up in some other deliverables.

I realize there is an active discussion going on on this topic, but
I wanted to address some of John's comments; please see my responses
embedded in John's e-mail message.

Arshad Noor
StrongAuth, Inc.


----- Original Message -----
From: "John Messing" <jmessing@law-on-line.com>
To: legalxml-enotary@lists.oasis-open.org, "Arshad Noor" <arshad.noor@strongauth.com>
Sent: Sunday, April 20, 2008 8:10:36 AM (GMT-0800) America/Los_Angeles
Subject: Points for the April 30 deadline

At the last TC Meeting, a deadline of April 30 was set for suggested
changes to the deliverable that Arshad has been working on. While it was
clarified that such matters can always be raised in connection with
needed changes to the work as it progresses, presumptively consideration
of such matters could be afterwards discouraged or considered out of
order if not raised before the April 30 deadline.

Some areas that were discussed in this context include:

1. Whether authentication of the notary was in or out of scope. My
feeling is that while it is important for notary signing applications to
authenticate notaries and to do so according to one or more standardized
ways, this feature should nonetheless be declared out of scope for this
version of the standard, which focuses principally on interoperability
of disparate cryptographic signing methods, but I welcome other views.

  [AN] An application authenticating any entity should not be within
  the scope of a standardized document.  From a technical viewpoint,
  it allows the standard document to survive technology. Applications 
  may then evolve to use better authentication technologies while the
  document standard remains the same.

2. Whether some of the processes of notarization should be captured as
meta-data in the standard. For example, a common law notary identifies
the signer and determines whether the act of signing appears to be
voluntary; i.e., the signer is not drunk or insane and does not appear
to be under duress. Should a determination of voluntariness be implied
from the act of notarization itself or optionally, expressly be able to
be captured in XML meta-data for the benefit of other applications?
Harry suggested the former. Unless there is a proponent of another view,
I think his position will carry as persuasive.

  [AN] I believe the legal experts on this TC are better qualified to
  respond to this than I.

3. I have attached an image from a page of the slide show document that
Arshad provided to the group in explaining the work he has done. It
shows elements he has crafted with regard to a signed document element,
which is an integral part of the work he has done. My thought was that
the elements he has defined could include a richer XML vocabulary, which
is a refinement of his work, so that applications could use the standard
xml vocabulary in connection with electronic journal features they
probably will or do also provide to notary users.

  [AN] Wherever there is a "boxed" element in the PDF presentation, the 
  eNotary-1.0-CommonTypes.xsd file does have more detail; I have just
  chosen not to clutter up the PDF with too much detail.

  For example, the SignerName from this image is erally a container for
  the following name-components:

   <xsd:complexType name="PersonNameType">
        <xsd:annotation>
            <xsd:documentation>The full name of a person.</xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="PersonPrefixName" type="tns:PersonPrefixNameType" minOccurs="0"></xsd:element>
            <xsd:element name="PersonGivenName" type="tns:PersonGivenNameType"></xsd:element>
            <xsd:element name="PersonMiddleName" type="tns:PersonMiddleNameType" minOccurs="0"></xsd:element>
            <xsd:element name="PersonSurName" type="tns:PersonSurNameType"></xsd:element>
            <xsd:element name="PersonSuffixName" type="tns:PersonSuffixNameType" minOccurs="0"></xsd:element>
            <xsd:element name="PersonMaidenName" type="tns:PersonMaidenNameType" minOccurs="0"></xsd:element>
            <xsd:element name="PersonFullName" type="tns:PersonFullNameType" minOccurs="0"></xsd:element>
        </xsd:sequence>
    </xsd:complexType>

   I took this definition from the JXDM model, since it appeared to address
   international requirements, while fully addressing US requirements too.

   Similarly, other elements also have details that are already defined.
   If you haven't had a chance to review the eNotary-1.0-CommonTypes.xsd
   file, I would encourage you to do so (with WordPad or an XML editor)
   and then let me know if the detail elements are appropriate for the
   eNotary standard.

4. I would have the signer name broken down into first, last and middle
name elements, on the theory that it is easier for computer applications
to combine pieces of smaller units of text than to take a larger block
of text and try to break it into component pieces (concatenate strings
rather than split them).  

   [AN] See my note for (3).

5. Similarly, I would break the address into street address, postal
code, city, state or province, and country.

   [AN] The eNotary-1.0-CommonTypes.xsd file has the following breakdown:

    <xsd:complexType name="USAddressType">
        <xsd:annotation>
            <xsd:documentation>A location address in the United States.</xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="StreetAddress1" type="tns:StreetAddressType" minOccurs="0"></xsd:element>
            <xsd:element name="StreetAddress2" type="tns:StreetAddressType" minOccurs="0"></xsd:element>
            <xsd:element name="City" type="tns:CityType" minOccurs="0"></xsd:element>
            <xsd:element name="County" type="tns:CountyType" minOccurs="1"></xsd:element>
            <xsd:element name="USState" type="tns:USStateCodeType" minOccurs="1"></xsd:element>
            <xsd:element name="USZipCode" type="tns:USZipCodeType" minOccurs="0"></xsd:element>
        </xsd:sequence>
    </xsd:complexType>

   We can extend the model to include an international address too,
   if needed in the first version of the standard.

6. WRT signer ID, I assume this means the hard copy identification
document or documents that the notary relied upon to establish identity.
I would have a list here, perhaps with child elements to establish the
number and issuing jurisdiction, include as options: driver's license,
national passport, state ID card, immigration document, etc.

  [AN] I have the following breakdown for SignerID:

   <xsd:complexType name="PersonIdentificationType">
        <xsd:annotation>
            <xsd:documentation>The identification document of a person.</xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="IDDocument" type="tns:IDDocumentType" minOccurs="1"></xsd:element>
            <xsd:element name="IDDocumentNumber" type="xsd:string" minOccurs="0"></xsd:element>
            <xsd:element name="IDExpirationDate" type="tns:DateType" minOccurs="0"></xsd:element>
            <xsd:element name="IDIssuedBy" type="xsd:string" minOccurs="1"></xsd:element>
        </xsd:sequence>
    </xsd:complexType>

   and for the IDDocumentType element, I have provided the following
   choices that application developers can use (we can add more if needed):

    <xsd:simpleType name="IDDocumentType">
        <xsd:annotation>
            <xsd:documentation>
                A code list that enumerates the types of identification
                documents.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:token">
            <xsd:enumeration value="Birth Certificate"/>
            <xsd:enumeration value="Citizenship Certificate"/>
            <xsd:enumeration value="Drivers License"/>
            <xsd:enumeration value="Identity Card"/>
            <xsd:enumeration value="Military ID Card"/>
            <xsd:enumeration value="Other"/>
            <xsd:enumeration value="Passport"/>
            <xsd:enumeration value="Permanent Resident Card"/>
            <xsd:enumeration value="REAL ID Card"/>
            <xsd:enumeration value="Veteran ID Card"/>
        </xsd:restriction>
    </xsd:simpleType>



7. As for signer digital certificate, I propose substituting digital
credential, with child elements that could include digital certificate,
user token, etc.

   [AN] This element is optional, and if used, will be used for
   generating an XML Signature with a standard X509 certificate *if*
   the signer has one.  I would recommend we leave this element alone, 
   since it has no bearing on the signer's signature if they used a
   different token for signing the document.  Attemtping to accommodate
   all types of signer tokens in the 1.0 standard will make the schema
   unwieldy and we might want to wait for implementation feedback as
   we move towards the 2.0 standard.

8. Other elements: in some states a notary actually records a
fingerprint in a journal. Some existing applications also capture a
biometric signature. I suggest an optional element of a  biometric
identifier, which could include iris scan, fingerprint, handwriting
exemplar, etc. This could perhaps be combined with the element list in
no. 7 as other companion elements in the digital credential category.

   [AN] Once again, I understand the goal of this standard to be the
   notarization of documents.  If we have captured the elements needed
   to identify an eNotarized document's signer(s) and verify the
   notary signature on the document, then we will have met our goal
   without including signer authentication information in the standard.

9. I encourage input from others to these and any other points so that
the TC can decide them at the next meeting and enable Arshad to move
expeditiously forward, and I particularly name as possible contributors
John Jones, Marc Aronson and any NNA representative to the TC.

Best regards.