ISO/IEC 24727-3:2008/Amd 1:2014

Identification cards — Integrated circuit card programming interfaces — Part 3: Application interface — Amendment 1

Cartes d'identification — Interfaces programmables de cartes à puce — Partie 3: Interface d'application — Amendement 1

General Information

• Status: Published
• Publication Date: 23-Mar-2014
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: ISO/IEC JTC 1/SC 17 - Cards and security devices for personal identification
• Drafting Committee: ISO/IEC JTC 1/SC 17/WG 4 - Generic interfaces and protocols for security devices
• Current Stage: 6060 - International Standard published
• Start Date: 27-Jan-2015
• Due Date: 27-Jan-2014
• Completion Date: 24-Mar-2014

Relations

• Amends: ISO/IEC 24727-3:2008 - Identification cards — Integrated circuit card programming interfaces — Part 3: Application interface
• Effective Date: 14-Jul-2018

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 24727-3
First edition
2008-12-01
AMENDMENT 1
2014-04-01


Identification cards — Integrated circuit
card programming interfaces —
Part 3:
Application interface
AMENDMENT 1
Cartes d'identification — Interfaces programmables de cartes à puce —
Partie 3: Interface d'application
AMENDEMENT 1




Reference number
ISO/IEC 24727-3:2008/Amd.1:2014(E)
©
ISO/IEC 2014

---------------------- Page: 1 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)

COPYRIGHT PROTECTED DOCUMENT


©  ISO/IEC 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland

ii © ISO/IEC 2014 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
Contents Page
Foreword .iv
Annex D (normative) Web Services Interface Description.1
D.1 Contents of Annex D .1
D.2 Connection handling for web service based communication.1
D.3 XML-based CardInfo-Structure for support of legacy cards.3
D.4 Complete XML-Schema Definition (CardInfo.xsd).27
Annex E (informative) XML Binding for Selected Authentication Protocols .41
E.1 PIN Compare.41
E.2 Mutual authentication.51
E.3 RSA Authentication .58
E.4 XML binding for generic digital signature operation .66
E.5 Modular Extended Access Control Protocol (M-EAC) .74
Annex F (normative) XML Service Access Layer Interface.87
F.1 XML-based Service Access Layer Interface.87
F.2 XML-Schema definitions for Service Access Layer functions (ISO24727-3.xsd).89
F.3 WSDL definitions for Service Access Layer functions (ISO24727-3.wsdl) .115
F.4 XML-Schema definitions for selected authentication protocols (ISO24727-Protocols.xsd) .139
F.5 WSDL definitions for connection establishment (ISO24727-Protocols.wsdl) .164


© ISO/IEC 2014 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Amendment 1 to ISO/IEC 24727-3:2008 was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information technology, Subcommittee SC 17, Cards and personal identification.
ISO/IEC 24727-2 standardizes the use of ISO/IEC 7816-15 data structures as "discovery information" that is
communicated throughout the ISO/IEC 24727 stack. This Amendment enhances the definition of the use of
ISO/IEC 7816-15 to fully link the entities defined at the Service Access Layer (API) (e.g. Differential Identity,
Authentication Protocol) with typical "on-card" entities such as keys, files and Access Control Rules. Examples
are provided.
XML encodings have become more and more used in the field of IAS [Identity, Authentication and (digital)
Signature] Identity Management and general networking communication. To enhance interoperability with
existing networking systems and federated identification and authorization systems (e.g. SAML, OpenID, etc.)
standardization of an XML representation of the API and data structures of ISO/IEC 24727-3 is essential.
This Amendment extends the scope of ISO/IEC 24727-3 in the following ways:
1. Make explicit (normative and informative elements, including examples) of the use of the ISO/IEC
7816-15-based Registry. XML representation of the ISO/IEC 24727-3 API including appropriate web
service bindings specified as WSDL-structure.
2. Reaffirm that ASN.1 is the central definition of the API and data structures. All other bindings and
representations are derived from ASN.1
3. ASN.1 and XML representations for ISO/IEC 24727-3 will reside in this part, which may necessitate
movement of text/annexes from other parts of ISO/IEC 24727 (i.e. ISO/IEC 24727-2 and ISO/IEC
24727-4 and ISO/IEC 24727-5).
4. As a result of Amendments under development for other parts of ISO/IEC 24727, portions of this
standard may be deleted and referenced.
5. Add to this standard the ISO/IEC 7816-13 application management and life cycle concepts.
6. Add a discovery mechanism to the API to indicate messaging is either ASN.1 or XML.
7. Enhance a Registry facility through which the SAL can record its use of the GCI and through which the
GCI mechanisms can be conveyed to the SAL.
8. Consider enhancements to the API to resolve technical deficiencies.
9. Remove ambiguities by elaborating and re-specifying concepts that may not be clear in the current
standard.
iv © ISO/IEC 2014 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
10. Incorporate concepts that are captured in other parts of ISO/IEC 24727 but are more relevant for
ISO/IEC 24727-3.
11. Include C and Java bindings in a Normative Annex ( C ) and an Informative Annex(Java).
12. Pursue additional mechanisms for discovery and (card and application) capability description based
e.g. on XML representations as part the development of a more comprehensive Registry. This XML is
restricted to a set of instructions that enable card recognition for legacy cards.

