ISO/IEC 29115:2013

Information technology - Security techniques - Entity authentication assurance framework

ISO/IEC 29115:2013 provides a framework for managing entity authentication assurance in a given context. In particular, it: - specifies four levels of entity authentication assurance; - specifies criteria and guidelines for achieving each of the four levels of entity authentication assurance; - provides guidance for mapping other authentication assurance schemes to the four LoAs; - provides guidance for exchanging the results of authentication that are based on the four LoAs; and - provides guidance concerning controls that should be used to mitigate authentication threats.

Technologies de l'information — Techniques de sécurité — Cadre d'assurance de l'authentification d'entité

General Information

• Status: Published
• Publication Date: 26-Mar-2013
• ICS: 35.030 - IT Security
• ICS: 35.040 - Information coding
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27/WG 5 - Identity management and privacy technologies
• Current Stage: 9092 - International Standard to be revised
• Start Date: 03-May-2024
• Completion Date: 30-Oct-2025

Overview

ISO/IEC 29115:2013 - Information technology - Security techniques - Entity authentication assurance framework - defines a structured framework for assessing and managing entity authentication assurance. The standard specifies four Levels of Assurance (LoA1–LoA4), provides criteria and guidelines to achieve each level, and offers guidance for mapping other assurance schemes to these LoAs and for exchanging authentication results. It also covers lifecycle phases (enrolment, credential management, authentication), actors, threats and controls, and service-assurance considerations.

Keywords: ISO/IEC 29115, entity authentication, Levels of Assurance, LoA, authentication framework, credential service provider.

Key topics and technical requirements

• Four Levels of Assurance (LoA1–LoA4): Defined levels that express the degree of confidence in authentication processes; guidance on selecting an appropriate LoA for a context.
• Criteria and guidelines per LoA: Minimum technical, management and process requirements for credentials and authentication to ensure equivalence across providers.
• Phased framework: Requirements and controls are structured across the enrolment, credential management, and entity authentication phases.
• Actors and roles: Defines key actors such as Credential Service Provider (CSP), Registration Authority (RA), Relying Party (RP), verifiers and trusted third parties.
• Threats and controls: Guidance on mitigating authentication threats (e.g., impersonation, man-in-the-middle, phishing) and recommended controls, including use of multifactor authentication and protected channels (examples include SSL/TLS).
• Interoperability and mapping: Guidance for mapping external assurance schemes to the four LoAs and for exchanging authentication assertions/results between parties.
• Service assurance & management: Operational, legal, contractual and audit considerations; measures for information security management and service measurement.
• Privacy and credential characteristics: Informative annexes cover protection of PII and characteristics of credentials.

Keywords: authentication threats, multifactor authentication, credential management, identity proofing.

Practical applications

• Designing identity and authentication architectures for web services, federations, e‑commerce and government identity programs.
• Establishing trust frameworks and service-level requirements for credential service providers.
• Assessing and auditing authentication services against objective LoA criteria.
• Mapping existing authentication schemes (commercial, sectoral, national) into a common LoA taxonomy for interoperability and risk-based access control.

Keywords: identity proofing, trust framework, authentication lifecycle, federation.

Who should use this standard

• Credential Service Providers (CSPs) and Registration Authorities implementing authentication services.
• Relying Parties (RPs) defining required authentication assurance for protected resources.
• Security architects, auditors and assessors who evaluate authentication controls and assurance levels.
• Policy makers designing identity schemes and federated authentication ecosystems.

Related standards

• ITU‑T X.1254 (related recommendation)
• ISO/IEC 19790 (authentication factors), ISO/IEC 24760 (identity concepts), and other identity/security standards referenced for terminology and complementary guidance.

Keywords: ISO authentication standard, identity assurance, ISO/IEC 29115 guidance.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 29115
First edition
2013-04-01
Information technology — Security
techniques — Entity authentication
assurance framework
Technologies de l'information — Techniques de sécurité — Cadre
d'assurance de l'authentification d'entité

