ISO/IEC 24727-3:2008
(Main)Identification cards — Integrated circuit card programming interfaces — Part 3: Application interface
Identification cards — Integrated circuit card programming interfaces — Part 3: Application interface
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. ISO/IEC 24727-3:2008 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. ISO/IEC 24727-3:2008 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. ISO/IEC 24727-3:2008 does not mandate a specific implementation methodology for this interface.
Cartes d'identification — Interfaces programmables de cartes à puce — Partie 3: Interface d'application
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 24727-3
First edition
2008-12-01
Identification cards — Integrated circuit
card programming interfaces —
Part 3:
Application interface
Cartes d'identification — Interfaces programmables de cartes à puce —
Partie 3: Interface d'application
Reference number
©
ISO/IEC 2008
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2008
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing 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 copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2008 – All rights reserved
Contents Page
Foreword .v
Introduction.vi
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Abbreviated terms.3
5 Organization for interoperability.4
5.1 General .4
5.2 Computation model.4
5.3 Entity relationships on the application interface .5
5.4 Security model.13
6 Card-application-service access .16
6.1 General .16
6.2 Initialize .16
6.3 Terminate .17
6.4 CardApplicationPath.18
7 Connection service .19
7.1 General .19
7.2 CardApplicationConnect .20
7.3 CardApplicationDisconnect .21
7.4 CardApplicationStartSession.22
7.5 CardApplicationEndSession .23
8 Card-application service.24
8.1 General .24
8.2 CardApplicationList .25
8.3 CardApplicationCreate.26
8.4 CardApplicationDelete.27
8.5 CardApplicationServiceList .28
8.6 CardApplicationServiceCreate.29
8.7 CardApplicationServiceLoad .30
8.8 CardApplicationServiceDelete .31
8.9 CardApplicationServiceDescribe.32
8.10 ExecuteAction.33
9 Named data service.34
9.1 General .34
9.2 DataSetList.35
9.3 DataSetCreate .36
9.4 DataSetSelect.37
9.5 DataSetDelete .38
9.6 DSIList .39
9.7 DSICreate .40
9.8 DSIDelete.41
9.9 DSIWrite.42
9.10 DSIRead.43
10 Cryptographic service.44
10.1 General .44
10.2 Encipher .45
© ISO/IEC 2008 — All rights reserved iii
10.3 Decipher.46
10.4 GetRandom.47
10.5 Hash .48
10.6 Sign .49
10.7 VerifySignature .50
10.8 VerifyCertificate .51
11 Differential-identity service.52
11.1 General.52
11.2 DIDList .53
11.3 DIDCreate.54
11.4 DIDGet.55
11.5 DIDUpdate.56
11.6 DIDDelete .57
11.7 DIDAuthenticate.58
12 Authorization service .59
12.1 General.59
12.2 ACLList .60
12.3 ACLModify.61
Annex A (normative) Authentication protocols .62
A.1 General.62
A.2 Common Definitions.63
A.3 Simple Assertion.64
A.4 Asymmetric Internal Authenticate .66
A.5 Asymmetric External Authenticate .69
A.6 Symmetric Internal Authenticate.72
A.7 Symmetric External Authenticate .75
A.8 Compare .78
A.9 PIN Compare .81
A.10 Biometric Compare.84
A.11 Mutual Authentication with Key Establishment .87
A.12 Client-Application Mutual Authentication with Key Establishment .90
A.13 Client-Application Asymmetric External Authenticate .93
A.14 Modular Extended Access Control Protocol (M-EAC) .96
A.15 Key Transport with mutual authentication based on RSA .100
A.16 Age Attainment .104
A.17 Asymmetric Session Key Establishment .107
A.18 Secure PIN Compare .114
A.19 EC Key Agreement with Card-Application Authentication.118
A.20 EC Key Agreement with Mutual Authentication .122
A.21 Simple EC-DH Key Agreement .128
A.22 GP Asymmetric Authentication.132
A.23 GP Symmetric Authentication (Explicit Mode) .138
A.24 GP Symmetric Authentication (Implicit Mode) .142
Annex B (normative) Cryptographic algorithms.145
B.1 Interoperability requirements.145
B.2 Symmetric Algorithms .146
B.3 Asymmetric Algorithms .149
B.4 Elliptic Curve Algorithms.150
B.5 Hash Functions.151
B.6 Message Authentication Codes .152
B.7 Key Establishment.153
Annex C (normative) ASN.1 Representation .154
C.1 General.154
Bibliography .193
iv © ISO/IEC 2008 — All rights reserved
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
© ISO/IEC 2008 — All rights reserved v
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.
vi © ISO/IEC 2008 — All rights reserved
INTERNATIONAL STANDARD ISO/IEC 24727-3:2008(E)
Identification cards — Integrated circuit card programming
interfaces —
Part 3:
Application interface
1 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.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 7816-11, Identification cards — Integrated circuit cards — Part 11: Personal verification through
biometric methods
ISO/IEC 24727-1, Identification cards — Integrated circuit card programming interfaces — Part 1: Architecture
ISO/IEC 24727-2, Identification cards — Integrated circuit card programming interfaces — Part 2: Generic
card interface
IETF RFC 2141, URN Syntax, May 1997
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 24727-1, ISO/IEC 24727-2 and
the following apply.
3.1
access control list
set of access rules
3.2
access permission
granted capability to perform an action
© ISO/IEC 2008 — All rights reserved 1
3.3
access rule
association of an action and a security condition in the context of a card-application
3.4
action
operation that a client-application can request of a card-application at the ISO/IEC 24727-3 application
interface
3.5
alpha card-application
administrative card-application, specific to ISO/IEC 24727, providing card and application discoverability and
administrative services
3.6
card-application-path
ordered set of protocol termination points in the network that connects the client-application to the
card-application
3.7
card-application-service
set of actions
3.8
channel
physical pathway allowing movement of bits of information between a client-application and a card-application
3.9
client-application
software component running on a platform that uses data storage and computational services offered by a
card-application
3.10
connection
logically referenced channel
3.11
global differential-identity
differential-identity recognized in all card-applications that are managed by the same alpha card-application
3.12
local differential-identity
differential-identity recognized only within a specific card-application in which it is defined
3.13
parameter
information required to define or effect an action
3.14
return code
information, including status, returned as a consequence of an action
3.15
security condition
boolean expression in terms of differential-identity authentication states
3.16
session
connection used under a particular security context
2 © ISO/IEC 2008 — All rights reserved
3.17
target
persistent entity that shall be manipulated through the actions of a card-application-service
4 Abbreviated terms
For the purposes of this document, the abbreviated terms given in ISO/IEC 24727-1 and the following apply.
ACL access control list
AR access rule
DID differential-identity
DSI data structure for interoperability
© ISO/IEC 2008 — All rights reserved 3
5 Organization for interoperability
5.1 General
A client-application and a card-application comprise two peer-level entities that interact through well-defined
transaction and communication mechanisms. The ISO/IEC 24727-3 application interface shall be the sole
mechanism through which a client-application interacts with a card-application.
This clause defines the model of computation and persistent entities on the ISO/IEC 24727-3 application
interface by which the client-application and the card-application interact. A security model governs the
security mechanisms through which trust in this interaction is achieved.
Clause 5.2 introduces the conceptual entities on the ISO/IEC 24727-3 application interface and describes their
operational behavior and relationships. Clause 5.3 specifies the entities and relationships presented on the
ISO/IEC 24727-3 application interface. Clause 5.4 specifies the security model provided on the
ISO/IEC 24727-3 application interface.
5.2 Computation model
Using the terminology defined in ISO/IEC 24727-1:
5.2.1 A client-application may know a card-application-path to a card-application. Using this card-
application-path, a client-application can initiate a connection to a card-application. The card-application shall
be known as the current card-application for the connection.
5.2.2 The ISO/IEC 24727-3 application interface is the set of card-application-services provided to the
client-application. Each card-application-service shall be comprised of actions that may be requested by a
client-application and confirmations returned by the SAL.
5.2.3 If the client-application does not know a card-application-path to a card-application, it may make a
request at the ISO/IEC 24727-3 application interface to discover a card-application-path to the requested
card-application.
5.2.4 A card-application shall be uniquely identified by an AID.
5.2.5 The alpha card-application provides the basis for trusted management of card-applications by the
client-application.
5.2.6 A client-application may open more than one connection. A client-application may open more than one
connection with the same card-application, each connection being referenced by a different connection handle.
5.2.7 Using an open connection, a client-application may initiate a session with a card-application.
5.2.8 A client-application may open more than one session. Only one session may be open within a
connection.
5.2.9 The current state is the current state of a connection defined by the current card-application, current
data-set, authentication state of recognized differential-identities, and the presence of a session on the
connection.
5.2.10 A card-application contains one or more card-application-services.
5.2.11 A specific card-application-service, the Named Data Service, provides access to zero or more data-
sets.
5.2.12 A data-set contains zero or more data structures for interoperability (DSI). A data-set shall provide
naming scope and access rules for the DSIs it contains.
4 © ISO/IEC 2008 — All rights reserved
5.2.13 Every data-set shall be accessible according to the access rules governing the actions available from
the Named Data Service.
5.2.14 The currently selected data-set in a card-application shall be known as the current data-set.
5.2.15 A single action request at the ISO/IEC 24727-3 application interface may translate into multiple
generic requests at the ISO/IEC 24727-2 generic card interface.
5.2.16 A card-application may support multiple actions that may be requested by the client-application
through the ISO/IEC 24727-3 application interface.
5.2.17 An action request shall produce an action confirmation.
5.2.18 An access rule consists of the name of an action and a security condition. The security condition is
said to be associated with the action by the access rule.
5.2.19 An access control list is a collection of zero or more access rules. An access control list shall be
associated with each target.
5.2.20 An action involving a target may be successfully performed if and only if the security condition
associated with the action by an access rule in the access control list of the target evaluates to TRUE.
5.2.21 An authentication protocol is the process by which a differential-identity demonstrates possession of a
marker.
5.2.22 Authentication is the successful execution of an authentication protocol. In this case the differential-
identity is said to be authenticated.
5.2.23 The authentication state of a differential-identity shall be a boolean variable that is TRUE if the
differential-identity is authenticated and FALSE otherwise.
5.2.24 A client-application may learn about information, status or services provided by a card-application
through a discovery process effected through the various List, Get, and Describe actions offered at the
24727-3 application interface.
5.2.25 Access rules are discoverable at the ISO/IEC 24727-3 application interface.
5.2.26 In general, the degree of interoperability of a card-application with client-applications depends on the
discoverable information presented by the card-application at the ISO/IEC 24727-3 application interface.
5.3 Entity relationships on the application interface
5.3.1 General
This clause describes the entities accessible through a card-application, specifically the alpha card-application
and card-applications it manages. Entities more directly involved in the security model are described in
Clause 5.4.
Figure 1 illustrates the client-application to card-application paradigm that underlies the ISO/IEC 24727
standard. The ISO/IEC 24727-3 application interface facilitates the connection and session mechanisms
shown in this figure.
© ISO/IEC 2008 — All rights reserved 5
Connection Session
Client-Application Card-Application
Card-Application-Path
Figure 1 — Application Connection Paradigm
A card-application-path can be specified to allow a client-application to be connected to a specific card-
application. Through such a connection, the client-application can access card-application-services using the
ISO/IEC 24727-3 application interface. A session adds a security context to a connection in addition to its
intrinsic security characteristics that can be used to protect the data flowing between the client-application and
the card-application.
Figure 2 illustrates the entities defined in the model of computation and establishes the relationships among
these entities. This entity-relationship diagram is elaborated below to describe individual card-application-
services. The type of target applicable to each action is shown in the rounded boxes associated with each
action.
Card-Application
which contains
Service Action
Service Action
Service Action
which is a set of which applies to
Target
Target
Target
each of which has
Access Rule
Access Rule
Access Control List Access Rule
which is a set of
Figure 2 — Model of Computation Entities and Relationships
A card-application is a collection of targets and services. A service is a collection of actions. An action is an
operation which is applied to a target. The actions and services of a card-application are accessed by a
client-application using the ISO/IEC 24727-3 application interface.
6 © ISO/IEC 2008 — All rights reserved
5.3.2 Alpha Card-Application
The alpha-card-application shall be available at the application interface. It may either be present in the ICC or
emulated by the SAL or GCAL implementation. In all cases, a connection by the client application to the
alpha-card-application grants the availability of the card application list.
5.3.3 Accessing Card-Application-Services
A client-application uses the Initialize and CardApplicationPath entry points on the ISO/IEC 24727-3
application interface to gain access to card-application-services. A client-application uses the Terminate entry
point to terminate access to card-application-services.
Before accessing card-application-services, a client-application must request the Initialize entry point on the
ISO/IEC 24727-3 application interface. After the Initialize confirmation, the client-application may open
connections and request actions with multiple card-applications, simultaneously or sequentially. The
client-application should request the Terminate entry point when use of card-application-services is no longer
needed.
5.3.4 Connection Service Interface
This card-application-service provides actions for the establishment of a connection between a
client-application and a card-application. Once a connection is established, a session may be effected through
this connection in order to enhance the security characteristics of the communication between the
client-application and the card-application. Figure 3 illustrates the entity relationships of the Connection
Service.
Card-Application
Connection Service
CardApplicationConnect Card-Application
CardApplicationDisconnect Card-Application
CardApplicationStartSession Card-Application
CardApplicationEndSession Card-Application
Figure 3 — Connection Service
The target of each of these actions, as specified in the diagram above, is the current card-application, or the
card-application to which the client-application is attempting to connect.
© ISO/IEC 2008 — All rights reserved 7
5.3.5 Card-Application Service Interface
This card-application-service provides actions for the creation and manipulation of card-applications. Figure 4
illustrates the entity relationships of the Card-Application Service.
Card-Application
Card-Application Service
CardApplicationList Card-Application
CardApplicationCreate Card-Application
CardApplicationDelete Card-Application
CardApplicationServiceList Card-Application
CardApplicationServiceCreate Card-Application
CardApplicationServiceLoad Card-Application
CardApplicationServiceDelete Card-Application
CardApplicationServiceDescribe Card-Application
ExecuteAction Card-Application
Figure 4 — Card-Application Service
The target of the CardApplicationCreate and CardApplicationDelete actions is the alpha card-application. The
current card-application shall be the alpha card-application when requesting these actions.
The target of each of the remaining actions is the current card-application.
8 © ISO/IEC 2008 — All rights reserved
5.3.6 Named Data Service Interface
This card-application-service provides actions for the creation and manipulation of data-sets, a containment
mechanism that allows for the establishment of common access rules for data contained in data structures for
interoperability. Data-sets may contain any number of DSIs. Figure 5 illustrates the entity relationships of the
Named Data Service.
Card-Application
Named Data Service
DataSetList Card-Application
DataSetCreate Card-Application
DataSetSelect Data-Set
DataSetDelete Card-Application
DSIList Data-Set
DSICreate Data-Set
DSIDelete Data-Set
DSIWrite Data-Set
DSIRead Data-Set
Figure 5 — Named Data Service
The target of each of these actions, as specified in the diagram above, is the current card-application, the
current data-set, or the data-set which the client-application is attempting to select.
© ISO/IEC 2008 — All rights reserved 9
5.3.7 Cryptographic Service Interface
This card-application-service provides actions for a variety of cryptographic operations to be performed on or
through the parameters contained within a differential-identity. Figure 6 illustrates the entity relationships of
the Cryptographic Service.
Card-Application
Cryptographic Service
Encipher Differential-Identity
Decipher Differential-Identity
GetChallenge Differential-Identity
Hash Differential-Identity
Sign Differential-Identity
VerifySignature Differential-Identity
VerifyCertificate Differential-Identity
Figure 6 — Cryptographic Service
The target of each of these actions, as specified in the diagram above, is the differential-identity named in the
request of the action.
10 © ISO/IEC 2008 — All rights reserved
5.3.8 Differential-Identity Service Interface
This card-application-service provides actions for the creation and manipulation of differential-identities.
Figure 7 illustrates the entity relationships of the Differential-Identity Service.
Card-Application
Differential-Identity Service
DIDList Card-Application
DIDCreate Card-Application
DIDGet Differential-Identity
DIDUpdate Differential-Identity
DIDDelete Card-Application
DIDAuthenticate Differential-Identity
Figure 7 — Differential-Identity Service
The target of each of these actions, as specified in the diagram above, is either the current card-application or
the differential-identity named in the request of the action.
© ISO/IEC 2008 — All rights reserved 11
5.3.9 Authorization Service Interface
This card-application-service provides actions for the manipulation of access control lists. Figure 8 illustrates
the entity relationships of the Authorization Service.
Card-Application
Authorization Service
ACLList Target
ACLModify Target
Figure 8 — Authorization Service
The target of these actions, as specified in the diagram above, can be any target. The target is specified in the
request of the action.
12 © ISO/IEC 2008 — All rights reserved
5.4 Security model
5.4.1 General
A shared security state is established between a client-application and a card-application by successfully
performing the required protocols between the client-application and the card-application. Establishing the
required security state authorizes the performance of actions requested of a card-application by a
client-application.
The mechanism for specifying the required security state for performing an action shall be the access rule. A
security state is established by authenticating differential-identities.
5.4.2 Differential-Identity
In order to establish a security state encompassing a client-application and a card-application, the differential-
identity authentication mechanism shall be used. The elements of each differential-identity are illustrated in
Table 1. At the generic card interface, a differential-identity may be transmitted as defined by the ASN.1 in
Annex C.
Table 1 — Elements of Differential-Identity
Element 1 Element 2 Element 3 Element 4 Element 5
DIDName Authentication Marker Scope Qualifier
Protocol
Mandatory Mandatory Mandatory Implicit Optional
The DIDName element shall be specified by the client-application which creates the differential-identity at the
time the differential-identity is created.
The Authentication Protocol element shall be specified as an object identifier (OID) and determines for which
actions the differential-identity can be used. Only if the authentication protocol specified by this OID is defined
for use in authentication as defined in Annex A shall its successful completion for the differential-identity set
the authentication state of the differential-identity to TRUE within the card-application. A DIDName shall be
associated with only one authentication protocol. The actions of the Cryptographic Service may make use of
the information in the Marker element as defined in Annex A.
Note: The Authentication Protocol indicated by element 2 is used either for authentication or for other
cryptographic services.
The Scope element is implicit. Differential-identities defined within the alpha card-application are global in
scope and therefore are recognized within all card-applications managed by this alpha card-application. All
other differential-identities are local in scope to the card-application in which they are defined. The scope of
the corresponding authentication state shall be identical to the scope of the differential-identity.
The optional Qualifier element may provide details on the use of the differential-identity. For example, it may
refer to an external specification by OID.
The Marker element is the information within the card-application, or a reference to it, that shall be used in
executing the authentication protocol specified in the Authentication Protocol element.
Examples of markers include:
• a PIN
• a password
© ISO/IEC 2008 — All rights reserved 13
• a symmetric key
• an asymmetric key
• a digital certificate
• a biometric image or template
• a pair of symmetric keys; e.g., one for encryption and one for message authentication code (MAC)
generation
As evidenced by the final entry in the previous list, the marker may be comprised of multiple parts; e.g., of
multiple keys. This allows for complex authentication protocols that may need to use multiple keys in parallel
or serially.
The Marker may often be implemented within a card-application as a key that is referred to by a key reference
as specified in ISO/IEC 7816-4. One differential-identity and hence its marker may be related to multiple key
references in some complex authentication protocols. The key reference may be coded as defined in
ISO/IEC 7816-4 security environments. A specific key reference may appear in several differential-identities.
The association of the DIDName to a Marker and Authentication Protocol is the mechanism through which the
differential-identity is associated with the marker. This mapping shall be maintained as part of the discovery
information. This mapping allows the client-application and the card-application to recognize, exchange, and
share information about a differential-identity.
5.4.3 Authentication Protocols
Authentication protocols shall be the mechanism by which the client-application sets an authentication state
within the card-application for the differential-identity indicated by the DIDName. Authentication protocols are
enumerated in Table 2, and described in Annex A.
Table 2 — Authentication Protocols
Simple Assertion Modular Extended Access Control Protocol (M-EAC)
Asymmetric Internal Authenticate Key Transport with mutual authentication based
on RSA
Asymmetric External Authenticate Age Attainment
Symmetric Internal Authenticate Asymmetric Session Key Establishment
Symmetric External Authenticate Secure PIN Compare
Compare EC Key Agreement with Card-Application
Authentication
PIN Compare EC Key Agreement with Mutual Authentication
Biometric Compare Simple EC-DH Key Agreement
Mutual Authentication with Key Establishment GP Asymmetric Authentication
Client-Application Mutual Authentication with Key GP Symmetric Authentication (Explicit Mode)
Establishment
Client-Application Asymmetric External Authenticate GP Symmetric Authentication (Implicit Mode)
To set the authentication state
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...