Identification, Authentification and electronic Signature by dhp30827

VIEWS: 50 PAGES: 45

									 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

								
To top