© ISO/IEC 2014 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)

Identification cards — Integrated circuit card programming
interfaces —
Part 3:
Application interface
AMENDMENT 1
Add the following new annexes after Annex C:

Annex D
(normative)

Web Services Interface Description
D.1 Contents of Annex D
• Clause D.2 contains information for the connection establishment for web service based SAL-
communication.
• Clause D.3 contains an XML-based CardInfo-Structure, which facilitates the support of legacy cards.
• Clause D.4 contains the XML-specification for the XML-based Service Access Layer Interface
D.2 Connection handling for web service based communication
This clause describes the connection handling for web service based communications in an ISO/IEC 24727-
based environment.
D 2.1 General security requirements
The security requirements of ISO/IEC 24727 dictate that the TLS protocol in accordance with RFC 4346 shall
be used.
Moreover, public server services shall have access to corresponding X.509 certificates.
When it comes to the security of the communication between the different modules realizing the ECC-3 stack
consisting of Service Access Layer (SAL) and IFD Layer), however, X.509 certificates shall be used, whereby
the associated private keys shall be adequately protected. Alternatively, anonymous TLS cipher suites, such
as TLS_DH_anon from RFC 4346 or TLS_ECDH_anon from RFC 4492, shall be used, although appropriate
security measures need to be taken in the operational environment in order to avert man-in-the-middle attacks
while the connection is being established.
© ISO/IEC 2014 – All rights reserved
1

---------------------- Page: 6 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
In both cases there shall be an exclusive binding of the communication context at application level to the TLS
channel which has been established in this process. This communication context is established on connection
to the IFD-Layer via the function EstablishContext and represented by the ContextHandle. When
connecting to the SAL, this communication context corresponds to a connection to the card application
established by means of CardApplicationConnect, which is represented by a ConnectionHandle.
As such, one single TLS channel shall be sufficient to establish communication between a SAL and the IFD
layer — irrespective of the number of card terminals and connected cards — whereas a separate TLS channel
shall be required for every connection to a card application for communication to take place between the
identity layer or the application layer and the SAL.
D.2.2 Connections for SOAP binding
When using the SOAP binding, the connection shall be established simply by setting up a TLS-protected
channel between the user of the web service (service consumer) and the provider of the web service (service
provider) via which web service messages can henceforth be exchanged. In this case the service consumer
and service provider take the roles of TLS/http client and TLS/http server, respectively.
D.2.3 Connections for PAOS binding
When using the PAOS binding, however, a more complex process shall be required to establish the
connection as, in this case, the TLS/http server acts as the user of the web service (service consumer) with
eService because the TLS/http client acts as the provider of the web service (service provider) and shall
initiate the connection.
Moreover, in this case there are typically two different TLS channels, and appropriate cryptographic
mechanisms shall be used to safeguard their logical relationship while the connection is established.
An example general connection sequence is illustrated in Figure D.1.
© ISO/IEC 2014 – All rights reserved
2

---------------------- Page: 7 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
eService SAL Dispatcher Dispatcher SAL Client App
Network
TLS
HTTPS REQUEST
HTTPS RESPONSE with REDIRECT to localhost with URL-encoded TC_API_Open(SrvAddr,SessionID,PAOS,{PathSecurity})
TC_API_Open(localhost,SessionID,PAOS,.)
URL-encoded TC_API_Open(.)
PAOS Connection
WaitForRequest(SessionID,PAOS,.) Establishment
Establish PAOS connection()
Establish Channel
Details depending on PathSecurity
GET .PAOS/EstablishConnection
5
response
return
return
return ch2cl
return ch2srv
CardApplicationPath(.)
Application Logic
WS REQUEST
GET .PAOS/GetNextCommand
GET RESPONSE incl. CardApplicationPath
CardApplicationPath(.)
return path
POST ./GetNextCommand incl. CardApplicationPathResponse
WS RESPONSE
CardApplicationPathResponse(.)
CardApplicationConnect(.)
WS REQUEST
POST RESPONSE incl. CardApplicationConnect
CardApplicationConnect(.)
return connection handle
POST incl. CardApplicationConnectResponse
WS RESPONSE
CardApplicationConnectResponse(.)

