[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]