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

Identification cards — Integrated circuit card programming interfaces — Part 4: Application programming interface (API) administration — Amendment 1

Cartes d'identification — Interfaces programmables de cartes à puce — Partie 4: Administration d'interface de programmation (API) — 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: 24-Mar-2014
• Completion Date: 01-Jan-2014

Relations

• Amends: ISO/IEC 24727-4:2008 - Identification cards — Integrated circuit card programming interfaces — Part 4: Application programming interface (API) administration
• Effective Date: 27-Nov-2021

Standards Content (Sample)

DRAFT AMENDMENT ISO/IEC 24727-4: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 4:
Application programming interface (API) administration
AMENDMENT 1
Cartes d'identification — Interfaces programmables de cartes à puce —
Partie 4: Administration d'interface de programmation (API)
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.
R PURPOSES,
IN ADDITION TO THEIR EVALUATION AS BEING ACCEPTABLE FOR INDUSTRIAL, TECHNOLOGICAL, COMMERCIAL AND USE
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

ISO/IEC 24727-4: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

ISO/IEC 24727-4 AMD:1
Contents Page
Foreword. iv
Introduction . v
Scope ………………………………………………………………….…………………………………………………7
Annex D ………………………………………………………………………………………………………………….
Annex E API for ISO/IEC 7816-15 data structures handling [Informative]. 29
Annex H Translation ASN.1 Module [Informative]. 110

© ISO/IEC 2012 — All rights reserved                                   iii

ISO/IEC 24727-4 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-4 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

ISO/IEC 24727-4 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 ICCs conform to ISO/IEC 7816-4.
ISO/IEC 24727 is relevant to ICC applications desiring interoperability among diverse application domains.
ISO/IEC 7498-1:1994 is used as the layered architecture of the client-application to card-application
connectivity. That is, the client-application, through the application interface, assumes that there is a protocol
stack through which it will exchange information and transactions among card-applications using commands
conveyed through the message structures defined in ISO/IEC 7816. The semantics of action requests through
the interface defined in ISO/IEC 24727-3 refers to application protocol data units (APDUs) as characterized
through the interface defined in ISO/IEC 24727-2, and in the following International Standards:
 ISO/IEC 7816-4:2005, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
 ISO/IEC 7816-8:2004, Identification cards — Integrated circuit cards — Part 8: Commands for security
operations
 ISO/IEC 7816-9:2004, Identification cards — Integrated circuit cards — Part 9: Commands for card
management
The goal of ISO/IEC 24727 is to maximize the applicability and solution space of software tools that provide
application interface support to card-aware client-applications. This effort includes supporting the evolution of
card systems as they become more powerful, peer-level partners with existing and future applications while
minimizing the impact to existing solutions conforming to ISO/IEC 24727.
By conforming to this part of ISO/IEC 24727, interoperable implementations of ISO/IEC 24727-3 and
ISO/IEC 24727-2 can be realized. Implementation details are not defined within this part of ISO/IEC 24727; it
is assumed that an implementation conforms to an accepted security policy. The specific security policy is
outside the scope of ISO/IEC 24727
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.
In order to support this addition to the ISO/IEC 24727-3 scope, the relevant stack configurations in ISO/IEC
24727-4 shall be updated and/or amended. The rules governing the use of various marshalling/un-marshalling
procedures shall be aligned with the amendment to ISO/IEC 24727-3.
© ISO/IEC 2012 — All rights reserved                                   v

ISO/IEC 24727-4 AMD:1
Identification cards — Integrated circuit card programming
interfaces —
Part 4:
Application programming interface (API) administration
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.
[Editor’s Note: A hybrid numbering scheme for new figures and tables is used (e.g. Figure 7-1) in order to fit
more seamlessly with the original document; i.e. to NOT require many modifications to simply change figure
and table numbers.]
1 Scope
ISO/IEC 24727 defines a set of programming interfaces for interactions between integrated circuit cards and
external applications to include generic services for multi-sector use.
This part of ISO/IEC 24727 standardizes the connectivity and security mechanisms between the client-
application and the card-application.
It specifies API-Administration of service-independent and implementation-independent ISO/IEC 24727
compliant modules, including security, that enables action requests to a specific card-application of an ICC
such that, when coupled to data model and content discovery operations, the card-application can be used by
a variety of client-applications.
1. Extend and update as necessary the stack configurations to address the XML representation such
that it is compatible with the relevant XML-based standards (e.g. SAML).
2. Clarify use of secure messaging.
3. As a result of Amendments under development for other parts of 24727, portions of this standard may
be deleted and referenced.
4. Consider additional forms of secure messaging and consider separating the security of information
transferred across a general network versus security of information transferred across the card
interface.
5. Refine TC_API to allow channel initiation for various mechanisms; e.g. web service communication
(SOAP PAOS), AJAX.
6. Update the current XML specifications to align with ISO and not import 3 party schemas e.g. OASIS.
7. Remove ambiguities by elaborating and re-specifying concepts that may not be clear in the current
standard.
© ISO/IEC 2012 — All rights reserved                                   vii

ISO/IEC 24727-4 AMD:1
8. Incorporate concepts that are captured in other parts of ISO/IEC 24727 but are more relevant for
ISO/IEC 24727-4.
9. Include C and Java bindings in a Normative Annex (for C) and an Informative Annex (Java); moved
from Part 5
10. Consider relocating data structure generation to the local machine level; e.g. remote ICC Stack

