Tom Arnold | 29 Mar 00:28 2001

Fwd: Re: SCMP V.07 to Informational RFC

I've just posted a revised draft of SCMP (it should be up in a few days) 
that deals with the negotiation of payload content between trading partners 
prior to processing requests.

In Patrik's notes, he raises a few additional points (one of which is 
transport negotiation). I'm wondering if this should be handled in the same 
manner as payloads or if I should specify http?  Any thoughts?

>X-Sender: pfaltstr <at> nordic.cisco.com
>Date: Thu, 10 Aug 2000 06:56:45 +0200
>To: Tom Arnold <toma <at> cybersource.com>
>From: Patrik Fältström <paf <at> cisco.com>
>Subject: Re: SCMP V.07 to Informational RFC
>Cc: "Jeffrey I. Schiller" <jis <at> mit.edu>, Ned Freed <Ned.Freed <at> innosoft.com>,
>         "Marcus Leech" <mleech <at> nortelnetworks.com>
>
>At 11.48 -0700 00-07-31, Tom Arnold wrote:
>>Patrik, this is a resend as I had your old email address... I also sent a 
>>copy of this to Jeff and Marcus, Security Area Directors.
>
>I have checked draft-arnold-scmp, and I don't see that it can be published 
>now either.
>
>The document doesn't specify enough to ensure interoperability between two 
>independently developed applications which each is developed with _only_ 
>the paper in question as a basis.
>
>For example, you don't even define the error codes or transport protocol 
>to be used! How is that to be negotiated?
>
(Continue reading)

Tom Arnold | 16 Mar 18:53 2001

Re: SCMP

SCMP is still a draft. Our company implemented the protocol to process 
transactions for e-commerce sites. We want to finish posting this as an 
informational RFC describing an application implementation of a messaging 
protocol using SMIME. In recent comments, we were asked to describe the 
mechanism that a client and server negotiate the payload of an SCMP 
message. We're still playing with this.

At 03:11 PM 3/12/2001 -0700, you wrote:

>RE:http://www.imc.org/draft-arnold-scmp
>
>I found this paper while researching e-commerce.
>What is the current status of the SCMP project?
>
>Thank you,
>
>Paul Clark
>Albuquerque TVI
>E-Commerce Instructor

Thomas A. Arnold
Chief Technical Officer
CyberSource Corporation
1295 Charleston Road
Mountain View, CA 94043-1307
email: toma <at> cybersource.com
Main: 650.965.6000
PGP Fingerprint: 2EB6 F7F0 6D80 A8E5 9BEC  A05A 0295 0ADE 8F42 EB0D
PGP keys located on PGP and MIT servers at pgp.com and mit.edu
--------------------
(Continue reading)

Tom Arnold | 31 Jul 20:39 2000

SCMP V.07 to Informational RFC

Patrik, Jeff, and Marcus,

We feel that the latest version currently posted at 
http://search.ietf.org/internet-drafts/draft-arnold-scmp-07.txt
is ready to advance as an informational RFC. SCMP is an application 
implementation of a transaction messaging protocol of S/MIME v3. We feel 
that this should probably be through the applications area as the most 
obvious current use is as a real-time request and reply messaging protocol 
supporting electronic commerce. We have spent a lot of time working out the 
protocol and it is currently being used in passion, processing over 15M 
transactions a month. Additionally, two other companies have constructed 
independent implementations of SCMP to provide their own services on the Net.

Lastly, in light of the announcement by John Pawling related to the release 
of Version 1.7 of the S/MIME Freeware Library (SFL) as an implementation of 
SMIME v3, ESS for SMIME v3, and other functions, we feel this is very 
timely for the release of an RFC documenting an application of these RFC's. 
We are also investigating the prospect of replacing the current licensed 
RSA toolking that provides the SMIMEv3 functions with the SFL. Should this 
workout, we may release a SCMP reference library.

Please let me know your thoughts on moving this forward and what our next 
steps might be.

All the best,

Tom

===========================================
toma <at> cybersource.com
(Continue reading)

Tom Arnold | 1 Jun 02:23 2000

Re: SCMP ver 06 posted

At 03:45 PM 5/31/00 +0200, you wrote:
> >
>[snip]
>the question was whether the SCMP-request-id is signed or not?

the request ID is in the inner MIME message and is enveloped.

