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

From: Steve Fabes <[email-masked]>
Date: Tue, 4 May 1999 10:33:51 -0700

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.
-----Original Message-----
From: [email-masked] <[email-masked]>
To: Ietf Trade WG <[email-masked]>
Date: Tuesday, May 04, 1999 09:33
Subject: RE: Brand IDs & their registration. Was: RE: Comments on
draft-ietf-t rade-iotp-v1.0-protocol-03.txt, part 1

>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
>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
>
>
>
>David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
>
>To:   Ietf Trade WG <[email-masked]>
>cc:   "Lewis, Tony" <[email-masked]> (bcc: Donald Eastlake/Hawthorne/IBM)
>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
>
>
>-----------------------------------------------------------------------
>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]