Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt

From: Denis Pinkas <[email-masked]>
Date: Mon, 04 Nov 2002 16:29:34 +0100

Trevor and Stefan,

> Denis,

> There is a way to accomplish associating multiple community logos within
> the existing draft. We permit the use of the logotype extension within
> attribute certificates as well as identity certificates. It is therefore
> possible to have an identity certificate, issued by Last National Bank
> to merchant foo with a community of Visa, and an attribute certificate,
> issued by Utah Credit Union to merchant foo with a community logo of
> MasterCard. In this situation, the UI can legitimacy display a community
> logotype for each valid certificate.

This does not solve the issue: there is still one single community logo type 
in a given certificate (whether it is a PKC or an AC).

The real issue is what do we call a "community".

Extracts from the present draft:

"The community may represent the subscribers of a service or any other group."

"The community logotype - is the general mark for a community. It identifies 
a service concept for entity identification and certificate issuance."

Well, the less that we can say is that this is not crystal clear !!! :-(

Within that definition both the logo CB and the logo VISA have their places.

CB is a logo used by some banks grouped under the GIE "Cartes Bancaire" and 
recognized by many French merchants.

VISA is a logo used by VISA and recognized by many merchants worldwide.
Both could be in a certificate.

Extract from : http://www.cartes-bancaires.com/GB/Pages/FrameVie.htm

A card bearing a "CB" logo is by definition an interbank card. One feature 
of the "CB" interbank system is that the card will be accepted even if the 
issuing bank is different from the merchant's bank or the bank managing the 
ATM.

(...)

In addition to the "CB" logo, "CB" cards can also have an international 
acceptance logo (Visa or MasterCard).

Denis

> Trevor
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Thursday, October 31, 2002 6:06 AM
> To: Denis Pinkas
> Cc: Housley, Russ; [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
> 
> 
> Denis,
> 
> I think you are mixing concepts and to some extent misreading the
> standard.
> 
> I comment below;
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Denis Pinkas
>>Sent: Wednesday, October 30, 2002 2:47 PM
>>To: Stefan Santesson
>>Cc: Housley, Russ; [email-masked]
>>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
>>
>>
>>
> 
> 
> stuff deleted...
> 
> 
>> > 1) We expand the concept beyond the intended scope
>> > 2) We make it harder and more complex for the GUI implementers
>>to make a
>> > distinct application.
>>
>>What is the "intended scope" ? Until it is clearly defined, you cannot
> 
> say
> 
>>that this is contradictory. So there is no demonstration here.
> 
> 
> Intentions and scopes are included in sections 1 and 2. The scope is
> clearly
> to allow issuers to claim that they issue a certificate as part of a
> community. The value of having just 1 community is that it brings
> clarity to
> the concept. There are numerous of examples in real life of this
> situation:
> 
> 1) Gasoline stations. They may be independent enterprises but they are
> sometimes members of A community (Shell, Esso etc)
> 2) Shops.. same thing.
> 3) Credit cards
> 4) Airlines
> ....
> ....
> 
> The common ground is that there is a point of issuing a service under
> JUST 1
> community. One big reason is that there generally is some kind of common
> explicit or implicit liability or protection of brand involved. If one
> service would be Both VISA AND MasterCard at the same time, or both
> SHELL
> AND ESSO or.... who would protect the brands, who would take
> responsibility
> for that ....
> 
> To my knowledge that type of situation does not exist.
> 
> All examples you state are not examples of multiple communities but
> examples
> of other aspects of reality.
> 
> So a good thing with having just 1 community logotype proved by you
> here.
> That is that people can't abuse the standard and put any obscure
> logotype as
> 1 of 10 community logos, making the GUI makers insane :-)
> 
> 
>>What is harder ? Display is always an option. We do not mandate
>>what MUST be
>>displayed.
> 
> 
> For a GUI of this kind, especially if we want to create a visual
> equivalent
> of an ID-card on the screen (in a standard format), it helps
> implementers to
> know if they will handle 1 or none logo, or if they must be prepared to
> handle any number of logos.
> 
> As said above, if this is not limited, as GUI maker you MUST expect CA:s
> to
> put in a whole bunch of obscure logos here representing everything from
> loyalty scheme, accreditation scheme, partners, sponsors...... you name
> it.
> 
> This is why the principle is good to say that the 3 main logotype types
> can
> only be 1 logo of each type.
> 
> If you want to include more logos, you provide them as other logos,
> according to section 4.2. This is a good structured way that provide
> clear
> expectations for the GUI makers.
> 
> 
>> > Denis,
>> >
>> > We had this discussion in Yokohama and all examples you came
>>up with had
>> > to do with loyalty structures rather than communities. The
>>community logo
>> > represent THE community within which the issuer acts as issuer.
>>
>>Besides loyalty structures (BTW, where do you place them ?),
>>there is as an
>>example "t-scheme approved" or what ever other "scheme" in Asia or in
> 
> the
> 
>>US. Same question: where do you place that information ?
>>
> 
> 
> This is not a community. I don't issue certificate belonging to the
> t-scheme
> community. T-scheme, TTP-NL, Web trust or whatever are conformance
> schemes
> that has nothing to do with community. If you want to display any
> logotype
> related to this you must define a new "other logo" type in section 4.2.
> 
> It could actually be a good idea to do that.
> 
> 
> 
>> > Example - A credit card can never be both MasterCard and VISA at
> 
> the
> 
>> > same time. If it would, who would be responsible for it if
> 
> something
> 
>> > goes wrong???
>>
>>Some merchants are accepting credit cards from Visa, Eurocard, and
> 
> AMEX.
> 
>>How are you going to be able to include that information in a server
>>certificate ?
> 
> 
> You don't
> 
> You may provide that information on the web page that is protected by
> the
> server certificate. But whatever you do, it is NOT part of the community
> logo in the server certificate.
> 
> 
> 
>>Some cards in my country have both the CB logo (CB = Carte
>>Bancaire) and the
>>Eurocard or VISA Logo.
>>
>>How are you going to be able to include that information in a person
>>certificate issued by a bank ?
> 
> 
> The standard allows 2 issuer logos for co-branding, 1:st the logo
> representing the Issuer organization, 2:nd the logo representing the
> community.
> 
> I'm not sure what function the CB logo has. If this is not covered by
> these
> logos, you can use some of the defined other logos (section 4.2), or
> define
> one for the purpose.
> 
> 
>> > If the community, within which the issuer operates when issuing a
>> > particular certificate, has a combined logo from two integrated
>> > community structures -
>> > Fine - This is then still just 1 community logo from the standards
>> > perspective.
>>
>>We never said that logos MUST be displayed. An application may look
> 
> for a
> 
>>given logo and chose to display it, if present. Combined logos would
> 
> not
> 
>>allow that feature and would be pretty big or unreadable since an
>>application would need to display, e.g. four, logos in a small
>>window size.
>>
> 
> 
> That's a feature, not a problem. This means that If the application
> display
> logo related to THE community, it can not screw up by showing just half
> of
> the relevant logo image data.
> 
> 
>> > I agree though that you can have multiple independent loyalty
> 
> schemes.
> 
>>Fine. Where do you place them ?
> 
> 
> Read section 4.2
> 
> Stuff deleted ...
> 
> 
>>Since a sentence is saying:
>>
>>     If a logotype is represented by more than one image file, then
> 
> the
> 
>>     image files MUST contain variants of the roughly the same image.
>>
>>My understanding is the following:
>>
>>image contains one or more variants of the roughly the same image. No
> 
> more
> 
>>that one of the LogotypeImage SHALL be displayed, since it is roughly
> 
> the
> 
>>same image.
>>
>>This does not permit to include images that are really different.
> 
> 
> Yes you are right. That is the defined meaning.
> 
> 
>>I am asking for:
>>
>>           communityLogo   [0] EXPLICIT SEQUENCE OF LogotypeInfo
> 
> OPTIONAL,
> 
>>instead of:
>>
>>           communityLogo   [0] EXPLICIT LogotypeInfo OPTIONAL,
>>
>>I hope that the above examples will be able to convince you.
> 
> 
> I regret to say that I'm not.
> 
> I still think it would make the standard worse
> 
> What would convince me is if anyone could show a realistic and relevant
> case
> where there are 2 independent communities, within which the issuer acts
> when
> issuing a certificate. I have yet to see that case.
> 
> /Stefan
> 
> 
>

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 6 Nov 2002 00:05:12 +0100

Denis,

We are ready to make a change to accommodate multiple community logos (thus
keeping issuer and subject organization logos limited to 1 each).

The condition for this would be:

If multiple community logos are defined in a certificate, and if the client
is designed to display just 1 community logo (or less than the number of
logos included in the certificate), it will use the first logo in the
sequence as the most preferred one and the last logo in the sequence as the
least preferred one to be displayed.

It is though too late to issue a new ID before Atlanta.

Would this satisfy your needs?

/Stefan

> Sent: Monday, November 04, 2002 4:30 PM
> To: Trevor Freeman
> Cc: Housley, Russ; [email-masked]; Stefan Santesson

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 07 Nov 2002 09:43:48 +0100

> Would this satisfy your needs?

Certainly. Thank you.

Denis