Reference number
©
ISO/IEC 2013
©  ISO/IEC 2013
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 [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2013 – All rights reserved

Contents Page
Foreword . iv
Introduction . v
1  Scope . 1
2  Normative references . 1
2.1  Identical Recommendations | International Standards . 1
2.2  Paired Recommendations | International Standards . 1
2.3  Additional references . 1
3  Terms and definitions . 1
4  Abbreviations . 5
5  Conventions . 6
6  Levels of assurance . 6
6.1  Level of assurance 1 (LoA1) . 7
6.2  Level of assurance 2 (LoA2) . 7
6.3  Level of assurance 3 (LoA3) . 7
6.4  Level of assurance 4 (LoA4) . 8
6.5  Selecting the appropriate level of assurance . 8
6.6  LoA mapping and interoperability . 9
6.7  Exchanging authentication results based on the 4 LoAs . 10
7  Actors . 10
7.1  Entity . 10
7.2  Credential service provider . 10
7.3  Registration authority . 11
7.4  Relying party . 11
7.5  Verifier . 11
7.6  Trusted third party . 11
8  Entity authentication assurance framework phases . 11
8.1  Enrolment phase . 12
8.2  Credential management phase . 14
8.3  Entity authentication phase . 16
9  Management and organizational considerations . 16
9.1  Service establishment. 17
9.2  Legal and contractual compliance . 17
9.3  Financial provisions . 17
9.4  Information security management and audit . 17
9.5  External service components . 17
9.6  Operational infrastructure . 18
9.7  Measuring operational capabilities . 18
10  Threats and controls . 18
10.1  Threats to, and controls for, the enrolment phase . 18
10.2  Threats to, and controls for, the credential management phase . 21
10.3  Threats to, and controls for, the authentication phase . 26
11  Service assurance criteria . 30
Annex A (informative) Privacy and protection of PII . 31
Annex B (informative) Characteristics of a credential . 33
Bibliography . 35
© ISO/IEC 2013 – All rights reserved iii

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 29115 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques.
A similar text is published as ITU-T Recommendation X.1254. It differs from this text in three instances: 1) 3.8:
the ISO/IEC definition includes asserted identities; 2) Table 10-1: ISO/IEC includes an example for
impersonation that includes use of an identity for an entity that does not exist; 3) 10.2.2.1: ISO/IEC describes
SSL as an example of a protected channel.

iv © ISO/IEC 2013 – All rights reserved

Introduction
Many electronic transactions within or between ICT systems have security requirements which depend upon
an understood or specified level of confidence in the identities of the entities involved. Such requirements may
include the protection of assets and resources against unauthorized access, for which an access control
mechanism might be used, and/or the enforcement of accountability by the maintenance of audit logs of
relevant events, as well as for accounting and charging purposes.
This International Standard provides a framework for entity authentication assurance. Assurance within this
International Standard refers to the confidence placed in all of the processes, management activities, and
technologies used to establish and manage the identity of an entity for use in authentication transactions.
Technical Management
&
Organizational
• Application and initiation • Record-keeping/ • Service establishment

Enrolment
• Identity proofing and identity recording • Legal and contractual
phase
information verification • Registration compliance
• Financial provisions
• Information security
management and audit
• Credential suspension,
• Credential creation
• External service
revocation, and/or
•Credential pre-processing
components
destruction
Credential • Credential issuance
• Credential renewal • Operational
• Credential activation
management
infrastructure
and/or replacement
• Credential storage
phase
• Measuring operational
• Record-keeping
capabilities
Entity
• Authentication
authentication
• Record-keeping
phase
Figure 1 — Overview of the Entity Authentication Assurance Framework

Using four specified Levels of Assurance (LoAs), this International Standard provides guidance concerning
control technologies, processes, and management activities, as well as assurance criteria that should be used
to mitigate authentication threats in order to implement the four LoAs. It also provides guidance for the
mapping of other authentication assurance schemes to the specified four levels, as well as guidance for
exchanging the results of an authentication transaction. Finally, this International Standard provides
informative guidance concerning the protection of personally identifiable information (PII) associated with the
authentication process.
© ISO/IEC 2013 – All rights reserved v

