[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
Understood. I think we should consider the following in the context of our discussion of application-specific profiles even though the vendor is not part of the group. We might want to invite them to join in a special session if they are interested. http://www.globalsign.com/adobe-cds/index.htm > -------- 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 12:41 pm > To: "'Arshad Noor'" <arshad.noor@strongauth.com>, > <legalxml-enotary@lists.oasis-open.org> > > > 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 > > > > --------------------------------------------------------------------- > 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]