Subject: Brand IDs & their registration.

From: David Burdett <[email-masked]>
Date: Fri, 21 May 1999 17:44:01 +0100

I think tony meant this for the Trade list.

> ----------
> From: 	Lewis, Tony[SMTP:[email-masked]]
> Sent: 	20 May 1999 15:26
> To: 	David Burdett
> Subject: 	RE: Brand IDs & their registration.
> 
> Looks OK to me. I am not well versed in the syntax used, but it looks
> reasonable.
> 
> Tony
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	Thursday, May 20, 1999 2:46 PM
> > To: 	Ietf Trade WG; Lewis, Tony
> > Subject: 	RE: Brand IDs & their registration.
> > 
> > I've been reading the emails on this topic and *think* I have a
> solution.
> > Details follow. But I really would like feedback on this before changing
> > the
> > spec.
> > 
> > David
> > 
> > INTRODUCTION
> > As I see it the requirement is as follows:
> > 1. We need to have a unique "brand id" so that we can link things like
> the
> > brand name, URL for the logo, etc to it.
> > 2. In addition for *some* payment protocols, we also need a protocol
> > specific version of a "brand id". For example for SET the payment
> protocol
> > specific of the Brand Id must be of the form "brand:[product]" and for
> EMV
> > it must be "RID+PIX", yet SCCD (I think) doesn't need a ProtocolBrandId
> at
> > all.
> > 
> > Currently the specification does not have a suitable "slot" into which
> to
> > put a payment protocol specific brand id. So how about the following as
> an
> > approach. It involves:
> > *	adding a new optional child element within the Brand elememt which
> > is protocol specific to hold the ProtocolBrandId, and
> > *	amending the definition of Brand Id in the Brand element of a Brand
> > list so that it becomes a pure IOTP defined brand id.
> > 
> > Detailed changes below ... 
> > 
> > BRAND ELEMENT.
> > 
> > Change the Brand Element definition (the ATTLIST doesn't change) from
> ...
> > 
> > 	<!ELEMENT Brand (PackagedContent*) >
> > 
> > ... to ...
> > 
> > 	<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
> > 
> > The only other change to the Brand element is to change the definition
> of
> > the BrandId attribute to simply read ...
> > 
> > 	This contains a unique identifier for the brand (or promotional
> > brand). It is used to match against a list of Payment Instruments which
> > the
> > Consumer holds to determine whether or not the Consumer can pay with the
> > Brand.
> > 
> > 	BrandIds are controlled under the procedures defined in section 12
> > IANA Considerations. User defined values of BrandId may be used.
> > 
> > PROTOCOL BRAND ELEMENT.
> > The new ProtocolBrand element is then defined as ...
> > 
> > 	<!ELEMENT ProtocolBrand EMPTY>
> > 	<!ATTLIST ProtocolBrand
> > 	   ProtocolId         CDATA   #REQUIRED
> > 	   ProtocolBrandId    CDATA   #REQUIRED >
> > 
> > ... where ProtcolId must match the ProtocolId within a PayProtocol
> > element,
> > and ProtocolBrandId is the ProtocolBrandId to be used with that brand
> and
> > protocol.
> > 
> > EXAMPLE
> > For example a Visa gold card could be defined as follows ...
> > 
> >   <Brand ID = 'xxx'
> >     BrandId='VisaGold'
> >     BrandName='Visa Gold'
> >     BrandLogoNetLocn='http://otplogos.visa.com'
> >     ProtocolAmountRefs='xxx xxx'>
> >     <ProtocolBrand 
> >         ProtocolId='SETv1.0' 
> >         ProtocolBrandId='Visa:Gold' />
> >     <ProtocolBrand 
> >         ProtocolId='EMVv1.0' 
> >         ProtocolBrandId='0xA000000004:0xA000000032' />
> >   </Brand>
> > 
> > Responsibility for defining valid values of ProtocolId and the structure
> > of
> > the ProtocolBrandId (if there is one) that should be used with that
> > version
> > of the payment protocol would lie with the payment protocol supplement
> for
> > IOTP.
> > 
> > Initial values for BrandIds would be defined in the main IOTP
> > specification
> > and initial values for ProtocolBrandId in the payment protocol
> supplement.
> > In the future, new values of BrandId and their associated
> > ProtocolBrandId's
> > would use IANA procedures. More precisely ...
> > 
> > 	"New values of BrandId and their associated ProtocolBrandIds (if
> > any) must be announced to the IETF Trade mailing list and, if there are
> no
> > objections within three weeks, are allocated on a "first come first
> > served"
> > basis."
> > 
> > In practice this means that if an established organisation (e.g
> > MasterCard,
> > Visa or Amex) wants to implement a new brand and give it a
> ProtocolBrandId
> > for each protocol to be used with it, then they can. It also means that
> > new
> > organisations with new brands can do the same sort of thing.
> > 
> > > ----------
> > > From: 	Lewis, Tony[SMTP:[email-masked]]
> > > Sent: 	18 May 1999 09:39
> > > 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
> > > 
> > > 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
> > > > Subject: 	RE: Brand IDs & their registration. Was: RE:
> Comments on
> > > > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > 
> > > > 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
> > > > > Subject: 	RE: Brand IDs & their registration. Was: RE:
> > Comments on
> > > > > draft-ie tf-t rade-iotp-v1.0-protocol-03.txt, part 1
> > > > > 
> > > > > 
> > > > > 
> > > > > 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
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 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
> > > > > > ----------
> > > > > > From:   Steve Fabes[SMTP:[email-masked]]
> > > > > > Sent:   Tuesday, May 04, 1999 10:33 AM
> > > > > > To:     [email-masked]; 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
> > > > > >
> > > > > > 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]
> > > > > >
> > > > >
> > >
> -----------------------------------------------------------------------
> > > > > 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]
> > > 
> > 
> >
> **************************************************************************
> > ********************
> > 
> > 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
> > 
> >
> **************************************************************************
> > *******************
> > 
> 

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

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: David Burdett <[email-masked]>
Date: Wed, 26 May 1999 20:43:44 +0100