Figure D.1 — Example of a general connection process with PAOS binding
D.3 XML-based CardInfo-Structure for support of legacy cards
D.3.1 Introduction
In order to use the generic Service Access Layer (SAL) interface defined in this standard with legacy cards, it
shall be necessary to provide a certain set of information, which allows to map the generic calls at the SAL to
card-specific APDUs.
The XML-schema introduced in this clause defines a structure that shall both be used for the specification of
card profiles and for the mapping of generic calls at the Service Access Interface to card-specific APDUs of
legacy cards.
The rest of this annex is structured as follows: Clause D.3.2 provides an overview of the defined structure and
explains the top-level element . The following clauses D.3.3 through D.3.7 describe the various
child-elements of , Clause E.7 contains the complete XML-schema-definition
D.3.2 Overview
The CardInfo structure shall be used for the specification of card profiles and for the mapping of generic
requests at the Service Access Layer to card-specific APDUs in case of legacy cards, which are not equipped
with appropriate ACD and CCD structures according to ISO/IEC 24727-2.
Each card profile shall be described by a element

© ISO/IEC 2014 – All rights reserved
3

---------------------- Page: 8 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)

of type CardInfoType which shall be defined as follows:

 
  
  
          type="iso:CardCapabilitiesType" maxOccurs="1" minOccurs="0" />
          type="iso:ApplicationCapabilitiesType" maxOccurs="1" minOccurs="0" />
          type="ds:SignatureType" maxOccurs="unbounded" minOccurs="0" />
  
  
 


[required]
Contains a unique identifier for the card type and optionally further links to specification documents.
[required]
Allows to determine the type of a given card by traversing an appropriate decision tree and checking
whether the characteristic features are as expected.
[optional]
Allows to specify the capabilities of the card. If the card is fully conformant to ISO/IEC 7816 this element
MAY be omitted.
[optional]
Allows to specify the card-applications on the card and shall be used to realize the mapping from SAL-
calls to card-specific APDUs. If the necessary information for this mapping is available on the card in
adequate CIA-information structures according to ISO/IEC 7816-15 (see Clause 7.5) this element may be
omitted.
[optional]

Shall be used to protect the integrity and authenticity of (parts of) the CardInfo-element.
D.3.3 CardType
The element in the CardInfoType is of type CardTypeType and contains a unique identifier
for the card type and optionally further links to specification documents. It is specified as follows:

 
  
   
    
     
     
    
© ISO/IEC 2014 – All rights reserved
4

---------------------- Page: 9 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
   
  
  
          type="string" maxOccurs="1" minOccurs="0" />
  
  
   
    
     
     
     
    
   
  
  
  
  
   
 
 


This type defines the following elements and attributes:
[optional]
This element shall contain information about a basic specification ( element)
which is extended, profiled or redefined (cf. element below) by the present
CardInfo structure. Using this element it shall be possible to re-use existing CardInfo-structures in a
modular approach.
[required]
This element shall contain the unique identifier of the card type, which MAY be the object identifier of a
profile defined in Part 4 of the present standard.
[optional]
This element may be used to specify the card issuer or the organization, which is responsible for the
specification.
[optional]
This element may contain the name of the card type.
[optional]
This element may contain the version number of the card type.
[optional]
This element may contain information about the state of the present CardInfo file (e.g. ‘draft’).
[optional]
This element may contain the date of creation of the CardInfo file.
[optional]
© ISO/IEC 2014 – All rights reserved
5

---------------------- Page: 10 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
This element may contain the address of a CardInfo-repository, which may provide related CardInfo-
files.
Furthermore there may be some additional element, which structure is defined by some other specification.
The element is of type ProfilingType and describes the relation between the
basic specification and the present CardInfo file.

 
  
  
 


The three cases have got the following meaning:
⎯ extends – indicates that the present CardInfo file is just an extension of the basic specification. All
definitions in the basic specification remain valid and the new specifications in the CardInfo file just
extend them (e.g. a new card application).
⎯ redefines – indicates that the elements of the CardInfo file overwrite the according elements of
the basic specification. Elements of the basic specification not appearing in the CardInfo file
remain valid.

D.3.4 CardIdentification
The element, which is part of the CardInfoType, allows to determine the type of
a given card by traversing the decision tree and checking whether the characteristic features are as expected.


    type="iso:ATRType" />
    minOccurs="0" />
    minOccurs="0">
 
  
      type="iso:CardCallType" />
  
 
 
 




[optional, unbounded]
© ISO/IEC 2014 – All rights reserved
6

