[757] in WWW Security List Archive
Re: IETF - sec.ispp.agenda
daemon@ATHENA.MIT.EDU (Paul-Andre Pays)
Fri Jun 30 08:32:16 1995
Date: Fri, 30 Jun 1995 11:14:55 +0200
To: Stef@nma.fv.com
From: Paul-Andre.Pays@edelweb.fr (Paul-Andre Pays)
Cc: Amir Herzberg <amir@watson.ibm.com>, e-payment@cc.bellcore.com,
mwalnut@cnri.reston.va.us, admin@ds.internic.net,
e-pay@zurich.watson.ibm.com, jis@mit.edu, www-buyinfo@allegra.att.com,
www-security@ns2.rutgers.edu, hamid@watson.ibm.com,
gopal@watson.ibm.com, jksumner@nycvmic1.watson.ibm.com,
John C Klensin <klensin@mci.net>
Errors-To: owner-www-security@ns2.rutgers.edu
At 20:47 29/06/95, Einar Stefferud wrote:
>Hello Amir -- I trust that with the latter ISPP BoF presenters limited
>to 5 minute time slots, that you are going to seriously ride herd on
>the early presenters to keep them within their time slots.
I'll go a step further.
Does it make any sense at all to have a BOF which mainly consists
in 5 or 10 min slots (ie. no time to have any interesting information that
is not available and certainly known by the participants) and which lets
only a very very small amount of time for discussion and future planning?
I know it is more work, but would not it be better to try through email and
previously to the meeting
1. to define the 3 to 4 conceptuals/architectural models that lay behind these
proposals and be able to make a grouping
Frankly there is nothing in common between a system limited to
establish a secure communication path between 2 entities (eg. a
merchant and a customer, or a customer and a bank) and one which
mandates a trusted third party acting as a clearing house. We
cann't expect to end-up with a common protocol for such
different models.
However it is of the highest interest for this potential WG
to identify a common set of security requirements and
functionalities (see 2. below) and even possibly a common
set of protocol elements (such as a customerID and name space
a certificate aso. see 34. below)
2. to establish a set of requirements and criterias.
this would enable by means of a table to compare at a glance
the application domains and level of security or guaranty
brought by each proposal
the requirements and criterias would encompass such technical
points as the one described for example by iKP but also operational
and even legal considerations (acceptability by the commerce key
actors and banks or credit card networks and conformance to
the trade regulations in different part of the word).
This also implies that for many criterias the technical people will
have to hand this over to people with an operational and
business background.
My own experience has shown that in the end the e-payment
technology is a minor factor when trying to set-up an
effective electronic commerce SERVICE; the technology is
just here to suit the operational and business oriented needs
3. to identify a set of common primary elements that
could be shared by the several systems that will survive.
One good example is the customer identification for which I hope
one (or a very few) name space can be agreed upon. Another one
is the exact brand of certificate...
This would enable, instead of a tedious sequence of ten presentations,
1. to use the meeting to have a first classification comparisom of the
proposal with respect to the things above
2. to give some flesh to the charter, as I am convinced, that this type
of activities and documents are required id we want this BOF be more than
a simple vendors forum or competition.
_________________________________________________________________________
PAP: paul-andre.pays@gctech.edelweb.fr tel +33 1 34 52 00 88
http://www.edelweb.fr/ fax +33 1 34 52 25 26
CC Tech : The Globe Online Technology Company
_________________________________________________________________________