As there have been no further comments, I plan to make this change. I'd
particularly someone with SET experience to review the revised Brand example
below.

Details follow ...

David

BRAND ELEMENT DEFINTION

Changed to ...

Definition of BrandId attribute now reads:

	This contains a unique identifier for the brand (or promotional
brand). It is used to match against a list of Payment Instruments which the
Consumer holds to determine whether or not the Consumer can pay using the
Brand.

	Values of BrandId are managed under the procedure described in
section 12 IANA Considerations.

	As values of BrandId are controlled under the procedures defined in
section 12 IANA Considerations user defined values may be defined.

PROTOCOL BRAND ELEMENT DEFINTION

The Protocol Brand Element contains information that is specific to the use
of a particular Protocol with a Brand. Its definition is as follows.

<!ELEMENT ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand
 ProtocolId         CDATA   #REQUIRED
 ProtocolBrandId    CDATA   #REQUIRED >

Attributes:
*	ProtocolId	This must match the value of a ProtocolId attribute
in a Pay Protocol Element (see section 7.7.5). The values of ProtocolId
should be unique within a Brand Element otherwise there is an error.	
*	ProtocolBrandId	This is the Payment Brand Id to be used with a
particular payment protocol. For example, SET and EMV have their own well
defined, yet different, values for the Brand Id to be used with each
protocol. The valid values of this attribute are defined in the supplement
for the payment protocol identified by ProtocolId that describes how the
payment protocol works with IOTP.	
Content:
*	PackagedContent	Optional Packaged Content (see section 3.7) elements
containing information about the protocol/brand which may be used by the
payment protocol. The content of this information is defined in the
supplement for a payment protocol which describes how the payment protocol
works with IOTP.	

BRAND LISTS AND BRAND SELECTION

Add another couple of paragraphs in section 11 that say ...

11.x.x.x Consumer Software Brand Id Recommendation

New Brand Ids are allocated under IANA procedures (see section 12 IANA
Considerations). Which also contains an initial list of Brand Identifiers.

It is recommended that implementers of consumer IOTP aware applications
(e.g. software wallets) pre-load their software with the then current set of
Brand Ids and provide a method by which they can be updated. For example, by
going to the software developer's web site. 

BRAND LIST EXAMPLE

Comments from people with SET knowledge are welcome on this.

The second Brand List Example changes to become ...

<BrandList ID='M1.2' 
  XML:Lang='us-en' 
  ShortDesc='Purchase ladies coat'
  PayDirection='Debit' >
  <Brand ID ='M1.3'
    BrandId='MasterCard'
    BrandName='MasterCard Credit' 
    BrandLogoNetLocn='ftp://otplogos.mastercard.com'
    ProtocolAmountRefs='M1.7 M1.8'>
    <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'>
    </ProtocolBrand>
  </Brand>
  <Brand ID ='M1.4'
    BrandId='Visa'
    BrandName='Visa Credit' 
    BrandLogoNetLocn='ftp://otplogos.visa.com'
    ProtocolAmountRefs='M1.7 M1.8'>
    <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'>
    </ProtocolBrand>
  </Brand>
  <Brand ID ='M1.5' 
    BrandId='BritishAirwaysMC'
    BrandName='British Airways MasterCard' 
    BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
    BrandNarrative='Double air miles with British Airways MasterCard'
    ProtocolAmountRefs ='M1.7 M1.8' >
    <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'>
    </ProtocolBrand>
  </Brand >
   ...
