[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalxml-enotary] Groups - Comments on Phase I Deliverable (eNotaryXSD) (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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]