the payload is signed. If there's a section of the text that is not clear, 
we need to fix it. Section 2 describes the message construction correctly 
and is consistent with the example. In essence, the payload is signed, then 
MIME encapsulated, forming the inner MIME message. This inner MIME message 
is enveloped (encrypted), then MIME encapsulated, forming the outer MIME 
message.

>The text and the example is not clear to me:
>Do you first encapsulate and then sign or the other way around?
>
>You example puts first a 'signed entity' and around it an
>'enveloped entity'. This doesn't seem to correspond to the
>text of the outer/inner construction.
>
>Do you actualy want to first encrypt the payload, and then
>add a signature around with the SCMP headers?

No. We want to have the payload signed by the sending agent's private key, 
authenticating that she produced the message and allowing us to verify the 
integrity of the message. Then, we want the sending agent's application to 
include the request_id, including this in the inner mime headers when the 
inner MIME message is formed. Once this is done, the inner MIME message is 
enveloped (encrypted to insure privacy). In accordance with the 
(Continue reading)

Tom Arnold | 30 May 19:14 2000

Re: SCMP ver 06 posted

Thanks for the comments Peter. Answers below.

At 07:34 PM 5/27/00 +0200, Peter Sylvester wrote:
>hi,
>
>Why is there a 'commerce' in the protocol name?

The first few implementations of the protocol have all been related to 
transport of messages related to commerce transactions. Also, as the 
protocol evolved, the clear use is related to a sending agent making a 
request from some receiving agent, then getting a reply from the receiving 
agent. After evaluating the implementations, it's clear the protocol is 
'simple' to implement and very efficient for handling many types of 
commerce transactions. Ergo, the name.

>Maybe somehow I am confused about the ordering of the signed and
>enveloped data. It seems to me that the example does it the wrong
>way, in particular the SCMP-request-id: 0123456789012345678901
>is not signed? Or do you mean by
>  [ OUTER MIME START ]
>a signedData structure, thus triple wrapping of ESS?

We looked at mandating triple wrapping, but opted not to implement this. We 
wanted the SCMP-request-id to be outside the encrypted payload so that the 
receiving agent's server could have a unique handle to the message prior to 
decrypting should an error condition exist. In this manner, both the 
receiving and sending agent's systems would have a known value to reference 
the error condition.

>Some nit-picking:
(Continue reading)

Tom Arnold | 25 May 20:43 2000

SCMP ver 06 posted

Version 06 of the SCMP draft has just been posted. The major change in this 
draft was to revise a few of the terms (specifically the definition related 
to RFC 2119), and to move the definition of terms up before the 
requirements section (where some of the terms are used.....  'duh')....

Thomas A. Arnold
Chief Technical Officer
CyberSource Corporation
1295 Charleston Road
Mountain View, CA 94043-1307
email: toma <at> cybersource.com
Main: 650.965.6000
---------------------------------------------------------------------------
This Email and any attached files are confidential and may also be
privileged. It is intended only for the individual or entity to whom
it is addressed. If you are not the recipient or an authorized agent
of the recipient, you are hereby notified that any use, dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this message in error, please contact CyberSource
Corporation immediately at 650.965.6000.

Thank you.

Tom Arnold | 18 Apr 01:16 2000

Fwd: Revised version of SCMP posted.

We have received a few quick comments on the recently posted draft that request a few minor changes to the introduction be made before submitting to the RFC editor as an informational RFC.

I'm making this posting as a last-call to the list to see if there are any other final comments that we should take into account before submitting the document.

Thanks.

The current comments are:

Section 1.2 in your document should be moved to a place which is before any use of the terms defined in RFC 2119. I also rather see you change section 1.2 to:

Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT are used in conformance to the definitions in RFC2119 [MUSTSHOULD].


Just thought I'd let everyone know that a revised version of the SCMP document has been posted as an I-D.

To: IETF-Announce: ; Subject: I-D ACTION:draft-arnold-scmp-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : Simple Commerce Messaging Protocol (SCMP)
Version 1 Message Specification
Author(s) : T. Arnold, J. Eaton
Filename : draft-arnold-scmp-05.txt
Pages : 12
Date : 11-Apr-00

