OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-enotary message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Use of containers for non-XML documents


I understand that Arshad has given thought in his deliverable about
legacy applications, but I would like to approach the use of the
deliverable with regard to non-XML documents from a slightly different
angle.

In the land recording industry, it is unlikely that "pure" XML documents
will be recorded for some time despite existing XML structures for that
purpose.

I think tiffs and pdf's will continue to dominate document filings for
some time, as they do in court filings.

Therefore, to improve the receptivity to the land recorders of the
deliverable and demonstrate its current relevance, I suggest that
specific consideration be given to non-XML documents, which I seek to
exemplify by two hypothetical work flows. I limit the discussion to the
symmetric signature profile only for sake of example.

1. Signer signs a paper document and wants the notary to e-notarize it
for e-recording purposes.

2. Signer signs a pdf document by simply typing his or her name into the
signature space in front of the notary for e-recording purposes.

Notary laws theoretically support notarization in each case.

In case 1, the notary scans the document as a tiff image, and
acknowledges it, which means the signer tells the notary he or she
signed it before coming to the notary. The scanned document is then sent
to the recording office in the notary container with the certificate,
probably as a base64 encoded blob, which is hashed and the certificate
signed using the symmetric key profile.

In case 2, the signer types his or her name into an appropriate field on
the pdf in front of the notary as an e-signature, the pdf is again
base64 encoded and hashed and the certificate signed, and in this case
the certificate is a jurat.

These scenarios do not necessarily require base64 encoding IMHO, because
DSIG legally allows for signing binaries as such, so perhaps base64 
methods for accomplishing these signatures may be optional. I think some
consideration of these points should be explicitly set out for the
benefit of potential users.

The subdivision of certificates into jurats or acknowledgments as child
elements should be relatively straight-forward technically, but my sense
is that in the notary community, the semantics and relationship of
parent and child elements between certificate, jurat and acknowledgment
could become non-technical and potentially divisive, and so careful
testing of the waters may be required, lest non-technical disputes
erupt, dominate and distract.

I wonder if the group agrees as to a need to focus on these matters,
particularly those with considerable MISMO-PRIA or notary experience,
such as Marc, Mark, John and Harry.



 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]