This International Standard is intended to be used principally by credential service providers (CSPs) and by
others having an interest in their services (e.g., relying parties, assessors and auditors of those services). This
Entity Authentication Assurance Framework (EAAF) specifies the minimum technical, management, and
process requirements for four LoAs to ensure equivalence among credentials issued by various CSPs. It also
provides some additional management and organizational considerations that affect entity authentication
assurance, but it does not set forth specific criteria for those considerations. Relying Parties (RPs) and others
may find this International Standard helpful to gain an understanding of what each LoA provides. Additionally,
it may be adopted for use within a trust framework to define technical requirements for LoAs. The EAAF is
intended for, but not limited to, session-based and document-centric use cases using various authentication
technologies. Both direct and brokered trust scenarios are possible, within either bilateral or federated legal
constellations.
vi © ISO/IEC 2013 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 29115:2013(E)

Information technology — Security techniques — Entity
authentication assurance framework
1 Scope
This International Standard provides a framework for managing entity authentication assurance in a given
context. In particular, it:
 specifies four levels of entity authentication assurance;
 specifies criteria and guidelines for achieving each of the four levels of entity authentication
assurance;
 provides guidance for mapping other authentication assurance schemes to the four LoAs;
 provides guidance for exchanging the results of authentication that are based on the four LoAs; and
 provides guidance concerning controls that should be used to mitigate authentication threats.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
2.1 Identical Recommendations | International Standards
None.
2.2 Paired Recommendations | International Standards
None.
2.3 Additional references
None.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
assertion
statement made by an entity without accompanying evidence of its validity
[ITU-T X.1252]
NOTE The meaning of the terms claim and assertion are generally agreed to be somewhat similar but with slightly
different meanings. For the purposes of this International Standard, an assertion is considered to be a stronger statement
than a claim.
© ISO/IEC 2013 – All rights reserved 1

3.2
authentication
provision of assurance in the identity of an entity
[ISO/IEC 18014-2]
3.3
authentication factor
piece of information and/or process used to authenticate or verify the identity of an entity
[ISO/IEC 19790]
NOTE Authentication factors are divided into four categories:
 something an entity has (e.g., device signature, passport, hardware device containing a credential, private key);
 something an entity knows (e.g., password, PIN);
 something an entity is (e.g., biometric characteristic); or
 something an entity typically does (e.g., behaviour pattern).
3.4
authentication protocol
defined sequence of messages between an entity and a verifier that enables the verifier to perform
authentication of an entity
3.5
authoritative source
repository which is recognized as being an accurate and up-to-date source of information
3.6
claim
statement that something is the case, without being able to give proof
[ITU-T X.1252]
NOTE The meaning of the terms claim and assertion are generally agreed to be somewhat similar but with slightly
different meanings. For the purposes of this International Standard, an assertion is considered to be a stronger statement
than a claim.
3.7
context
environment with defined boundary conditions in which entities exist and interact
[ITU-T X.1252]
3.8
credential
set of data presented as evidence of a claimed or asserted identity and/or entitlements
NOTE See Annex B for additional characteristics of a credential.
3.9
credential service provider
trusted actor that issues and/or manages credentials
2 © ISO/IEC 2013 – All rights reserved

3.10
entity
something that has separate and distinct existence and that can be identified in a context
[ITU-T X.1252]
NOTE For the purposes of this International Standard, entity is also used in the specific case for something that is
claiming an identity.
3.11
entity authentication assurance
degree of confidence reached in the authentication process that the entity is what it is, or is expected to be
[ITU-T X.1252]
NOTE The confidence is based on the degree of confidence in the binding between the entity and the identity that is
presented.
3.12
identifier
one or more attributes that uniquely characterize an entity in a specific context
3.13
identity
set of attributes related to an entity
[ISO/IEC 24760]
NOTE Within a particular context, an identity can have one or more identifiers to allow an entity to be uniquely
recognized within that context.
3.14
identity information verification
process of checking identity information and credentials against issuers, data sources, or other internal or
external resources with respect to authenticity, validity, correctness, and binding to the entity
3.15
identity proofing
process by which the Registration Authority (RA) captures and verifies sufficient information to identify an
entity to a specified or understood level of assurance
3.16
man-in-the-middle attack
attack in which an attacker is able to read, insert, and modify messages between two parties without their
knowledge
3.17
multifactor authentication
authentication with at least two independent authentication factors
[ISO/IEC 19790]
3.18
mutual authentication
authentication of identities of entities which provides both entities with assurance of each other's identity
© ISO/IEC 2013 – All rights reserved 3

