|
Technical Committee Meeting, London, 4 - 6 February 1998
Wednesday, Feb. 4
Thursday, Feb. 5
Friday, Feb. 6
Following a brief introductory roundtable, Bertrand du Castel led a discussion on techniques that we might use to facilitate discussions with the
Strategic Partners.
- Make subgroups
- Each subgroup tries to establish a list of important requirements
- Let each participant suggest an item; go around to all the participants
- Do two complete rounds like this; only list topics, don't discuss them
- Now the facilitator goes through each of the items on the list and tries to extract discussion to better define the individual topics. Place
emphasis on grouping together items which are actually aimed at the same topic.
- Once the topics are well defined and grouped, take a vote to rank (order) the topics. For example, let each participant vote for three topics,
allocating points in order of preference (perhaps 5, 3, & 1). This will allow each participant to emphasize the topics that are important to him.
- Now select a speaker who will prepare a slide describing the top three or four items. Past experience suggests that by this point there will be
only three or four top items.
Christian Goire suggests that we have two main goals for the effort:
- Get the maximum input
- Be efficient and get results rapidly.
There was a discussion about how this meeting process should fit relative to the previous meeting (in Paris) with the Strategic Partners. There will
be new participants at this meeting who were not at the Paris meeting. These new participants should have the opportunity to provide their input; i.e. the requirements have not been fixed at the previous meeting. At
this meeting, we need to make progress toward finalizing the requirements and providing a framework in which we can progress toward API specifications that respond to their requirements.
Bertrand du Castel's summary of the discussions (regarding the process to be followed):
- start with a brainstorming session [done through subgroups]
- presentation of general results; general discussion
- begin working on the document itself (Market Requirements); the leader of each domain group is responsible for starting to fill in the document
topics.
This would be a good agenda for Thursday morning. For Thursday afternoon, the agenda might be:
- (2:00 - 3:30) Needs and objectives; e.g. is a separate API really needed? [3 domain groups]
- (3:30 - 4:30) Process (for getting to specifications) [3 domain groups]
- (4:30 - 6:00) Develop an action plan [Michel Roux to moderate]
How should the groups be divided? Financial: 10 Strategic Partners and 13 JCF people [need 2 subgroups]
Chair: Christian Goire
GSM: 12 Strategic Partners and 14 JCF people [need 3 subgroups]
Chair: Olivier Piou
IT: 4 Strategic Partners and 10 JCF people [can probably only have 1 group]
Chair: Arnaud Chain
Only the Strategic Partners should have a voice in prioritizing the requirements within the groups.
« « « « « « BREAK » » » » » »
Following the break, Bertrand did a dry run of the brainstorming approach, using the IT requirements as a starting point. He further identified
the facilitators for the various subgroups:
- GSM 1 - Valerie Bardet (De La Rue)
- GSM 2 - Fabien Thieret (Schlumberger)
- GSM 3 - Stephan Hild (IBM)
- Financial 1 - Mario Di Prizio (Motorola)
- Financial 2 - Christian Goire (Bull)
- IT - Daniel Ciesinger (G&D)
Question and Answer Session (Including Strategic Partners)
What's the goal of the vertical domain APIs?
- Single format into all cards?
- Single behavior of an application on all cards?
Philip Yen (VISA) - "Make the life of the issuer simpler and easier."
Jack Pan (Citibank) _
The issuers don't want to have to keep multiple copies of an application around and then load a specific one depending on the specific (card) vendor.
Bertrand du Castel (SLB) - Presented a strong plea for
the financial companies to present their requirements in terms of the end result they want, and not in terms of a solution that they perceive will give them this end result.
From GSM companies - Also
don't want to have to distinguish between different vendor's cards. Also, the communication channel to the card is slow (short message system) so the loading mechanism has to take that into consideration.
Mondex and MasterCard - Consistency of the behavior of an applet is essential. Also, the security characteristics of an applet must be consistent across cards.
Olivier Piou (SLB) - noted that
JavaSoft had mentioned in their presentation that there were some facilities in security and sharing (between applets) which were ill-defined and would not be able to pass an ITSEC certification as they now
stand. JavaSoft noted that these facilities would need to be redefined. Olivier's question is, when will the revisions be done and how will they be done.
Patrice Peyret (JavaSoft) - the response is that they'll probably do a Rev 2.1 of the Java Card spec and that they'll probably distribute this to the licensees in an early March timeframe.
|
