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

From: Steve Fabes <[email-masked]>
Date: Mon, 3 May 1999 09:39:02 -0700

EMV - decade or sooner - I understand that the extent of mag stripe fraud in
some territories is growing at such a fast rate that in order to survive the
banks will be forced into EMV or face the possibility of shutting down their
credit operations. What we in the US/Japanese markets must worry about is
that fraud activity remains constant and will shift from EMV enabled
territories to those that currently do not have such problems. So while the
US/Japanese banks may seem to not have a strong current need for chip they
must move there to defend their risk levels.
-----Original Message-----
From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Cc: Lewis, Tony <[email-masked]>
Date: Thursday, April 29, 1999 09:43
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie
tf-t rade-iotp-v1.0-protocol-03.txt, part 1

>I agree with Tony. Smart card based EMV transactions will be the dominant
>payment model within a decade, probably even earlier especially in the
>non-US part of the world. The main reasons being, in my view:
>* it will reduce fraud as it's much much harder to copy a smart card
>than a mag stripe card
>* it makes internet credit card payments "card present" transactions
>which should result in lower merchant fees. This also means that it will be
>much harder for customers to claim they never made an internet purchase
>* using a multi-application smart card you will be able to use just
>one smart card for debit, credit, electronic cash, a loyalty scheme as well
>as hold electronic tickets for anything from local cinema to your next
>flight.
>
>To rephrase a MasterCard ad line, "smart cards are the future of money".
>
>David
>
>> ----------
>> From: Lewis, Tony[SMTP:[email-masked]]
>> Sent: 28 April 1999 20:30
>> To: Ietf Trade WG
>> Subject: RE: Brand IDs & their registration. Was: RE: Comments on
>> draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part  1
>>
>> My point is that the brand is "Visa" no matter whether using IOTP, SET or
>> any other protocol.
>>
>> As for EMV, the very first live SET 1.0 transaction was made using an EMV
>> card with the EMV data carried inside a SET message extension. EMV credit
>> and debit products are a significant part of the future of electronic
>> commerce. I expect they will be the dominant model for payment in a
>> decade.
>>
>> Tony
>> > ----------
>> > From: Steve Fabes[SMTP:[email-masked]]
>> > Sent: Wednesday, April 28, 1999 3:43 PM
>> > To: Lewis, Tony; Ietf Trade WG
>> > Subject: Re: Brand IDs & their registration. Was: RE: Comments on
>> > draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part  1
>> >
>> > 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
>> > >> ----------
>> > >> From: David Burdett[SMTP:[email-masked]]
>> > >> 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
>> > >>
>> > >> 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]
>> > >>
>> >
>-----------------------------------------------------------------------
>> > >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]
>

-----------------------------------------------------------------------
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: "Lewis, Tony" <[email-masked]>
Date: Tue, 4 May 1999 17:09:25 -0700

In fact, Europay, MasterCard, and Visa have established EMVCo. (EMVCo does
not currently have a web site so I can't point you there. I'm told the site
won't be up until July.)

EMV does not have brands in the same way that SET or IOTP do. EMV deals with
application identifiers or AIDs. An AID consists of two parts: a Registered
ID (RID) obtained from ISO and a Proprietary Extension (PIX). The RID is
roughly analogous to a brand. For example, Visa has an RID with a value of
0xA000000003. Visa then assigns PIX values for various applications, e.g.,
Credit/Debit, VisaCash, etc.

Typically, an RID will be obtained by a payment brand, but there is no
guarantee that there is a one to one correspondence between a brand and a
RID.

As we look at a way to integrate EMV cards with SET, we expect to add AIDs
to the SET Initiation message, which will ultimately be replaced by IOTP.

Tony
> Sent: 	Tuesday, May 04, 1999 10:33 AM
> To: 	[email-masked]; Ietf Trade WG
> Donald, I do not have much to add but when looking at the actions of SETCo
> we should also anticipate that the EMV world will establish EMVCo and its
> rules will need to be considered along side those of SETCo's. The
> membership
> of the two Co's will overlap but be different and to assume the same brand
> and operating rules may be optimistic.
> From: [email-masked] <[email-masked]>
> Date: Tuesday, May 04, 1999 09:33
> >Regardless of EMV or whatever, it seems to me that we have a "brand"
> registry
> >problem to solve.  Credit/Debit cards are sort of odd creatures because
> they can
> >be used in payments via multiple different protocols.  Most stored value
> cards
> >can be used via only a single protocol.
> >
> >SETco clearly operates a card brand regisgration operations, however
> limited and
> >even if it's only expressed in the brand level certificates that SETco
> allows to
> >be created under its root.  I think the hope was that the SET
> registration
> could
> >be used in IOTP for all credit/debit cards.  This would at least avoid
> the
> >problem where some brand was registered under different names at
> different
> >registries (where "different" could just be things like whether there is
> really
> >a space between American and Express or whether the C is capitalized in
> >Mastercard or whether Visa is all caps, ...).  Is there a list of bands
> >officially supported by SETco and their official names?
> >
> >However, if SETco is inappropriate for this, because they won't
> "register"
> >brands that haven't joined", then we need a separate solution.  It
> certainly
> >isn't very difficult to set up regsitration via IANA, probably using the
> same
> >Designated Expert criteria being used for other things.  The only
> difficulty I
> >can see is that some brand might get registered there for IOTP use and
> then
> >later join SETco or otherwise get registered in some other system under
> some
> >other name.  Various messyness with Discover/Novus, AT&T Universal Card
> changing
> >to CitiBank Universal Card and the like occur to me.  I'm not sure those
> cases
> >are actually name change problems but one can image such.
> >
> >All this seems to imply that we need to be prepared to register
> credit/debit
> >card brands under "IOTP:".  I'm a bit reluctant to drop the "SET:" branch
> of the
> >brand tree in IOTP.  If some brand exists under SETco but hasn't yet been
> >registered under IOTP, it seems like it should be usable.  Of course,
> this
> means
> >that some brand registered under IOTP could later join SETco and could
> exist as
> >both IOTP:BrandX and SET:BrandX or SET:Brand-ex.  So you might get into
> >equivalence tables but these are really just an artifact of the real
> world
> being
> >messy and not particularly worse than brands splitting or merging.
> >
> >I don't see a major problem with us using
> brand:[product]:[promotional-name] if
> >we want, even after "SET:", although we should make it clear in that case
> that
> >these values differ from those permitted in the SET protocol.  The other
> >possibility that occurs to me would be to use brand[:product] and have a
> >separate [promotional=xxx] optional attribute.
> >
> >What do people think?
> >
> >Thanks,
> >Donald
> >
> >Donald E. Eastlake, 3rd
> >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> >
> >cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald
> Eastlake/Hawthorne/IBM)
> draft-ie

