RE: Notary services requirements -- directions?

[Richard Hansberger <rhansberger@xxxxxxxxxxxxxxxxxx>]

Andreas,

The term "Electronic Notary" is perhaps a bit awkward for US Notaries. It
might work well in other countries, but in the U.S. we have model
legislation that regulates the "Electronic Notary," which a number of states
have adopted already. Thus, I could see confusion resulting from this
service.

"eCertification Services" or "e-certification service" isn't all that clumsy
and is, in fact, more acceptable to US Notaries. In the US, we have long
recognized that the certification services human Notaries now provide will
gradually be replaced by machine services that provide better certification
guarantees.

Notaries witness; machines certify. It makes sense to me.

Rich Hansberger
National Notary Association
  

-----Original Message-----
From: Andreas U. Schmidt [mailto:Andreas.U.Schmidt@xxxxxxxxxxxxxxxxx] 
Sent: Friday, October 08, 2004 2:25 AM
To: Denis Pinkas
Cc: Larry Masinter; ietf-ltans@xxxxxxx
Subject: Re: Notary services requirements -- directions?


Denis,

certain examples in the form of scenarios and use-cases are necessary
*in the beginning* of this requirements document to delineate the scope,
clarify the subject, and provide rationales for the requirements proper.
What we have now, including two suggestions I posted earlier on, could
already be sufficient if we make good use of RFC3029 as a secondary
reference.

"e-Certification Serivces" to me seems overly clumsy - reading that title
one might wonder what such a thing might do *more* than a CA or a
Timestamping Service. At the moment I cannot think of a solid name
which avoids the conflicts with the legal domain of notaries public, and 
still
has some impact. How about "Electronic Notary (e-Notary) Services".
Still I think we should keep some relation to the title of the WG and
not make an ad hoc change which might then persist.

With regard to the abstract I would like to stick to Larry's last proposal.

AUS

Denis Pinkas wrote:

>
> Larry,
>
>> I was unaware of RFC 3029.  Should we add a reference to
>> RFC 3029 as an example of what is intended in the requirements
>> document? 
>
>
> A requirements document should not simply be a collection of examples.
> Examples can certainly be mentionned in informative annexes, but the 
> core document would still need to say what needs to be supported.
>
> RFC 3029 supports many use cases, maybe too many. A subset of RFC 3029 
> would certainly makes sense once we have define the document filling 
> the requirements (which still need to be defined). RFC 3029 contains 
> solutions to many problems, but it is not a requirements document.
>
> Besides the vocabulary problem about the use of the term "notary", we 
> would have first to define what would be the title and the topic of 
> the requirements document. I would propose something along the 
> following strawman proposal:
>
> "e-Certification Services requirements
>
> Abstract
>
> This document defines the requirements for e-Certification services. 
> Such services may be used when there is a need to register one or many 
> documents and to certify that these documents have been duly 
> semantically verified by a given person prior to registration. These 
> persons may or may not be Notaries, as understood by Civil Law or 
> Common Law. The document to be certified may or may not contain 
> electronic signatures from other persons."
>
> Denis
>
>> Would it be reasonable to rename the document:
>>
>>   Data Validation and Certification Protocol Requirements
>>
>> and replace 'Notary' with 'Data Validation or
>> Certification Service' as appropriate?
>>
>> RFC 3029 contains a few uses of the word 'notary', but
>> only in descriptions of patents and relationship to
>> prior work.
>>
>> Larry
>
>
>
>

This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed.  If you have received this email message in error, please notify the sender immediately.