Subject: RE: Notary services requirements -- directions?

From: Peter Sylvester <[email-masked]>
Date: Mon, 18 Oct 2004 20:04:04 +0200 (MEST)

All,

I thought that the discussion of last days indicated
that the protocols for 'notarisation' (voluntarily
written with an s) are NOT there to define all and
everything what a 'notary' can do or DOES and exclusively 
a notary, but rather technical services that can/may 
be used by notaries but also by other people/services. 

==> more use cases necessary, not just 'a notary'.

e.g. B&B a "service" in a company that needs to countersign
all outgoing invoices, contracts, letters, whatever
(this service talks to a company archiver).
A service can be implemented by a machine process
combined with some persons who 'confirm'.

Here some concrete text.  

- The protocol intends to have a 'client' delegate
  some validation and procedural activity to some
  entity that will deliver an attestation concerning
  the operation. 

- An attestation contains payload data and may 
  eventually contain a security envelope.

- The payload can occur in at least two flavors:

  - An information collection attestation, including
    all things that have been done. (signed document
    is valid because the follwing CAs are trustworthy, 
    and I have performed the validation against 
    CRL etc etc)

  - An information reduction attestation, i.e.
    'this document is valid according to policy,
     details of my activities concerning this
     statement may be obtained via reference xyz'

- Security envelopes of attestion can come from
  persons or machines (with the common understanding
  of 'a person making a digital signature' 

- Since we seem to operate in context of digital signature,
  some particular 'validation policy' concerns the
  validity of digital signatures and, in particular,
  for attestations. 

- ERS and archives techniques are most likely used
  in order to ensure long term validity (if necessary),
  either explicitly towards the clients, or internally
  to the service (securing and archiving an activity log).    
  
- The protocol is not intended to replace whatever activity
  of a notary by a totally automated process. 

Well, my few cents. 

Peter
BTW:  http://www.edelweb.fr/EdelStuff/EdelNews/#first 
Thanks in advance

PS: I'd like to know how others are preparing the drafts,
I have good experience with Marshall Rose' XML based tool,
if this could be used, I propose to make the xml version
available in the web server, contributions seem easier
to make, not even speaking about the work that we canb
save to the rfc editor. The reverse engineering of a draft
to an nroff input creates a horrible amount of pbs.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 18 Oct 2004 16:25:34 -0700

I and the other editors of the notary services requirements draft
will be attempting to take feedback so far and integrate it
into the document.

I already converted the document to XML a while back, but
there's nothing to be posted yet. I hope we'll have a new
version before the Monday cutoff.

Larry
-- 
http://larry.masinter.net