3.19
non-repudiation
ability to protect against denial by one of the entities involved in an action of having participated in all or part of
the action
[ITU-T X.1252]
3.20
phishing
scam by which an email user is duped into revealing personal or confidential information which the scammer
can then use illicitly
3.21
registration authority
trusted actor that establishes and/or vouches for the identity of an entity to a CSP
3.22
relying party
actor that relies on an identity assertion or claim
3.23
repudiation
denial in having participated in all or part of an action by one of the entities involved
[ITU-T X.1252]
3.24
salt
non-secret, often random, value that is used in a hashing process
NOTE It is also referred to as sand.
3.25
shared secret
secret used in authentication that is known only to the entity and the verifier
3.26
time stamp
reliable time variant parameter which denotes a point in time with respect to a common reference
3.27
transaction
discrete event between an entity and service provider that supports a business or programmatic purpose
3.28
trust framework
set of requirements and enforcement mechanisms for parties exchanging identity information
3.29
trusted third party
authority or its agent, trusted by other actors with respect to specified activities (e.g., security-related activities)
NOTE A trusted third party is trusted by an entity and/or a verifier for the purposes of authentication.
3.30
validity period
time period during which an identity or credential may be used in one or more transactions
4 © ISO/IEC 2013 – All rights reserved

3.31
verification
process of checking information by comparing the provided information with previously corroborated
information
3.32
verifier
actor that corroborates identity information
NOTE The verifier can participate in multiple phases of the EAAF and can perform credential verification and/or
identity information verification.
4 Abbreviations
For the purposes of this International Standard, the following abbreviations apply:
CAs Certificate Authorities
CSP Credential Service Provider
CV  Card Verifier
EAA Entity Authentication Assurance
EAAF Entity Authentication Assurance Framework
IdM  Identity Management
ICT  Information and Communications Technology
IP  Internet Protocol
LoA  Level of Assurance
LoAs Levels of Assurance
MAC  Media Access Control
NPE Non-Person Entity
PII  Personally Identifiable Information
PIN  Personal Identification Number
RA  Registration Authority
RP  Relying Party
SAML Security Assertion Markup Language
SSL Secure Sockets Layer
TCP/IP Transmission Control Protocol/Internet Protocol
TLS Transport Layer Security
TPM Trusted Platform Module
TTP Trusted Third Party
URL Uniform Resource Locator
© ISO/IEC 2013 – All rights reserved 5

