Subject: Brand IDs & their registration. Was: RE: Comments on draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1

From: David Burdett <[email-masked]>
Date: Wed, 28 Apr 1999 19:36:56 +0100

In the current specification the basic idea for identifying brands is that
they should be of the form "xxx:brandid" where "xxx" can be "SET" which
indicates that the brandid is any valid brandid that is accepted by SET, or
alternatively "IOTP" which can be used to define any brand not defined by
SET. The idea was that we should not need to define "Visa", "MasterCard",
"American Express", etc more than once since they are already defined and
registered by SET.

However a couple of problems may arise ...

USING THE SET BRAND ID FOR NON-SET PAYMENTS
Although IOTP can support SET as a payment protocol, it can also support
credit card payments (using Secure Channel Credit Debit - SCCD) where the
credit card information (no, name, expiration date, etc) is coded
effectively in the clear but with privacy protection provided by using a
secure channel such as SSL. In this way it provides a similar level of
privacy/security as for credit card payments that occur now where a web page
form is completed by the user.

My question is, will it be reasonable to use the SET brandid in this way to
cover non-SET credit card payments. I *think* the answer is "yes" as you can
quite imagine a situation where a consumer is offered a choice of using
their VISA credit card to pay using either SET or SCCD.

WHAT BRAND ID SHOULD BE USED FOR CO BRANDS
If a payment brand, such as a local brand or co-brand, chooses, initiall to
use just SCCD rather than SET then they would not (I think) need to register
their brand with SET. In this case, they might register their brand as an
"IOTP" brand. However if they later adopted SET, they would end up with
potentially two equivalent Brand IDs. Do you think we might be better off
with a straight IOTP brand and keep all the names under the procedures
defined by IANA? I'm not sure?

REGISTERING NEW BRAND IDs
To help assist in answering the last point, the following is what I'm
currently writing as the proposed IANA procedure for registering new brand
ids. Any comments:

>>>Clip>>>
The format of the Brand ID is either:
*	SET:setbrand where setbrand is a brand which is accepted by the
[SET] payment protocol
*	IOTP:iotpbrand where iotpbrand may be:
	- GeldKarte
	- Mondex

New values of the high level prefix (SET or IOTP) should be allocated
following review on the IETF Trade Working Group mailing list and by the
Designated Expert.

Values of "setbrand" are allocated as defined in the [SET] specifications.

New values of "iotpbrand" must be announced to the IETF Trade WG mailing
list and, if there are no objections within three weeks, be allocated on a
"first come first served" basis.
<<<End Clip<<<

Regards