---------------------- Page: 11 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
1
For contact-based smart cards this element may contain information to the Answer To Reset (ATR) of
the card, allowing the realisation of a preselection of the card type. Further details are explained below.
[optional]
In an analogous way this element may contain information to the Answer To Select of a contactless smart
card, allowing the realisation of a preselection of the card type. Further details are explained below.
[optional, unbounded]
This element may contain a list of card calls, which can be used to determine the card type. The elements
of the list are of type CardTypeType. Further details are explained below.
Furthermore there may be some additional element, which structure is defined by some other specification.
The element of type ATRType is part of the element .

 
  
  
  
   
    
     
     
     
     
    
   
  
  
   
    
     
    
   
  
  
 


[required]
The element describes the first byte of the communication. This element is as many others of type
ByteMaskType which is explained below.
[required]
The element is of type ByteMaskTypeand describes the "format character" which shall indicate the
amount of historical bytes and the presence of the first interface bytes (TA1, TB1, TC1 and TD1).
[required]

1
Because there are several protocols for contact smart cards (e.g. T=0 and T=1) which can be supported by the same
card it is possible that one card has several ATRs. All of these ATR elements could be used for a preselection of the card
type (using a disjunction).
© ISO/IEC 2014 – All rights reserved
7

---------------------- Page: 12 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
This element shall contain the interface bytes which are included in the ATR. The elements ,
i∈{1,2,3,4 } are of type ATRInterfaceBytesType. This type is explained below.
[optional]
This element contains the historical bytes as a sequence of at most 15 bytes. Each element is of
type ByteMaskType(see below) which also describes the significant part of the byte to identify the card
type.
[optional]
This element of type ByteMaskType may contain the check sum of all bytes of the ATR beginning with
T0.
The ByteMaskType consists of a hexadecimal value and a corresponding mask which results in the
significant part of the value when a logical AND is performed on value and mask.

 
  
  
 


If the whole byte is significant the mask 'FF' has to be used. To get the first half byte the mask has to be 'F0',
for the second half byte '0F'. If only the first bit is significant the mask would be '80' and so on.
The type ATRInterfaceBytesType is used by the elements of the element .
This type consists of four elements , x∈{A,B,C,D}. Each of these elements is of type ByteMaskType
(see above) which also describes the significant part of the byte.

 
  
  
  
  
 


The element of type ATSType is part of the element Answer To Select of contactless smart cards.

 
  
  
  
  
   
    
     
    
   
  
  
  
© ISO/IEC 2014 – All rights reserved
8

---------------------- Page: 13 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
 


[required]
The element contains the length of the ATS including the TL byte itself but excluding CRC1 and
CRC2. This element is of type ByteMaskTypewhich also describes the significant part of the byte.
[required]
The element contains the Frame Size for proximity Card Integer (FSCI) and also indicates the
presence of interface bytes in the ATS. This element is of type ByteMaskType which also describes the
significant part of the byte.
[required]
This element contains the interface bytes which could be included in the ATS. The element is of type
ATSInterfaceBytesType which is explained below.
[optional]
This element contains the historical bytes as a sequence of at most 15 bytes. Each element is of
type ByteMaskType which also describes the significant part of the byte to identify the card type.
, [required]
These two elements of type ByteMaskType can contain the check sum of all bytes of the ATS beginning
with TL.
The following type ATSInterfaceBytesType is used by the element of the element
. This type consists of three elements , x∈{A,B,C}. Each of these elements is of type
ByteMaskType which also describes the significant part of the byte.

 
  
  
  
 


A list of elements of the type CardCallType is used to describe the characteristic features of the card in the
element. While the CardCallType is defined in the protocol related schema
definition it is explained here to ease reading.


 
    maxOccurs="unbounded" minOccurs="1" />



[required]
© ISO/IEC 2014 – All rights reserved
9

---------------------- Page: 14 ----------------------
ISO/IEC 24727-3:2008/Amd.1:2014(E)
This element contains the command APDU to be sent to the card. For security reasons APDUs with CLA
values ‘0x’ or ‘1x’, x∈{0,…,9, A,…,F} and INS values ‘20’, ‘21’, ‘24’, ‘2C’, and ‘22’ SHOULD NOT be used,
because these values would correspond to the commands CHANGE REFERENCE DATA, RESET
RETRY COUNTER und MANAGE SECURITY ENVIRONMENT. With these commands an attacker could
use the card identification to increase the retry counter of the card which could result in a denial of service
attack. Such commands shall be blocked if the element is not signed by a
trustworthy authority.
[required]
This element contains the response of the smart card to the command APDU. If the response
corresponds to the given value in the Ca
...

DRAFT AMENDMENT ISO/IEC 24727-3:2008/DAM 1
ISO/IEC JTC 1 Secretariat: ANSI