5 Conventions
This International Standard follows the ISO Directive, Part 2, Annex H regarding verbal forms for the
expression of provisions.
a) “Shall” indicates a requirement;
b) “Should” indicates a recommendation;
c) “May” indicates a permission; and
d) “Can” indicates a possibility and capability.
6 Levels of assurance
This Entity Authentication Assurance Framework (EAAF) defines four levels of assurance (LoAs) for entity
authentication. Each LoA describes the degree of confidence in the processes leading up to and including the
authentication process itself, thus providing assurance that the entity that uses a particular identity is in fact
the entity to which that identity was assigned. For the purposes of this International Standard, LoA is a
function of the processes, management activities, and technical controls that have been implemented by a
CSP for each of the EAAF phases based on the criteria set forth in Clause 10. Entity Authentication
Assurance (EAA) is affected by management and organizational considerations, but this International
Standard does not provide explicit normative criteria for those considerations. An entity can be a human or a
non-person entity (NPE).
For example, a network’s LoA could be a function of the LoAs of all components that make up the network
and includes NPEs or endpoint devices (e.g., mobile phones, PDAs, set-top boxes, laptops). In some
instances, endpoint devices may impersonate legitimate entities. Consequently, the ability to distinguish a
trusted device, with some degree of confidence, from a rogue device is fundamental to EAA.
LoA1 is the lowest level of assurance, and LoA4 is the highest level of assurance specified in this International
Standard. Determining which LoA is appropriate in a given situation depends on a variety of factors. The
determination of the required LoA is based mainly on risk: the consequences of an authentication error and/or
misuse of credentials, the resultant harm and impact, and their likelihood of occurrence. Higher LoAs shall be
used for higher perceived risk.
The EAAF provides requirements and implementation guidance for each of the four LoAs. In particular, it
provides requirements for the implementation of processes for the following phases:
a) Enrolment (e.g., identity proofing, identity information verification, registration);
b) Credential management (e.g., credential issuance, credential activation); and
c) Authentication.
It also provides guidance regarding management and organizational considerations (e.g., legal compliance,
information security management) that affect entity authentication assurance.
The LoAs are defined as shown in Table 6-1.
6 © ISO/IEC 2013 – All rights reserved

Table 6-1 – Levels of assurance
Level Description
1 – Low Little or no confidence in the claimed or asserted identity
2 – Medium Some confidence in the claimed or asserted identity
3 – High High confidence in the claimed or asserted identity
4 – Very high Very high confidence in the claimed or asserted identity

This framework contains requirements to achieve a desired LoA for each entity authentication assurance
framework phase. The overall LoA achieved by an implementation using this framework will be the level of the
phase with the lowest LoA.
6.1 Level of assurance 1 (LoA1)
At LoA1, there is minimal confidence in the claimed or asserted identity of the entity, but some confidence that
the entity is the same over consecutive authentication events. This LoA is used when minimum risk is
associated with erroneous authentication. There is no specific requirement for the authentication mechanism
used; only that it provides some minimal assurance. A wide range of available technologies, including the
credentials associated with higher LoAs, can satisfy the entity authentication assurance requirements for this
LoA. This level does not require use of cryptographic authentication methods (e.g., cryptographic-based
challenge-response protocol).
For example, LoA1 may be applicable for authentication in which an entity presents a self-registered
username or password to a service provider’s website to create a customized page, or transactions involving
websites that require registration for access to materials and documentation, such as news or product
documentation.
For example, at LoA1, a media access control (MAC) address may satisfy a device authentication requirement.
However, there is little confidence that another device will not be able to use the same MAC address.
6.2 Level of assurance 2 (LoA2)
At LoA2, there is some confidence in the claimed or asserted identity of the entity. This LoA is used when
moderate risk is associated with erroneous authentication. Single-factor authentication is acceptable.
Successful authentication shall be dependent upon the entity proving, through a secure authentication
protocol, that the entity has control of the credential. Controls should be in place to reduce the effectiveness of
eavesdropper and online guessing attacks. Controls shall be in place to protect against attacks on stored
credentials.
For example, a service provider might operate a website that enables its customers to change their address of
record. The transaction in which a beneficiary changes an address of record may be considered a LoA2
authentication transaction, as the transaction may involve a moderate risk of inconvenience. Since official
notices regarding payment amounts, account status, and records of changes are usually sent to the
beneficiary's address of record, the transaction additionally entails moderate risk of unauthorized release of
PII. As a result, the service provider should obtain at least some authentication assurance before allowing this
transaction to take place.
6.3 Level of assurance 3 (LoA3)
At LoA3, there is high confidence in the claimed or asserted identity of the entity. This LoA is used where
substantial risk is associated with erroneous authentication. This LoA shall employ multifactor authentication.
Any secret information exchanged in authentication protocols shall be cryptographically protected in transit

LoA is a function of the processes, management activities, and technical controls that have been implemented by a
CSP for each of the EAAF phases based on the criteria set forth in Clause 10.
© ISO/IEC 2013 – All rights reserved 7