---

From: David Burdett <[email-masked]>
Date: Wed, 5 May 1999 20:10:46 +0100

Having read the various notes from Tony, Don and Steve on this topic. I
think that we should have a separate IOTP brand registry, maintained by IANA
under the procedures I included in an earlier email ... if only because it
will be simpler. However I think this would mean that:
*	we would need to copy all the SET brands to the IOTP spec
*	we would need to also copy the SET method of defining Brand Ids to
the IOTP spec (although we might be able to refer to the SET specs)

The last item is less than ideal since it will involve replication and
therefore the need to keep things in step.

Thoughts?

David

> Sent: 	04 May 1999 17:09
> > >which should result in lower merchant fees. This also means that it
> will
> > be
> > >> My point is that the brand is "Visa" no matter whether using IOTP,
> SET
> > or
> > >> any other protocol.
> > >>
> > >> > product that an IOTP product supplier can expect to see. Can you
> see
> > a
> > >> day
> > >> > >There are undoubtedly some issues that I don't know about.
> However,
> > it
> > >> > seems
> > >> > >such registry rather than the two being proposed. I recommend
> having
> > a
> > >> > >> privacy/security as for credit card payments that occur now
> where
> > a
> > >> web
> > >> > >> page
> > >> > >> cover non-SET credit card payments. I *think* the answer is
> "yes"
> > as
> > >> > you
> > >> > >> can
> > >> > >> following review on the IETF Trade Working Group mailing list
> and
> > by
> > >> > the
> > >> > >> Designated Expert.
> > >> > >>

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

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.

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200

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

---

From: Steve Fabes <[email-masked]>
Date: Wed, 5 May 1999 13:53:34 -0700

Referencing SET spec must be preferred - but having linked to it we are a
tad vulnerable to changes that they make within the SET closed world. As
long as we are careful to only link to their method of brand Id we should be
OK - it does infer that IETF Trade Group must now keep an open eye on SET.
-----Original Message-----
From: David Burdett <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Date: Wednesday, May 05, 1999 12:43
Subject: RE: Brand IDs & their registration. Was: RE: Comments on draft-ie

>> > >> As for EMV, the very first live SET 1.0 transaction was made using
an
>> > EMV
>> > >> > >> indicates that the brandid is any valid brandid that is
accepted
>> > >> > >> use just SCCD rather than SET then they would not (I think)
need
>> > >> > >> currently writing as the proposed IANA procedure for
registering
>> > new
>> > >> > >> > international brand's hierarchy and/or the cardholder can
have
the
*******************
privileged.
email
them
the
******************

---

From: [email-masked]
Date: Thu, 6 May 1999 02:01:08 -0400

My understanding is that a RID (Registered ID obtained from ISO) is assigned
more to an organization or association.

It is not easy to distinguish between
a RID, a brand, and a consumer acceptance mark.

For MasterCard, the same RID is used for:
   - MasterCard International chip credit cards,
   - and Maestro International pin based debit cards - which uses a different
   acceptance "mark" for what some consumers may consider a "brand".