viii © ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
This clause is a new addition to ISO/IEC 24727-4.
5.7 Extensions of the Service Access Layer
5.7.1 Extensions under ISO/IEC 7816-15
This clause comprises an enhancement of the functionality assigned to the local platform through which is
accessed the card-application. In so doing, it re-uses the existing ISO/IEC 24727-4 middleware stack
configurations with only a change bearing upon the location of the component handling ISO/IEC 7816-15 -
based registry. The main objective being to alleviate the workload of the client-application platform by
supplying it upon request with pre-built data structures for interoperability (ISO/IEC 24727-3).
5.7.2 SAL API Lite
ISO/IEC 24727-2 AMD 1 envisions explicit (normative and informative elements, including the use of the
ISO/IEC 7816-15 based Registry. As such, 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. To achieve
this discovery process, it is necessary to locate an ISO/IEC 7816-15 based Procedural Elements component
within the platform connected to the card-application for the Remote-ICC-stack and the Opaque-ICC-stack
(see Figure 7-1) as follows:
- This component is in charge of linking the entities defined at the Service Access Layer (API) (e.g.
Differential Identity, DataSet, DSI) with typical "on-card" entities such as keys, files and Access Control Rules.
Accordingly enabled with this Registry processing capability, this component is ONLY in charge of retrieving
the ISO/IEC 7816-15 based Registry, parsing it, and generating the interoperability data structures
representing the objects handled by the SAL API in conformance with ISO/IEC 24727-3.
- this component is part of a SAL API Lite implementation that implements a subset of existing SAL API herein
called SAL API Lite
- the SAL API Lite is comprised ONLY of the the SAL API functions that serve to retrieve data structures for
interoperability as DataSet, DSI, DID, ACL, etc. to supply it to the client-application upon request.

5.7.3 SAL API Lite Supported Requests:
The SAL API Lite interface provides a subset of the full ISO/IEC 24727-3 API. Specifically included are the
following requests:
• CardApplicationConnect(),
• CardApplicationList(),
• CardApplicationServiceList(),
• CardApplicationServiceDescribe(),
• DataSetList(),
• DataSetSelect(),
• DSIList(),
© ISO/IEC 2012 — All rights reserved                                   ix

ISO/IEC 24727-4 AMD:1
• DSIRead(),
• DIDList(),
• DIDGet(),
• ACLLIst()
The SAL API Lite requests are limited in the following ways:
5.7.3.1 Registry Delegation
The Service Access Layer implemented on the same platform as the client-application shall delegate the
Registry processing capability to the SAL API Lite implementation.
5.7.3.2 Registry Bootstrap
The SAL API Lite implementation shall start the ISO/IEC 7816-15 based Registry processing at bootstrap and
save processing time to the Service Access Layer implementation by making available all the data structures
defined at SAL API Lite interface.

5.7.3.3 Registry Connection
The SAL API Lite implementation shall provide to the application running on a local machine to which the
card-application is connected e.g to allow for GUI to expose the user all or part of his on-card ISO/IEC 7816-
15 based Registry.
5.7.3.4 ICC-Resident-Stack Exclustion
The SAL API Lite component does not fit in an ICC-Resident-stack for the following reasons: the SAL-Agent is
located on-card and not visible to the outside world, and additionally, on ICC-Resident-stack, the data
structures for interoperability can be built-in structures already available on-card, so they do not need to be
derived from a ISO/IEC 7816-15 based Registry.
5.7.3.5 Static Library Option
Optionally, the SAL API Lite implementation may rely on a static or dynamic library to explore the on-card
ISO/IEC 7816-15 based Registry. To this intent, informative Annex E is proposed with a comprehensive
description and binding for an API typically handling on-card ISO/IEC 7816-15 based Registry.
Figure 7-1 illustrates a Full Network Stack that makes use of a SAL API Lite registry facility. In addition, this
figure illustrates the use of a procedural element that can translate the formal language representation of the
ISO/IEC 24727-3 API functions directly into card specific APDUs. The only required ISO/IEC 24727-2 GCI
APDU is the ENVELOPE APDU. The contents of the ENVELOPE APDU can be, for example, DER-TLV
represented API functions. Thus, the procedural elements can function as a full Service Access Layer.
x © ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
Figure 7-1 —Network stack
5.7.4 Secure Messaging
Within a stack configuration as shown in Figure 7-1, a client-application may establish an end-to-end secure
channel with a card-application. The secure APDU commands generated by the SAL implementation are
delivered as IFD API marshalled commands to the local host where the Interface Device Agent redirects them
to the Interface Device. The SAL API Lite component does not process secure APDUs. Accordingly,
whenever the ACL controlling the access to a data structure e.g. DataSet, requires secure messaging, the
transaction shall go through the following sequence :

1. client-application sends for the first time during a session a DataSetList call through SAL API
2. the API call is marshalled into either XML or DER-TLV and sent through TC to the SAL API Lite
component
© ISO/IEC 2012 — All rights reserved                                   xi

ISO/IEC 24727-4 AMD:1
3. the SAL API Lite builds the requested data structure (i.e DataSetNameList) as part of the
DataSetListResult and returns it through TC layer to the SAL.
4. the SAL hands on the DataSetListResult to the client-application.
5. the client-application sends an ACLList call through SAL API with a parameter targetType denoting a
data-set and a parameter targetName related to a named DataSet that was retrieved from the just
received list of DataSetNameList (before this call, the client-application may optionally selects a
named DataSet and sends a DataSetSelect call through SAL API)
6. the API call is marshalled into either XML or DER-TLV and sent through TC to the SAL API Lite
component
7. the SAL API Lite builds the requested data structure (i.e AccessControlList) as part of the
ACLListResult and returns it to through TC layer to the SAL.
8. the SAL hands on the ACLListResult to the client-application.
9. the client-application parses the set of AccessRules contained in ACLListResult and figures out which
Differential-Identity is to be verified in order to get access to the DataSet contents (with the
assumption that the targetted DataSet is protected with a DID controlling access to its contents e.g
DIDRead requiring mutual authentication with establishment of secure messasing).
10. the client-application sends a DSIList call through SAL API
11. the API call is marshalled into either XML or DER-TLV and sent through TC to the SAL API Lite
component.
12. the SAL API Lite builds the requested data structure (i.e DSINameList) as part of the DSIListResult
and returns it to through TC layer to the SAL. in order to allow the client-application to read properly
the DSI contents, the SAL API Lite maps the DSI attributes onto on-card attributes; for this purpose
the SAL API Lite uses the Cryptographic Information Application (CIA or P15) to figure out the on-card
attributes related to each DSI in the DSIListResult. Alternatively, the SAL API Lite may send a
SELECT APDU command to the card with parameter P2 requesting the Control Parameter (CP)
Template (see ISO/IEC 7816-4); accordingly, a DO'98' within CP denotes DO instances, a DO'9B'
within CP denotes EF instances in either DF or ADF, and a DO'97' within CP denotes DF instances in
either DF or ADF. To map those on-card attributes onto DSI attributes, an additional parameter is
required in DSIListResult definition in ISO/IEC 24727-3 (see Annex below)
13. the SAL hands on the DSIListResult to the client-application
14. the client-application sends a DIDAuthenticate (according step 9 above) to fulfil the access rules
controlling the reading of DSI contents.
15. the SAL parses the DID requirements (i.e DIDName, DIDAuthenticationData) and starts the
authentication protocol with the card i.e SAL generates the appropriate APDU commands and send
them out to the card through IFD API and TC layer.
16. Once the end-to-end secure messaging is established between the card and the SAL, the SAL
delivers the API return code to the client-application
17. the client-application then sends a DSIRead call through the SAL API.
18. the SAL generates the corresponding APDU command conforming to DSI attributes received in step
12 above; then SAL secures the APDU commands with current session keys and sends it via the IFD
API, TC and Interface Device to the Card Application;
19. the SAL recovers the DSI contents and builds the dsiContent as part of the DSIReadResult, then
return it to the client-application.

Table 7-1 indicates the messages exchanged between SAL API and SAL API Lite during a transaction with
secure messaging :
xii © ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
Client- SAL IFD TC IFD SAL API Lite IFD Card-
Application Proxy Agent Application
Registry
processing
DataSetList DataSetList DataSetList
�������� �������� ��������
DataSetSelect DataSetSelect DataSetSelect
�������� �������� ��������
ACLList ACLList ACLList
�������� �������� ��������
DSILIst DSILIst DSILIst
�������� �������� ��������
(*)
DIDAuthenticate APDU C-RP
�������� �������� �������� �������� ��������

����                   SECURE MESSAGING                           ����
DSIRead APDU C-RP
�������� �������� �������� ��������    ��������

Table 7-1 – Command Progression
(*) APDU C-RP = APDU command-response pair i.e GET DATA or READ BINARY

© ISO/IEC 2012 — All rights reserved                                   xiii

ISO/IEC 24727-4 AMD:1
This clause is a new addition to ISO/IEC 24727-4.
8 Registry Implementations
8.1 ISO/IEC 7816-15 registry implementation
To achieve interoperability among various Service Access Layer implementations, it is necessary to record the
mechanisms used to translate between ISO/IEC 24727-3 API functions and ISO/IEC 24727-2 GCI APDUs.
This clause defines how to prepare this record in the form of an ISO/IEC 7816-15 formatted Registry.
Included is the representation of ISO/IEC 24727-3 Card-Application discovery information as an ISO/IEC
7816-15 Cryptographic Information Application.
The ISO/IEC 7816-15 representation of an ISO/IEC 24727 card-application contains all the information that
the ISO/IEC 24727-2, ISO/IEC 24727-3 implementations need to realize the ISO/IEC 24727 specified
interoperable connection between the client-application and the card-application.
Data Structures for Interoperability are discovery information made available to the SAL by the card through
the bootstrap mechanism, unless it is provided by other means. The SAL API or the SAL API Lite shall
undertake the processing of the discovery information in order to dynamically generate the data structures
defined in ISO/IEC 24727-3 as Access Control List, Differential-Identity, Data-Set and Data Structures for
Interoperability (DSI), and Card-Application Services and Actions. These data structures shall be surfaced to
the client-application upon request through the SAL API or the SAL API Lite.
To allow for coding of access control rules conforming to ISO/IEC 7816-15 implementation, a mapping of SAL
API actions onto ISO/IEC 7816-15 accessMode attributes is described. This mapping is laid on the extension
of accessMode according the second amendment of ISO/IEC 7816-15.
The information in the ISO/IEC 7816-15 representation of an ISO/IEC 24727 card-application is referred to
informally in ISO/IEC 24727-1 as the discovery information and in ISO/IEC 24727-4 as an ISO/IEC 7816-15
based Registry.
To implement the ISO/IEC 7816-15 based Registry, several ASN.1 definitions are available:

- Clause 8.1.3.1 establishes the ASN.1 types for translation of SAL API calls into card-specific APDU; the
APDU command parameters rendering each SAL API Action can be so determined by the issuer and
DER-TLV encoded then hosted on-card as part of the Cryptographic Information Application or on a
remote repository that can be accessible though the interface of which the XML-Binding is described in
Annex I [informative] “interoperable access to the repository”.

- Annex H[informative] illustrates the actual ASN.1 reference Module implementing clause 8.1.3.1.
Common ASN.1 types are imported from ISO 24727-3; only types newly designed in the Amendment are
defined within this module.
- Annex G[informative] illustrates application of the rules and guidelines described in clause 8.1.1 “ISO/IEC
24727-3 data structures mapping” to build an ISO/IEC 7816-15 based Registry for a fictitious service
called “myService”. In G.1.1.2.1, an ASN.1 value notation illustrates an implementation example;
accordingly, DER-encoding may be derived from this notation.

8.1.1 ISO/IEC 24727-3 data structures mapping
The data structures that may be surfaced to the client-application upon request are DataSet, DSI, ACL,
Differential-Identities, list of Card-Application Services, list of Differential-Identities.
xiv © ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
The SAL generates these data structures from the information available in CardApplicationServiceDescription
that is defined as an ASN.1 SEQUENCE of ISO/IEC 7816-15 CIAInfo value along with consecutive ISO/IEC
7816-15 CIOChoice(s) value(s).
The interpretation of CardApplicationServiceDescription value in terms of ACL, Differential-Identities, Services,
DataSet or DSI, is based on the mapping described in the following sub-clauses.

8.1.1.1 DataSet
Table 8-1 indicates the mapping of a DataSet onto a DataContainerObjectChoice and describes how the
DataSet's ACL can be derived from it. In this and following tables, an “X” in the “ACL items” column indicates
that this attribute may be controlled through an Access Control List (ACL) entry.
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
DataContainerObject- commonObjectAttributes.label DataSet X The label is ASCII
Choice Name encoded and shall
evaluate to 'DATA-SET'
used as a prefix
iso7816DO
denoting the target
type, concatenated with
commonObjectAttributes
the DataSet actual
name.
accessControlRule.accessMode Action Shall conform to Table
10 and Table 8-8
accessControlRule.securityCondition Ref to DID 1 authId referring to a
X
CIO within the
cryptographic
information application
(DF.CIA)
ClassAttributes classAttributes.applicationName  Either applicationName
or application OID of
© ISO/IEC 2012 — All rights reserved                                   xv

ISO/IEC 24727-4 AMD:1
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
the card-application
owning the DataSet.
Shall not be NULL.
TypeAttributes   NULL
ISO/iEC 7816 DO
container for the DSI(s)
within the DataSet
CommonObjectAttributes commonObjectAttributes.label DSIName The DSI Name shall be
ASCII encoded.
accessControlRule.accessMode DSI's accessRules are

controlled by DataSet
accessControlRule.securityCondition  DSI's accessRules are
controlled by DataSet
accessRules
ClassAttributes 
TypeAttributes efidOrTagChoice location of File Id or extended
the actual Path (acc. ISO/IEC
resource 7816-15:2004/AM2) to
(EF,DF, the DSI resource
ADF, DO)
hosting the
DSI content.
In case the action is controlled by a logical combination of DIDs, several consecutive securityCondition values may
provide different security conditions applying to the same access Mode denoting the SAL API action. The logical
operation combining the DIDs is AND or OR depending on the ASN.1 encoding of the securityContitions.

Table 8-1 — Mapping DataSet to ACL
The DIDs referenced by the access rules protecting a DataSet are either Authentication Information Objects or
Private Objects or Secret Key. Secret Key and Private Key mapping to Differential-Identities is presented in
subsequent tables.
8.1.1.2 CardApplication
xvi © ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
Table 8.2 shows the mapping of a CardApplication onto a DataContainerObjectChoice and describes how the
CardApplication's ACL can be derived from it.
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
DataContainerObject- commonObjectAttributes.label Card-Appli- X The label is ASCII
Choice cation Name encoded and shall
valuate to 'CARD-
APPLICATION' used
ISO/IEC 7816 DO
as a prefix denoting the
target type,
commonObjectAttributes
concatenated with the
CardApplication actual
name.
accessControlRule.accessMode SAL API SAL API actions shall
Action conform to value in
Table 10 and Table 8-8
X
accessControlRule.securityCondition Ref to DID May be authId referring
to a CIO within the
cryptographic
information application
(DF.CIA)
ClassAttributes classAttributes.applicationName  Either applicationName
or application AID.
Shall not be NULL.
TypeAttributes   NULL
ISO/IEC 7816 DO
container for each target
resource of the
CardApplication (DataSet
Name, DID Name)
CommonObjectAttributes commonObjectAttributes.label DataSet or The target name shall
DID Name be ASCII encoded with
a prefix denoting the
target type
concatenated with the
actual target name.
accessControlRule.accessMode Refer to the named

target
accessControlRule.securityCondition  Refer to the named
target
© ISO/IEC 2012 — All rights reserved                                   xvii

ISO/IEC 24727-4 AMD:1
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
ClassAttributes 
TypeAttributes efidOrTagChoice location of File Id or extended
the actual Path (acc. ISO/IEC
resource 7816-15:2004/AM2) to
(EF,DF, the named target
ADF, DO) resource
hosting the
named
target.
In case the Action is controlled by a logical combination of DIDs, several consecutive securityCondition values may
provide different security conditions applying to the same access Mode denoting the SAL API Action. The logical
operation combining the DIDs is AND or OR depending on the ASN.1 encoding of the securityConditions.

Table 8-2 — mapping CardApplication to DataContainerObjectChoice

xviii © ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
8.1.1.3 Service
Table 8.3 shows a possible alternative for the mapping of a Service onto a DataContainerObjectChoice But
since a Named Service is not a target, no ACL is attached to it according ISO/IEC 24727. Deriving ACL from
Named Service is not recommended by the present standard.
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
DataContainerObject- commonObjectAttributes.label Service Name X The Service Name
Choice shall be comprised
of ASCII coded
prefix 'SERVICE'
iso7816DO for the Service
concatenated with
the respective
commonObjectAttributes
Service Name
conforming to
ISO/IEC 24727-3
naming rules
accessControlRule.accessMode SAL API Action two supported
Actions for
Authorization
Service :
ACL_LIST,
ACL_MODIFY
encoding shall
conform to Table 10
and Table 8-8
X
accessControlRule.securityCondition Ref to DID authId.
ACL_LIST may
valuate to
ALWAYS.
authId is the cross-
reference to an
Authentication
Object protecting
the current CIO
ClassAttributes applicationName  applicationName
or/and application
OID. Shall not be
NULL. It gives the
location of the
© ISO/IEC 2012 — All rights reserved                                   xix

ISO/IEC 24727-4 AMD:1
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
applicationOID  executable code
implementing the
named Service
within the card
application.
TypeAttributes   NULL
iso7816DO container for
the Actions within the
Service
CommonObjectAttributes commonObjectAttributes.label  The Action Name
Action Name shall conform to
ISO/IEC 24727-3
naming rules. If
present, it clears
ambiguity for SAL
API actions sharing
the same
AccessMode byte
value.
accessControlRule.accessMode SAL API Action Shall conform to
Table 10 and Table
8-8
authId. this is the
accessControlRule.securityCondition Ref to DID ACL
cross-reference to
an Authentication
Object protecting
the current CIO
ClassAttributes applicationName  The
applicationName
or/and application
applicationOID
OID shall not be
NULL. It gives the
location of the
xx © ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
CommonDataContainerObjectAttributes.iD Ref to a CIO location of the
executable code
implementing the
named Service
within the card
application.
The iD may be used
to associate the
current data
container object
with some other
CIO ( e.g.: a private
key information
object, a public key
information object, a
certificate
information object, a
secret key
information object)
TypeAttributes efidOrTagChoice location of the File Id or Path to the
cryptographic CIA directory file
information containing the CIO
object executing referenced by the
the Action (e.g : ClassAttributes.iD
a PrK for a above
SIGN action)
This ACL is for Authorization Service that applies for all card-application services.

This ACL relates to a specific Action within the card-application named Service
Table 8-3 — mapping Service to ACL

8.1.1.4 Differential-Identity
In the context of ISO/IEC 24727-3, Differential-Identities are used to describe objects for authentication and
cryptographic usage. As a consequence, ISO/IEC 7816-15 AuthenticationObjectChoice structures are used to
describe differential identities with the focus on authentication.
KeyObjectChoice structures shall be used to qualify differential identities which should mainly be used for the
cryptographic methods (e.g. Encipher, Decipher, Sign).
© ISO/IEC 2012 — All rights reserved                                   xxi

ISO/IEC 24727-4 AMD:1
8.1.1.4.1 Differential-Identities for authentication
The structure of a differential identity is heavily depending on the used authentication protocol. The marker
and qualifier structures are only known after the authentication protocol has been identified. Therefore, the
first step in the discovery mechanism is to retrieve the correct value for the authentication protocol while
parsing the service description of the Application Capability Descriptor.
The discovery mechanism for the authentication protocol value is shown in Figure 8-1. The mechanism is
starting with parsing the AuthenticationObjectChoice. At the beginning, the TypeAttributes of the
AuthenticationObjectChoice can be determined. If the TypeAttributes are PasswordAttributes or
BiometricAttributes, the type of the authentication protocol shall be either the PIN Compare or the Biometric
Compare protocol.
In case the TypeAttributes are ExternalAuthObjectAttributes, it has to be investigated which choice was made
for the ExternalAuthObjectAttributes:
 If CertBasedAuthenticationAttributes are used, the protocol shall be the Asymmetric External
Authenticate protocol,
 In the case AuthKeyAttributes are used, it's the Symmetric External Authenticate Protocol unless
otherwise specified by the related objId : the corresponding AlgorithmInfo within the CIAInfo structure of
the adequate application shall be used to retrieve the objId. If the equivalent non DER-TLV encoded
value of this objId is starting with "1 0 24727 3", the value shall be directly used to determine the
authentication protocol value.
xxii © ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
parse AuthenticationObjectChoice
Investigate TypeAttributes of AuthenticationObjectChoice
PasswordAttributes
DID.authProtocol := PIN Compare (A.8)
BiometricAttributes
DID.authProtocol := BiometricCompare (A.9)
ExternalAuthObjectAttributes
Investigate ExternalAuthObjectAttributes
CertBasedAuthenticationAttributes
DID.authProtocol := Asymmetric External Authenticate(A .4)
AuthKeyAttributes
AuthKeyAttributes
DID.authProtocol := Symmetric External Authenticate (A.6)
retrieve key with CommonKeyAttributes.iD == AuthKeyAttributes.authKeyId
retrieve AlgorithmInfo out of CIAInfo with AlgorithmInfo.algRef == CommonKeyAttributes.algRef
investigate AlgorithmInfo.objId
AlgorithmInfo.objId starts with " 1 0 24727 3"
DID.authProtocol := AlgorithmInfo.objId
else
unknown protocol
Figure 8-1 - Discovery of the authentication protocol value
© ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
Table 8.4 shows the mapping of an Authentication Object to the related Differential-Identity
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID item
AuthenticationObject- commonObjectAttributes.label Name DIDNam
Choice denoting the e
authObject
commonObjectAttributes purpose
(ASCII-
encoded)
commonObjectAttributes.authId Cross- Auth Matches the value
reference to Protocol AlgorithmInfo.algRef
the algorithm in
used to CIAInfo.supportedAlg
authenticate orithms
this DID.
accessControlRule.accessMode SAL API Shall conform to
Action Table 10 & Table 8-8;
Alternatively (not
accessControlRule.securityCondition ISO/IEC 7816-
15 compatible recommended), the
access rules
controlling the SAL
API Actions
executable upon this
DID may be found in
Differential-Identity
Service ACLs
ClassAttributes authID Cross- CommonAuthenticati
reference from onObjectAttributes.au
any CIO to this thID enables DID
DID. Shall lookup for private
match for objects or
instance dataContainerObjects
authId used as .
securityCon-
ditions
attribute for
DataSets or
Services.
authReference Key reference Marker
of the
cryptographic
object involved
in the DID
Auth Protocol
in security
environments
© ISO/IEC 2012 — All rights reserved 1

ISO/IEC 24727-4 AMD:1
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID item
seIdentifier If present, it
identifies the
security
environment to
which the DID
Marker and
Auth Protocol
belong.
TypeAttributes pwdFlags.local If present (for Scope
pwd and
biometric
template
CIOs), it
denotes
whether the
object is local
or global
Any other TypeAttribute shall If present, Qualifier once the OID of the
comprise the Qualifier (i.g pwdType, shall be part of authentication
minLength, storedLength, the Qualifier protocol is
maxLength, padChar, path) determined by the
terminal, the actual
Qualifer content shall
conform to the
definition provided in
Annex A of ISO/IEC
24727-3.
Table 8-4 — mapping authObject to DID

Table 8.5 shows the mapping of a Secret Key to a Differential-Identity.
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID Item
SecretKeyChoice commonObjectAttributes.label Name denoting DIDName
the secretKey
purpose (ASCII-
commonObjectAttributes
encoded)
2 © ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID Item
commonObjectAttributes.authId Cross-reference Auth May be employed
to the Protocol as cross-
authentication reference to the
object used to algorithm used to
protect this authenticate this
secret key DID. If so, it shall
matches the
value
AlgorithmInfo.alg
Ref in
CIAInfo.supported
Algorithms. But it
is recommanded
to use authId as a
cross-reference to
the authentication
object used to
protect this secret
key
accessControlRule.accessMode SAL API Action Shall conform to
Table 10 and
Table 8-8.
accessControlRule.securityCondition
Alternatively (not
recommended),
the access rules
controlling the
ISO/IEC 24727-3
Actions
executable upon
this DID may be
found in
Differential-
Identity Service
ACLs.
ClassAttributes iD Unique identifier Used as cross-
of the Secret reference from
Key in the access rules of
ISO/IEC 7816- DataSets or
15 structure Services.
iD value shall
match authId
value.
usage Indicates the Denotes the
possible usage usage authorized
of the key for the DID
Marker
© ISO/IEC 2012 — All rights reserved 3

ISO/IEC 24727-4 AMD:1
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID Item
native  Denotes whether
the algorithm use
by the key is
Mandatory
attribute but implementated in
the card hardware
unused for DID
building
keyReference Unique Marker Reference used
reference in CRT (within
security
environments)  or
cryptographic
commands to
reference the key
in the card-
Application.
Encoded as
INTEGER
algReference identifies Auth Preferably used
algorithms that Protocol instead of
may be used CommonObjectAt
with the key by tributes.authId.
referencing
supported-
Algorithm values
This attribute is
from CIAInfo. Optional but shall
be used for DID
mapping.
Sub-Class Attributes CommonSecretKeyAttributes.keyLen Key length in This attribute is
bytes encoded Optional. If used it
as INTEGER shall be figured
within the DID
Qualifier
TypeAttributes SecretKeyAttributes.value The value shall This attribute is

be a Path to a mandatory
file containing
Qualifier
the key or to
some
representation
of the key. If
used, shall be
part of the
Qualifier
Table 8-5 — mapping Secret Key to DID

4 © ISO/IEC 2012 — All rights reserved

ISO/IEC 24727-4 AMD:1
Table 8.6 indicates the mapping of a RSA Private Key to a Differential-Identity
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID Item
PrivateKeyChoice commonObjectAttributes.label Name DIDNam
denoting the e
commonObjectAttributes PrivateKey
purpose
(ASCII-
encoded)
userConsent
commonObjectAttributes.authId Cross- (Auth May be employed as
reference to Protocol) cross-reference to the
the algorithm used to
authentication authenticate this DID.
object used to If so, it shall match
protect this the value
Private Key AlgorithmInfo.algRef
in
CIAInfo.supportedAlg
o-rithms. But it is
recommanded to use
authId as a cross-
reference to the
authentication object
used to protect this
Private Key
accessControlRule.accessMode SAL API Shall conform to
Action Table 8-
...

INTERNATIONAL ISO/IEC
STANDARD 24727-4
First edition
2008-11-01
AMENDMENT 1
2014-04-01
Identification cards — Integrated circuit
card programming interfaces —
Part 4:
Application programming interface (API)
administration
AMENDMENT 1
Cartes d'identification — Interfaces programmables de cartes à puce —
Partie 4: Administration d'interface de programmation (API)
AMENDEMENT 1
Reference number
ISO/IEC 24727-4:2008/Amd.1:2014(E)
©
ISO/IEC 2014
ISO/IEC 24727-4:2008/Amd.1:2014(E)

©  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

ISO/IEC 24727-4:2008/Amd.1:2014(E)
Contents Page
Foreword .iv
5.7 Extensions of the Service Access Layer .1
5.7.1 Extensions under ISO/IEC 7816-15.1
5.7.2 SAL API Lite .1
5.7.3 SAL API Lite Supported Requests: .1
5.7.4 Secure Messaging.3
8 Registry Implementations.6
8.1 ISO/IEC 7816-15 registry implementation .6
8.1.1 ISO/IEC 24727-3 data structures mapping.6
8.1.2 SAL API Action mapping onto ISO/IEC 7816-15 attributes .20
8.1.3 Card-specific APDU mapping onto ISO/IEC 7816-15 attributes.21
8.1.4 ISO/IEC 24727-3 data structures storage onto the card.23
Annex D (informative) Enhanced Use of Procedural Elements.25
D.1 Background .25
D.2 Full Network Stack configuration.28
D.3 Amendments to existing stack models .30
D.4 Stack Enhancement.41
Annex E (informative) API for ISO/IEC 7816-15 data structures handling.42
E.1 C-language Binding for the P15-API .42
E.2 Interface functions .62
E.3 Objects .64
E.4 Macros.106
E.5 Example of use (C++ Language) .108
Annex F (informative) A Lightweight Service Access Layer (SAL API LITE).110
F.1 ASN.1 Definitions for SAL API Lite.110
F.2 Migration of Stack Configurations .110
Annex G (informative) Cryptographic Information Application Examples.111
G.1 Creating a new service.111
Annex H (informative) Translation ASN.1 Module .122
Annex I (informative) Interoperable Access to the Repositery.123
I.1 - Example: An excerpt from a EU standard CEN/TS15480-3.123
Annex J (informative) CryptoAPI (CAPI) Access Via Procedural Elements.126
J.1 SAL API Lite Access to CAPI .126
J.2 Access Methods .126

© ISO/IEC 2014 – All rights reserved iii

ISO/IEC 24727-4: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-4:2008 was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information technology, Subcommittee SC 17, Cards and personal identificaition.
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.
In order to support this addition to the ISO/IEC 24727-3 scope, the relevant stack configurations in ISO/IEC
24727-4 will be updated and/or amended. The rules governing the use of various marshalling/un-marshalling
procedures will be aligned with the amendment to ISO/IEC 24727-3.
This Amendment has been prepared to:
1. Extend and update as necessary the stack configurations to address the XML representation such
that it is compatible with the relevant XML-based standards (e.g. SAML).
2. Clarify use of secure messaging.
3. As a result of Amendments under development for other parts of 24727, portions of this standard may
be deleted and referenced.
4. Consider additional forms of secure messaging and consider separating the security of information
transferred across a general network versus security of information transferred across the card
interface.
5. Refine TC_API to allow channel initiation for various mechanisms; e.g. web service communication
(SOAP PAOS), AJAX.
6. Update the current XML specifications to align with ISO and not import 3 party schemas e.g. OASIS.
7. Remove ambiguities by elaborating and re-specifying concepts that may not be clear in the current
standard.
8. Incorporate concepts that are captured in other parts of ISO/IEC 24727 but are more relevant for
ISO/IEC 24727-4.
9. Include C and Java bindings in a Normative Annex (for C) and an Informative Annex (Java); moved
from Part 5
iv © ISO/IEC 2014 – All rights reserved

ISO/IEC 24727-4:2008/Amd.1:2014(E)
10. Consider relocating data structure generation to the local machine level; e.g. remote ICC Stack
Note: A hybrid numbering scheme for new figures and tables is used (e.g. Figure 7-1) in order to fit more seamlessly with
the original document; i.e. to NOT require many modifications to simply change figure and table numbers.
© ISO/IEC 2014 – All rights reserved v

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

Identification cards — Integrated circuit cards programming
interfaces —
Part 4:
Application programming interfaces (API) administration
AMENDMENT 1
Page 12
Add the following new subclause before Clause 6:
5.7 Extensions of the Service Access Layer
5.7.1 Extensions under ISO/IEC 7816-15
This clause comprises an enhancement of the functionality assigned to the local platform through which is
accessed the card-application. In so doing, it re-uses the existing ISO/IEC 24727-4 middleware stack
configurations with only a change bearing upon the location of the component handling ISO/IEC 7816-15 -
based registry. The main objective being to alleviate the workload of the client-application platform by
supplying it upon request with pre-built data structures for interoperability (ISO/IEC 24727-3).
5.7.2 SAL API Lite
ISO/IEC 24727-2 AMD 1 envisions explicit (normative and informative elements, including the use of the
ISO/IEC 7816-15 based Registry. As such, 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. To achieve
this discovery process, it is necessary to locate an ISO/IEC 7816-15 based Procedural Elements component
within the platform connected to the card-application for the Remote-ICC-stack and the Opaque-ICC-stack
(see Figure 7-1) as follows:
- This component is in charge of linking the entities defined at the Service Access Layer (API) (e.g.
Differential Identity, DataSet, DSI) with typical "on-card" entities such as keys, files and Access Control Rules.
Accordingly enabled with this Registry processing capability, this component is ONLY in charge of retrieving
the ISO/IEC 7816-15 based Registry, parsing it, and generating the interoperability data structures
representing the objects handled by the SAL API in conformance with ISO/IEC 24727-3.
- this component is part of a SAL API Lite implementation that implements a subset of existing SAL API herein
called SAL API Lite
- the SAL API Lite is comprised ONLY of the the SAL API functions that serve to retrieve data structures for
interoperability as DataSet, DSI, DID, ACL, etc. to supply it to the client-application upon request.
5.7.3 SAL API Lite Supported Requests:
The SAL API Lite interface provides a subset of the full ISO/IEC 24727-3 API. Specifically included are the
following requests:
• CardApplicationConnect(),
• CardApplicationList(),
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
• CardApplicationServiceList(),
• CardApplicationServiceDescribe(),
• DataSetList(),
• DataSetSelect(),
• DSIList(),
• DSIRead(),
• DIDList(),
• DIDGet(),
• ACLLIst()
The SAL API Lite requests are limited in the following ways:
5.7.3.1 Registry Delegation
The Service Access Layer implemented on the same platform as the client-application shall delegate the
Registry processing capability to the SAL API Lite implementation.
5.7.3.2 Registry Bootstrap
The SAL API Lite implementation shall start the ISO/IEC 7816-15 based Registry processing at bootstrap and
save processing time to the Service Access Layer implementation by making available all the data structures
defined at SAL API Lite interface.
5.7.3.3 Registry Connection
The SAL API Lite implementation shall provide to the application running on a local machine to which the
card-application is connected e.g to allow for GUI to expose the user all or part of his on-card ISO/IEC 7816-
15 based Registry.
5.7.3.4 ICC-Resident-Stack Exclustion
The SAL API Lite component does not fit in an ICC-Resident-stack for the following reasons: the SAL-Agent is
located on-card and not visible to the outside world, and additionally, on ICC-Resident-stack, the data
structures for interoperability can be built-in structures already available on-card, so they do not need to be
derived from a ISO/IEC 7816-15 based Registry.
5.7.3.5 Static Library Option
Optionally, the SAL API Lite implementation may rely on a static or dynamic library to explore the on-card
ISO/IEC 7816-15 based Registry. To this intent, informative Annex E is proposed with a comprehensive
description and binding for an API typically handling on-card ISO/IEC 7816-15 based Registry.
Figure 7-1 illustrates a Full Network Stack that makes use of a SAL API Lite registry facility. In addition, this
figure illustrates the use of a procedural element that can translate the formal language representation of the
ISO/IEC 24727-3 API functions directly into card specific APDUs. The only required ISO/IEC 24727-2 GCI
APDU is the ENVELOPE APDU. The contents of the ENVELOPE APDU can be, for example, DER-TLV
represented API functions. Thus, the procedural elements can function as a full Service Access Layer.
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)

Figure 7-1 —Network stack
5.7.4 Secure Messaging
Within a stack configuration as shown in Figure 7-1, a client-application may establish an end-to-end secure
channel with a card-application. The secure APDU commands generated by the SAL implementation are
delivered as IFD API marshalled commands to the local host where the Interface Device Agent redirects them
to the Interface Device. The SAL API Lite component does not process secure APDUs. Accordingly,
whenever the ACL controlling the access to a data structure e.g. DataSet, requires secure messaging, the
transaction shall go through the following sequence :
1. client-application sends for the first time during a session a DataSetList call through SAL API
2. the API call is marshalled into either XML or DER-TLV and sent through TC to the SAL API Lite
component
3. the SAL API Lite builds the requested data structure (i.e DataSetNameList) as part of the
DataSetListResult and returns it through TC layer to the SAL.
4. the SAL hands on the DataSetListResult to the client-application.
5. the client-application sends an ACLList call through SAL API with a parameter targetType denoting a
data-set and a parameter targetName related to a named DataSet that was retrieved from the just
received list of DataSetNameList (before this call, the client-application may optionally selects a
named DataSet and sends a DataSetSelect call through SAL API)
6. the API call is marshalled into either XML or DER-TLV and sent through TC to the SAL API Lite
component
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
7. the SAL API Lite builds the requested data structure (i.e AccessControlList) as part of the
ACLListResult and returns it to through TC layer to the SAL.
8. the SAL hands on the ACLListResult to the client-application.
9. the client-application parses the set of AccessRules contained in ACLListResult and figures out which
Differential-Identity is to be verified in order to get access to the DataSet contents (with the
assumption that the targetted DataSet is protected with a DID controlling access to its contents e.g
DIDRead requiring mutual authentication with establishment of secure messasing).
10. the client-application sends a DSIList call through SAL API
11. the API call is marshalled into either XML or DER-TLV and sent through TC to the SAL API Lite
component.
12. the SAL API Lite builds the requested data structure (i.e DSINameList) as part of the DSIListResult
and returns it to through TC layer to the SAL. in order to allow the client-application to read properly
the DSI contents, the SAL API Lite maps the DSI attributes onto on-card attributes; for this purpose
the SAL API Lite uses the Cryptographic Information Application (CIA or P15) to figure out the on-card
attributes related to each DSI in the DSIListResult. Alternatively, the SAL API Lite may send a
SELECT APDU command to the card with parameter P2 requesting the Control Parameter (CP)
Template (see ISO/IEC 7816-4); accordingly, a DO'98' within CP denotes DO instances, a DO'9B'
within CP denotes EF instances in either DF or ADF, and a DO'97' within CP denotes DF instances in
either DF or ADF. To map those on-card attributes onto DSI attributes, an additional parameter is
required in DSIListResult definition in ISO/IEC 24727-3.
13. the SAL hands on the DSIListResult to the client-application
14. the client-application sends a DIDAuthenticate (according step 9 above) to fulfil the access rules
controlling the reading of DSI contents.
15. the SAL parses the DID requirements (i.e DIDName, DIDAuthenticationData) and starts the
authentication protocol with the card i.e SAL generates the appropriate APDU commands and send
them out to the card through IFD API and TC layer.
16. Once the end-to-end secure messaging is established between the card and the SAL, the SAL
delivers the API return code to the client-application
17. the client-application then sends a DSIRead call through the SAL API.
18. the SAL generates the corresponding APDU command conforming to DSI attributes received in step
12 above; then SAL secures the APDU commands with current session keys and sends it via the IFD
API, TC and Interface Device to the Card Application;
19. the SAL recovers the DSI contents and builds the dsiContent as part of the DSIReadResult, then
return it to the client-application.
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
Table 7-1 indicates the messages exchanged between SAL API and SAL API Lite during a transaction with
secure messaging :
Table 7-1 – Command Progression
Client- SAL IFD TC IFD SAL API Lite IFD Card-
Application Proxy Agent Application
Registry
processing
DataSetList DataSetList ÅÆ ÅÆ ÅÆ DataSetList
DataSetSelect DataSetSelect ÅÆ ÅÆ ÅÆ DataSetSelect
ACLList ACLList ÅÆ ÅÆ ÅÆ ACLList
DSILIst DSILIst ÅÆ ÅÆ ÅÆ DSILIst
(*)
DIDAuthenticate APDU C-RP ÅÆ ÅÆ ÅÆ ÅÆ ÅÆ
Å                   SECURE MESSAGING                           Æ
DSIRead APDU C-RP ÅÆ ÅÆ ÅÆ ÅÆ    ÅÆ

(*) APDU C-RP = APDU command-response pair i.e GET DATA or READ BINARY

© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
Page 47
Add the following new clause before Annex A:
8 Registry Implementations
8.1 ISO/IEC 7816-15 registry implementation
To achieve interoperability among various Service Access Layer implementations, it is necessary to record the
mechanisms used to translate between ISO/IEC 24727-3 API functions and ISO/IEC 24727-2 GCI APDUs.
This clause defines how to prepare this record in the form of an ISO/IEC 7816-15 formatted Registry.
Included is the representation of ISO/IEC 24727-3 Card-Application discovery information as an ISO/IEC
7816-15 Cryptographic Information Application.
The ISO/IEC 7816-15 representation of an ISO/IEC 24727 card-application contains all the information that
the ISO/IEC 24727-2, ISO/IEC 24727-3 implementations need to realize the ISO/IEC 24727 specified
interoperable connection between the client-application and the card-application.
Data Structures for Interoperability are discovery information made available to the SAL by the card through
the bootstrap mechanism, unless it is provided by other means. The SAL API or the SAL API Lite shall
undertake the processing of the discovery information in order to dynamically generate the data structures
defined in ISO/IEC 24727-3 as Access Control List, Differential-Identity, Data-Set and Data Structures for
Interoperability (DSI), and Card-Application Services and Actions. These data structures shall be surfaced to
the client-application upon request through the SAL API or the SAL API Lite.
To allow for coding of access control rules conforming to ISO/IEC 7816-15 implementation, a mapping of SAL
API actions onto ISO/IEC 7816-15 accessMode attributes is described. This mapping is laid on the extension
of accessMode according the second amendment of ISO/IEC 7816-15.
The information in the ISO/IEC 7816-15 representation of an ISO/IEC 24727 card-application is referred to
informally in ISO/IEC 24727-1 as the discovery information and in ISO/IEC 24727-4 as an ISO/IEC 7816-15
based Registry.
To implement the ISO/IEC 7816-15 based Registry, several ASN.1 definitions are available:

- Clause 8.1.3.1 establishes the ASN.1 types for translation of SAL API calls into card-specific APDU; the
APDU command parameters rendering each SAL API Action can be so determined by the issuer and
DER-TLV encoded then hosted on-card as part of the Cryptographic Information Application or on a
remote repository that can be accessible though the interface of which the XML-Binding is described in
Annex I [informative] “interoperable access to the repository”.

- Annex H[informative] illustrates the actual ASN.1 reference Module implementing clause 8.1.3.1.
Common ASN.1 types are imported from ISO 24727-3; only types newly designed in the Amendment are
defined within this module.
- Annex G[informative] illustrates application of the rules and guidelines described in clause 8.1.1 “ISO/IEC
24727-3 data structures mapping” to build an ISO/IEC 7816-15 based Registry for a fictitious service
called “myService”. In G.1.1.2.1, an ASN.1 value notation illustrates an implementation example;
accordingly, DER-encoding may be derived from this notation.

8.1.1 ISO/IEC 24727-3 data structures mapping
The data structures that may be surfaced to the client-application upon request are DataSet, DSI, ACL,
Differential-Identities, list of Card-Application Services, list of Differential-Identities.
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
The SAL generates these data structures from the information available in CardApplicationServiceDescription
that is defined as an ASN.1 SEQUENCE of ISO/IEC 7816-15 CIAInfo value along with consecutive ISO/IEC
7816-15 CIOChoice(s) value(s).
The interpretation of CardApplicationServiceDescription value in terms of ACL, Differential-Identities,
Services, DataSet or DSI, is based on the mapping described in the following sub-clauses.
8.1.1.1 DataSet
Table 8-1 indicates the mapping of a DataSet onto a DataContainerObjectChoice and describes how the
DataSet's ACL can be derived from it. In this and following tables, an “X” in the “ACL items” column indicates
that this attribute may be controlled through an Access Control List (ACL) entry.
Table 8-1 — Mapping DataSet to ACL
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
DataContainerObject- commonObjectAttributes.label DataSet X The label is ASCII
Choice Name encoded and shall
evaluate to 'DATA-SET'
iso7816DO used as a prefix
denoting the target
type, concatenated with
commonObjectAttributes
the DataSet actual
name.
accessControlRule.accessMode Action Shall conform to Table
10 and Table 8-8
accessControlRule.securityCondition Ref to DID authId referring to a
X
CIO within the
cryptographic
information application
(DF.CIA)
ClassAttributes classAttributes.applicationName  Either applicationName
or application OID of
the card-application
owning the DataSet.
Shall not be NULL.
TypeAttributes   NULL
ISO/iEC 7816 DO
container for the DSI(s)
within the DataSet
CommonObjectAttributes commonObjectAttributes.label DSIName The DSI Name shall be
ASCII encoded.
accessControlRule.accessMode DSI's accessRules are

controlled by DataSet
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
accessControlRule.securityCondition  DSI's accessRules are
controlled by DataSet
accessRules
ClassAttributes 
TypeAttributes efidOrTagChoice location of File Id or extended
the actual Path (acc. ISO/IEC
resource 7816-15:2004/AM2) to
(EF,DF, the DSI resource
ADF, DO)
hosting the
DSI content.
In case the action is controlled by a logical combination of DIDs, several consecutive securityCondition values may
provide different security conditions applying to the same access Mode denoting the SAL API action. The logical
operation combining the DIDs is AND or OR depending on the ASN.1 encoding of the securityContitions.

The DIDs referenced by the access rules protecting a DataSet are either Authentication Information Objects or
Private Objects or Secret Key. Secret Key and Private Key mapping to Differential-Identities is presented in
subsequent tables.
8.1.1.2 CardApplication
Table 8.2 shows the mapping of a CardApplication onto a DataContainerObjectChoice and describes how the
CardApplication's ACL can be derived from it.
Table 8-2 — mapping CardApplication to DataContainerObjectChoice
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
DataContainerObject- commonObjectAttributes.label Card-Appli- X The label is ASCII
Choice cation Name encoded and shall
valuate to 'CARD-
APPLICATION' used
ISO/IEC 7816 DO
as a prefix denoting the
target type,
commonObjectAttributes
concatenated with the
CardApplication actual
name.
accessControlRule.accessMode SAL API SAL API actions shall
Action X conform to value in
Table 10 and Table 8-8
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
accessControlRule.securityCondition Ref to DID May be authId referring
to a CIO within the
cryptographic
information application
(DF.CIA)
ClassAttributes classAttributes.applicationName  Either applicationName
or application AID.
Shall not be NULL.
TypeAttributes   NULL
ISO/IEC 7816 DO
container for each target
resource of the
CardApplication (DataSet
Name, DID Name)
CommonObjectAttributes commonObjectAttributes.label DataSet or The target name shall
DID Name be ASCII encoded with
a prefix denoting the
target type
concatenated with the
actual target name.
accessControlRule.accessMode Refer to the named

target
accessControlRule.securityCondition  Refer to the named
target
ClassAttributes 
TypeAttributes efidOrTagChoice location of File Id or extended
the actual Path (acc. ISO/IEC
resource 7816-15:2004/AM2) to
(EF,DF, the named target
ADF, DO) resource
hosting the
named
target.
In case the Action is controlled by a logical combination of DIDs, several consecutive securityCondition values may
provide different security conditions applying to the same access Mode denoting the SAL API Action. The logical
operation combining the DIDs is AND or OR depending on the ASN.1 encoding of the securityConditions.

© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
8.1.1.3 Service
Table 8.3 shows a possible alternative for the mapping of a Service onto a DataContainerObjectChoice But
since a Named Service is not a target, no ACL is attached to it according ISO/IEC 24727. Deriving ACL from
Named Service is not recommended by the present standard.
Table 8-3 — mapping Service to ACL
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
DataContainerObject- commonObjectAttributes.label Service Name X The Service Name
Choice shall be comprised
of ASCII coded
prefix 'SERVICE'
iso7816DO for the Service
concatenated with
the respective
commonObjectAttributes
Service Name
conforming to
ISO/IEC 24727-3
naming rules
accessControlRule.accessMode SAL API Action two supported
Actions for
Authorization
Service :
ACL_LIST,
ACL_MODIFY
encoding shall
conform to Table 10
and Table 8-8
X
accessControlRule.securityCondition Ref to DID authId.
ACL_LIST may
valuate to
ALWAYS.
authId is the cross-
reference to an
Authentication
Object protecting
the current CIO
ClassAttributes applicationName  applicationName
or/and application
OID. Shall not be
NULL. It gives the
location of the
executable code
applicationOID
implementing the
named Service
within the card
application.
TypeAttributes   NULL
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
iso7816DO container for
the Actions within the
Service
CommonObjectAttributes commonObjectAttributes.label  The Action Name
Action Name shall conform to
ISO/IEC 24727-3
naming rules. If
present, it clears
ambiguity for SAL
API actions sharing
the same
AccessMode byte
value.
accessControlRule.accessMode SAL API Action Shall conform to
Table 10 and Table
8-8
accessControlRule.securityCondition Ref to DID ACL authId. this is the
cross-reference to
an Authentication
Object protecting
the current CIO
ClassAttributes applicationName  The
applicationName
or/and application
applicationOID
OID shall not be
NULL. It gives the
location of the
CommonDataContainerObjectAttributes.iD Ref to a CIO executable code
implementing the
named Service
within the card
application.
The iD may be used
to associate the
current data
container object
with some other
CIO ( e.g.: a private
key information
object, a public key
information object, a
certificate
information object, a
secret key
information object)
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description ACL
items
TypeAttributes efidOrTagChoice location of the File Id or Path to the
cryptographic CIA directory file
information containing the CIO
object executing referenced by the
the Action (e.g : ClassAttributes.iD
a PrK for a above
SIGN action)
This ACL is for Authorization Service that applies for all card-application services.

This ACL relates to a specific Action within the card-application named Service

8.1.1.4 Differential-Identity
In the context of ISO/IEC 24727-3, Differential-Identities are used to describe objects for authentication and
cryptographic usage. As a consequence, ISO/IEC 7816-15 AuthenticationObjectChoice structures are used to
describe differential identities with the focus on authentication.
KeyObjectChoice structures shall be used to qualify differential identities which should mainly be used for the
cryptographic methods (e.g. Encipher, Decipher, Sign).
8.1.1.4.1 Differential-Identities for authentication
The structure of a differential identity is heavily depending on the used authentication protocol. The marker
and qualifier structures are only known after the authentication protocol has been identified. Therefore, the
first step in the discovery mechanism is to retrieve the correct value for the authentication protocol while
parsing the service description of the Application Capability Descriptor.
The discovery mechanism for the authentication protocol value is shown in Figure 8-1. The mechanism is
starting with parsing the AuthenticationObjectChoice. At the beginning, the TypeAttributes of the
AuthenticationObjectChoice can be determined. If the TypeAttributes are PasswordAttributes or
BiometricAttributes, the type of the authentication protocol shall be either the PIN Compare or the Biometric
Compare protocol.
In case the TypeAttributes are ExternalAuthObjectAttributes, it has to be investigated which choice was made
for the ExternalAuthObjectAttributes:
⎯ If CertBasedAuthenticationAttributes are used, the protocol shall be the Asymmetric External
Authenticate protocol,
⎯ In the case AuthKeyAttributes are used, it's the Symmetric External Authenticate Protocol unless
otherwise specified by the related objId : the corresponding AlgorithmInfo within the CIAInfo structure of
the adequate application shall be used to retrieve the objId. If the equivalent non DER-TLV encoded
value of this objId is starting with "1 0 24727 3", the value shall be directly used to determine the
authentication protocol value.
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)