and at rest (although LoA3 does not require the use of a cryptographic-based challenge-response protocol).
There are no requirements concerning the generation or storage of credentials; they may be stored or
generated in general purpose computers or in special purpose hardware.
For example, a transaction in which a company submits certain confidential information electronically to a
government agency may require a LoA3 authentication transaction. Improper disclosure could result in a
substantial risk for financial loss. Other LoA3 transaction examples include online access to accounts that
allow the entity to perform certain financial transactions, or use by a third party contractor of a remote system
to access potentially sensitive client personal information.
6.4 Level of assurance 4 (LoA4)
At LoA4, there is very high confidence in the claimed or asserted identity of the entity. This LoA is used when
high risk is associated with erroneous authentication. LoA4 provides the highest level of entity authentication
assurance defined by this International Standard. LoA4 is similar to LoA3, but it adds the requirements of in-
person identity proofing for human entities and the use of tamper-resistant hardware devices for the storage of
all secret or private cryptographic keys. Additionally, all PII and other sensitive data included in authentication
protocols shall be cryptographically protected in transit and at rest.
For example, services where there is a potential high risk for harm or distress in case of an authentication
failure may require LoA4 protection. The responsible party needs full assurance that the correct entity
provided certain critical information, and the responsible party may even be criminally liable for any failure to
verify the information. Finally, approval of a transaction involving high risk of financial loss may be a LoA4
transaction.
At LoA4, digital certificates (e.g., X.509, Card-Verifier (CV) certificates) may be used to authenticate NPEs,
such as laptops, mobile phones, printers, fax machines, and other devices connected to a network. For
example, the smart phone enrolment process may require the deployment of digital certificates to the smart
phone. Also, in order to prevent unauthorized access to the power grid, digital certificates may be used in the
deployment of smart meter technologies.
6.5 Selecting the appropriate level of assurance
Selection of the appropriate LoA should be based on a risk assessment of the transactions or services for
which the entities will be authenticated. By mapping impact levels to LoAs, parties to an authentication
transaction can determine what LoA they require and can procure services and place reliance on assured
identities accordingly. Table 6-2 indicates possible consequences and impacts of authentication failure at the
various LoAs.
Table 6-2 – Potential impact at each level of assurance
Potential impact of
authentication failure by LoA
Possible consequences of authentication failure
1 2 3 4
Inconvenience, distress or damage to standing or reputation Min* Mod Sub High
Financial loss or agency liability Min Mod Sub High
Harm to the organization, its programs, or public interests N/A Min Mod High
Unauthorized release of sensitive information N/A Mod Sub High
Min Sub
Personal safety N/A N/A
Mod High
Civil or criminal violations N/A Min Sub High
* Min=Minimum; Mod=Moderate; Sub=Substantial; High=High