Voting begins on Voting terminates on
2012-04-23 2012-09-23
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION • МЕЖДУНАРОДНАЯ ОРГАНИЗАЦИЯ ПО СТАНДАРТИЗАЦИИ • ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION • МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОММИСИЯ • COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE


Identification cards — Integrated circuit card programming
interfaces —
Part 3:
Application interface
AMENDMENT 1
Cartes d'identification — Interfaces programmables de cartes à puce —
Partie 3: Interface d'application
AMENDEMENT 1
ICS 35.240.15


To expedite distribution, this document is circulated as received from the committee
secretariat. ISO Central Secretariat work of editing and text composition will be undertaken at
publication stage.
Pour accélérer la distribution, le présent document est distribué tel qu'il est parvenu du
secrétariat du comité. Le travail de rédaction et de composition de texte sera effectué au
Secrétariat central de l'ISO au stade de publication.


THIS DOCUMENT IS A DRAFT CIRCULATED FOR COMMENT AND APPROVAL. IT IS THEREFORE SUBJECT TO CHANGE AND MAY NOT BE
REFERRED TO AS AN INTERNATIONAL STANDARD UNTIL PUBLISHED AS SUCH.
URPOSES,
IN ADDITION TO THEIR EVALUATION AS BEING ACCEPTABLE FOR INDUSTRIAL, TECHNOLOGICAL, COMMERCIAL AND USER P
DRAFT INTERNATIONAL STANDARDS MAY ON OCCASION HAVE TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL TO BECOME
STANDARDS TO WHICH REFERENCE MAY BE MADE IN NATIONAL REGULATIONS.
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT, WITH THEIR COMMENTS, NOTIFICATION OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPORTING DOCUMENTATION.
International Organization for Standardization, 2012
©
International Electrotechnical Commission, 2012

---------------------- Page: 1 ----------------------
ISO/IEC 24727-3:2008/DAM 1

Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted
under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be
reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic,
photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to either ISO at the address below or ISO's
member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO/IEC 2012 — All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 24727-3 AMD:1
Contents Page
Foreword. iv
Introduction . v
Annex D .………………………………………………………………………………………….………………….….2
Annex E ………………………………………………………………………………………………….……………….40
Annex F ……………………………………………………………………………………….………………………….85

© ISO/IEC 2012 — All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 24727-3 AMD:1
Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 24727-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and personal identification.
ISO/IEC 24727 consists of the following parts, under the general title Identification cards — Integrated circuit
card programming interfaces:
 Part 1: Architecture
 Part 2: Generic card interface
 Part 3: Application interface
 Part 4: Application programming interface (API) administration
 Part 5: Testing
 Part 6: Registration authority procedures for the authentication protocols for interoperability

iv © ISO/IEC 2012 — All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 24727-3 AMD:1
Introduction
ISO/IEC 24727 is a set of programming interfaces for interactions between integrated circuit cards (ICCs) and
external applications to include generic services for multi-sector use. The organization and the operation of
the ICC conform to ISO/IEC 7816-4.
ISO/IEC 24727 is relevant to ICC applications desiring interoperability among diverse application domains.
This part of ISO/IEC 24727 specifies a language-independent and implementation-independent application
level interface that allows information and transaction interchange with a card. ISO/IEC 7498-1 is used as the
layered architecture of the application interface. That is, the application interface assumes that there is a
protocol stack through which it will exchange information and transactions among cards using commands
conveyed through the message structures defined in ISO/IEC 7816. The semantics of commands accessed
by the application interface refers to application protocol data units (APDUs) as characterized in
ISO/IEC 24727-2, and in the following standards:
 ISO/IEC 7816-4, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
 ISO/IEC 7816-8, Identification cards — Integrated circuit cards — Part 8: Commands for security
operations
 ISO/IEC 7816-9, Identification cards — Integrated circuit cards — Part 9: Commands for card management
The goal of this part of ISO/IEC 24727 is to maximize the applicability and solution space of software tools
that provide application interface support to card-aware applications. This effort includes supporting the
evolution of card systems as the cards become more powerful, peer-level partners with existing and future
applications while minimizing the impact to existing solutions conforming to this part of ISO/IEC 24727.
ISO/IEC 24727-2 standardizes the use of ISO/IEC 7816-15 data structures as "discovery information" that is
communicated throughout the ISO/IEC 24727 stack. This proposed amendment shall enhance the definition
of the use of ISO/IEC 7816-15 to fully link the entities defined at the Service Access Layer (API) (e.g.
Differential Identity, Authentication Protocol) with typical "on-card" entities such as keys, files and Access
Control Rules. Examples shall be provided.
XML encodings have become more and more used in the field of IAS [Identity, Authentication and (digital)
Signature] Identity Management and general networking communication. To enhance interoperability with
existing networking systems and federated identification and authorization systems (e.g. SAML, OpenID, etc.)
standardization of an XML representation of the API and data structures of ISO/IEC 24727-3 is essential.
*This new work item proposal is one of three new work item proposals on the ISO/IEC 24727 series of
standards that are envisioned to be developed in parallel.
© ISO/IEC 2012 — All rights reserved v