Figure 8-1 - Discovery of the authentication protocol value
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
Table 8.4 shows the mapping of an Authentication Object to the related Differential-Identity
Table 8-4 — mapping authObject to DID
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID item
AuthenticationObject- commonObjectAttributes.label Name DIDNam
Choice denoting the e
authObject
purpose
commonObjectAttributes
(ASCII-
encoded)
commonObjectAttributes.authId Cross- Auth Matches the value
reference to Protocol AlgorithmInfo.algRef
the algorithm in
used to CIAInfo.supportedAlg
authenticate orithms
this DID.
accessControlRule.accessMode SAL API Shall conform to
Action Table 10 & Table 8-8;
accessControlRule.securityCondition ISO/IEC 7816- Alternatively (not
recommended), the
15 compatible
access rules
controlling the SAL
API Actions
executable upon this
DID may be found in
Differential-Identity
Service ACLs
ClassAttributes authID Cross- CommonAuthenticati
reference from onObjectAttributes.au
any CIO to this thID enables DID
DID. Shall lookup for private
match for objects or
instance dataContainerObjects
authId used as .
securityCon-
ditions
attribute for
DataSets or
Services.
authReference Key reference Marker
of the
cryptographic
object involved
in the DID
Auth Protocol
in security
environments
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID item
seIdentifier If present, it
identifies the
security
environment to
which the DID
Marker and
Auth Protocol
belong.
TypeAttributes pwdFlags.local If present (for Scope
pwd and
biometric
template
CIOs), it
denotes
whether the
object is local
or global
Any other TypeAttribute shall If present, Qualifier once the OID of the
comprise the Qualifier (i.g pwdType, shall be part of authentication
minLength, storedLength, the Qualifier protocol is
maxLength, padChar, path) determined by the
terminal, the actual
Qualifer content shall
conform to the
definition provided in
Annex A of ISO/IEC
24727-3.
Table 8.5 shows the mapping of a Secret Key to a Differential-Identity.
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
Table 8-5 — mapping Secret Key to DID
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID Item
SecretKeyChoice commonObjectAttributes.label Name denoting DIDName
the secretKey
purpose (ASCII-
commonObjectAttributes
encoded)
commonObjectAttributes.authId Cross-reference Auth May be employed
to the Protocol as cross-
authentication reference to the
object used to algorithm used to
protect this authenticate this
secret key DID. If so, it shall
matches the
value
AlgorithmInfo.alg
Ref in
CIAInfo.supported
Algorithms. But it
is recommanded
to use authId as a
cross-reference to
the authentication
object used to
protect this secret
key
accessControlRule.accessMode SAL API Action Shall conform to
Table 10 and
Table 8-8.
accessControlRule.securityCondition
Alternatively (not
recommended),
the access rules
controlling the
ISO/IEC 24727-3
Actions
executable upon
this DID may be
found in
Differential-
Identity Service
ACLs.
ClassAttributes iD Unique identifier Used as cross-
of the Secret reference from
Key in the access rules of
ISO/IEC 7816- DataSets or
15 structure Services.
iD value shall
match authId
value.
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID Item
usage Indicates the Denotes the
possible usage usage authorized
of the key for the DID
Marker
native  Denotes whether
the algorithm use
by the key is
Mandatory
attribute but implementated in
the card hardware
unused for DID
building
keyReference Unique Marker Reference used
reference in CRT (within
security
environments)  or
cryptographic
commands to
reference the key
in the card-
Application.
Encoded as
INTEGER
algReference identifies Auth Preferably used
algorithms that Protocol instead of
may be used CommonObjectAt
with the key by tributes.authId.
referencing
supported-
Algorithm values
This attribute is
from CIAInfo. Optional but shall
be used for DID
mapping.
Sub-Class Attributes CommonSecretKeyAttributes.keyLen Key length in This attribute is
bytes encoded Optional. If used it
as INTEGER shall be figured
within the DID
Qualifier
TypeAttributes SecretKeyAttributes.value The value shall This attribute is