Determination of what constitutes minimum, moderate, substantial, and high risk depends on the risk criteria
defined by the organization using this standard for each of the possible consequences. Additionally, it is
possible to have multiple impact scenarios (e.g., consequences could include harm to the organization, as
8 © ISO/IEC 2013 – All rights reserved

well as, unauthorized release of sensitive information). In multiple impact scenarios, the highest LoA
corresponding to consequences should be used.
Each LoA shall be determined by the strength and rigor of the controls and processes for each phase of the
EAAF that the CSP applies to the provision of its service. The EAAF establishes a need for operational
service assurance criteria at each LoA for CSPs. Service assurance criteria are introduced in Clause 11, but
specific requirements are out of scope for this International Standard.
There may be other business related factors to take into account, beyond the scope of security, when using
the results of the risk assessment to determine the applicable LoA. Such business factors may include:
a) The organization’s approach to managing residual risk;
b) The organization’s appetite for accepting risk in terms of the impacts shown in Table 6-2; and
c) The business objectives for the service (e.g., a service with the business objective of driving uptake may
be better served by a lower LoA using a credential such as a password, if the organization has processes
in place to mitigate fraud and is comfortable accepting the risk of fraud).
The risk assessment of a transaction may be conducted as a part of organization’s overall information security
risk assessment (e.g., ISO/IEC 27001) and should focus on the specific need for security in the transactions
being contemplated. The risk assessment shall address risk related to EAA. The results of the risk
assessment shall be compared to the four LoAs. The LoA that best matches the results of the risk assessment
shall be selected.
Where multiple classes of transactions are envisaged, it is possible that a different LoA applies to each
transaction or to groups of transactions. In other words, multiple LoAs may be accepted by a single
organization, according to the specific transaction in question.
6.6 LoA mapping and interoperability
Different domains may define LoAs differently. These LoAs will not necessarily support a 1-to-1 mapping to
the four LoAs described in this Framework. For example, one domain may adopt a four-level model, and
another domain may adopt a five-level model. The various criteria for the different authentication models must
be separately defined and widely communicated.
In order to achieve interoperability between different LoA models, each domain shall explain how its mapping
scheme relates to the LoAs defined in this standard by:
a) Developing a well defined entity authentication assurance methodology, including well defined categories
of LoAs; and
b) Widely publishing this methodology so that organizations wishing to enter into federation-type
agreements with them can clearly understand each other’s processes and terminology.
The LoA methodology shall take into account and clearly define LoAs in terms of a risk assessment that
specifies and quantifies:
a) Expected threats;
b) Impacts (i.e., min, mod) should threats become reality;
c) Identification of threats that must be controlled at each LoA;
d) Recommended security technologies and processes for use in implementing controls at each LoA, such
as specifying a credential be carried on a hardware device (e.g., smart card) or specifying requirements
for the generation and storage of credentials; and
e) Criteria for determining the equivalence of different combinations of authentication factors taking into
account both identity proofing and associated credentials.
© ISO/IEC 2013 – All rights reserved 9

One approach to address the issue of mapping/bridging between different LoA models may be to use the four-
level model defined in this document and map other n-level models against it. This method would allow
identity federations using different models for authentication assurance to map against the four-level model.
Mappings shall define how un-mapped LoAs will be handled, which may be to simply ignore them or to
effectively map them to the next lowest level (since there could be no basis for assuming a higher LoA if it had
not been specifically determined beforehand).
6.7 Exchanging authentication results based on the 4 LoAs
Actors participating in an authentication transaction (e.g., CSPs, RPs) may need to exchange information to
complete the transaction or activity.
The range of actions includes, but is not limited to, the following:
a) Allowing an RP to express its expectations for the LoA at which an entity should be authenticated;
b) Allowing an entity or CSP to indicate the actual LoA in its responses;
c) Allowing an entity or CSP to advertise those LoAs for which it has been certified capable of meeting the
requirements associated with that LoA.
Actors participating in an authentication transaction shall agree on the protocol, semantics, format, and
structure of the information to be exchanged. The RP may need to specify if it will accept any authentication
response other than that exactly requested.
While digital certificates are an established way to convey information concerning assurance of related
credentials, metadata is increasingly being used as a method to communicate what assurance requirements
the exchanging parties have. A Context Class, such as a Security Assertion Markup Language (SAML)
Authentication Context Class in the form of a URI, is a well-known mechanism for parties to express those
classes concerning authentication assurance in authentication requests and assertions. For example, a typical
assertion from an identity provider might convey information such as “This user is John Doe; he has an email
address of [e-mail]; and he was authenticated into this system using a password
mechanism.”
The remainder of this Framework addresses the structure within which processes and requirements for
services are established and the threats and impacts relating to entity authentication. It concludes with an
overview of the need for service assurance criteria against which services may be assessed to ensure that the
appropriate LoA is assigned to achieve adequate credentialing services.
7 Actors
The actors involved in the EAAF include entities, CSPs, RAs, RPs, verifiers, and TTPs. These actors may
belong to a single organization or separate organizations. There may be a variety of relationships and
capabilities provided by a number of organizations including shared or interacting components, systems, and
services.
7.1 Entity
An entity can have its identity authenticated. The ability to authenticate an entity depends on a number of
factors. In the context of this Framework, the ability to authenticate an entity implies that the entity has been
registered and issued the appropriate credentials by a CSP and that an authentication protocol has been
specified. During authentication, the entity may attest to its own identity. It is also possible that there is a
separate party representing the entity for the purposes of authentication.
7.2 Credential service provider
A credential service provider (CSP) issues and/or manages credentials or the hardware, software, and
associated data that can be used to produce credentials. Passwords and biometric characteristics are
examples of a credential that may be issued and managed by a CSP. Smart cards containing private keys are
an example of hardware and associated data (that can be used to produce credentials) that may be issued
10 © ISO/IEC 2013 – All rights reserved

