What do you mean by SCMS ?

As I was on holidays, I discussed my current job with an old friend. In the middle of the conversation my friend said to me you always speak about "Smart Card Management System" (SCMS), but what do you really mean by that ? So I explain what I meant by a SCMS to him.

Back on my computer, I wanted to check my interpretation of a SCMS. What I expected to be fairly straightforward didn't turn out to be the case. I think this confusion is best summarized in this quote from Frost & Sullivan "The definition of a SCMS is found to vary depending on its use or application. In general, a SCMS must be able to provide information on the different applications present on a card. This refers to the application’s expiration, the application’s access for a particular project, the type of data that can be viewed by individuals and so on. Another key aspect of any SCMS is to provide post issuance capabilities. This allows for other applications to be added on to a card."

In fairness the first sentence of this quote does well reflect the current situation, when we are all talking about SCMS, we are not talking about the same things. If you are not convinced do a search on the web... Or are we?

Well, it is time to get back to basic and use of one of the most commonly accepted definitions of a system "A system is a set of objects together with relationships between the objects and between their attributes." (in 'Definition of System' by Hall and Fagen, 1956).

So it is time to try and describe a SCMS, as in the quote from Frost & Sullivan, following this definition. A SCMS is a set of objects: Card Image Database[1], Card Personalisation System[2], Data Preparation[3] and Key Management[4], Post-Issuance Server[5], Card Management Server[6]... Wait, a minute here is one of the paradox we are facing. We are using the SCMS terminology for the whole system and one of its part - the Card Management Server. The next contreversial aspect is the application data, this often handled inconsistently. For example, in the above quote, consideration is given in terms of application data that can be viewed but post-issuance is limited to adding application on the card and not data application update. Then depending on the market where such SCMS are deployed, other features such as cardholder data or EMV parameters might be included. Those topics subject to interpretation have created the situation in which there isn't a clear definition of a SCMS.


I think there is merit in attempting to adopt a common definition of a SCMS, similar to what a RDBMS or an Application Server is. I think the SCMS should not manage cardholder or application data, this is best left to other systems. However the SCMS should be capable of performing any personalisation either during issuance or post-issuance using those data. The SCMS doesn't attach any semantics to those data, it handles them as opaque blob according to specified syntax rules regarding their format, encoding, length, type... As for removing the confusion between the whole system and its part maybe it is time to re-introduce the Card Life Cycle terminology to describe what the Card Management Server does.

[1] That provides persistence storage

[2] That performs chip and magnetic stripe encoding and card surface printing, embossing and lamination

[3] That retrieves data from the Card Image Database and External Application and formats it for personalisation (Issuance and Post-Issuance) purposes.

[4] That provides secure persistent key storage, cryptographic services using those keys and key exchange and configuration.

[5] That supports secure post-issuance personalisation, authenticating the card and performing card updates (usually chip encoding).

[6] That provides interfaces to external systems and users and control the status and operations those systems attempts to perform on the card delegating keys and cyrytpographic operations and personalisation to other systems (KMS and SCPS)

A Software Tale on the Allegory of the Cave and the Prometheus Myth

Although not short of standardization bodies the IT industry (and the smart card sector in particular) is full of proprietary solutions, often but not always due to the Customer's demands for innovation.

In the smart card space, one of the major bodies is GlobalPlatform who has set itself the mission to simplify and accelerate the development, deployment and management of smart card applications. I have worked on GlobalPlatform specifications for over 9 years, back when they were called OpenPlatform and originated from a small group at Visa International. So I am definitely biased and I think there is something positive in their approach, so you have been warned.

Recently, CardBASE the company I am working for has delivered two Smart Card Management Systems, to my surprise in both cases the Customer was but impressed with some GlobalPlatform features. Some of their complaints were related to the complexity of the GlobalPlatform Messaging and the verbosity of the Profiles definition.

I felt like the prisoner in Plato's cave, and started to wonder if GlobalPlatform hasn't seen the reality but only a representation of it? Surely my Customer's criticisms were at the heart of GlobalPlatform's mission to simplify and accelerate the development.

Standardization is hard work. And credit to GlobalPlatform they have done a good job on the card specifications, which have been re-used by many others (e.g. in JavaCard 3.0), and the GlobalPlatform Card Committee has demonstrated a rather effective organisation. However the idiosyncrasies of integration and interoperability are definitely giving trouble to the GlobalPlatform System Committee. Since they issued specifications 5 years ago (a lifetime in the current technology world), there had been no major updates. The expected revisions of Profiles and Scripting have disappeared of their web site. If they have set a clear direction, they haven't made it publicly known.

In terms of system integration and interoperability, this is a strategic mistake. It would be beneficial for GlobalPlatform to become more open in order to be the Prometheus they wish to be. The Profiles and Scripting were an attempt at tackling real life integration and interoperability problem. The world is moving, and it would be beneficial for the GlobalPlatform System Committee to take into account technical advances such as web-services. Being more open would facilitate the exchange with the open source communities who are leading the way in the middleware integration and interoperability space.

As often there is a fine line between being Prometheus or the prisoner in Plato's Cave.