be a Path to a mandatory
file containing
Qualifier
the key or to
some
representation
of the key. If
used, shall be
part of the
Qualifier
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
Table 8.6 indicates the mapping of a RSA Private Key to a Differential-Identity
Table 8-6 — mapping private Key to DID
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID Item
PrivateKeyChoice commonObjectAttributes.label Name DIDNam
denoting the e
commonObjectAttributes PrivateKey
purpose
(ASCII-
encoded)
userConsent
commonObjectAttributes.authId Cross- (Auth May be employed as
reference to Protocol) cross-reference to the
the algorithm used to
authentication authenticate this DID.
object used to If so, it shall match
protect this the value
Private Key AlgorithmInfo.algRef
in
CIAInfo.supportedAlg
o-rithms. But it is
recommanded to use
authId as a cross-
reference to the
authentication object
used to protect this
Private Key
accessControlRule.accessMode SAL API Shall conform to
Action Table 8-10 & Table 8-8.
Alternatively (not
recommended), the
accessControlRule.securityCondition
access rules
controlling the
ISO/IEC 24727-3
Actions executable
upon this DID may be
found in Differential-
Identity Service
ACLs.
ClassAttributes iD Unique Used as cross-
identifier of reference from
the Private access rules of
Key in the DataSets or Services.
ISO/IEC 7816-
15 structure iD value shall match
authId value.
© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
ISO/IEC 7816-15 attribute ISO/IEC 7816-15 sub-attribute(s) ISO/IEC 24727-3 Comments
Description DID Item
usage Indicates the Denotes the usage
possible authorized for the DID
usage of the Marker
key
native  Denotes whether the
algorithm use by the
key is implementated
Mandatory
attribute but in the card hardware
unused for
DID building
keyReference Unique Marker Reference used in
reference CRT (within security
environments)  or
cryptographic
commands to
reference the key in
the card-Application.
Encoded as
INTEGER
algReference identifies (Auth Preferably used
algorithms Protocol) instead of
that may be CommonObjectAttrib
used with the utes.authId.
key by
referencing
supported-
This attribute is
Algorithm Optional but shall be
values from
used for DID
CIAInfo. mapping.
Sub-Class Attributes CommonPrivateKeyAttributes. . This attribute is
Optional. If used it
shall be figured within
If used, shall
be part of the the DID Qualifier
Qualifier
Qualifier
TypeAttributes PrivateRSAKeyAttributes.value and Shall be part This attribute is
of the Qualifier mandatory
PrivateRSAKeyAttributes.modulusLength

