[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-enotary] Groups - Comments on Phase I Deliverable (eNotary XSD) (Phase-I-Deliverable-Comments.pdf) uploaded
Arshad is right as to my comments. As John's comments indicate, the identification of the signer is identical in both paper and electronic worlds. What I'm saying, as Arshad pointed out, is that the signer's credentials should not be in the document. I think I also mentioned in a previous post that, if data or meta-data like the Identifying Document ID number (e.g. driver license number) were included in an electronic document such as a mortgage, it would render that document un-recordable under many existing laws aimed at keeping "personally identifiable information" out of the public records. Since the mortgage industry is a prime user of notarized documents, for this reason alone, I wouldn't want a standard that even allowed me to include as an option any of the credential or authenticating information in the document. David > -----Original Message----- > From: Arshad Noor [mailto:arshad.noor@strongauth.com] > Sent: Monday, May 26, 2008 02:35 PM > To: legalxml-enotary@lists.oasis-open.org > Subject: Re: [legalxml-enotary] Groups - Comments on Phase I > Deliverable (eNotary XSD) (Phase-I-Deliverable-Comments.pdf) uploaded > > John, > > If I understand David's posting correctly, all he's asking for is > to remove elements that refer to the Signer's credentials - not > the identification of the Signer him/herself. The SignedDocument > will identify the Signer by name, just as the paper document does, > but the authenticating meta-data (what credential was used to > verify the identity, who issued the credential, etc.) do not need > to be in the e-Notarized document. > > I find myself concurring with David on this, but leave it to the > legal experts on the TC to make the final determination. > > WRT the web-service, I apologize for not recalling that part of > the discussion, but yes, it is possible to include an optional > element as a child of the NotaryPublic element, that applications > can fill in with the URL of a web-service that can verify the > credentials of the signing Notary Public. > > The question is, will that one element suffice? To the best of > my knowledge, web-services can be implemented in a couple of > different ways: using JAX-RPC or SOAP. I am extremely familiar > with SOAP, but not only understand JAX-RPC conceptually. Let me > do some preliminary research on this and get back to the TC about > what this additional element might involve. > > Arshad > > John Messing wrote: > > I really don't understand this alleged privacy issue. A notary > > identifies the signer in a paper document. The same identification > must > > occur electronically for the notarization to be valid. Otherwise, how > > can one tell from the four corners of the document whose signature > was > > notarized? If that is true, then having meta data that is machine > > readable that serves the same purpose is no more invasive of privacy > > than the identification in the jurat, acknowledgment or certificate. > > > > On another point, one thing that we discussed and tentatively agreed > > upon but which did not make it into Arshad's paper, at least as far > as I > > could tell, was the notion that there should be "hooks" to enable > notary > > identification through a web service, which optionally could include > > SAML or WSS authentication before a query was honored, for > compatibility > > with concerns of notary administrators. Did I miss it somewhere? > > > >> -------- Original Message -------- > >> Subject: RE: [legalxml-enotary] Groups - Comments on Phase I > >> Deliverable (eNotary XSD) (Phase-I-Deliverable-Comments.pdf) > uploaded > >> From: "David E. Ewan" <dewan@speakeasy.net> > >> Date: Mon, May 26, 2008 6:52 am > >> To: <arshad.noor@strongauth.com>, > >> <legalxml-enotary@lists.oasis-open.org> > >> > >> > >> All -- Looks like we're moving right along. I'd like to comment on > Arshad's response to one of my comments regarding Signer ID. > >> > >> I've re-thought my position, and I now believe that the entire > SignerID element is more properly relegated to a journal entry/function > and does not belong in the document itself. After all, the hallmark of > getting the notary's signature (electronic or otherwise) is that the > notary will not sign UNLESS the principal signer has been identified to > the satisfaction of the notary as required by the jurisdiction's laws. > How the notary does/did this is immaterial to me if I am relying on the > notarized document. I'm allowed to (if not expected to) rely on the > document precisely because the notary's signature is there saying to me > that the notary has identified the document signer(s) as required by > law. That's the whole point of having a notarized document -- all the > person's personally identifying information does NOT have to be set > forth at length in the document. If we add all this information back > into the document, we not only run afoul of the privacy laws, but also > somew > h > > at defeat the whole purpose of having notaries. > >> So, my preference would be to omit the SignerID element in its > entirety. > >> > >> If SignerID is retained, the IDDocumentNumber and IDExpirationDate > should be omitted (not made optional, but omitted) for the privacy > reasons I expressed previously. IDIssuedBy should be either omitted or > changed to be optional, and PersonallyKnownTo added as Arshad suggested > (either method Arshad described seems acceptable). > >> > >> I do wonder about having the enumerated list of IDDocumentType -- > doesn't this artificially limit the schema to currently existing > document types and preclude future documents which may be acceptable or > even required as the various laws in this area develop? In my mind, > this reinforces my conclusion above that the entire SignerID element > should be omitted, since the notary's signature says that the notary > identified the document signer according to whatever > laws/rules/regulations existed at the time. > >> > >> David > >> > >> -----Original Message----- > >> From: arshad.noor@strongauth.com [mailto:arshad.noor@strongauth.com] > >> Sent: Sunday, May 25, 2008 3:26 PM > >> To: legalxml-enotary@lists.oasis-open.org > >> Subject: [legalxml-enotary] Groups - Comments on Phase I Deliverable > (eNotary XSD) (Phase-I-Deliverable-Comments.pdf) uploaded > >> > >> The document named Comments on Phase I Deliverable (eNotary XSD) > >> (Phase-I-Deliverable-Comments.pdf) has been submitted by Arshad > Noor* to > >> the OASIS LegalXML eNotarization TC document repository. > >> > >> Document Description: > >> The combined comments on the XSD for the eNotary TC's specification > on > >> e-notarized documents, along with responses from some TC members and > the > >> consultant. > >> > >> View Document Details: > >> http://www.oasis-open.org/apps/org/workgroup/legalxml- > enotary/document.php?document_id=28389 > >> > >> Download Document: > >> http://www.oasis-open.org/apps/org/workgroup/legalxml- > enotary/download.php/28389/Phase-I-Deliverable-Comments.pdf > >> > >> > >> PLEASE NOTE: If the above links do not work for you, your email > application > >> may be breaking the link into two pieces. You may be able to copy > and paste > >> the entire link address into the address field of your web browser. > >> > >> -OASIS Open Administration > >> > >> > >> __________ Information from ESET NOD32 Antivirus, version of virus > signature database 3131 (20080526) __________ > >> > >> The message was checked by ESET NOD32 Antivirus. > >> > >> http://www.eset.com > >> > >> > >> > >> __________ Information from ESET NOD32 Antivirus, version of virus > signature database 3131 (20080526) __________ > >> > >> The message was checked by ESET NOD32 Antivirus. > >> > >> http://www.eset.com > >> > >> > >> > >> -------------------------------------------------------------------- > - > >> To unsubscribe from this mail list, you must leave the OASIS TC that > >> generates this mail. You may a link to this group and all your TCs > in OASIS > >> at: > >> https://www.oasis- > open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]