Get documents about "Identification, Authentification and electronic Signature
Document Sample
Document Owner: Intended Reader:
Smart Card Charter Smart Card Charter: TBs (EU)
NICSS (J)
Project:
GLOBAL INTEROPERABILITY FRAMEWORK
FOR
IDENTIFICATION, AUTHENTICATION AND ELECTRONIC SIGNATURE (IAS)
WITH SMART CARDS
Document Title:
PART 1:
CONTEXTUAL AND CONCEPTUAL MODELLING
Document type:
Blueprint
Prepared by: Date: Version and status:
Marc Lange 29 August 2002 V. 2.01
Theo van Sprundel
Laurent Den Hollander
e-Europe Smart Card Charter
HISTORY
Name/function Action Circulation Version
Marc Lange Document structure definition + Internal V. 0.1
input from the eEPOCH draft
proposal of 23 August & input from
the T. van Sprundel’s paper
Theo van Sprundel Adaptations, complements, Internal V. 0.2
& Marc Lange additions
Theo van Sprundel Review Internal V. 0.3
Jan van Arkel Review Internal V. 0.4
Theo van Sprundel Draft to be released to eESCC TB ESCC TB and V. 0.5
and eEpoch WP for comments eEpoch WP chairs
Marc Lange Overall format and quality review Internal V. 0.6
Review of sections 2, 3,
Input in Enclosure I
Theo van Sprundel Review of section 4 ESCC Chair V. 0.7
& Marc Lange Input in section 5 and enclosures
Marc Lange & Last review before dissemination in ESCC TB V. 0.8
Theo van Sprundel view of the GIF meeting of 15 eEpoch WP chairs
Henry Ryan November NICSS
Marc Lange & - Update from comments of GIF Internal V. 0.9
Theo van Sprundel meeting,
- Review of the whole document
and in particular section 4 and 5
- Input on the Framework
methodology on page 4 and in
section 1.5
- Input on PKI
- Input on data modelling
Henry Ryan, Last review before dissemination in ESCC TB V. 1.0
Marc Lange & view of the OSC3 of 10-11 eEpoch WP chairs
Theo van Sprundel December NICSS
Marc Lange & Implementation of answers to Q 2, Public v. 1.01
3, 5, 6, 7, 9, 12, 13 from the Q&A
file embedded below.
Jan van Arkel Review
Marc Lange Input from “Work document - Internal v. 1.90
Analysis and comments on DLV#1”
v.0.9 from L. Den Hollander
Implementation of answers to Q 4,
10, 15, 16, 18, 19, 21, 25 from the
file “Questions & Answers to DLV#1
v43.xls” available on request
Marc Lange Implementation of Jan van Arkel Internal v. 1.91
review comments, substantially in
simplifying chapter 5 and deleting
the enclosures of chapter 7
“DLV#1 …” is replaced by
“GIF Part 1 …”
Laurent Den Hollander Technical Review Internal v. 1.92
Marc Lange Validating review and closing
issues
Henry Ryan English Review Internal v. 1.93
Marc Lange Validating review and closing Internal v. 1.94
issues
Jan van Arkel Final Review
Marc Lange Closing last open issues Public v. 2.00
Marc Lange Implementing answers to questions Public v. 2.01
03-1 GIF Part 1_V201.doc Page 2 of 45
e-Europe Smart Card Charter
Name/function Action Circulation Version
26 to 49 from the file “Questions &
Answers to DLV#1 v5.xls” available
on request
TABLE OF CONTENTS
1 INTRODUCTION ..........................................................................................................................5
1.1 BACKGROUND: THE SMART CARD CHARTER ..................................................................5
1.2 OBJECTIVE OF THE “INTEROPERABILITY FRAMEWORK FOR IAS WITH SMART CARDS” ...5
1.3 SCOPE OF THE FRAMEWORK.............................................................................................5
1.4 REFERENCES ....................................................................................................................6
1.4.1 Background documentation.............................................................................................6
1.4.2 An open framework .........................................................................................................6
1.5 DEFINITIONS AND ACRONYMS ..........................................................................................7
1.5.1 Definitions.......................................................................................................................7
1.5.2 Acronyms.........................................................................................................................9
1.6 BUILDING THE GLOBAL INTEROPERABILITY FRAMEWORK ............................................10
1.6.1 Step-by-step...................................................................................................................10
1.6.2 Quality methodology .....................................................................................................10
2 CONTEXTUAL MODEL FOR IAS INTEROPERABILITY..................................................13
2.1 IDENTIFICATION, AUTHENTICATION AND ELECTRONIC SIGNATURE ..............................13
2.1.1 The need for trust ..........................................................................................................13
2.1.2 Authentication, Identification and Attributes ................................................................13
2.1.3 Signature and non-repudiation .....................................................................................14
2.1.4 What is IAS?..................................................................................................................14
2.1.5 Physical presence and material proof in IAS ................................................................14
2.2 SMART CARD MANAGEMENT FRAMEWORK ....................................................................15
2.2.1 Definition and Basic Model...........................................................................................15
2.2.2 SCMF stakeholder’ roles ..............................................................................................16
2.2.3 SCMF and generic trust model .....................................................................................19
2.3 SMART CARD COMMUNITIES AND E-SERVICE COMMUNITIES ..........................................20
2.3.1 Case 1: The Basic Situation – 1 card issuer /1 service provider...................................21
2.3.2 Case 2: Multi-application Frameworks - 1 card issuer / N-service providers.............21
2.3.3 Case 3: Scheme Recognition - n card issuers / N service providers .............................22
3 VISION ON INTEROPERABLE IAS........................................................................................24
3.1 ADDRESSING THE FUTURE: GENERIC IAS APPLICATION. ...............................................24
3.2 MODIFYING THE SCMF MODEL .....................................................................................25
4 CONCEPTUAL MODEL FOR BUILDING BLOCKS AND DATA ......................................26
4.1 SMART CARD INFORMATION SYSTEM .............................................................................26
4.2 SMART CARD LAYER .....................................................................................................26
4.2.1 Smart Card....................................................................................................................26
4.2.2 On-card applications ....................................................................................................28
4.2.3 Card security.................................................................................................................28
4.2.4 SCMF and Smart Card Life Cycle ................................................................................28
4.3 INFRASTRUCTURE LAYER ..............................................................................................30
4.4 FRONT OFFICE APPLICATION LAYER .............................................................................31
4.5 META-MODEL FOR DATA ...............................................................................................32
5 CONCEPTUAL MODEL FOR FUNCTIONS ..........................................................................34
5.1 THE FUNCTIONAL BOX MODEL .......................................................................................34
5.2 THE IAS APPLICATION FUNCTION ..................................................................................35
5.3 THE PLATFORM FUNCTION .............................................................................................35
5.4 THE “PKI” FUNCTION ....................................................................................................35
5.5 THE “USER INTERFACE” FUNCTION ...............................................................................36
03-1 GIF Part 1_V201.doc Page 3 of 45
e-Europe Smart Card Charter
5.6 THE “CONNECTIVITY” FUNCTION ..................................................................................36
5.7 THE “ADDITIONAL APPLICATIONS” FUNCTION .............................................................36
6 CONCEPTUAL MODEL FOR IAS INTEROPERABILITY..................................................37
6.1 TYPOLOGY OF INTEROPERABILITY SCENARIO ................................................................37
6.2 IAS INTEROPERABILITY SCENARIOS IN ON-LINE E-SERVICES CONTEXT..........................37
6.3 SCMF INTEROPERABILITY MODELLING .........................................................................40
6.4 IMPACT OF IAS INTEROPERABILITY ON THE ROLES MODEL ............................................41
6.5 IMPACT OF IAS INTEROPERABILITY ON THE FUNCTIONS MODEL ....................................41
6.5.1 IAS interoperability interfaces ......................................................................................42
6.5.2 IAS interoperability decision tree..................................................................................42
6.5.3 PKI Adapter ..................................................................................................................44
7 MORE INFORMATION .............................................................................................................45
TABLE OF FIGURES
Figure 1: Four tiers in the methodology .................................................................................. 11
Figure 2: GIF Parts and the 4-Tier Methodology .................................................................... 12
Figure 3: Simple Trust model.................................................................................................. 13
Figure 4: Basic roles model for a Smart Card Management Framework ................................ 15
Figure 5: Stakeholder’ roles .................................................................................................... 16
Figure 6: Generic trust model.................................................................................................. 19
Figure 7: The trust model in the Smart Card Management Framework.................................. 19
Figure 8: Case 1 – Each card has access to one single service................................................ 21
Figure 9: Case 2 – Cards accessing service from several providers........................................ 21
Figure 10: Implementing the IAS function in case 2............................................................... 22
Figure 11: Case 3 - Offering service to cards from several card issuers ................................. 22
Figure 12: Implementing the IAS function in case 3............................................................... 23
Figure 13: Separate service and card application providers .................................................... 25
Figure 14: Implementing generic IAS ..................................................................................... 25
Figure 15: Client/server model................................................................................................ 26
Figure 16: Smart Card Layer Conceptual Model .................................................................... 27
Figure 17: Card Issuance Process............................................................................................ 29
Figure 18: Operational Phase .................................................................................................. 29
Figure 19: Revocation Phase ................................................................................................... 30
Figure 20: Infrastructure Layer Conceptual Model ................................................................. 30
Figure 21: Applications Layer Conceptual Model .................................................................. 31
Figure 22: Data model ............................................................................................................. 33
Figure 23: The basic model of the functional boxes ............................................................... 34
Figure 24: Typology of IOP scenario ...................................................................................... 37
Figure 25: Typical scenario with a "on-us" card in its domestic smart card community ........ 38
Figure 26: Typical scenario with a "not-on-us" card accessing its domestic scheme through an
“on-us” (i.e. host) smart card community........................................................................ 38
Figure 27: Typical scenario with "not-on-us" card in its domestic smart card community but
connecting to an “on-us” (i.e. host) service provider ...................................................... 39
Figure 28: Typical scenario with a "not-on-us" card in a "host" scheme ................................ 39
Figure 29: Interoperability relationships ................................................................................. 40
Figure 30: Roles concerned in IAS interoperability ................................................................ 41
Figure 31: IOP Interfaces ........................................................................................................ 42
Figure 32: IAS decision tree related to IOP ........................................................................... 43
03-1 GIF Part 1_V201.doc Page 4 of 45
e-Europe Smart Card Charter
1 Introduction
1.1 Background: The Smart Card Charter 1
This document is a product of the eEurope Smart Card Charter.
The Smart Card Charter identified the issues and an outline action plan for their resolution in
order that smart cards can help to fulfil the expectations of citizens within the information
society.
Following the establishment of the Charter, the next step was the publication, at the end of
2000, of the Common Requirements 2, a document containing the action plans and
deliverables of the 12 Smart Card Charter trailblazer working groups. The action plan
addresses both the citizens’ needs and those of the business community in terms of business
cases, multi-functionality and interoperability of systems and infrastructure, and the provision
of trust in all aspects of service delivery.
The overall outcome of these action plans is being consolidated in a set of Smart Card
Charter Common Specifications to be concluded at the end of 2002 and launched early in
2003.
This Framework for Identification, Authentication and Electronic Signature (IAS) is part of the
Common Specifications. Its aim is to facilitate interoperability between the various IAS
schemes emerging in Europe and more widely throughout the world.
1.2 Objective of the “Interoperability Framework for IAS with Smart
Cards”
The objective of the framework is to provide both smart card communities and e-service
communities with the necessary concepts and guidance on the tools required for access to
e-services and for security of transactions over the Internet where special “high-end”
requirements must be fulfilled concerning identification, authentication (tokens and persons),
non-repudiation (by electronic signature), encryption and integration with other applications.
This guidance includes:
• Preparing information systems for interoperating i.e. providing the rules and
standards which should be used within information systems in order to be able to
guarantee IAS interoperability for internet transactions;
• Organising the operation of this IAS interoperability i.e. the ability of a smart card
community to verify the identification and the validity of the authentication and electronic
signature of a member from a different smart card community.
1.3 Scope of the Framework
The framework is restricted to the data, technology and process agreements required for IAS
interoperability with smart cards in an e-Government context. Its scope is the “interoperable
nucleus” of Internet-based high-end services which are accessed and protected by smart
cards.
The hooking mechanism to these services is part of the framework, but the Internet-based
services themselves are not. Note that the following elements are also not in the scope of this
document:
• Arranging interoperability at service level,
• Rules and standards for interoperability of encryption for data confidentiality,
1
See http://eeurope-smartcards.org/
2
See the document “eEurope Smart Cards Common Requirements: Executive summary”. Available on the
website
03-1 GIF Part 1_V201.doc Page 5 of 45
e-Europe Smart Card Charter
• Rules and standards for integration with other services.
1.4 References
1.4.1 Background documentation
The following documents have been used as background documentation for the preparation
of this document:
# Author Title Version Issuing date
R1 eEurope Smart eEurope Smart Cards, An Information v. 0.00 25.04.2001
Card Charter Society for All - Common Requirements
R2 Nederlands Open Infrastructure for Chip Card First June 1997
Normalisatie- Application – NPR 7402 Edition
instituut
R3 NICSS NICSS-Framework Scheme v. 1.20 24.04.2001
R4 NICSS Multi-RC Model in the NICSS Framework - 15.01.2002
Scheme
R5 TIE Consortium Trust Infrastructure for Europe, D8 & D10 - 25.09.2001
(Project Number 26763)
R6 GTA Rule Book v. 1.0 13.03.2001
R7 TB 1 of Requirement for European Public EID- v. 0.14 06.02.2002
eEurope Smart card’s Issuers supporting PKI and
Card Charter Certificate contents
R8 TB 2 of A pre-inventory of smart card based PKI - Nov. 2001
eEurope Smart projects within the EU
Card Charter
R9 CEN/ISSS Technical Specifications CWA 14174 - July 2001
WS/FINREAD
R10 Belgian FedPKI, The Belgian Federal V. 1.0 June 2001
Government Government’s internal PKI-environment
Basic Concept & Fundamentals
R11 CEN/ISSS “Application Interface for Smart Cards V. 0.8 12 March
WS/ESIGN-K used as Secure Signature Creation 2002
Devices”
R12 NICSS NICSS Approach for IAS concept: - 6 June 2002
Variation in mounting IAS in GIF
1.4.2 An open framework
Full standardisation of complete trusted e-ID services and products in a market with many
types of suppliers and different national histories is not feasible and is not required. Any
standardisation must allow sufficient flexibility so as not to impede developments in smart
cards technology and infrastructure.
A minimal architectural nucleus for e-IDs within a general common conceptual framework can
provide the required answer for pan-European and wider needs of the following stakeholders
for the foreseeable future:
• Smart card users
• Significant issuers of smart cards and smart card services
• Card management suppliers
• Providers of public and private key infrastructure schemes
• Application and service suppliers that are or will be connected in sessions using the
common interoperable e-ID smart card token
• Suppliers of smart cards, system components and infrastructure.
The technologies specified in this eESC-endorsed framework are based on open standards,
and must operate with the agreed minimum logical functions and the agreed data for common
use. The framework includes therefore the logical functions and data for common use.
03-1 GIF Part 1_V201.doc Page 6 of 45
e-Europe Smart Card Charter
1.5 Definitions and acronyms
1.5.1 Definitions
The definitions provided below are only valid within the scope of the Global Interoperability
Framework. Their usability beyond that scope should be verified on a case-by-case basis.
Access Provider The Access Provider is the entity in charge of managing the
infrastructure (i.e. the card readers and necessary drivers,
communication network and servers) to be used by the card
holder accessing the offered services.
Authentication Authentication is the process through which a decider can
obtain trustable proof through a trusted third party about whom
the requester claims to be (identification) OR what the
requester is capable of or authorized to do (attributes).
Card Application When the provision of business services to the card holder
Provider requires the card to be loaded with additional applications or
data, then the Service Provider, acting as Card Application
Provider, delivers the “on-card” application or data to the card
by any appropriate mechanisms.
Card Holder The Card Holder or user is a physical person (in the legal
sense, i.e. an individual human being not a company/legal
structure) who has been issued a smart card by a card issuer.
Card Issuer The role of the Card Issuer is to issue smart cards to card
holders.
Content Provider The Content provider is the entity in charge of keeping the
content of the service provider up-to-date.
Certificate Provider The role of the certificate providers (also known as CSP) is to
issue certificates under the responsibility of the stakeholder
who ordered it, e.g.
• IAS certificates and attribute certificates related to the
card holder
• Any other certificates used for the functioning of the smart
card information system
• Any other certificates required by the service provider for
the functioning of its business service.
e-Service An e-service community is made up of all smart cards
Community recognized by a given service provider.
Front Office The front office application layer of a smart card information
Application layer system includes all off card components required to deliver a
service to the card holder. It is in charge of invoking as
appropriate on-card applications (i.e. located in the smart card
layer).
GIF Global Interoperability Framework for Identification,
Authentication and electronic Signature with Smart Cards.
The Framework is a document in 4 parts:
• GIF Part 1: Contextual and conceptual modelling (i.e. this
document)
an in-depth modelling of the smart card, its environment
and interoperability issues with regards to identification,
authentication and electronic signature;
• GIF Part 2: Requirements for IAS functional
interoperability
03-1 GIF Part 1_V201.doc Page 7 of 45
e-Europe Smart Card Charter
a list of functional requirements and interoperability
prerequisites to be used together with Part 1 for
establishing a set of specifications for interoperability at
IAS level;
• GIF Part 3: Recommendation for IOP specifications
guidance for enabling, implementing and operating IAS
inter-operability;
• GIF Part 4: Deployment strategies for generic IAS
an overview of business plan elements, organisation
issues, and system development processes for mass
deployment strategies.
IAS IAS is the set of processes, data and technology agreements
required in a given environment to provide Identification,
Authentication and Signature services
IAS application The IAS application function is the nucleus application of the
function whole smart card information system and provides three
different sub-functions:
• Identification i.e. who is the card holder?
• Authentication i.e. determining if the card holder really is
who he/she professes to be by using key pairs to verify
the identity of the card holder
• Electronic signature i.e. has the card holder expressed
his/her consent for committing to a particular action?
Identification Identification is the process of obtaining information about
whom the requester claims to be without considering the
“trustability” of this information.
Infrastructure Layer The infrastructure layer of a card information system includes
all (technical) components required to enable and support
communication between all other layers of the architecture.
On-us & Not-on-us The attribute “On-us” or “Not-on-us” is assigned to each
component of the SCMF depending on whether it is being used
respectively in their domestic community (i.e. in the community
for which they have been primarily produced - e.g. on-us card
or certificate) or in a host scheme (i.e. in a community other
than their domestic one - e.g. not-on-us card or certificate).
Smart Card A Smart Card Community is made up of all smart cards issued
Community and managed by a given card issuer
Smart Card The role of the SCC Administrator is to administer, monitor and
Community support the relationships between the card issuer, the access
Administrator provider(s) and service provider(s) in order to ensure the
integrity of the smart card community.
Smart Card The Smart card information system is made up of three
Information System architectural layers, each with their own sets of specific
building blocks as follows:
• The smart card layer
• The infrastructure layer, including card readers and other
card interacting devices, remote servers and private or
public telecommunication networks,
• The front office application layer comprising
o The application which delivers a service to a user with
a smart card
o An interface to the IAS generic application which
needs to be integrated in the business application and
03-1 GIF Part 1_V201.doc Page 8 of 45
e-Europe Smart Card Charter
connected to its counterpart on the card for IAS
processes.
Smart Card A Smart Card Management Framework (SCMF) is defined at
Management conceptual level as a system constituted of a set of roles and
Framework corresponding entities (i.e. the building blocks described below
under Clause 4 and the stakeholder’ functions described
below) which enable and make use of smart cards within a
smart card information system.
Signature A signature can be defined as a mark or sound strongly linked
to the bearer’s identity and which if applied to a contract
commits the bearer to its terms.
Smart Card A smart card is an electronic trusted token with capabilities to
securely store and operate IAS functions. This excludes:
• “Passive” electronic tokens such as magnetic stripe and
memory chip cards.
• Secure (security level to be defined) “active” electronic
tokens with form factors other than an ISO/IEC 7816
smart card, such as USB tokens, RF tokens
Service Provider The role of the service provider is to provide business services
to the card holder using the smart card as an IAS token and/or
as a support for a specific on-card application.
1.5.2 Acronyms
The acronyms provided below are only valid within the scope of the Global Interoperability
Framework. Their usability beyond that scope should be verified on a case-by-case basis.
APDU Application Protocol Data Units
API Application Programming Interface
CA Certification Authority
CRL Certificate Revocation List
CSP Certification Service Provider
DES Data Encryption Standard (with symmetric keys pairs)
eEpoch e-Europe Smart Card Charter Proof of Concept and Holistic solution
eESCC e-Europe Smart Card Charter
eESC TB e-Europe Smart Card Trailblazer
GIF Global Interoperability Framework for Identification, Authentication and
electronic Signature with Smart Cards for Internet Applications
IAS Identification, Authentication and electronic Signature in an e-
government context
ID Identifier, or Identity
IOP Interoperability
MAMS Multi-Application Management System
OCSP Online Certificate Status Protocol
PKI Public Key Infrastructure
RA Registration Authority
RSA Encryption standard with asymmetric keys pairs,
named after Rivest, Shamir, and Adleman
SCC Smart Card Community
03-1 GIF Part 1_V201.doc Page 9 of 45
e-Europe Smart Card Charter
SCMF Smart Card Management Framework
1.6 Building the Global Interoperability Framework
1.6.1 Step-by-step
Defining the Global Interoperability Framework has been conducted in a step-by-step
approach:
• GIF Part 1: Contextual and conceptual modelling (i.e. this document)
an in-depth modelling of the smart card, its environment and interoperability issues with
regards to identification, authentication and electronic signature;
• GIF Part 2: Requirements for IAS functional interoperability
a list of functional requirements and interoperability prerequisites to be used together
with Part 1 for establishing a set of specifications for interoperability at IAS level;
• GIF Part 3: Recommendation for IOP specifications
guidance for enabling, implementing and operating IAS inter-operability;
• GIF Part 4: Deployment strategies for generic IAS
an overview of business plan elements, organisation issues, and system development
processes for mass deployment strategies.
This process was iterated until it all parts were sufficiently consistent and complementary.
In this way, the Interoperability Framework has been designed to include the necessary
specifications and, at the same time, be:
• Focused on the content required for “interoperability of IAS with smart cards”
• Flexible and, therefore, as least constraining as possible in order to support or
participate in a broad development of the usage of smart cards in e-service communities
• Comprehensive, in the sense that at minimum it clearly identifies all issues which
prevent two smart card communities from fully inter-operating at IAS level.
Notwithstanding this list, it is expected that some items will remain, for a certain period of
time, only resolvable by bilateral agreement between two or more e-service communities
until more comprehensive standards are widely agreed and adopted. More details on this
are provided in GIF Part 4.
While the framework addresses IOP at the level of smart cards, it also considers IOP
essential at the levels of the information systems and data. A number of IOP issues which
depend on the ability to secure willingness for common processes amongst different
e-communities, for example, are currently resolved wholly or partially only with great difficulty.
In time, these will be eliminated thanks to emerging synergies and standardization
between smart card and Web technologies.
1.6.2 Quality methodology
The framework uses a simplified four-tiered system inspired by established software and
system engineering methodologies (TINA-C, UML).
03-1 GIF Part 1_V201.doc Page 10 of 45
e-Europe Smart Card Charter
CONTEXTUAL MODEL
CONCEPTUAL MODEL
OPERATIONAL MODEL
IMPLEMENTATION MODEL
Figure 1: Four tiers in the methodology
The contextual model
The contextual model is an informal description of the system and other relevant background
context in which the model is being designed. The other three tiers provide a more formal
description. The contextual model constitutes the “raw material” of the formal modelling
process, similar to the “requirements elicitation” phase in software engineering
methodologies.
Having established the contextual framework, a vision is then presented and used to derive a
conceptual understanding.
The conceptual model
The conceptual model is the first semi-formal description of the system. It is a very high level
and abstract description of the system which answers the question “What” (What is the
described system supposed to do?).
The conceptual model is described using the following elements:
• Entities: which describe conceptual units of the model.
• Roles: which describe the interactions between entities.
The operational model
The operational model refines the conceptual model by answering the question “Who” (Who
is doing the job?).
Note that a conceptual model may lead to multiple operational models each presenting a
different operational scenario.
The operational model is described using the following elements:
• Actors: which describe operational entities.
• Functions: which describe the interactions between actors.
The implementation model
The implementation model refines a given operational model by answering the question
“How” (How are things done?).
Note that an operational model may lead to multiple implementation models each presenting
a different implementation scenario.
Mapping the framework with the methodology
The mapping of the four parts of the framework with this four-tired methodology may be
interpreted as follows:
03-1 GIF Part 1_V201.doc Page 11 of 45
e-Europe Smart Card Charter
• GIF Part 1 and GIF Part 4 address respectively background and deployment from the
perspective of the first two tiers of the methodology (context and concepts).
• GIF Part 2 presents the functional requirements to be taken into account when defining
the operational and implementation models by deriving them from the context and
concepts defined in GIF Part 1 and some strategic decisions/assumptions
• GIF Part 3 presents operational and implementation models.
Part#1 Part#2 Part#3 Part#4
Context
Concept
Operations
Implementation
Figure 2: GIF Parts and the 4-Tier Methodology
03-1 GIF Part 1_V201.doc Page 12 of 45
e-Europe Smart Card Charter
2 Contextual Model for IAS interoperability
2.1 Identification, Authentication and Electronic Signature
2.1.1 The need for trust
All social interactions are implicitly based on achieving some mutually acceptable level of trust
between the parties.
Throughout the ages, each society has devised and refined methods and protocols to
facilitate the achievement and enforcement of this trust through custom and formalized
frameworks such as administrative and legal systems.
2.1.2 Authentication, Identification and Attributes
Analysis of these frameworks leads to a simple three entities model as follows.
Trusted
Is Referenced Third Party Asks for reference
Asks for service
Requester Decider
Grants/denies service
Figure 3: Simple Trust model
In other words, trust between the requester and decider is achieved by reference to a
common third party already trusted by the decider.
Typical examples:
• Someone you don’t know that well (requester) asks you (decider) to lend him some
money. Your decision will be facilitated by asking a trusted friend (trusted third party)
what he thinks of it, i.e. if he answers “yes, you can trust this guy” or “Be careful, he
never paid me back the money he borrowed last month”.
• A security guard (decider) will only allow authorized staff into the company building.
Since he does not know all the employees by sight he will only allow in people
(requester) that show him a company ID card issued by administration (trusted third
party)
The process we have described above is called authentication and can be defined as follows:
• Authentication is the process through which a decider can obtain trustable proof through
a trusted third party about whom the requester claims to be (identification) OR what the
requester is capable of or authorized to do (attributes).
Note that in many instances the concept of authentication is often incorrectly considered to be
equivalent to identification:
• Identification is the process of obtaining information about whom the requester claims to
be without considering the “trustability” of this information.
There are many cases where authentication is mainly concerned with the attributes of the
requester:
• If a person wearing a uniform in a police car with flashing blue lights tells you to pull over
to the side of the road you comply because you recognize and trust these attributes of a
police officer
03-1 GIF Part 1_V201.doc Page 13 of 45
e-Europe Smart Card Charter
• When accepting a credit card payment a sales assistant is primarily interested in
verification of your ability to pay (attribute) as confirmed by the clearance centre.
2.1.3 Signature and non-repudiation
Authentication is a necessary step to achieve trust, but in many cases is not sufficient.
Authentication enables the decider to verify the identity and/or attributes of the requester. This
is enough when the decision and commitment of the decider is immediate such as the case of
our security guard granting entry to employees.
On the other hand, most social interactions are based on agreements which are complex sets
of commitments and obligations spread over time. Typical examples are:
• Someone borrows money today with the commitment to pay it back with specific interest
within a month.
• A customer orders and pays for a washing machine in a shop with the agreement that it
will be delivered to his/her home the following evening.
• An employee agrees to come and work in the office on the understanding he will be paid
an agreed salary at the end of the month
These situations often require an additional level of trust between parties guaranteeing that
they will each respect the agreement, and providing each with means to have the agreement
enforced should one or more of the other parties fail.
This need has given birth to the concept of contract as a means to formally represent the
agreement, but more importantly to the concept of signature as a way to formally bind a party
to the contract.
A signed contract is thus a material proof of an agreement between two (or more) parties to
avoid repudiation by any of the parties. A signed contract for example helps to avoid:
• A borrower not paying back borrowed money on time.
• A customer not receiving his washing machine.
• An employee not getting his paycheck at the end of the month.
A signature can be defined as a mark or sound strongly linked to the bearer’s identity and
which if applied to a contract commits the bearer to its terms. Typical means of signature are:
• Written signature (unique calligraphy of name or initials) on a paper document (validated
by a trusted copy e.g. on an authorised ID document).
• Oral commitment taken in front of a trusted party acting as witness.
• Registered seal applied to a document (e.g. in China and Japan).
2.1.4 What is IAS?
IAS is the set of processes, data and technology agreements required in a given environment
to provide Identification, Authentication and Signature services.
2.1.5 Physical presence and material proof in IAS
The notion of physical presence and material proof has implicitly been the corner stone of IAS
for centuries.
ID documents for example typically bear a photograph, enabling a decider to identify you
while you are physically in his presence.
Most legal systems are traditionally based on the concept of “physical proof” which leads to
concepts such as the need for a “handwritten signature on an original document” or
03-1 GIF Part 1_V201.doc Page 14 of 45
e-Europe Smart Card Charter
“witnessed verbal commitment” to make any contract or agreement legally enforceable.
The advent of the information society is shaking these foundations by making possible remote
electronic exchanges and transactions where none of the parties is physically in presence of
the others.
Decider, Requester and Trusted Third Party physically present
The simplest case is when all entities are physically present at the same time. This is the one
originally used in many cultures leading to the modern concept of “official witness” to some
formal occasions and transactions (weddings, wills, …).
Trusted Third Party not physically present
This case arose as soon as societies became more complex and physical presence of the
trusted third party was not practically manageable for every operation.
This has led to the invention of trusted tokens documents such as ID cards, passports,
memberships cards, letters of recommendation, official badges and uniforms, etc.,
These trusted tokens are in some way “signed” by the trusted third party and enable a decider
to authenticate a requester’s identity and/or attributes without the physical presence of the
trusted third party.
Totally remote exchanges
This is the case for example in electronic transactions between remote parties. Here,
authentication and signature is required through electronic means without any party being in
physical presence of the other and without any physical proof of the transaction.
This has led to the concepts of e-contracts, e-authentication and e-signature, which are
gaining an ever widening support and legal recognition throughout the world.
In most cases this recognition is based on an electronic trusted token to be used as an
electronic support for IAS. In this framework the electronic trusted token is assumed to be a
smart card with capabilities to securely store and operate IAS functions.
2.2 Smart card management framework
2.2.1 Definition and Basic Model
A Smart Card Management Framework (SCMF) is defined at conceptual level as a system
constituted of a set of roles and corresponding entities (i.e. the building blocks described
below under Clause 4 and the stakeholder’ functions described below) which enable and
make use of smart cards within a smart card information system.
Card Holder
Card
Registers
Grants/Denies
Requests Issues
IAS
IAS
Answer
Invocation
Verifies
Service Provider Card Issuer
Grants
Figure 4: Basic roles model for a Smart Card Management Framework
03-1 GIF Part 1_V201.doc Page 15 of 45
e-Europe Smart Card Charter
2.2.2 SCMF stakeholder’ roles
The basic processes within a Smart Card Management Framework are executed by the
following stakeholder’ roles:
• The card holder (e.g. consumer, user)
• The card issuer
• The service provider
• The SCC Administrator
• The access provider
• The content provider
• The card provider
• The certificate provider.
Some of these stakeholder roles may be fulfilled by the same entity. This is an
implementation issue which does not impact the roles model.
The figure below pinpoints the basic roles. Some of the roles are “content” oriented and
others “issuer” oriented. The latter roles govern the business conditions and technical
implementation means.
Card Community processes side
• Issuing, identification management
• Life cycle management (cards, infrastructure)
• Business issues
SCC
Issuer Admin
User
Access Certif.
provider Provider
Content
Service
provider
provider
E-Community processes side
• Daily use / delivery / interaction
• Content management
• Creative challenges
Figure 5: Stakeholder’ roles
The Card Holder
The Card Holder or user is a physical person (in the legal sense, i.e. an individual human
being not a company/legal structure) who has been issued a smart card by a card issuer.
The issued smart card is associated with and issued to the specific card holder and to him/her
only.
This association enables the card to be used by the card holder for IAS purposes and thus to
enable him/her to access services provided by the service provider
The card holder is only the user of the card and not its owner. The card holder has the use of
the card, but the card and its contents remain controlled by and under the responsibility of the
card issuer.
03-1 GIF Part 1_V201.doc Page 16 of 45
e-Europe Smart Card Charter
Note that:
• In order to be issued a smart card, the card holder must first register with the card issuer.
• In some cases, a card may be used to grant associated rights to a family or other group
of persons e.g.
o For tax purposes
o For Health care/Social security (where the children/spouse are covered under the
adult’s health plan)
o For social services
These cases do not contradict the fact that the card holder is a unique physical person. They
just mean that for some specific applications the rights of the card holder may be extended to
other physical persons. Nonetheless, each card is strictly only associated with a unique and
specific holder.
The Card Issuer
The role of the Card Issuer is to issue smart cards to card holders.
While the card issuer holds the legal responsibility, most of its operational tasks are likely to
be delegated/sub contracted to specific entities such as a card manufacturer and/or the
certificate provider.
Independently of the issuance policy deployed by a card issuer (this is an implementation
level issue), the card issuer has the responsibility to:
• Register card holders: i.e. obtain sufficient proof of the identity of the card holder by
traditional means. This RA function may be operationally delegated.
• Generate IAS (data, functions): i.e. triggers the key generation and issue certificates
associated with the card holder. This CA function may be operationally delegated to a
certificate provider.
• Physically issue the smart card. This function may be operationally delegated to the card
manufacturer.
• Personalise the card with the appropriate software and IAS data on board.
• Securely deliver the smart card and authentication mechanism (Pin or enrolment of
biometrics) to the card holder.
The card issuer, since it is the owner of the cards also has the responsibility post-issuance to:
• Operationally manage IAS and cards (e.g. CRL, repudiation policy in case of lost, stolen
or misuse of cards)
• Operationally manage card security (e.g. authorize application download/activation in the
case of multi-application frameworks, authorize card unlocking)
Example of a Card Issuer: A government or a government related agency (e.g. Ministry of the
Interior, Ministry of Health) is a good example of a card issuer. Today card issuers are
essentially private companies like banks.
Note: The Card Issuer roles and responsibilities are independent of whether the issuer is a
public or private organization.
The Certificate Providers
The role of the certificate providers (also known as CSP) is to issue certificates under the
responsibility of the stakeholder who ordered it, e.g.
• IAS certificates and attribute certificates related to the card holder
• Any other certificates used for the functioning of the smart card information system
• Any other certificates required by the service provider for the functioning of its business
service.
03-1 GIF Part 1_V201.doc Page 17 of 45
e-Europe Smart Card Charter
The Service Provider
The role of the service provider is to provide business services to the card holder using the
smart card as an IAS token and/or as a support for a specific on-card application.
Example of service providers:
• A service provider only using the IAS function of the card: e.g. an e-commerce company.
This company will use the IAS function to obtain a non-repudiable electronic signature
from the card holder binding him to the order he has made on the Internet (Note:
payment is not under discussion here).
• A service provider using a specific card application: e.g. the health service. The health
service, for example, may find it useful to have a specific card application which
manages the card holder medical rights and which uses medical prescription details
stored electronically “on card” to allow the card holder obtain prescription medication
from a pharmacy without direct payment.
When the provision of business services to the card holder requires the card to be loaded with
additional applications or data, then the Service Provider, acting as Card Application Provider,
delivers the “on-card” application or data to the card by any appropriate mechanisms.
SCC Administrator
The role of the SCC Administrator is to administer, monitor and support the relationships
between the card issuer, the access provider(s) and service provider(s) in order to ensure the
integrity of the smart card community. This responsibility includes:
• Definition and maintenance of IOP specifications and rules of access which are internal
to the smart card community (e.g. IOP between the card issuer and a service provider),
• Registration of the different stakeholders in the smart card community and verification of
their compliance to the smart card community specifications and rules of access.
Note 1: In many existing SCMFs, this role is often fulfilled by the card issuer.
Note 2: In a multi-application environment, this responsibility includes definition and
maintenance of the specifications required for enabling and managing the coexistence of
several applications on the same card. In this context, this role is also known as Multi-
Application Management System (MAMS)
Access Provider
The Access Provider is the entity in charge of managing the infrastructure (i.e. the card
readers and necessary drivers, communication network and servers) to be used by the card
holder accessing the offered services. This responsibility includes:
• Identification of the card by the card reader,
• Security of the communication between the card and the reader as well as the path
between the reader and the desired front office application layer
• Loading of the reader with the appropriate software for reading the card
• Initial checks (valid card, valid issuer, expiration) for accepting/refusing the card.
Note that both the card issuer and the service provider strongly rely for IAS purpose and any
of their e-transactions on the security provided by the access provider.
Content provider
The Content provider is the entity in charge of keeping the content of the service provider up-
to-date. This will be in accordance with the content service requirements and agreements
concerned. Note that it does not play any role in IAS interoperability.
03-1 GIF Part 1_V201.doc Page 18 of 45
e-Europe Smart Card Charter
2.2.3 SCMF and generic trust model
The addition of an ID token to the simple trust model described earlier provides a generic trust
model which bears a very close correspondence with the SCMF model.
Verifies
Trusted
Third Party
Grants
Issues
IAS
Is Referenced
ID/Authentication Token Invocation
IAS
Answer
Asks for service
Requester Decider
Grants/denies service
Figure 6: Generic trust model
Card Holder
Card
Registers
Grants/Denies
Requests Issues
IAS
IAS
Answer
Invocation
Verifies
Service Provider Card Issuer
Grants
Figure 7: The trust model in the Smart Card Management Framework
The corresponding constituent entities are as follows:
Generic Trust Trusted Third Decider Requester Trusted Token
Model Party
SCMF Model Card Issuer Service Provider Card Holder Smart Card
This parallel with the generic trust model demonstrates that SCMF is logically a perfect
support for trusted IAS.
The Card Issuer/Card relationship
The relationship between card issuer and card (within the IAS interoperability scope) is limited
to the responsibility of the issuance of cards bearing an IAS card application compliant with
the IAS Card interoperability specifications.
This responsibility only holds for the issuance phase of the card’s life cycle. It has no impact
on the Card Issuer’s processes, operational organisation or implementation, but the design
and issuance of an IAS card application compliant with IAS interoperability specifications as
well as the collection and loading of the IAS data of the card holder on the card.
The Card/Service Provider relationship
The relationship between a service provider and a card is activated every time a service
provider requires IAS services from a card holder’s smart card.
03-1 GIF Part 1_V201.doc Page 19 of 45
e-Europe Smart Card Charter
This responsibility holds for every service provider transaction, which requires IAS services
and for every card during its operational phase when its IAS services are invoked by an off
card application.
On the card side, this responsibility only implies having an operational IAS card application
compliant with the IAS interoperability specification. This responsibility is already achieved
during the card’s issuance phase by the card issuer. This responsibility has thus no impact on
the card during its operational phase.
On the service provider side this responsibility implies having an on/off-card application
interface respecting the IAS interoperability specification. This responsibility has no impact on
the Service Provider’s processes, operational organisation or implementation apart from the
design and operation of an IAS interoperability compliant interface.
The Card Issuer/Service Provider relationship
The relationship between card issuer and service provider is invoked every time a service
provider wishes to determine the revocation status of a given smart card or certificate. A
service provider may choose not to invoke this relationship depending on its business policy.
This responsibility holds for any service provider making a revocation query to any card
issuer. Whether access to the revocation data is unrestricted or requires some prior
agreement/contract with the card issuer is an implementation issue.
On the service provider side this responsibility implies having an IAS interoperability
specification compliant front end to make revocation queries. This responsibility has no
impact on the Service Provider’s processes, operational organisation or implementation.
This responsibility only impacts the design and operation of an IAS interoperability compliant
interface for revocation queries.
On the card issuer side this responsibility means having a revocation list/database accessible
through the protocols defined by the IAS interoperability specification. Note that the actual
management of the revocation database is a responsibility of the card issuer but not within
the scope of IAS interoperability).
This responsibility has no impact on the Card Issuer’s processes, operational organisation or
implementation but the design and operation of an IAS interoperability compliant interface on
the revocation list/database.
2.3 Smart card communities and e-service communities
The Global interoperability Framework makes extensive use of the following concepts:
• A Smart Card Community
A Smart Card Community is made up of all smart cards issued and managed by a given
card issuer.
• An e-service community
An e-service community is made up of all smart cards recognized by a given service
provider. (Note: Card recognition does not imply access to the service. Assuming it can
“talk” to the smart card, the service provider will grant or deny the service based on its
business rules).
03-1 GIF Part 1_V201.doc Page 20 of 45
e-Europe Smart Card Charter
2.3.1 Case 1: The Basic Situation – 1 card issuer /1 service provider
This is the basic situation of a large number of SCMF today where the smart card community
exactly equals the e-service community.
Card Communities
e-Service Communities
Case 1 Case 2 Case 3
Figure 8: Case 1 – Each card has access to one single service
Each SCMF is totally separated from the other one with no interoperability whatsoever.
In those cases there is a strong binding between card issuer and service provider who
generally happen to be the same legal entity.
Examples:
• Banking debit cards which only work with ATMs of the issuing bank.
• Health cards which only work for the services of the health service issuing them.
• Transport cards which only work for services provided by the issuing operator.
In these specific cases, IAS interoperability is not of interest.
2.3.2 Case 2: Multi-application Frameworks -
1 card issuer / N-service providers
Most of the existing or emerging multi-application services propose a range of preset or
dynamically modifiable services (post issuance) on a given card.
Nonetheless multi-application frameworks are generally CI centric in the sense that a single
card issuer is recognized at the top of the system.
These frameworks enable a smart card community to support multiple e-service communities
but their design does not necessarily facilitate e-service communities spanning multiple smart
card communities.
Card Communities
e-Service Communities
Case 1 Case 2 Case 3
Figure 9: Case 2 – Cards accessing service from several providers
Examples:
• Multi-application city cards for transportation/e-purse/access to public facilities
03-1 GIF Part 1_V201.doc Page 21 of 45
e-Europe Smart Card Charter
• Joint credit cards/loyalty schemes (airlines).
These frameworks generally do not make use of IAS interoperability. Instead they adopt a
multi-application smart card approach, in which additional card applications are loaded on the
same card, each with its own (possibly proprietary) IAS scheme instead of relying on a
common one.
Scheme No 1 Front Office
Support Application
with proprietary (OFF Card)
IAS interface
Card Card
Application Application
No 1 No 2
with with Smart Card
proprietary proprietary
IAS IAS
Figure 10: Implementing the IAS function in case 2
2.3.3 Case 3: Scheme Recognition - n card issuers / N service providers
This is the case where groups of service providers agree to mutually recognize each others’
cards independently of the card issuers involved.
This can be achieved on a “one to one” basis between service providers or by the definition of
a common scheme within a specific industry.
Typical examples of this are:
• In the financial industry, where credit companies strive to get their “schemes” to be
recognized by as many banks as possible. This for example enables a card with a VISA
(MasterCard, JCB, Amex, …) card application, independently of its issuing bank (card
issuer) to be recognized in a large number of ATMs throughout the world.
• In the mobile telephony industry, through standardisation efforts, where a SIM card will
be recognized by any GSM mobile telephony operator throughout the world
independently of the issuing operator (granting/denial of service only depends on the
type of subscription the card holder has contracted).
This typically enables e-service communities to span several distinct card communities as
described below:
Card Communities
e-Service Communities
Case 1 Case 2 Case 3
Figure 11: Case 3 - Offering service to cards from several card issuers
This case demonstrates some application level interoperability but does not implement IAS
interoperability (with maybe the exception of SIM cards which by standard comply to a world
wide ID scheme).
03-1 GIF Part 1_V201.doc Page 22 of 45
e-Europe Smart Card Charter
Scheme interoperability is usually achieved by multiplying the off-card applications supported
by each service provider (like the ATM application in the case of the financial industry) so that
they will recognize and operate with the proprietary card application corresponding to a given
scheme, as illustrated below:
Scheme No 1 Scheme No 2 Front Office
Support Support Application
with proprietary with proprietary (OFF Card)
IAS interface IAS interface
Card Card
Application Application
No 1 No 2
Smart Card with with Smart Card
from SCC 1 proprietary proprietary from SCC 2
IAS IAS
Figure 12: Implementing the IAS function in case 3
03-1 GIF Part 1_V201.doc Page 23 of 45
e-Europe Smart Card Charter
3 Vision on Interoperable IAS
In most cases today, IAS is strongly embedded in proprietary smart card applications and is
not considered a “generic” functionality of the smart card. This reflects the nature of SCMF
deployments up to now where the roles of card issuer and service provider are often held by a
single commercial entity (e.g., bank, transport company, telecommunications operator).
3.1 Addressing the future: Generic IAS application.
On the other hand, national legal systems are being modified worldwide to enable the
development of the information society by defining and recognising concepts such as
e-signature, e-contacts, e-authentication, etc. This is expected to lead to the imminent
deployment of a new generation of SCMFs with institutional card issuers (government based
or, in any case, recognised within the national legal system) clearly separated from the
service providers.
In the current context, IAS is only considered to be a subset of a proprietary card application
security functions. The range of service providers is essentially limited to those who have the
means to be card issuers or at least to associate with them.
In the vision of the Global Interoperability Framework, the future IAS-enabled smart cards will:
• By default be issued with a generic IAS card application supporting a nationally
recognised scheme;
• Most of them will be multi-application with many service providers leasing or otherwise
using the facilities of the existing smart card information systems.
Where e-signature is legally recognized within a country and IAS compliant smart cards are
distributed by recognized institutions, then IAS will become the key generic functionality of the
smart cards independently of any specific card application.
The national recognition of IAS compliant smart cards will be able to invoke the card’s IAS
application to conduct an e-transaction, obtain legally recognized e-authentication,
identification and/or e-signature on behalf of and with the authorization of the card holder.
Typical examples would be cases of operations requiring physical signature today and which
could be securely and legally expedited on-line by using smart card for recognised
authentication and e-signature. For example:
• Issuing sale/buy orders for stocks and shares
• Signing loan/mortgage contracts
• Expediting the signature of legal documents
• Making tax returns
• Signing employment contracts
• Signing customer service contracts
In general, recognized IAS schemes are expected to generate large smart card communities
(nationwide in the case of nationally supported schemes) containing many e-service
communities.
03-1 GIF Part 1_V201.doc Page 24 of 45
e-Europe Smart Card Charter
3.2 Modifying the SCMF model
The SCMF model presented earlier is based on the traditional schemes where service
providers are implicitly considered to be on-card application providers. When these two roles
are explicitly assigned to two logically separate entities the IAS model below is applicable:
Card Holder
Card
Registers
Requests Issues
Grants/ IAS Card
Denies
Issues And IAS
Card
App
Service Provider Card Issuer
Card App
Provider Grants
Checks Revocation
Figure 13: Separate service and card application providers
In order to enable a whole new generation of service providers
• Using the smart card IAS functions without having to be on-card application providers,
• Offering services to a larger audience of card holder, i.e. beyond a particular Smart Card
Community,
the IAS implementation scheme presented earlier should also be adapted.
Multi-application card Front Office Application
accessing various Front Office Applications accessed by cards from various Smart Card Community
…
…
Front Office Many Front Office Scheme No 1 Generic Scheme Front Office
Application No1 Application Support IAS No 2 Application
Off Card IAS Off with proprietary Interface Support (OFF Card)
Application Interface Card IAS interface
No 1 Applic.
Card Card IAS Generic Card Generic
Application Applic. IAS Application IAS
No 1 No 2 IF. Application No 1 Application
Smart Card Smart Card with Smart Card
with without
from SCC 1 proprietary from many
proprietary IAS
IAS different SCCs
IAS
Figure 14: Implementing generic IAS
Note: The “national” IAS outlined in previous paragraph is only ONE of the possible
deployment models of IAS. It is given as an example and does not exclude other possibilities.
03-1 GIF Part 1_V201.doc Page 25 of 45
e-Europe Smart Card Charter
4 Conceptual Model for building blocks and data
4.1 Smart card information system
The smart card is not seen as an information system as such but as one of the functional
components of an information system. The Smart card information system is made up of
three architectural layers, each with their own sets of specific building blocks as follows:
• The smart card layer
• The infrastructure layer, including card readers and other card interacting devices,
remote servers and private or public telecommunication networks,
• The front office application layer comprising
o The application which delivers a service to a user with a smart card
o An interface to the IAS generic application which needs to be integrated in the
business application and connected to its counterpart on the card for IAS processes.
4.2 Smart Card Layer
4.2.1 Smart Card
A smart card is an electronic trusted token with capabilities to securely store and operate IAS
functions. This excludes:
• “Passive” electronic tokens such as magnetic stripe and memory chip cards.
• Secure (security level to be defined) “active” electronic tokens with form factors other
than an ISO/IEC 7816 smart card, such as USB tokens, RF tokens
This model therefore focuses on processor based contact smart cards (ISO/IEC 7816-X) and
on processor based contactless smart cards (ISO/IEC 14443-X). One reason for this form
factor is the expressed need for eye readable text and images on the ID card.
Note: Although the architecture can be applied to any token, this document relates only to
smart cards.
The Smart card is an application server
The smart card functions as a component of an information system. It acts as a server in a
client-server relationship because it never proactively generates an action/process. It can only
respond to the requests from external “client” software.
Client
software
on terminal
Server
software
on card
Figure 15: Client/server model
The card based server applications are generally “simple” (due to the cost limitations of
processing, memory, and communications bandwidth on card) and are accessed through a
predefined functional interface (API implemented through a set of APDUs)
03-1 GIF Part 1_V201.doc Page 26 of 45
e-Europe Smart Card Charter
On-Card and Off-Card applications
Within this client-server context, the concepts of “off-card” and “on card” applications are
introduced and defined as follows:
• The “On Card” application(s) as the software, which needs to be present on the card to
make this service operational.
• The “Off-Card” application(s) as the software, which resides in the infrastructure
(terminal, front and back-office servers) to make this service operational.
An application of one of this type at least is required for any service provided to a card holder
by a service provider.
More details of the content of and requirements for on card application are outlined in
following.
Generic Functional model
The generic modelling of the different functions which together constitute the smart card layer
is outlined in the following figure.
Note: Similar figures are introduced for modelling the two smart card information system
layers and their constituent building blocks. These will be simplified when the focus is
exclusively placed on IAS interoperability issues.
application
application
Card
application
application
Card
application
Card
Card
Human interface
Human interface
interface interface interface
Security / Certificates
Security / Certificates
IAS-data
Smart card platform
Contact Other Chip
Contactless
interface Interface
interface
(reader) Technology
Figure 16: Smart Card Layer Conceptual Model
In this model, the smart cards at least carry - or can access via the network - the common
minimum set of IAS-data. The smart card layer includes the following technological
components:
• Contact or contactless card interface
Although the framework description to some extent focuses on contact cards, it
specifically also includes contactless cards.
• Multi-application card platform
This allows the applications and / or available “data sets” to be downloaded on, or at
least be handled by a card. This ability is important, because the applications differ from
community to community, and, if decided within a particular community, from person to
person.
• The security processor to be used in the smart card platform
This is considered as a separate component, because it can be based on different
techniques.
• The user interface
This is the part of the card layer that controls the user readable display / screen and the
03-1 GIF Part 1_V201.doc Page 27 of 45
e-Europe Smart Card Charter
keyboard. This component may differ from smart card community to smart card
community, and, if decided from person to person within a particular community.
4.2.2 On-card applications
In this document, on-card applications are divided into two distinct groups:
• The additional application function …;
• The IAS-functions, embedded in security and interface functions and which rules the
identification issues of any application
This last category is considered as a separate application - the IAS-nucleus - because IAS
must be pre-loaded during the card issuing process, cannot be deleted and cannot be
changed (at least not the core elements). A new key pair or a change in personal
identification data of the card holder requires issuance of a new card.
4.2.3 Card security
Although the level of security required varies for different applications or services, the security
capabilities of the card are essential for IOP. The level must comply appropriately with the
requirements: an airline frequent flyer points application might need protection against the
unauthorised writing of points onto the card, but does not need the sophisticated security
required by an e-purse; other applications might do without any data protection at all.
The IAS nucleus must be protected against unauthorised changes, and should be easily
readable. However, the card must also support different read and write criteria, under the
responsibility of the on-card application issuer:
• No access restriction
• After PIN/Biometric-verification (e.g. ensuring only the card holder can offer the access) 3
• Off-line protected by the terminal (e.g. after a card holder has duly identified himself to
the terminal as having access to the data or the application)
• On-line protected by the host (e.g. for very critical data that may only be accessed by the
issuer or the application provider).
The security also covers other elements of the information system which are part of the
infrastructure and will therefore, to the extent they fall under the scope of the IOP framework,
be dealt with in Clause 4.2.4. They are for instance:
• The different technologies for managing key infrastructures
• Off-the-shelf tools for (mass-) personalisation of the card platform
• Support for (mass-) personalisation of cards.
4.2.4 SCMF and Smart Card Life Cycle
The SCMF model described above can be analysed according to the following 3-steps life
cycle of the smart cards.
3
Note: PIN may be supported by or replaced by a biometric technology.
03-1 GIF Part 1_V201.doc Page 28 of 45
e-Europe Smart Card Charter
Card Life Cycle Part 1: Card Issuance Process
During the card issuance process, the card issuer has to take all appropriate measures in
order to secure the link between the card holder and the card.
Card Issuer
Registers Issues
Card Holder Card
Figure 17: Card Issuance Process
Card Life Cycle Part 2: Operational Phase
In the operational phase of the life cycle, the interaction is essentially between the card/card
holder and the service providers:
• The card holder requests a service from the service provider
• The service provider invokes the card to operate specific or IAS processes
• The service provider may request an additional verification (validity for example) from the
card issuer
• The service provider then provides or denies the service to the card holder according to
its own business policy.
Card Holder Card
Provides/
Requests Denies IAS
Verifies/Grants
Service Provider Card Issuer
Figure 18: Operational Phase
Card Life Cycle Part 3: Revocation Phase.
In this very last phase, the association between the card holder and the card is broken
through a revocation process. This may come at the request of the card holder (lost or stolen
card) or from another authorized source depending on the card issuer’s policy (card misuse,
card obsolete)
03-1 GIF Part 1_V201.doc Page 29 of 45
e-Europe Smart Card Charter
Note: the card life cycle may be different from the certificate life cycle.
Card Holder Card
Requests
Requests
Card Issuer Other Source
Figure 19: Revocation Phase
4.3 Infrastructure Layer
The infrastructure layer of a card information system includes all (technical) components
required to enable and support communication between all other layers of the architecture.
The generic modelling of the different functions which together constitute the infrastructure
layer is outlined in the following figure.
application
application
Terminal-
application
Terminal-
Terminal-
Security / Certificates
Security / Certificates
interface interface interface
Human interface
IAS processing functions
Network server
Network
Network
Readers GSM / LAN - WAN -
for (IP) GPRS Access Access
network Device (Hot spot)
Chips / Cards WEB / back office
Figure 20: Infrastructure Layer Conceptual Model
Typically, the infrastructure layer comprises entities which:
• Recognise the presented smart card layer and invoke the IAS application as well as
other on-card applications as required
• Create, as appropriate, the secure communication channel for processing the IAS
application.
• Offer tools and services for the purpose of the human interface
• Support several networking standards for linking the two other layers.
03-1 GIF Part 1_V201.doc Page 30 of 45
e-Europe Smart Card Charter
4.4 Front Office Application Layer
The front office application layer of a smart card information system includes all off card
components required to deliver a service to the card holder. It is in charge of invoking as
appropriate on-card applications (i.e. located in the smart card layer).
Note that at the implementation level, the components of the front office application layer may
be distributed throughout the card information system. In ATM for example some components
are located in the ATM terminal itself, others distributed on various network servers.
Services are provided to the card holder via two separate and different roles:
• The service provider who has identified the business needs, defines the business
policy and provides/manages the necessary means for accessing the desired content,
• The content provider who keeps the content of the service up-to-date or who interacts
with the user. (Note: CP plays no role in IAS IOP).
Using the same modelling drawing as above, they are both to be considered indistinguishable
as a “business application” component.
application
management
management
ID
application
application
Business-
Business-
tion
Personalisa-
Security / Certificates
Security / Certificates
Human interface
IAS functions
Server
IP network Any
Internet
Figure 21: Applications Layer Conceptual Model
This business application component is using:
• The IAS application.
How it will be structured depends on the smart card community:
o As an integrated part of each application, or
o As an application to which the business application is linked at a certain stage.
• The key infrastructure application
• The standards or protocols for using the human interfaces
• The standards to be used for the platforms
• The network standards.
The e-Government / e-Commerce (business-) applications and information systems could for
instance include the following services:
• Secure e-mail services,
• Access to government information (generic and specific),
• Transactions (like submitting forms, applying for permits, funds transfer and settlements),
• Keeping track of procedures and getting status information on letters and complaints,
• Contracts and public procurement,
03-1 GIF Part 1_V201.doc Page 31 of 45
e-Europe Smart Card Charter
• Distribution of information,
• Ordering and delivering of goods and services.
The content will not be considered in this document since from an interoperability viewpoint, it
is only accessible to the user via the service provider.
4.5 Meta-model for Data
The entities to be considered in the data meta-model include the identified building blocks and
roles, including the smart card community itself. They are exhaustively the following entities:
• Smart card layer
o Smart card,
o Card application,
• Infrastructure layer
o Card reader
o Network
o PKI certification authority
• Front office application layer
o Front office application
• Entities with IAS Roles
o User/card holder
o Access provider
o Card issuer
o Service/Application provider
o SCC Administrator
o Smart Card Community
Since the meta-model of the framework is aimed at supporting IOP between applications or
services within and between smart card communities, it is limited to the identification and
authentication of each of the entities participating in the inter-operable IAS business process
and includes three types of entity-related data:
• The entity identifier,
• The smart card community identifier
• The certificate with associated key pairs (public/private) for authentication and electronic
signature.
From the data relationship viewpoint and business process, these entities may act as sender
or receiver of a message/transaction authenticating the card holder.
Note 1: A more detailed modelling of the identifier for the entity “user/card holder” is provided
below, in an IAS context (see clause 5.2).
Note 2: The requirements, recommended choices and the mandatory specifications are
defined in GIF Parts 2 and 3.
Note 3: In accordance with the framework, the global Identifier is at SCC level. There is no
need for a common rule for identification purpose within a specific smart card community.
03-1 GIF Part 1_V201.doc Page 32 of 45
e-Europe Smart Card Charter
A proposed summary of the data modelling is provided in the following table:
ID SCC ID Certificate
Smart card X X X
Card application X X X
(including IAS)
Card reader X X X
Network X X
CA directory X X X
Front office application X X
User card holder X X
Access provider X X
Card issuer X X
Service/application provider X X
SCC administrator X X
Smart card Community X
Sender
Receiver
Figure 22: Data model
03-1 GIF Part 1_V201.doc Page 33 of 45
e-Europe Smart Card Charter
5 Conceptual Model for functions
5.1 The functional box model
The models of the layers with building blocks and the data related to IAS have been
introduced in the previous section. The purpose of this section is to provide a model for the
functions which together enable the smart card information system to work.
Each layer has been modelled on the basis of the same approach and includes the same
functions. However, from a modelling viewpoint, it is not always necessary to specify in which
building block(s) a particular sub-function is implemented. Therefore, for the functional
architecture model, the building blocks of Clause 4 have been simplified and transferred to
the autonomous “functional boxes” model. This model is applied to the three layers used to
describe the typical smart card environment. Each of the three layers is communicating with
the others through the connectivity “functional box” via a secure communication channel.
application
infrastructure
card
Additional
Applications
4
Human Interface
IAS
PKI
2 3
Platform
infrastructure
infrastructure
1 application
application
card
card
application
infrastructure
card
Connectivity
0
Figure 23: The basic model of the functional boxes
For the purpose of the framework, it is not necessary at this level to be concerned about the
internal processes as long as the functional input and output descriptions of the boxes are
respected. As a consequence, the detailed functional description requires:
• The label of the functions which must be executed by the box, including the possible
constraints and key sub-functions;
• The IOP- interface between the central and peripheral functionalities.
The functional input/output interface between the central boxes and the peripheral boxes is
labelled as the “IOP-interface” (interoperability interface). Four IOP-interfaces are defined:
• #1. From nucleus to (external) connections,
• #2. From nucleus to human interface,
• #3. From nucleus to PKI application,
• #4. From nucleus to front office applications when IAS functionality is required.
The IOP-interface must be adequate for the function concerned. This means meeting
identified and agreed requirements criteria for aspects such as availability, quality, speed,
safety and security.
03-1 GIF Part 1_V201.doc Page 34 of 45
e-Europe Smart Card Charter
Note: For the purposes of this section the technology infrastructure used for public and private
key management is identified in shorthand as PKI. No restriction in intended on the particular
infrastructure as long as the requirements defined in GIF Part 2 are complied with.
5.2 The IAS application function
The IAS application function is the nucleus application of the whole smart card information
system and provides three different sub-functions:
• Identification i.e. who is the card holder?
• Authentication i.e. determining if the card holder really is who he/she professes to be by
using key pairs to verify the identity of the card holder
• Electronic signature i.e. has the card holder expressed his/her consent for committing
to a particular action?
Note 1: It is considered as granted that mutual device authentication and secure channel
have been executed as part of the IAS application.
This IAS application uses the personal data set required to identify the card holder for
authentication and electronic signature purposes in an e-government context. This data set is
available to be read without restriction by any service provider to whom the card holder
proffers the card. However, the definition of its content is under the responsibility of the card
issuer.
Note 2: A minimal subset of this personal data set is necessary for IAS interoperability
purpose. It is identified in GIF Part 2 and defined in GIF Part 3.
Additional personal information (e.g. social security identification number, membership
number of a specific association) may be required by a particular front office application
domain subject to particular access rights. This additional personal information does not
belong to the IAS application function. Instead it is specific to an additional application
function. It is stored and accessed separately from the minimum personal data set of the IAS
nucleus and has its own protection mechanisms. On the other end, the card issuer may also
require to load the card with additional personal information (i.e. beyond the IAS minimum
personal data set). As far as these data are under the responsibility of the card issuer, then,
for technical reasons, they may belong to the IAS application function, but are out of the
scope of the framework.
Distribution and processing of personal information is governed by the European Data
Protection Directive, the Telecommunications Directives and National legislation.
Consequently, care must be taken to protect this and any other personally identifiable
information.
The same reservations apply to data on the various attributes of the card holder which may
provide information on the capacity in which the card holder is to be authenticated or is
signing an e-transaction. The arguments for separating these data from the IAS ones are also
practical. Such data is subject to change where the core identity data generally is not.
5.3 The Platform function
This function includes the operating system of the related building block.
The platform box will have no direct IOP-interface to its functional environment other than to
the IAS-application that is running on this platform and the connectivity function.
5.4 The “PKI” function
The PKI set of tools related to the IAS function has two or more (bio) PIN-based key pairs. A
key pair is used for authenticating the card holder and is required before any signatures for
03-1 GIF Part 1_V201.doc Page 35 of 45
e-Europe Smart Card Charter
non-repudiation can be generated, a second one is used as a signature mechanism for
expressing card holder consent and a third one could be used for confidentiality purpose.
The following sub-functions are part of the “PKI” function:
• Key loading and or n-card key generation,
• Key storage
• Digital signature generation,
• Calling the PKI directories i.e. to check on policies
• Handling the PKI settings
• Verifying certificate validity.
5.5 The “User Interface” function
The following sub-functions are considered part of the “user interface” function of the card
layer:
• Smart card community settings (language, accessibility options and tools to ensure
access for all)
• Individual settings (profiles, preferences)
5.6 The “Connectivity” function
The “connectivity” function is in charge of inter-connecting building blocks and includes the
following sub-functions:
• Challenging the smart card via the reader
• Establishing a secure connection with the smart card
These functions are realised based on standard industry technologies. In addition, in principle
a sub-function can be transferred from one building block (i.e. technology) to another one
between or within smart card communities.
5.7 The “Additional Applications” function
The following sub-functions are part of the “additional applications” function:
• Applications containing additional Personal data (if required)
• Additional functions for identification and/or card management (if required)
• General applications as mentioned in section 4.2.2, or the access to them (as far as
required)
• Connection to “e-government”, “e-business” applications as mentioned in section 4.4.
Note: The downloading of a particular “additional application” onto a card remains subject to
authorisation from the card issuer responsible for the smart card concerned (see Clause
4.2.2).
03-1 GIF Part 1_V201.doc Page 36 of 45
e-Europe Smart Card Charter
6 Conceptual Model for IAS interoperability
6.1 Typology of interoperability scenario
For the purpose of modelling interoperability scenarios, a new attribute is assigned to each
component of the SCMF (i.e. the members of a Smart Card Community as well as the
technical components such as cards, certificates, reader). Each of them may be described as
either “On-us” or “Not-on-us”.
The attribute “On-us” or “Not-on-us” is assigned to each component of the SCMF depending
on whether it is being used respectively in their domestic community (i.e. in the community for
which they have been primarily produced - e.g. on-us card or certificate) or in a host scheme
(i.e. in a community other than their domestic one - e.g. not-on-us card or certificate).
Keeping the Infrastructure Layer constant (i.e. “on-us”) and assuming the certificate and card
layers are at same level (either “on-us” or “Not-on-us”), four IOP scenarios are possible.
Based on the above described models, these IOP scenarios can be modelled as follows:
Connectivity
Platf orm
PKI Human
Interface
IAS
Scenario Card layer Infra. Applic. Certificate Additional Applications
ID layer layer
IOP #0 On-us On-us On-us On-us
IOP #1 Not-on-us On-us On-us Not-on-us Connectivity
Platf orm
Human
PK I
Interface
IAS
Addit ional Applications
IOP #2 Not-on-us On-us Not-on-us Not-on-us
IOP #3 On-us On-us Not-on-us On-us
Connectivit y
Platform
Human
PKI
Interface
IAS
Connect ivity
Addit ional Applications
Plat form
Human
PKI
Interface
IAS
Additional Applications
Figure 24: Typology of IOP scenario
6.2 IAS Interoperability scenarios in on-line e-services context
The purpose of this section is to illustrate these four IOP scenarios when applied to the
access, by the card holder, to on-line e-government or e-business services with
authentication and electronic signature requirements.
The basic processes of any high-end services as considered in the framework include:
1. Access to the e-government or e-business services (using the IAS nucleus)
2. Identification / (strong) authentication
3. Validations
4. Securing the links
5. Delivery (knowledge products, service, entertainment, interaction)
6. Confirming
7. Signature
8. Validations
9. Closing
03-1 GIF Part 1_V201.doc Page 37 of 45
e-Europe Smart Card Charter
The following figures outline from a high level functional viewpoint how interoperable IAS can
work worldwide with smart cards. The outline is independent of the type of key mechanisms
(i.e. token) for access and electronic signature, but the use of smart cards is assumed in this
document as recommended for greater proven security and ease of use.
Service Provider
4. Set-up of a secure communication link
9. Closing the transaction and
communication link
Card issuer
Access Provider
3. Secure authentication validated
User/card Holder
8. Electronic signature validated
Content provider
5. Transaction or delivery of user-related
1. Access to a Web application with
Information (if any)
transaction capabilities
2. PIN 1 (or equivalent) for secure authentication
6. User filling in the form/confirming the transaction
7. PIN 2 (or equivalent) for electronic signature
Figure 25: Typical scenario with a "on-us" card in its domestic smart card community4
«Not-on-us»
Service Provider
4. Set-up of a secure communication link
Host Smart 9. Closing the transaction and
Card C
Community communication link
Host «Not-on-us»
Access Provider Card issuer
3. Secure authentication validated
«Not-on-us»
8. Electronic signature validated
User/card Holder
«Not-on-us»
Content provider
5. Transaction or delivery of user-related
1. Access to a Web application with
Information (if any)
transaction capabilities
2. PIN 1 (or equivalent) for secure authentication
6. User filling in the form/confirming the transaction
7. PIN 2 (or equivalent) for electronic signature
Figure 26: Typical scenario with a "not-on-us" card accessing its domestic scheme
through an “on-us” (i.e. host) smart card community5
4
This description corresponds to scenario 0 from Figure 24: Typology of IOP scenario
5
This description corresponds to scenario 2 from Figure 24
03-1 GIF Part 1_V201.doc Page 38 of 45
e-Europe Smart Card Charter
Host Smart
Card
Community
Host
Content Provider
3b. Secure authentication validated
8. Electronic signature
Host validated
Service Provider
4a. Set-up of a secure communication link
9a. Closing the communication link Host
Card Issuer
3a. Verification of
authentication
«Not-on-us»
Access Provider «Not-on-us»
Card Issuer
«Not-on-us» 5. Transaction or delivery of user-related
User/Card Holder
Information (if any)
1. Access to a Web application with
transaction capabilities
2. PIN 1 (or equivalent) for secure authentication
6. User filling in the form/confirming the transaction
7. PIN 2 (or equivalent) for electronic signature
Figure 27: Typical scenario with "not-on-us" card in its domestic smart card
community but connecting to an “on-us” (i.e. host) service provider6
«Not-on-us»
Service Provider
4b. Set-up of a secure communication link
9b. Closing the communication link
Host Smart
Card
Community
Host
Service Provider
4a. Set-up of a secure communication link
9a. Closing the communication link «Not-on-us»
Card Issuer
3b. Verification of
«Not-on-us»
authentication Content Provider
Host 5. Transaction or
Access Provider Host
Card Issuer delivery of user-related
Information (if any)
3b. Secure authentication validated
«Not-on-us» 8. Electronic signature validated
User/Card Holder
Host
Content Provider
1. Access to a Web application with 5. Transaction or
transaction capabilities delivery of user-related
2. PIN 1 (or equivalent) for secure authentication Information (if any)
6. User filling in the form/confirming the transaction
7. PIN 2 (or equivalent) for electronic signature
Figure 28: Typical scenario with a "not-on-us" card in a "host" scheme7
6
This description corresponds to scenario 3 from Figure 24
7
This description corresponds to scenario 1 combined with scenario 2 from Figure 24
03-1 GIF Part 1_V201.doc Page 39 of 45
e-Europe Smart Card Charter
6.3 SCMF interoperability modelling
The drawing below is based on the role modelled under section 2.2.2 and identifies the roles
and processes required for interoperability between smart card communities.
SCC
Not-on-us smart card community Issuer Admin.
User
Access
provider
Content
Service
provider
provider
On-us smart card community
SCC
Issuer Admin
User
Access
provider
Content
Service
provider
provider
Figure 29: Interoperability relationships
When a Service Provider is willing to welcome a “not-on-us” card for identification,
authentication and electronic signature purposes, three role-interfaces are needed and will be
called upon to ensure this interoperability:
• The interface between the “not-on-us” card and the access provider from the host smart
card community for
o Electronically reading the content of the card,
• The interface between this access provider and the service provider for
o Retrieving the necessary IAS data from the card and
o Carrying it in a secure way to the service provider (premises),
• The interface between the two smart card communities concerned which will enable
o The validation of the IAS certificate included in the “not-on-us” card,
o The verification of the card revocation list,
o The confirmation of the compliancy of the card issuer of the “not-on-us” card with the
IOP rules,
o The confirmation of the compliancy of the “not-on-us” service provider with the IOP
rules, as far as additional data related to the user are required by the host service
provider,
o The verification with the "not-on-us" SCC Administrator, of the identity details of the
"not-on-us" card issuer and the "not-on-us" service provider as far as data or services
are required from, as well as with the "on-us" SCC Administrator, the identity details
of the "not-on-us" SCC Administrator.
03-1 GIF Part 1_V201.doc Page 40 of 45
e-Europe Smart Card Charter
6.4 Impact of IAS interoperability on the roles model
Within an IAS interoperability context, the model introduced under clause 2.2.1 can be
simplified and presented as follows8:
Registers with
Card Holder
Card
Requests Service Issues
Grants/denies Service IAS Issues Card
Card and
App IAS
Card App
Service Provider Provider Card Issuer
Grant
Checks Revocation
Figure 30: Roles concerned in IAS interoperability
The IAS interoperability framework is only concerned with the yellow/shaded blocks with thick
borderlines.
6.5 Impact of IAS interoperability on the functions model
Realisation of IAS interoperability is dependent on a service provider being willing to welcome
a “not-on-us” card. Thus IAS interoperability between smart card communities is effective only
when:
• Enabled by agreements between smart card communities,
• Ruled by the SCC Administrators of the smart card communities involved - or by a kind
of “root certification & registration authority” that will be commonly accepted by both of
them - for assessing the conformance of a particular stakeholder to the agreed
interoperability specifications and eventually the successfully performance of the agreed
conformance testing.
The sub-sections below identify how far, how deep, and in what other way the modelling
concepts above are impacted by the requirements for “extended” IAS interoperability between
smart card communities.
8
The full role model described under section 2.2.2 distinguishes the CI role from the SCC Administrator and
Access provider ones. For the sake of readiness however, all clauses directly related to the IOP issue will simplify
this by grouping them all together since they are often - but not always - assumed by the same organisation, in
particular in the e-Government field.
03-1 GIF Part 1_V201.doc Page 41 of 45
e-Europe Smart Card Charter
6.5.1 IAS interoperability interfaces
The figure below illustrates the required extensions in interfaces and connections.
4
PKI
3 2
application
1
PKI adapter
card
connectivity
0
4
PKI
2 3
IOP adapter
1 application
infrastructure
connectivity
0
Host smart card community
Figure 31: IOP Interfaces
As shown in the above figure, two adapters can enable interfacing between two smart card
communities as follows:
1. The IOP adapter operates in the connectivity level and enables process interfaces
between the IAS and application levels required for accessing/transferring data at card
layer for the purpose of the front office application layer.
o At connectivity level, it may be implemented using a card reader with multiple card
interfaces and supporting multiple card operating systems. It is located in the
infrastructure layer of the smart card information system of the host smart card
community and under the responsibility of the access provider’s concerned.
o At IAS level, it includes all conditions on how to handle a IAS request from a “not-on-
us” smart card community process. These conditions are extensions to the host (“on-
us”) smart card information system. These add-on conditions, modelled in the "IOP-
adapter", include both the receiving and sending smart card community requests.
o At application layer, it includes all business rules applicable to the agreed
interoperability between the two smart card communities.
2. The PKI adapter which is technically identical to the interface required for enabling
certificate verification issued by two different PKI within the same smart card community.
It enables:
o The verification of the validity of certificates delivered by another CA to be used by
The cardholder/user for a trusted transaction with an Internet application,
The smart card community building blocks for securing the smart card information
system.
o The establishment of a trusted relationship between the host smart card community
and the “not-on-us” Certification Authority.
6.5.2 IAS interoperability decision tree
To manage connectivity between different smart card communities, a decision list mechanism
has been developed which is implemented at the level of the IAS off-card interface. Specific
actions are defined based on the conditions tested and the related responses:
• What foreign smart card community the “not-on-us” card comes from?
• What are the parameters for this smart card community?
• What are the agreed and applicable IOP parameters?
03-1 GIF Part 1_V201.doc Page 42 of 45
e-Europe Smart Card Charter
The IAS-application is able to produce an interaction in which the (at least virtual) interfaces
are recognized with:
• The business rules to interface with e-Government or e-Business applications. They will
be qualified as “on-us” or “not-on-us” rules depending on the presence or absence of a
“not-on-us” element involved in the transaction;
• The human interface for the handling of IAS;
• The certificate(s) verification processes
• The connectivity issues.
When access is required by or from another smart card community, the connectivity
mechanism triggers the IOP-adapter. This IOP-adapter translates the interaction with the (at
least virtual) interfaces from the host infrastructure to the infrastructure of the requesting
smart card community. All (virtual) interfaces identified above will be covered in this
interaction.
Note that:
• The code of colours applied in “Figure 23: The basic model of the functional boxes” has
been re-used in the below figure;
• The thick blue arrows illustrate the steps where the processes initiated in the “on-us”
smart card community are accessing the “not-on-us” smart card community.
IOP Adapter Card ID On-us infrastructure
Not-on-us On-us
card card
Human Human
Interface Interface
Not-on-us Not-on-us Not-on-us On-us
Business rule A Business rule A Business rule A Business rules
Authentication ID Authentication ID Authentication ID Out of GIF
(+ PIN) (+ PIN) (+ PIN) (+ PIN) (+ PIN) (+ PIN) scope
Not-on-us
On-us authent.
authent. IOP#0
certificate
certificate
verification
verification
Not-on-us Not-on-us Not-on-us Not-on-us Not-on-us Not-on-us
Business rule B Business rule B Business rule B Business rule B Business rule B Business rule B
On-us On-us Not-on-us Not-on-us Not-on-us Not-on-us
Front office Front office Front office Front office Front office Front office
application application application application application application
IOP#1 IOP#2 IOP#3
Not-on-us Not-on-us
On-us e-Sign.
e-Sign. authent./e-Sign. Not-on-us ID
certificate
certificate certificate verification
verification
verification verification
Figure 32: IAS decision tree related to IOP 9
As shown on this drawing, the IOP adapter will be triggered by the IAS nucleus of the host
(i.e. to be understood as “on-us”) smart card community as soon as:
• The “on-us” infrastructure layer recognises that it is in contact with a “not-on-us” card (i.e.
IOP scenario #1 and 2);
9
This drawing is applicable to both identification with authentication and identification without authentication.
03-1 GIF Part 1_V201.doc Page 43 of 45
e-Europe Smart Card Charter
• A “not-on-us” front office application layer recognises that it is in contact with an “on-us”
card (i.e. IOP scenario #3).
6.5.3 PKI Adapter
The PKI adapter, in technical terms, deals with the interface questions of accessing a CRL -
or an OCSP responder or a Verification Authority - from the “not-on-us” CA.
The involvement of the PKI Adapter in connecting two smart card communities will be
triggered by the IOP adapter as shown in the decision tree. The PKI Adapter will be invoked
as soon as the infrastructure layer or the front office application layer identifies that the
certificate to be verified for authentication or electronic signature purposes has been issued
by a Certification Authority from another smart card community. How this information and is
determined and verified is an internal matter.
Certificates will be used in two different areas:
• For card holder’s authentication and for electronic signature purposes,
• For smart card community building blocks’ authentication purposes.
Therefore, the PKI adapter will also be invoked for both areas as well.
Solutions for the PKI verification process already exist on the marketplace. These include:
• Cross-certification
• Hierarchical certification
• Community of Interest
• Bridge validation
Further details and recommendations in this domain may be obtained from the work done in
the European Electronic Signature Standardization Initiative (EESSI).
03-1 GIF Part 1_V201.doc Page 44 of 45
e-Europe Smart Card Charter
7 More information
GIF is part of the eEurope Smart Card Charter Common Specifications.
For more information on the Global Interoperability Framework Parts 1-4 and its relationship
to the eESC Common Specifications and Demonstrators you are invited to contact any of the
following persons:
• Jan van Arkel arkel@cardlife.nl
• Théo van Sprundel theo.vansprundel@bull.nl
• Marc Lange marc.lange@build-in-europe.be
• Laurent Den Hollander laurent.den.hollander@sharp.co.uk
03-1 GIF Part 1_V201.doc Page 45 of 45
Related docs