For MasterCard's RID the hexadecimal characters 0xA000000004 have been assigned
by ISO to MasterCard.  The RID does not differentiate between our MasterCard and
Maestro marks,
but it is only the full RID + PIX (AID) that distinguishes what "brand" or mark
is involved.

"Lewis, Tony" <[email-masked]> on 05/04/99 08:09:25 PM

To:   Ietf Trade WG <[email-masked]>
cc:    (bcc: John Wankmueller/NYC/MASTERCARD)
Subject:  RE: Brand IDs & their registration. Was: RE: Comments on draft-ie tf-t
      rade-iotp-v1.0-protocol-03.txt, part 1

Tony

---

From: David Burdett <[email-masked]>
Date: Tue, 18 May 1999 02:17:09 +0100

John/Tony

I don't think the RID+PIX is the way to go. Surely all we need is a clearly
defined name declared in a public forum (e.g. the Trade WG or its
successor). For example we could declare:
*	MasterCard (implies credit)
*	Maestro (MasterCard debit)
*	Mondex (electronic cash)
*	Visa (implies credit)
*	VisaCash (electronic cash)

The "protocols" that can be used with each brand, e.g. SETv1.0, SCCD, etc.
are then separately specified with their own individual "payment
protocol/version no" identifiers. 

There is still the need to know which payment protocols can be used with
each brand. However I don't think this an IOTP issue since:
*	Merchant's will know when they create a Brand List which protocols
are applicable for each Brand
*	Consumer's will know when they add a new brand what type of payment
instrument it is (e.g. Credit) and the consumer software can then decide
which payment protocols apply.

Do you both agree?

David

> ----------
> From:
> [email-masked][SMTP:[email-masked]]
> Sent: 	05 May 1999 23:01
> To: 	Ietf Trade WG

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200

---

From: David Burdett <[email-masked]>
Date: Tue, 18 May 1999 02:17:05 +0100

Apart from Steve Fabes, I haven't received any comments on this suggestion.
Before doing this change I'd like some additional feedback.

David

> Sent: 	05 May 1999 12:10
> > > >possibility that occurs to me would be to use brand[:product] and
> have
> > a
> > > >one smart card for debit, credit, electronic cash, a loyalty scheme
> as
> > > well
> > > >> > >will need to be a registry. It seems to me that there should
> only
> > be
> > > >> one
> > > >> > >> My question is, will it be reasonable to use the SET brandid
> in
> > > this
> > > >> > way
> > > >> > >> to
> > > >> > >> "IOTP" brand. However if they later adopted SET, they would
> end
> > up
> > > >> with

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200

---

From: "Lewis, Tony" <[email-masked]>
Date: Tue, 18 May 1999 09:39:18 -0700

This chain has taken so many turns, I'm not convinced that I know what
problem we're trying to solve anymore.

I think the problem is: How do we identify the brand that will be used in a
transaction regardless of payment protocol?

For SET, this is "brand[:product]". For EMV, this is RID+PIX. Other
protocols will have their own internal method of encoding the brand. In all
cases, the user will want to see a graphical representation of the Visa,
MasterCard, Maestro, Mondex, etc. logo.

Do we need a new registry for brands? If we create such a registry, how do
we correlate those registrations with other schemes that know about the same
brands? Are we going to have a big table somewhere that correlates IOTP
brand, SET brand, EMV brand, etc.?

By the way, Visa does not imply "credit". It can be credit or debit.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Monday, May 17, 1999 6:17 PM
> To: 	[email-masked]; Lewis, Tony
> Cc: 	Ietf Trade WG
> > but it is only the full RID + PIX (AID) that distinguishes what "brand"
> or
> > mark
> > is involved.
> > 
> > 
> > 
> > 
> >

---

From: Dave Birch <[email-masked]>
Date: Wed, 19 May 1999 20:42:31 +0100

Lewis, Tony said

>By the way, Visa does not imply "credit". It can be credit or debit.

Or cash (e.g. VisaCash, CEPS etc).

Regards,
Dave Birch.

...  My own opinion (I think!) given solely in my capacity as  ...
...         an interested member of the general public         ...
...                                                            ...
...  mailto:[email-masked]   .........  http://pobox.com/~dgwb ...

---

From: "Lewis, Tony" <[email-masked]>
Date: Wed, 19 May 1999 13:27:26 -0700

Actually, VisaCash is its own brand. As far as I know, CEPS is not branded
(at least from a Visa perspective).

Tony
> ----------
> From: 	Dave Birch[SMTP:[email-masked]]
> Sent: 	Wednesday, May 19, 1999 12:42 PM
> To: 	Ietf Trade WG

---

From: Dave Birch <[email-masked]>
Date: Thu, 20 May 1999 13:37:46 +0100

Lewis, Tony said

>(at least from a Visa perspective).

My (distant and possibly imperfect) understanding of CEPS is that Europay 
issuers will brand as "Clip" and Visa issuers will brand as "VisaCash".

Regards,
Dave Birch.