</BrandList>

> Sent: 	20 May 1999 14:46
> To: 	Ietf Trade WG; Tony Lewis
> I've been reading the emails on this topic and *think* I have a solution.
> 1. We need to have a unique "brand id" so that we can link things like the
> specific version of a "brand id". For example for SET the payment protocol
> specific of the Brand Id must be of the form "brand:[product]" and for EMV
> it must be "RID+PIX", yet SCCD (I think) doesn't need a ProtocolBrandId at
> all.
> 
> Currently the specification does not have a suitable "slot" into which to
> put a payment protocol specific brand id. So how about the following as an
> approach. It involves:
> Change the Brand Element definition (the ATTLIST doesn't change) from ...
> 
> The only other change to the Brand element is to change the definition of
> and ProtocolBrandId is the ProtocolBrandId to be used with that brand and
> protocol.
> 
> EXAMPLE
> of the payment protocol would lie with the payment protocol supplement for
> IOTP.
> 
> and initial values for ProtocolBrandId in the payment protocol supplement.
> any) must be announced to the IETF Trade mailing list and, if there are no
> Visa or Amex) wants to implement a new brand and give it a ProtocolBrandId
> > 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,
> > 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
> > > The "protocols" that can be used with each brand, e.g. SETv1.0, SCCD,
> > etc.
> > > *	Merchant's will know when they create a Brand List which protocols
> > > *	Consumer's will know when they add a new brand what type of payment
> > > > My understanding is that a RID (Registered ID obtained from ISO) is
> > > > assigned
> > > >    - and Maestro International pin based debit cards - which uses a
> > > > different
> > > >    acceptance "mark" for what some consumers may consider a "brand".
> > > > 
> > > > 0xA000000003. Visa then assigns PIX values for various applications,
> > > e.g.,
> > > > 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.
> > > > 
> > > > to the SET Initiation message, which will ultimately be replaced by
> > > IOTP.
> > > > 
> > > > Tony
> > > > > ----------
> > > > > Subject:     Re: Brand IDs & their registration. Was: RE: Comments
> > on
> > > > > 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
> > > > > >even if it's only expressed in the brand level certificates that
> > > SETco
> > > > > allows to
> > > > > >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
> > > > > >Mastercard or whether Visa is all caps, ...).  Is there a list of
> > > bands
> > > > > >Designated Expert criteria being used for other things.  The only
> > > > > difficulty I
> > > > > >later join SETco or otherwise get registered in some other system
> > > under
> > > > > some
> > > > > >brand tree in IOTP.  If some brand exists under SETco but hasn't
> > yet
> > > > been
> > > > > >that some brand registered under IOTP could later join SETco and
> > > could
> > > > > exist as
> > > > > >possibility that occurs to me would be to use brand[:product] and
> > > have
> > > > a
> > > > > >David Burdett <[email-masked]> on 04/29/99 12:17:01 PM
> > > > > >
> > > > > >I agree with Tony. Smart card based EMV transactions will be the
> > > > dominant
> > > > > >which should result in lower merchant fees. This also means that
> it
> > > > will
> > > > > be
> > > > > >*    using a multi-application smart card you will be able to use
> > > just
> > > > > >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
> > > > > >
> > > > > >> ----------
> > > > > >> card with the EMV data carried inside a SET message extension.
> > EMV
> > > > > credit
> > > > > >> commerce. I expect they will be the dominant model for payment
> in
> > a
> > > > > >> decade.
> > > > > >>
> > > > > >> Tony
> > > > > >> > ----------
> > > > > >> > 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
> > > > > >> > >The only difference I see between "IOTP:Visa" and "SET:Visa"
> > is
> > > > that
> > > > > >> the
> > > > > >> > >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
> > > > > >> > >> Subject: Brand IDs & their registration. Was: RE: Comments
> > on
> > > > > >> > >> alternatively "IOTP" which can be used to define any brand
> > not
> > > > > >> defined
> > > > > >> > by
> > > > > >> > >> credit card payments (using Secure Channel Credit Debit -
> > > SCCD)
> > > > > where
> > > > > >> > the
> > > > > >> > >> To help assist in answering the last point, the following
> is
> > > > what
> > > > > I'm
> > > > > >> > >> * SET:setbrand where setbrand is a brand which is accepted
> > by
> > > > the
> > > > > >> > >> [SET] payment protocol
> > > > > >> > >> Values of "setbrand" are allocated as defined in the [SET]
> > > > > >> > specifications.
> > > > > >> > >>
> > > > > >> > >> > credit card company) and the international brand as part
> > of
> > > > the
> > > > > SET
> > > > > >> > >> > BrandID.
> > > > > >> > >> >
> > > > > >> > >> > Tony
> > > > > >
> > > > > >
> > > > >
> > >

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