The Simple Commerce Messaging Protocol (SCMP) is a general-purpose
electronic commerce message protocol for secure, real-time
communication of a set of data from a sending agent's application
to a receiving agent's server. Additionally the response by the
receiving agent's server to the sending agent is the reply from the
request represented by the set of data in the message's payload. The
intent of this protocol is to define a method where trading partners can
perform on-line business requests in an environment where the sending
partner is fully authenticated, and the message cannot be repudiated.

The taxonomy of the SCMP message payload is not in the scope of this
document. The SCMP protocol does not specify payload definitions or
how trading partners are expected to process the payload, beyond basic
server-level functions related to processing SCMP headers. This intent
is to permit trading partners the flexibility to implement either a
standard commerce message format as in ANSI-X12 Electronic Data
Interchange (EDI) or some other non-standard payload format. This
document does give an example implementation of a payload format
based on [XML].

The only requirement on the message payload is that it be prepared
as specified in [MIME].

In this manner, SCMP fundamentally differs from many emerging
commerce message protocols. Beyond specifying the method for
encryption, authentication and handling, these other protocols
specify the contents of the message and details how a server is to
process and respond to a given message payload.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arnold-scmp-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-arnold-scmp-05.txt".

A list of Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv <at> ietf.org.
In the body type:
"FILE /internet-drafts/draft-arnold-scmp-05.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <20000411095908.I-D <at> ietf.org>
ENCODING mime
FILE /internet-drafts/draft-arnold-scmp-05.txt
<ftp://ftp.ietf.org/internet-drafts/draft-arnold-scmp-05.txt>



Thomas A. Arnold                              
Chief Technical Officer                        
CyberSource Corporation
1295 Charleston Road
Mountain View, CA 94043-1307
email: toma <at> cybersource.com
Main: 650.965.6000
---------------------------------------------------------------------------
This Email and any attached files are confidential and may also be
privileged. It is intended only for the individual or entity to whom
it is addressed. If you are not the recipient or an authorized agent
of the recipient, you are hereby notified that any use, dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this message in error, please contact CyberSource
Corporation immediately at 650.965.6000.

Thank you.



Thomas A. Arnold                              
Chief Technical Officer                        
CyberSource Corporation
1295 Charleston Road
Mountain View, CA 94043-1307
email: toma <at> cybersource.com
Main: 650.965.6000
---------------------------------------------------------------------------
This Email and any attached files are confidential and may also be
privileged. It is intended only for the individual or entity to whom
it is addressed. If you are not the recipient or an authorized agent
of the recipient, you are hereby notified that any use, dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this message in error, please contact CyberSource
Corporation immediately at 650.965.6000.

Thank you.
Tom Arnold | 17 Apr 04:19 2000

Revised version of SCMP posted.

Just thought I'd let everyone know that a revised version of the SCMP document has been posted as an I-D.

To: IETF-Announce: ; Subject: I-D ACTION:draft-arnold-scmp-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : Simple Commerce Messaging Protocol (SCMP)
Version 1 Message Specification
Author(s) : T. Arnold, J. Eaton
Filename : draft-arnold-scmp-05.txt
Pages : 12
Date : 11-Apr-00

The Simple Commerce Messaging Protocol (SCMP) is a general-purpose
electronic commerce message protocol for secure, real-time
communication of a set of data from a sending agent's application
to a receiving agent's server. Additionally the response by the
receiving agent's server to the sending agent is the reply from the
request represented by the set of data in the message's payload. The
intent of this protocol is to define a method where trading partners can
perform on-line business requests in an environment where the sending
partner is fully authenticated, and the message cannot be repudiated.

The taxonomy of the SCMP message payload is not in the scope of this
document. The SCMP protocol does not specify payload definitions or
how trading partners are expected to process the payload, beyond basic
server-level functions related to processing SCMP headers. This intent
is to permit trading partners the flexibility to implement either a
standard commerce message format as in ANSI-X12 Electronic Data
Interchange (EDI) or some other non-standard payload format. This
document does give an example implementation of a payload format
based on [XML].

The only requirement on the message payload is that it be prepared
as specified in [MIME].

In this manner, SCMP fundamentally differs from many emerging
commerce message protocols. Beyond specifying the method for
encryption, authentication and handling, these other protocols
specify the contents of the message and details how a server is to
process and respond to a given message payload.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arnold-scmp-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-arnold-scmp-05.txt".