and managed by a CSP. A CSP may also issue and manage data that can be used to authenticate credentials.
If passwords are used as credentials, this data may be the values of one-way functions of the passwords. If
credentials are based on digitally-signed information, CSPs may produce public key certificates that can be
used by verifiers. The credentials that are issued and supported, as well as the safeguards that are
implemented by the CSP, are key factors in determining which LoA will be reached during a particular
authentication transaction (see also clause 10.3).
Every entity shall be issued one or more credentials, or means to produce credentials, to enable later
authentication. Credentials, or means to produce credentials, are typically only issued after successful
completion of an enrolment process, at the end of which the entity is registered.
7.3 Registration authority
A Registration Authority (RA) establishes and/or vouches for the identity of an entity to a CSP. The RA shall
be trusted by the CSP to execute the processes related to the enrolment phase and register entities in a way
that allows later assignment of credentials by the CSP.
Each RA shall perform some form of identity proofing and identity information verification according to a
specified procedure. In order to differentiate the entity from other entities, an entity is typically assigned one or
more identifiers, which will allow the entity to be recognized later in the applicable context.
7.4 Relying party
An RP is an actor that relies on an identity claim or assertion. The relying party may require an authenticated
identity for a variety of purposes, such as account management, access control, authorization decisions, etc.
The relying party may itself perform the operations necessary to authenticate the entity, or it may entrust these
operations to a third party.
7.5 Verifier
The verifier is an actor that corroborates identity information. The verifier can participate in multiple phases of
EAA and can perform credential verification and/or identity information verification.
7.6 Trusted third party
A TTP is an authority or its agent, trusted by other actors with respect to certain activities (e.g., security-
related activities). For this Framework, a TTP is trusted by an entity and/or a verifier for the purposes of
authentication. Examples of TTPs for the purposes of entity authentication include Certification Authorities
(CAs) and Time-Stamping Authorities.
8 Entity authentication assurance framework phases
This clause provides a description of the phases and processes of EAA. Although some EAA models may
differ from the structure of this model, conformance to this model requires that functional capabilities fully meet
the requirements set out in this Framework. This Framework is technology neutral.
Organizations adopting this Framework shall establish policies, procedures, and capabilities that provide the
necessary supporting processes and fulfil requirements set forth in this Framework. These will vary according
to the role chosen by a particular organization and, for instance, the LoAs at which an organization provides
credentials. For example, an organization may be subject to:
a) Requirements for particular actions on behalf of the organization or its representatives related to
particular LoAs;
b) Requirements for external or third party assessment of an organization’s operational capability within the
EAAF; and
c) Policies, actions, and capabilities necessary to establish the trustworthiness of the processes, services,
and capabilities provided by organizations adopting the Framework.
© ISO/IEC 2013 – All rights reserved 11

8.1 Enrolment phase
The enrolment phase consists of four processes: application and initiation; identity proofing; identity
information verification; and record-keeping/recording. These processes may be conducted entirely by a
single organization, or they may consist of a variety of relationships and capabilities provided by a number of
organizations including shared or interacting components, systems, and services.
The required processes differ according to the rigor required by the applicable LoA. In the case of an entity
enrolling under LoA1, these processes are minimal (e.g., an individual may click a “new user” button on a
webpage and create a username and password). In other cases, enrolment processes may be extensive. For
example, enrolment at LoA4 requires an in-person meeting between the entity and the RA, as well as
extensive iden
...