W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2000

use case for XP -- revalue smart card

From: David Ezell <David_E3@Verifone.Com>
Date: Thu, 7 Dec 2000 12:23:46 -0500
Message-ID: <472E220BA79DD11186340060B06B38D9033AD129@tpantmail1.ssr.hp.com>
To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Dear group:
Following is a use case for smart card revaluation.  I think
this is an interesting use case for XP because it is both complex
in terms of messages coming and going and should probably be
available on a small device.

Note that the use case does not address XP at all... it simply
states what has to happen.  Our ongoing task would be to see
if this use case can be accomodated by XP (I hope so!).

Per conversations with some others, this use case is in XML.
You may choose to cut and paste it into a browser or other
tool which can read the xml in a more friendly manner.

Please comment.

David Ezell


<!-- edited with XML Spy v3.0.7 NT (http://www.xmlspy.com) by David Ezell
(Hewlett Packard Company) -->
<usecase ident="HPV01" systemCode="XPV1.0">
		<author>David Ezell</author>
		<company>Hewlett Packard, Verifone</company>
The alternate flows need more work, since they could require more interaction
between the entities.  The exception flows are probably ok from the perspective
of defining XP needs since once an exception is recognized that's the end of it
for the protocol (right?).
This use case describes the sequences of steps a user will go through to load
value to a smart card.
This use case describes the revaluation of a smart card through a secure dial-up
connection using an application host.  The appliance for revaluing the smart
card is designed specifically for that task, though it is possible that this
same use case could be used for revaluing smart cards using a personal computer
connected to the internet.  The result of this use case is that the smart card
has cash value transferred from some value store.
User has access to a dial-up phone line, and has programmed the appropriate
numbers and other information into the smart card revaluation device.
Smartcard Appliance
Application Host Framework
Application Session
Host Adapter 
Bank Host
The cardholder inserts the target smartcard into the smartcard appliance.  The
system notifies the cardholder that a connection with the application host
framework is being attempted.  Once the connection is complete, the application
host framework asks the appliance for it's type and serial number.  The
smartcard appliance responds and the application host framework recognizes the
type of smartcard appliance connected (E-5.  Unknown applicance type), and the
application host framework and appliance establish a session key and a PIN
encryption key to be used for message authentication in this session.  The
application framework host creates an application session responsible for this

The application session prompts the cardholder for the personal identification
number (PIN) required for the card.  The smartcard appliance encrypts the pin
with the session PIN encryption key and and then sends the pin along with the
card information to the application session.  The application session determines
from the card information that the card is a cash card, and opens a session with
the host adapter for the bank host (E-2.  No valid host adapter for card
information.)  The application session forwards the encrypted PIN and card
information to the host adapter.  

The host adapter reencrypts the PIN with a host session key valid for the bank
host, and sends the PIN and card information to the bank host.  The bank host
responds (E-3.  Host timeout) with a verification message (E-1.  PIN invalid).
The application session receives the validation from the host adapter and
requests the cardholder to continue the transaction (outlined below).
The cardholder then selects the function "reload card".  The application session
prompts the cardholder  for an amount to load into the smartcard, and the
cardholder enters a valid currency amount.  The application session requests the
smartcard to create a "signature" for card reload based on the amount requested
("s1", which will be opaque to all entities except the smartcard and the bank
host).  The application session gives the s1 signature to the host adapter
session.  The host adapter formats the message for the bank host which includes
the signature (s1) and sends it.  The bank host responds (E-3.  Host timeout)
with a response "signature" (also opaque to intervening entities), called "s2",
which either authorizes the reload or not.   The host adapter returns s2 to the
application session, which forwards the signature s2 to the smartcard.  The
smartcard responds with a "reload complete" message and another "signature" s3
(the sub-flow "A-1.  Reload failed" will be performed if the reload was declined
by the bank host), and the application displays a message to the cardholder that
the reload was performed.  The application session logs the s3 signature to a
batch database (on the application host) for later reconfirmation with the bank
host at the end of the day.  The cardholder removes the smartcard from the
smartcard appliance and the use case ends.  
			<alternateFlow fid="1">
Reload failed.
(N.B. This flow should be fleshed out better since if it is entered there might
be further messages with the application host.)
			<exceptionFlow fid="1">
Pin Invalid
			<exceptionFlow fid="2">
No valid host adapter for card type.
			<exceptionFlow fid="3">
Host timeout.
			<exceptionFlow fid="4">
Reload amount declined by host.
			<exceptionFlow fid="5">
Unknown appliance type.
Received on Thursday, 7 December 2000 12:23:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:30 UTC