---------------------- Page: 5 ----------------------
ISO/IEC 24727-3 AMD:1
Identification cards — Integrated circuit card programming
interfaces —
Part 3:
Application interface
AMENDMENT 1
All new or changed text in this amendment is underlined in the clauses being replaced. All removed text will
show with a strike-through. When merging all such text into the base standard, the underlining is to be
removed and any words showing a strike-through should be removed. In the case of entirely new annexes
relative to the base standard will be so indicated by a statement at the beginning of the annex. In that case,
the “underline” convention will NOT be used. Rather, it is to be interpreted that the entire annex wording is to
be merged into the base document.
Scope
This part of ISO/IEC 24727 defines services as representations of action requests and action responses to be
supported at the client-application service interface. The services are described in a programming-language-
independent way.
This part of ISO/IEC 24727 is the application interface of the Open Systems Interconnection Reference Model
defined in ISO/IEC 7498-1. It provides a high-level interface for a client-application making use of information
storage and processing operations of a card-application as viewed on the generic card interface.
This part of ISO/IEC 24727 does not mandate a specific implementation methodology for this interface.
ISO/IEC 24727-3 AMD 1 extends the scope of ISO/IEC 24727-3 in the following ways:
1. Make explicit (normative and informative elements, including examples) of the use of the 7816-15-
based Registry. ref wg4n2231 XML representation of the 24727-3 API including appropriate web
service bindings specified as WSDL-structure. ref wg4n2232
2. Reaffirm that ASN.1 is the central definition of the API and data structures. All other bindings and
representations are derived from ASN.1
3. ASN.1 and XML representations for 24727-3 shall reside in this part, which may necessitate movement
of text/annexes from other parts of 24727 (i.e. 24727-2 and 24727-4 and 24727-5).
4. As a result of Amendments under development for other parts of 24727, portions of this standard may
be deleted and referenced.
5. Add to this standard the ISO/IEC 7816-13 application management and life cycle concepts.
6. Add a discovery mechanism to the API to indicate messaging is either ASN.1 or XML.
7. Enhance a Registry facility through which the SAL can record its use of the GCI and through which the
GCI mechanisms can be conveyed to the SAL.
8. Consider enhancements to the API to resolve technical deficiencies.
9. Remove ambiguities by elaborating and re-specifying concepts that may not be clear in the current
standard.
10. Incorporate concepts that are captured in other parts of ISO/IEC 24727 but are more relevant for
ISO/IEC 24727-3.
11. Include C and Java bindings in a Normative Annex ( C ) and an Informative Annex(Java).
© ISO/IEC 2012 — All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/IEC 24727-3 AMD:1
12. Pursue additional mechanisms for discovery and (card and application) capability description based
e.g. on XML representations as part the development of a more comprehensive Registry. This XML is
restricted to a set of instructions that enable card recognition for legacy cards.




2 © ISO/IEC 2012 — All rights reserved

