Subject: RE: Notary services requirements -- directions?

From: Peter Sylvester <[email-masked]>
Date: Tue, 12 Oct 2004 17:14:16 +0200 (MEST)

Merriam-Webster is sometimes helpful: 

'notarization' =  
1. the act, process, or an instance of notarising.
2. the notarial certificate appended to a document.

'notarize' = to acknowledge or attest as notary public.

'notarial' = 
1. of relating to, or characteristic of a notary public
2. donce or executed by a notary public.         

'notary public' = a public officer who attests or certifies writings
(as a deed) to make them authentic, and takes affidavits, depositions,
and protests of negotiable paper.

It seems that indeed the words notarXXX are heavily connected to
one profession, and, as I conclude from this discussion, notaries
don't like someone else playing in their garden. :-) So be it. :-)

(As far as I understand from French dictionaries, the words
 notarisation or notariser seem not to exist in French. I
 haven't contacted the Acedemy Francaise. 

It was (maybe) a mistake (of mime?) to have the word in the name
of the working group. 

How can we (escape from)/remedy this situation?
We could add a remark "the term is a French word". 

But, well, before making a title, it seems to me that we may first come 
to an agreement  about *what* protocol we are doing, i.e., the ones 
between machines that 'certify' something, my view:

- act as a more or less automatic tool to perform some defined 
  validation activity 
- a to 'certify' the result, i.e. authenticating the data.
- used in workflows.  

Note that protocol is meant in a large sense, not just the 'access protocol', 
there are components for auditable operational requirements, i.e. a service
must play the game in the right way, and cannot just pretend to do something. 

Is it that what we are talking about? 
It seems that this is what Larry was proposing? 

Since more than 15 years or 20, we call some beasts 'certification authority',
and not 'e-certification authority', I am not sure whether the remark 'clumsy'
is related to the prefix 'e-' or to 'e-certification' as a buzzword.  

  "Protocol requirements for (data?) certification services"
 
seems another possibilities, also long and maybe 'clumsy', too. 

("Data" in order to avoid a confusion with public key certification)

I hope not having added too much confusion to the discussion. 
Peter

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 12 Oct 2004 12:51:34 -0400

> But, well, before making a title, it seems to me that we may 
> first come to an agreement  about *what* protocol we are 
> doing, i.e., the ones between machines that 'certify' 
> something, my view:
> 
> Note that protocol is meant in a large sense, not just the 
> 'access protocol', there are components for auditable 
> operational requirements, i.e. a service must play the game 
> in the right way, and cannot just pretend to do something. 

It seems like we are settling on a few avenues (with existing protocol
correlations in parentheses):

	- long-term signature formats (e.g. ERS)
	- long-term signature format protocols (e.g. machine-to-machine a la
WebDAV or DVCS variant)
	- server-based data certification protocols (e.g. machine-to-machine
a la DVCS)

Is there an additional need to define means for representing notarial acts
performed by humans?

Has anyone been following the OASIS work that was discussed during the San
Diego meeting?

---

From: Larry Masinter <[email-masked]>
Date: Tue, 12 Oct 2004 16:25:01 -0700

Personally, I don't think we get into too much trouble
using the word 'Notary' in the title of the working group
or even in the title of a document here and there, as long
as we're clear -- after all, it's a term that's been used
already in the industry, and we're not particularly offering
those services for sale, in any case. 

I think the requirements document might note that the
term may have restricted use in some legal jurisdictions,
and I think it is reasonable to add some wording to that effect.

Are time-stamping services associated with unsigned
data out of scope, because they're already covered?

Are combined archive-and-certification services
(which archive data and also provide for the certification
of the data archived) out of scope?

Larry

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 12 Oct 2004 19:35:25 -0400

> From: Larry Masinter [mailto:[email-masked]] 
> Sent: Tuesday, October 12, 2004 7:25 PM
> Subject: RE: Notary services requirements -- directions?
> 
> Personally, I don't think we get into too much trouble using 
> the word 'Notary' in the title of the working group or even 
> in the title of a document here and there, as long as we're 
> clear -- after all, it's a term that's been used already in 
> the industry, and we're not particularly offering those 
> services for sale, in any case. 

I don't mind the title either.  
 
> I think the requirements document might note that the term 
> may have restricted use in some legal jurisdictions, and I 
> think it is reasonable to add some wording to that effect.
> 
> Are time-stamping services associated with unsigned data out 
> of scope, because they're already covered?

I'm not sure what you mean out of scope.  If you mean outside the scope for
new specification work, I think so.  If you mean outside the scope of what
we may refer to as a notary service, I don't think so.  Timestamping seems
like a fundamental component.  We've explicitly included support for
unsigned data in the archive discussion and since those have so far been
discussed pretty much solely in terms timestamp solutions, I think this is
in scope (if already covered elsewhere).  
 
> Are combined archive-and-certification services (which 
> archive data and also provide for the certification of the 
> data archived) out of scope?

I think this combination is very much in scope.  It seems natural for the
data certification service we define to be capable of verifying the
structures defined for long-term archive purposes.  For some purposes, this
combination may be invest too much trust in a single entity.  For other
purposes, it seems like the ideal pairing (e.g. a binding that verified the
evidence record upon data retrieval).