Subject: RE: Brand IDs & their registration.

From: Andrew Drapp <[email-masked]>
Date: Tue, 18 May 1999 12:43:41 +0900

Yoshiaki as mentioned a bit before why we recommended the format:

SET:Brand:[Product]:[Promotional Card Name]

([] denotes optional)

Actually, at the meeting where this was discussed, we were only proposing a 
standard way for defining brands when performing a SET transaction. 
 Originally, the suggestion was for it to be IOTP:Brand:[Product]:[PCN]

I think there was a bit of confusion in the discussion.  SET brands are not 
defined as above.  A Set BrandID is composed of "Brand[:Product]".  We 
needed to be able to map the brands listed in the TPO to a SET BrandID.

Additionally, we considered it desirable to be able to distinguish 
Promotional or Dual card names.  This information is included in the SET 
certificate, but is not part of the actual BrandID.  The ability to offer 
discount based on the payment brand is a nice advantage in IOTP, and we 
wanted to preserve this with PCNs.  In order to do this, the PCN needed to 
be included as part of the IOTP brand name.  Again, the PCN is not part of 
the SET BrandID.

With SET, the colon is also optional, and only included if a Product name is 
given, for example:

Visa
Visa:Gold

We encountered a problem if we just tagged on the PCN.  If both of the above 
cards were UC Card dual brands, then tagging on the PCN would yield:

Visa:UC_Card
Visa:Gold:UC_Card

The problem is that in the first example above, "UC_Card" would be 
misinterpreted as the Product name within the SET BrandID, instead of as a 
PCN.  To eliminate this problem, we wanted to make the colons mandatory in 
the brand name, giving:

Visa::UC_Card
Visa:Gold:UC_Card

Thus, when we generated the SET messages in the SET bridge, the SET Brand ID 
would be given as "Visa" and "Visa:Gold", respectively.  However, the dual 
brand status of the card could still be used to provide discounts.

As a side note, while dual brands are specific to Japan, Promotional Card 
Names are not.  PCNs include store issued cards, alumni association cards, 
etc.

Anyway, because we wanted to require the extra colons in a brand name, it 
was suggested that we use a different namespace, specifically "SET:".

It doesn't really make much difference to us what prefix we use, as long as 
it is possible to both include the PCN, and be able to properly separate it 
from the SET BrandID.

Regards,

Andrew

--
Andrew Drapp
[email-masked]
Systems Development Laboratory, Hitachi Ltd.
Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
TEL:+81-44-966-9111   FAX:+81-44-966-1796
PGP Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F

-----Original Message-----
From:	David Burdett [SMTP:[email-masked]]
Sent:	Tuesday, May 18, 1999 10:17 AM
To:	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

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

David

> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	05 May 1999 12:10
> 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
>
> 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
>
> > ----------
> > From: 	Lewis, Tony[SMTP:[email-masked]]
> > Sent: 	04 May 1999 17:09
> > 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
> >
> > 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]
> >
>
> 
**************************************************************************
> ********************
>
> 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

****************************************************************************  
*****************
-----------------------------------------------------------------------
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: David Burdett <[email-masked]>
Date: Thu, 20 May 1999 22:46:00 +0100

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.

> Sent: 	18 May 1999 09:39
> 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
> > 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
> > > 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
> > > 
> > > cc:    (bcc: John Wankmueller/NYC/MASTERCARD)

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

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

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