---------------------- Page: 7 ----------------------
ISO/IEC 24727-3 AMD:1
Annex D
Web Services Interface Description
[Normative]
This annex is a new addition to ISO/IEC 24727-3.
D.1 - Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Amendment 1 to ISO/IEC 24727-3:2008 was prepared by Joint Technical Committee ISO/IEC JTC 1,
Identificaation cards - integrated circuit card programming interfaces, Subcommittee SC 17, Application
interface.
• Clause D.2 contains information for the connection establishment for web service based SAL-
communication.
• Clause D.3 contains an XML-based CardInfo-Structure, which facilitates the support of legacy cards.
• Clause D.4 contains the XML-specification for the XML-based Service Access Layer Interface
D.2 Connection handling for web service based communication
This clause describes the connection handling for web service based communications in an ISO/IEC 24727-
based environment.
D 2.1 General security requirements
The security requirements of ISO/IEC 24727 dictate that the TLS protocol in accordance with RFC 4346 shall
be used.
Moreover, public server services shall have access to corresponding X.509 certificates.
When it comes to the security of the communication between the different modules realizing the ECC-3 stack
consisting of Service Access Layer (SAL) and IFD Layer), however, X.509 certificates shall be used, whereby
the associated private keys shall be adequately protected. Alternatively, anonymous TLS cipher suites, such
as TLS_DH_anon from RFC 4346 or TLS_ECDH_anon from RFC 4492, shall be used, although appropriate
security measures need to be taken in the operational environment in order to avert man-in-the-middle attacks
while the connection is being established.
In both cases there shall be an exclusive binding of the communication context at application level to the TLS
channel which has been established in this process. This communication context is established on connection
to the IFD-Layer via the function EstablishContext and represented by the ContextHandle. When
© ISO/IEC 2012 — All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/IEC 24727-3 AMD:1
connecting to the SAL, this communication context corresponds to a connection to the card application
established by means of CardApplicationConnect, which is represented by a ConnectionHandle.
As such, one single TLS channel shall be sufficient to establish communication between a SAL and the IFD
layer — irrespective of the number of card terminals and connected cards — whereas a separate TLS channel
shall be required for every connection to a card application for communication to take place between the
identity layer or the application layer and the SAL.
D.2.2 Connections for SOAP binding
When using the SOAP binding, the connection shall be established simply by setting up a TLS-protected
channel between the user of the web service (service consumer) and the provider of the web service (service
provider) via which web service messages can henceforth be exchanged. In this case the service consumer
and service provider take the roles of TLS/http client and TLS/http server, respectively.
D.2.3 Connections for PAOS binding
When using the PAOS binding, however, a more complex process shall be required to establish the
connection as, in this case, the TLS/http server acts as the user of the web service (service consumer) with
eService because the TLS/http client acts as the provider of the web service (service provider) and shall
initiate the connection.
Moreover, in this case there are typically two different TLS channels, and appropriate cryptographic
mechanisms shall be used to safeguard their logical relationship while the connection is established.
An example general connection sequence is illustrated in Figure D1.
eService SAL Dispatcher Dispatcher SAL Client App
Network
TLS
HTTPS REQUEST
�
HTTPS RESPONSE with REDIRECT to localhost with URL-encoded TC _API_Open(SrvAddr,SessionID,PAOS,{PathSecurity})
� �
TC_API_Open (localhost,SessionID,PAOS,.)
URL-encoded TC _API_Open(.)
PAOS Connection
�
�
WaitForRequest(SessionID,PAOS,.) Establishment
Establish PAOS connection()
Establish Channel
Details depending on PathSecurity
GET .PAOS/EstablishConnection
5
response
return
return
return ch2cl
return ch2srv
CardApplicationPath (.)
Application Logic
WS REQUEST
GET .PAOS/GetNextCommand
GET RESPONSE incl. CardApplicationPath
CardApplicationPath (.)
�
return path
POST ./GetNextCommand incl. CardApplicationPathResponse
WS RESPONSE
CardApplicationPathResponse (.)
CardApplicationConnect (.)
WS REQUEST
POST RESPONSE incl. CardApplicationConnect
CardApplicationConnect (.)
return connection handle
POST incl. CardApplicationConnectResponse
WS RESPONSE
CardApplicationConnectResponse (.)

Figure D1 — Example of a general connection process with PAOS binding
4 © ISO/IEC 2012 — All rights reserved

---------------------- Page: 9 ----------------------
ISO/IEC 24727-3 AMD:1
D.3 XML-based CardInfo-Structure for support of legacy cards
D.3.1 Introduction
In order to use the generic Service Access Layer (SAL) interface defined in this standard with legacy cards, it
shall be necessary to provide a certain set of information, which allows to map the generic calls at the SAL to
card-specific APDUs.
The XML-schema introduced in this clause defines a structure that shall both be used for the specification of
card profiles and for the mapping of generic calls at the Service Access Interface to card-specific APDUs of
legacy cards.
The rest of this annex is structured as follows: Clause D.3.2 provides an overview of the defined structure and
explains the top-level element . The following clauses D.3.3 through D.3.7 describe the various
child-elements of , Clause E.7 contains the complete XML-schema-definition
D.3.2 Overview
The CardInfo structure shall be used for the specification of card profiles and for the mapping of generic
requests at the Service Access Layer to card-specific APDUs in case of legacy cards, which are not equipped
with appropriate ACD and CCD structures according to ISO/IEC 24727-2.
Each card profile shall be described by a element


of type CardInfoType which shall be defined as follows:




type="iso:CardCapabilitiesType" maxOccurs="1" minOccurs="0" />
type="iso:ApplicationCapabilitiesType" maxOccurs="1" minOccurs="0" />
type="ds:SignatureType" maxOccurs="unbounded" minOccurs="0" />