A list of Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv <at> ietf.org.
In the body type:
"FILE /internet-drafts/draft-arnold-scmp-05.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <20000411095908.I-D <at> ietf.org>
ENCODING mime
FILE /internet-drafts/draft-arnold-scmp-05.txt
<ftp://ftp.ietf.org/internet-drafts/draft-arnold-scmp-05.txt>



Thomas A. Arnold                              
Chief Technical Officer                        
CyberSource Corporation
1295 Charleston Road
Mountain View, CA 94043-1307
email: toma <at> cybersource.com
Main: 650.965.6000
---------------------------------------------------------------------------
This Email and any attached files are confidential and may also be
privileged. It is intended only for the individual or entity to whom
it is addressed. If you are not the recipient or an authorized agent
of the recipient, you are hereby notified that any use, dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this message in error, please contact CyberSource
Corporation immediately at 650.965.6000.

Thank you.
by way of Tom Arnold | 9 Oct 00:49 1999
Picon

I-D ACTION:draft-arnold-scmp-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Simple Commerce Messaging Protocol (SCMP)
	Author(s)	: T. Arnold, J. Eaton
	Filename	: draft-arnold-scmp-04.txt
	Pages		: 12
	Date		: 05-Oct-99
	
The Simple Commerce Messaging Protocol (SCMP) is a general-purpose 
electronic commerce message protocol for secure, real-time 
communication of a set of data from a sending agent's application 
to a receiving agent's server. Additionally the response by the 
receiving agent's server to the sending agent is the reply from the 
request represented by the set of data in the message's payload. The 
intent of this protocol is to define a method where trading partners can 
perform on-line business requests in an environment where the sending 
partner is fully authenticated, and the message cannot be repudiated.
The taxonomy of the SCMP message payload is not in the scope of this 
document. The SCMP protocol does not specify payload definitions or 
how trading partners are expected to process the payload, beyond basic 
server-level functions related to processing SCMP headers. This intent 
is to permit trading partners the flexibility to implement either a 
standard commerce message format as in ANSI-X12 Electronic Data 
Interchange (EDI) or some other non-standard payload format. This 
document does give an example implementation of a payload format
based on [XML]. 
The only requirement on the message payload is that it be prepared
as specified in [MIME].
In this manner, SCMP fundamentally differs from many emerging  
commerce message protocols. Beyond specifying the method for
encryption, authentication and handling, these other protocols 
specify the contents of the message and details how a server is to 
process and respond to a given message payload.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arnold-scmp-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-arnold-scmp-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-arnold-scmp-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<19991005121948.I-D <at> ietf.org>

ENCODING mime
FILE /internet-drafts/draft-arnold-scmp-04.txt

<ftp://ftp.ietf.org/internet-drafts/draft-arnold-scmp-04.txt>

Tom Arnold | 5 Oct 15:49 1999

Update

We have taken comments on draft 3 (currently posted) and have produced
draft 04. The primary changes are in two areas:

- Some wordsmithing related to non-repudiation

- Added an XML payload example. This has actually been a hot issue in that
our original intent was to define a protocol that was completely payload
independent. That being said, we went ahead and produced a section
describing how a XML DTD and data would be encapsulated and transported in
an SCMP message. We have struck a compromise in that we illustrated how an
XML message would be delivered, not defining any type of message taxonomy.
Groups like Rosetta Net, CompTIA, DISA, EDIInt, IOTP, OBI, and others using
private protocols are responsible for providing actual message definition.

Our intent and belief is that this version is ready to become an
Informational RFC. Once I receive confirmation that the draft has been
posted, I'll notify the list.

Thomas A. Arnold                                CyberSource Corporation
Chief Technical Officer                         550 S. Winchester Bl. #301
                                                San Jose, CA 95128
toma <at> cybersource.com                            Direct: 1.408.260.6010
http://www.cybersource.com/                     Main: 1.408.556.9100
---------------------------------------------------------------------------
This Email and any attached files are confidential and may also be 
privileged. It is intended only for the individual or entity to whom 
it is addressed. If you are not the recipient or an authorized agent 
of the recipient, you are hereby notified that any use, dissemination, 
distribution or copying of this communication is strictly prohibited. 
If you have received this message in error, please contact CyberSource 
Corporation immediately at (408) 556-9100.

Thank you.

Golden Plan | 3 Aug 02:20 1999
Picon
Picon

signoff

sign off


Gmane