© ISO/IEC 2014 – All rights reserved
ISO/IEC 24727-4:2008/Amd.1:2014(E)
8.1.2 SAL API Action mapping onto ISO/IEC 7816-15 attributes
Table 8.7 provides the mapping of all SAL API actions in terms of ISO/IEC 7816-15 accessMode attributes.
The ISO/IEC 7816-15 containers from which the SAL API access control rules can be extracted are provided.
Whenever a SAL API action is always authorized, the ISO/IEC 7816-15 securityCondition byte is set to
'ALWAYS' value (see comments in Table 8.7)
Table 8-7 — SAL API action mapping onto ISO/IEC 7816-15 attributes (1/2)

SAL-API action 7816-15 container comments

Card-application-service access
Initialize  1     ALWAYS

Terminate  1     ALWAYS
CardApplicationPath  1     ALWAYS

Connection service
C-App
CardApplicationConnect   1         ALWAYS
C-App
CardApplicationDisconnect   1         ALWAYS
C-App
CardApplicationStartSession   1       1 1 DataContainerObjectChoice (1) see DIDAuthenticate
C-App
CardApplicationEndSession   1         ALWAYS

Card-application-service
C-App (1) : from the
DataContainerObjectChoice, the
securityCondition attribute applying to
the SAL-API Actions can make
reference to a cryptographic
information object through its identifier
authId. This authId shall point to an
object that can be an
AuthenticationObject representing the
DifferentialIdentity protecting the SAL-
CardApplicationList 1     DataContainerObjectChoice (1) API
...