On 10/09/2014 10:12, Paul Corfield wrote:
On Tue, 9 Sep 2014 23:44:13 +0100, David Walters
wrote:

On Tue, 9 Sep 2014 13:00:11 +0100, Roland Perry wrote:
And with Oyster there's at least the chance that you can see your
balance disappearing, if you know exactly where to look on a gate for
the fraction of a second it displays the number. I'm quite sure there's
no such facility for the contactless cards.

I'm a member of the contactless pilot and on my journey home this
evening both gates gave me red lights while opening but the exit gate
also displayed my fare. I've just checked the online version and that
is matching what I expected to pay and what was shown on the gate.

I'm not really sure how that happened. I'll have to look more closely
at the displays next time and perhaps try and get a picture.

Hmmm interesting. I wonder if TfL have responded to the trial
feedback about people not liking the absence of the fare to the paid
being shown on the exit gate display.

It suggests (I'll put it no more strongly than that) that something is
written to the bank card. I cannot see how else an exit gate could
calculate and display a fare within the few hundred millisecond
processing time parameter. I can't see there being contact with the
"back room" system in that time parameter.


Paul,

the current generation of CPC (aka EMV) cards can't be written to by the
'transit application' in the gate or validator, but they are updated by
the reader. They contain a transaction counter and a cumulative sum
recording the contactless transactions. If either of these reach a set
threhold then the card will require a Chip'n'PIN transaction so that it
can go online and ge tthe counters reset. This is a design feature to
minimise some of the risks if the card is lost or stolen.

If all you do is buy a coffee at Starbucks (or whatever), then the
occasional Chip'n'PIN operation won't be a problem. IN the transit world
I'm not 100% sure whether the card can go on for ever, or whether you
will need to buy a coffee every so often.

Future generations of EMV cards will have 'transit sectors' so that they
can carry tranit-related data.

With ITSO cards there is a lot of capability - depending on the
technical product (IPE in ITSO speak) - to store data on the card. A
Stroed Travel Rights IPE (TYP 2) is very like an Oyster APYG, and can
maintain a number of counters and accumlators on the card. Other IPE
TYPs are used for singles/returns and season/period products. But there
does seem to be a move at present to use the card - whether EMV or ITSO
- as just an ;entitlement to travel' token, with the cost of travel
being worked out in a commercial back office after the travel has taken
place.

I could go on and on about this, so if you have any more specific
questions I'd be happy to take them via private email.

Time to get off my hobby horse...

Kevin

In message , at 20:32:42 on Wed, 10 Sep
2014, Kevin Ayton remarked:
the current generation of CPC (aka EMV) cards can't be written to by
the 'transit application' in the gate or validator, but they are
updated by the reader. They contain a transaction counter and a
cumulative sum recording the contactless transactions.

But neither of these have any details about the individual transactions.

If either of these reach a set threhold then the card will require a
Chip'n'PIN transaction so that it can go online and ge tthe counters
reset. This is a design feature to minimise some of the risks if the
card is lost or stolen.

If all you do is buy a coffee at Starbucks (or whatever), then the
occasional Chip'n'PIN operation won't be a problem. IN the transit
world I'm not 100% sure whether the card can go on for ever, or whether
you will need to buy a coffee every so often.

My understanding is that transit operators such as TfL have managed to
negotiate an exemption (possibly at their own risk, but let's face it a
blagged journey on a tube train costs them nothing, a blagged Starbucks
coffee costs the franchisee real money).

I don't know exactly how this exemption has been implemented, but I
wouldn't be surprised if all TfL readers were excluded from the
requirement to increment either of the two counters mentioned.

Clearly, there's no possibility of anyone typing in a PIN.

If a card is reported (or maybe even suspected by usage patterns) to
have been stolen, then TfL will block it from being used any more by
having hot-lists at the gates. We know they do this because of the way
they describe what happens if you travel on a CPC card whose previous
day's journeys have run up a "bad debt" because the most recent
overnight funds transfer was refused by the bank.
--
Roland Perry

In article ,
(Paul Corfield) wrote:

Thank you for the detailed info. I'm less bothered about ITSO because
it's clear it can cater for various product definitions and after
extraordinary efforts it is now working on the TfL estate and with
Southern. If I'm ever sufficiently enthused then I can always
download the ITSO spec and read it.

Not (for my national bus concession pass) on any of the 3 buses I used on
Tuesday.

--
Colin Rosenstiel

In message , at 23:06:11 on
Wed, 10 Sep 2014, Paul Corfield remarked:
I'm much less informed about the CPC stuff. I understand the issue of
requiring PIN validation after so many "wave and pay" ones. I thought
TfL had negotiated a way round this but again I can't point to
anything in detail.

Building on my posting from yesterday, I think we know that TfL CPC
transactions are all "zero pence", so that would mean the CPC's internal
"money spent since the last PIN transaction" counter won't be
incrementing each time.

All we'd need then is for, either built in by default, or as a special
TfL feature, for the "number of waves" counter not to increment either
when it sees a zero-value transaction or a TfL transaction. Perhaps such
functionality would be inherent in TfL's readers.

Of course, the most recent conventional transaction might have been the
one which tripped the counters into the state of "ask for a PIN next
time", but that can't be done at a TfL gate so postponing it for the
next conventional transaction must be inherent in the design.
--
Roland Perry