David
> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	28 April 1999 08:14
> To: 	Ietf Trade WG
> Subject: 	RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> part  1
> 
> In SET, the BrandID is either "brand" or "brand:product".
> 
> In Japan, there are products that are co-branded. Essentially these
> products
> are private label cards for domestic transactions with an international
> brand for non-domestic transactions. The private label can be reflected in
> a
> SET cardholder certificate as the "promotional card name" under the
> international brand's hierarchy and/or the cardholder can have a
> certificate
> issued under the private label hierarchy.
> 
> There is no provision to carry both the private label (of the Japanese
> credit card company) and the international brand as part of the SET
> BrandID.
> 
> Tony
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	Tuesday, April 27, 1999 6:31 PM
> > To: 	Ietf Trade WG; [email-masked]
> > Subject: 	RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> > part  1
> > 
> > I'm working my way through Don's comments and came across this one where
> > our
> > friends in Japan might be able to help ... I think ...
> > 
> > Don says ...
> > 
> > 	"I looked around a bit in SET literature and couldn't find anything
> > about Dual or Promotional brands or anything about a three component SET
> > Brand.  Two components, "brand" and "product" I see in the SET
> literature,
> > such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case where a
> > colon
> > is included if there isn't anything after it.  In other words, it's
> > "Visa",
> > not "Visa:", and certainly not "Visa::" as a SET brand (re also examples
> > in
> > 6.6.1)."
> > 
> > This requirement arose as a result of meeting the needs of the Japan
> > market.
> > Can some people who are more familiar with this, please have a look at
> > this
> > part of the spec and check it is ok please?
> > 
> > David
> > 
> > > ----------
> > > From: 	[email-masked][SMTP:[email-masked]]
> > > Sent: 	22 April 1999 15:25
> > > To: 	[email-masked]
> > > Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> > > 1
> > > 
> > > I've done a careful review of the document through section 6 and
> section
> > > 13
> > > and greater and came up with the following somewhat length list of
> > > suggestions.  I don't think they substantially change the intended
> > meaning
> > > of the document but those on the list should judge that.
> > > 
> > > 
> > > IMPORTANT:
> > > 
> > > "IANA Considerations" needs to be a top level section, perhaps #11.
> > > Gathering this stuff together into 3.7.3 is good but its still
> > > unreasonable
> > > to expect IANA to comb the document to find it.
> > >      I'm not sure about the criteria for registration.  "IETF
> Consensus"
> > > is
> > > pretty stiff and requires a vote of the IESG.  I should think someone
> > > could
> > > register an IOTP Band or CurrCode by publishing an RFC.  Perhaps that
> is
> > > what you mean for ProtocolId but it is not clear.
> > >      Toward end so 3.7.3, change "with" to "without".
> > > 
> > > 
> > > MISCELLANEOUS:
> > > 
> > > I don't understand the difference between "Objectives" and "Purpose".
> I
> > > suggest that 1.4 and 1.5 be merged and that the reference to "IOTP
> > > Business
> > > Description" which, as far as I know, is not intended to ever become
> an
> > > IETF document, be dropped.
> > > 
> > > Section 1.7 still refers to an XML Overview section 11.
> > > 
> > > Page spanning figures, like Figure 3, are really pretty messy.  It
> would
> > > be
> > > better if the text could be made much more terse and this and similar
> > > figures started high on a page so they aren't split by a page
> boundary.
> > > 
> > > Section 2.2: suggest "The Open Trading Protocols identify" be changed
> to
> > > "IOTP identifies".
> > > Section 2.2: says "IOTP Transactions are composed of these exchanges"
> > but
> > > does not list Inquiry or Ping exchange.
> > > 
> > > Starting in section 2.3 and many other places in the document, words
> or
> > > phrases are prefixed and suffixed by an underscore character ("_").
> > This
> > > is not any normal IETF style.  I suspect it means that the original
> text
> > > is
> > > italic.  These should be suppressed or if that is impossible, a
> separate
> > > pass should be done to delete them.
> > > 
> > > In Figure 9, the things which are supposed to be identical or match
> > aren't
> > > and don't.  Is that deliberate?
> > > 
> > > I don't think that section 3.6 Brands and Brand Selection fits very
> well
> > > where it and suggest it be moved into section 10 which could be
> renamed
> > > "Brands".
> > >      Continuing on Brands, I looked around a bit in SET literature and
> > > couldn't find anything about Dual or Promotional brands or anything
> > about
> > > a
> > > three component SET Brand.  Two components, "brand" and "product" I
> see
> > in
> > > the SET literature, such a "MasterCard" or "Visa:Gold".  But not A:B:C
> > and
> > > no case where a colon is included if there isn't anything after it.
> In
> > > other words, it's "Visa", not "Visa:", and certainly not "Visa::" as a
> > SET
> > > brand (re also examples in 6.6.1). Can anyone give me any references
> to
> > > shed light on this?
> > > 
> > > Section 3.8.1: I don't understand why sub-pages of an HTML main page
> > > couldn't have links back to the main page.
> > > 
> > > Section 4.1: first section reference says "0"?
> > > 
> > > Figures 10 and 11: These flow diagrams each *almost* fit on a page. If
> > the
> > > initial "Input IOTP Message" box could be to the side with a
> horizontal
> > > arrow and the text were edited down to something a bit more terse, I
> > think
> > > they would, which would be quite helpful.
> > > 
> > > Section 5: Suggest this section be called "Digital Signature" or
> > > something.
> > > Usually an IETF Security Considerations section is brief and talks
> about
> > > really high level issues.  Material in 5.4 is appropriate for Security
> > > Considerations.  A separate Security Considerations section would need
> > to
> > > also say something about deciding when to require signatures, even if
> it
> > > is
> > > just by referring to section 5.1.4, and about depending on payment
> > scheme
> > > security for the safety of funds, which I didn't see anywhere.
> > >      Section 5 seems pretty heavy on certificates and public key
> crypto,
> > > especially given the originally IOTP v1.0 was going to be secret key
> > only
> > > and, as I recall, it was with some reluctance that public key hooks
> were
> > > added.  The stuff on checking a signature, for example, talks about
> > > checking the certificate as if there always has to be one.
> > >      Section 5.1.4: another reason you might not need signatures is
> the
> > > that the sender and receiver were on the same machine so it can check
> > > integrity just by comparing with a saved copy.
> > > 
> > > Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
> > > Consortium" and suggest dropping whole note. I don't see any
> difference
> > at
> > > all between OkTo/OkFrom and amount.  Both could appear in human
> readable
> > > form in the Order Description and in machine readable form in their
> > > element.  Recommending that the UI display the machine readable
> version
> > is
> > > reasonable (as in 6.4.1).
> > > 
> > > ContentSoftwareId: the standard text given for this is quite length
> and
> > > repeated dozens of time.  If it could be moved to the glossary or
> > > something
> > > and a simple "see glossary" put in, it would save many pages.
> > > 
> > > As previously discussed, change ISO4217 to ISO4217A or the like.
> > > 
> > > Just before section 6.7, it says that examples exist in 6.6 when they
> > are
> > > in 10.
> > > 
> > > Section 6.17: references to the Richard Brown draft and probably not
> > > appropriate.  RFCs are not supposed to refer to drafts.  About the
> > future,
> > > I'm not sure you need to say anything but if you do, I think it should
> > > just
> > > say the future versions of IOTP will use industry standard XML
> signature
> > > technology if it meets IOTP requirements.
> > >      Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to
> refer
> > > to
> > > that draft because the idea is that it and the main protocol document
> > will
> > > be issued as RFCs simultaneously.  Maybe the XMLDSIG reference should
> > just
> > > be changed to refer to the IOTP DSIG document.
> > >      There is a reference in  6.17.1 to payment scheme specific
> > > algorithms.
> > > Wouldn't their use be encapsulated inside the packaged contents and be
> > in
> > > the payment scheme modules, not an IOTP implementation itself?
> > >      Section 6.18: similarly for certificate reference.  Should point
> > out
> > > that certs not needed for symmetric keying or for cases where public
> key
> > > has been registered at recipient.
> > > 
> > > Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge, I
> > > believe it should say "content" rather than "PackagedContent".
> > > 
> > > 
> > > 
> > > TRIVIAL NITS:
> > > 
> > > In the Abstract and section 1, Delivery Handler is capitalized but
> > payment
> > > handler isn't.
> > > 
> > > It is not usual to have a section like 1.7, History, in an IETF
> > document.
> > > If the evolution of a protocol sheds light on its technical content,
> > > that's
> > > one thing.  But it is not usual to have what is mostly a list of
> editing
> > > versions.  Suggest it be dropped to shorten the document.
> > > 
> > > I'm not sure why there is a skip to new page before section 3.1 or
> > 3.1.2.
> > > Suggest dropping these to make the document more compact.  RFC style
> is
> > to
> > > have no skips to the start of a new page anywhere in the body text.
> > > 
> > > Section 3.8 example packaged content:  I don't like the "Name"s
> FirstMsg
> > > and SecondMsg.  Using Msg => Message seems confusing.  Suggest
> > FirstPiece
> > > and SecondPiece.
> > > 
> > > Section 3.10 says "Where both types of net location are present, the
> > > following rules apply:" and then gives three rules only the third of
> > which
> > > applies in the described circumstances.  Suggest moving the first two
> up
> > > and combining the quoted phrase with the third.
> > > 
> > > Section 3.11.1 "treated by the recipient is an error": is -> as
> > > 
> > > Section 4: "There are a several ..." delete "a"
> > > 
> > > Section 4.4.1.2: in first sentence has -> have.
> > > 
> > > Section 4.4.2.9: in first sentence, insert "server" between "the" and
> > > "unless".
> > > 
> > > Not sure why skip to new page before section 5.3.1 shortly before
> Figure
> > > 14
> > > which overflows onto next page by just one line...
> > > 
> > > Section 5.3.1.1: numbered subsections, lettered subsubsections:  The
> > text
> > > at the ends of these 12 subsubsections is substantially the same.
> > > Starting
> > > with 3)b) sometimes the final period is omitted.  Suggest moving this
> > text
> > > up to the numbered section level or to before the whole two level
> list.
> > > 
> > > Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
> > > 
> > > Section 6.1: towards the end, delete "the" from "that the should".
> > > 
> > > Section 6.2: Insert "may be" after "there" in "there only one".
> > > 
> > > Section 6.5.5: PostalCode missing from detailed attributes list.
> > > 
> > > Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
> > > 
> > > Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the
> TLS
> > > RFC to the References.
> > > 
> > > Section 6.11:  has "Plain/Text" where other similar sentences use
> "Plain
> > > Text" which is probably better.  The "/" makes it look like a MIME
> type
> > > and
> > > the MIME type is actually text/plain.  But I would suggest not using
> the
> > > MIME type as there isn't a unique one for HTML.
> > > 
> > > Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must"
> > ->
> > > "Mechanism and must".
> > > 
> > > Section 6.13: Content, should be "PackagedContent" not "Delivery
> Note".
> > > 
> > > 
> > > 
> > > REFERENCES (section 14)
> > > 
> > > For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.
> > For
> > > HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
> > > Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
> > > 
> > > It looks pretty odd to the IETF spelled out in the RFC references.
> I've
> > > never seen that in an IETF document references section.
> > > 
> > > For SET, suggest referencing the SETco.org site, not Mastercard.
> Can't
> > > reference the Brown XMLDSIG draft in an RFC (although you can talk
> about
> > > it
> > > without a URL or file name reference if necessary).
> > > 
> > > 
> > > Donald E. Eastlake, 3rd
> > > 17 Skyline Drive, Hawthorne, NY 10532 USA
> > > [email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833
> > > 
> > > home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> > > [email-masked]   tel: 1-914-276-2668
> > > 
> > > 
> > >
> -----------------------------------------------------------------------
> > > Message addressed to: [email-masked]
> > > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > > To (un)subscribe send a message with "subscribe" or "unsubscribe" in
> the
> > > body to: [email-masked]
> > > 
> > 
> >
> **************************************************************************
> > ********************
> > 
> > This Email and any attached files are confidential and may also be
> > privileged. 
> > If you are not the intended recipient, please notify the postmaster
> using
> > email 
> > address [email-masked] or call +44 171 557 5000 and ask for the 
> > IT Helpdesk.  You should not copy this email and any attached files, use
> > them 
> > for any purpose or disclose the contents to any other person; all copies
> > of the 
> > Email and associated files in your possession should be destroyed.
> > 
> > Mondex International Limited
> > 47-53 Cannon Street
> > London EC4M 5SQ
> > United Kingdom
> > Registered No: 3122085, England
> > 
> > Phone:          +44 171 557 5000
> > Fax:            +44 171 557 5200
> > Email:          [email-masked]
> > WebSite:        http://www.mondexinternational.com
> > 
> >
> **************************************************************************
> > *******************
> > -----------------------------------------------------------------------
> > Message addressed to: [email-masked]
> > Archive available at: http://www.elistx.com/archives/ietf-trade/
> > To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> > body to: [email-masked]
> > 
> -----------------------------------------------------------------------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
> body to: [email-masked]
> 

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

---

From: Steve Fabes <[email-masked]>
Date: Wed, 28 Apr 1999 15:43:30 -0700

Tony - do your comments infer that SET.Visa will be the only e-Commerce
product that an IOTP product supplier can expect to see. Can you see a day
when a Visa EMV 3.1.1 (or 3.x.x) based credit product could also be used
inside an IOTP product?
-----Original Message-----
From: Lewis, Tony <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Date: Wednesday, April 28, 1999 13:21
Subject: RE: Brand IDs & their registration. Was: RE: Comments on
draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1

>David,
>
>I am new to this group and do not know what lead to the current approach.
>There are undoubtedly some issues that I don't know about. However, it
seems
>to me that a brand is a brand no matter what payment protocol is being
used.
>The only difference I see between "IOTP:Visa" and "SET:Visa" is that the
>latter indicates that the brand is supported by a specific payment
protocol.
>Since you need to support brands other than those supported by SET, there
>will need to be a registry. It seems to me that there should only be one
>such registry rather than the two being proposed. I recommend having a
>single domain for these brands. It seems reasonable to initially populate
it
>using the brands registered with SET and those non-SET brands you listed in
>your note.
>
>Tony
>> ----------
>> Sent: Wednesday, April 28, 1999 11:36 AM
>> To: Ietf Trade WG; Lewis, Tony
>> Subject: Brand IDs & their registration. Was: RE: Comments on
>> draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
>>
>> > > > Subject: Comments on
>> draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
>> > > > 1
>> > > >
>> > > > other words, it's "Visa", not "Visa:", and certainly not "Visa::"
as
>> > > > Section 6.19.2: For ElContIllegal, ValueTooSmall, and
ValueTooLarge,
the