[required]
Contains a unique identifier for the card type and optionally further links to specification documents.
Further details are explained in Clause 0.
[required]
Allows to determine the type of a given card by traversing an appropriate decision tree and checking
whether the characteristic features are as expected. Further details are explained in Clause 0.
[optional]
Allows to specify the capabilities of the card. If the card is fully conformant to ISO/IEC 7816 this element
MAY be omitted. Further details are explained in Clause 0.
© ISO/IEC 2012 — All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/IEC 24727-3 AMD:1
[optional]
Allows to specify the card-applications on the card and shall be used to realize the mapping from SAL-
calls to card-specific APDUs. If the necessary information for this mapping is available on the card in
adequate CIA-information structures according to ISO/IEC 7816-15 (see Clause 7.5) this element may be
omitted. Further details are explained in Clause 0.
[optional]
Shall be used to protect the integrity and authenticity of (parts of) the CardInfo-element. Further details are
explained in Clause D.3.3.
D.3.3 CardType
The element in the CardInfoType is of type CardTypeType and contains a unique identifier
for the card type and optionally further links to specification documents. It is specified as follows:











type="string" maxOccurs="1" minOccurs="0" />


















This type defines the following elements and attributes:
[optional]
This element shall contain information about a basic specification ( element)
which is extended, profiled or redefined (cf. element below) by the present
CardInfo structure. Using this element it shall be possible to re-use existing CardInfo-structures in a
modular approach.
[required]
This element shall contain the unique identifier of the card type, which MAY be the object identifier of a
profile defined in Part 4 of the present standard.
6 © ISO/IEC 2012 — All rights reserved

---------------------- Page: 11 ----------------------
ISO/IEC 24727-3 AMD:1
[optional]
This element may be used to specify the card issuer or the organization, which is responsible for the
specification.
[optional]
This element may contain the name of the card type.
[optional]
This element may contain the version number of the card type.
[optional]
This element may contain information about the state of the present CardInfo file (e.g. ‘draft’).
[optional]
This element may contain the date of creation of the CardInfo file.
[optional]
This element may contain the address of a CardInfo-repository, which may provide related CardInfo-
files.
Furthermore there may be some additional element, which structure is defined by some other specification.
The element is of type ProfilingType and describes the relation between the
basic specification and the present CardInfo file.







The three cases have got the following meaning:
 extends – indicates that the present CardInfo file is just an extension of the basic specification. All
definitions in the basic specification remain valid and the new specifications in the CardInfo file just
extend them (e.g. a new card application).
 redefines – indicates that the elements of the CardInfo file overwrite the according elements of
the basic specification. Elements of the basic specification not appearing in the CardInfo file
remain valid.

D.3.4 CardIdentification
The element, which is part of the CardInfoType (cf. Clause 0), allows to
determine the type of a given card by traversing the decision tree and checking whether the characteristic
features are as expected.


© ISO/IEC 2012 — All rights reserved 7

---------------------- Page: 12 ----------------------
ISO/IEC 24727-3 AMD:1
type="iso:ATRType" />
minOccurs="0" />
minOccurs="0">


type="iso:CardCallType" />








[optional, unbounded]
1
For contact-based smart cards this element may contain information to the Answer To Reset (ATR) of
the card, allowing the realisation of a preselection of the card type. Further details are explained below.
[optional]
In an analogous way this element may contain information to the Answer To Select of a contactless smart
card, allowing the realisation of a preselection of the card type. Further details are explained below.
[optional, unbounded]
This element may contain a list of card calls, which can be used to determine the card type. The elements
of the list are of type CardTypeType. Further details are explained below.
Furthermore there may be some additional element, which structure is defined by some other specification.
The element of type ATRType is part of the element .
























1
Because there are several protocols for contact smart cards (e.g. T=0 and T=1) which can be supported by the same
card it is possible that one card has several ATRs. All of these ATR elements could be used for a preselection of the card
type (using a disjunction).
8 © ISO/IEC 2012 — All rights reserved

---------------------- Page: 13 ----------------------
ISO/IEC 24727-3 AMD:1


[required]
The element describes the first byte of the communication. This element is as many others of type
ByteMaskType which is explained below.
[required]
The element is of type ByteMaskTypeand describes the "format character" which shall indicate the
amount of historical bytes and the presence of the first interface bytes (TA1, TB1, TC1 and TD1).
[required]
This element shall contain the interface bytes which are included in the ATR. The elements ,
i∈{1,2,3,4 } are of type ATRInterfaceBytesType. This type is explained below.
[optional]
This element contains the historical bytes as a sequence of at most 15 bytes. Each element is of
type ByteMaskType(see below) which also describes the significant part of the byte to identify the card
type.
[optional]
This element of type ByteMaskType may contain the check sum of all bytes of the ATR beginning with
T0.
The ByteMaskType consists of a hexadecimal value and a corresponding mask which results in the
significant part of the value when a logical AND is performed on value and mask.







If the whole byte is significant the mask 'FF' has to be used. To get the first half byte the mask has to be 'F0',
for the second half byte '0F'. If only the first bit is significant the mask would be '80' and so on.
The type ATRInterfaceBytesType is used by the elements of the element ...