Binding Assurance Standard

Return to Evidence of Identity Standard

 

This standard provides specific controls for ensuring an entity is appropriately bound to their entity information and to an authenticator in order to prevent identity theft.

Application of this standard

This standard applies to any Relying Party (RP). The RP is accountable for the controls stated in this standard, even if they have employed or contracted aspects to other parties.

Application of the controls in this standard will contribute to the reduction of identity theft, entity information (account) takeover, and therefore the impacts that result.

Effective Date

This standard is effective from 1 March 2021.

It replaces part of the Evidence of Identity (EOI) Standard Version 2.0 – Dec 2009, in particular the requirements outlined in Table 8 of the EOI Standard relating to Object C – Presenter ‘links’ to identity.

Scope

This standard applies whenever an association is established between an Entity and Entity Information, and/or an Entity and an Authenticator, whether during enrolment or a subsequent transaction.

Binding an Entity to Entity Information establishes that the Entity Information, regardless of its level of assurance, relates to the Entity claiming it. Effective binding ensures the authorised use of Entity Information and Authenticators needed for business operations.

Entity Binding can be undertaken at various times over the life of the Entity Information, not just at enrolment. For example:

• when the Entity information is orphaned – through loss of all Authenticators or where no Entity Binding occurred at enrolment (e.g. registering of a birth; unassigned stored value card);
• adding new Authenticators;
• increasing the assurance level in the binding processes;
• when the Entity Information is believed to have been compromised.

The requirements in this standard are explicitly related to the binding of Authenticators and Entity Information and do not include considerations for general security, messaging methods, or implementation matters.

The binding of Entities to Entity Information, for which the Entity is not the subject, will be covered in Delegation Assurance (yet to be developed).

In relation to the scope of Identification management, this standard relates to the quality of the connections between Entities, Entity Information and Authenticators, as indicated in the diagram below.

Diagram 1: Relationship between elements

Detailed description of the image

This diagram shows a triangle representing the connection between an Entity (in this example, represented by a person) at the top of the triangle, Authenticator (represented by a key) at the bottom left, and Entity Information (represented by files of information) at bottom right.

The connection between Entity and Entity Information is labelled Entity Binding, the connection between Entity Information and Authenticator is labelled Authenticator Registration and connection between Authenticator and Entity is Authenticator Binding.

There are red circles around the Authenticator Binding connection and the Entity Binding connection to indicate the primary processes that are the scope of this standard in relation to the other elements.

There is a dotted red circle around the Authenticator Registration connection as this is a secondary process that stems from the other 2.

Relationship with other identification management standards

Table 1 describes each of the assurance components and the processes they relate to. This standard addresses the second of these assurance components – Binding Assurance.

Table 1: Assurance components

Assurance component	Description
IA Information Assurance	Robustness of the process to establish the quality and accuracy of Entity Information.
BA Binding Assurance	Robustness of the process to bind the Entity to Entity Information and/or Entity to Authenticator.
AA Authentication Assurance	Robustness of the process to ensure an Authenticator remains solely in control of its holder.
FA Federation Assurance	Additional steps undertaken to maintain the integrity, security and privacy of 1 or more credentials, and their use in many contexts.

Before applying this standard

Enrolment is a broad process which includes (but is not limited to) the initial collection of Entity Information from an Entity, the creation or association of an Authenticator, if required, and the binding of these 3 elements. Enrolment could be carried out over several transactions.

The factors for binding are the same types as those used for authentication:

• something the entity knows (knowledge factor)
• something the entity has (possession factor)
• something the entity is or does (biometric factor)

During enrolment, the provision of Entity Information by the Entity establishes a minimum level of assurance while the transaction session is maintained. As soon as there is an interruption in the transaction there is the possibility that a returning Entity may not be the same Entity that initiated the enrolment.

Document structure

This standard divides requirements into 2 sections:

• Requirements for Entity binding - Entity Binding is the process of confirming to a level of assurance, the information collected about the Entity is related to that Entity.
• Requirements for Authenticator binding - Authenticator Binding is the process of assuring the Entity can present the Authenticator which in turn gets registered in the Entity Information.

Requirements for Entity Binding

Objective 1 – Binding risk is understood

Rationale

For entities to trust that their information and the services they are enrolled in are being adequately protected from unauthorised access and use, the binding level should be consistent with the risk posed.

Relying parties may also need to achieve specific levels of assurance to mitigate risks and potentially to comply with legislation.

BA1.01 Control

The RP MUST carry out an assessment of the binding risk posed by any service before offering it.

Additional information – While any risk assessment process can be used, specific guidance is available on assessing identification risk of which binding is a part.

Objective 2 - Entity can claim an instance of Entity Information

Rationale

Before binding an Entity to Entity Information, the relevant instance of Entity Information needs to be identified.

Entity Information is expected to be specific to a single Entity, therefore only 1 Entity can have a legitimate association or binding with an instance of Entity Information.

Failure to ensure Entity Information is specific to a single Entity can result in Entity Information being inadvertently disclosed or it being taken over by another Entity once binding occurs. If there are multiple claims to the same Entity Information, counter fraud investigation might be indicated.

BA2.01 Control

The RP MUST ensure the Entity provides enough information to identify a distinct instance of Entity Information.

BA2.02 Control

The RP MUST be able to identify when an instance of Entity Information has been claimed.

Additional information – Orphaned or unclaimed instances of Entity Information are at greater risk of being incorrectly bound to an Entity. A subsequent claim to an association with Entity Information, that has already been recorded as having been bound, should raise concerns.

Objective 3 - Entity is the subject of Entity Information

Rationale

Establishing that an Entity is the subject of either Entity Information they have provided or are claiming (for example, orphaned) is fundamental to preventing impersonation of an Entity for the purposes of gaining a benefit or avoiding an obligation.

BA3.01 Control

The RP MUST establish the level of binding assurance (BA) required, for establishing the relationship between the Entity and the information collected.

BA3.02 Control

The RP selects a binding method, consistent with the level of binding assurance (BA) required, using the following binding factor types:

• knowledge factors that are not publicly known, easily determined or predictable;
• possession factors that contain enough features to assess as genuine;
• biometric factors with appropriate measures to detect spoofing attempts (e.g. recordings, masks, makeup or prosthetics etc.)

For level 1 – This control does not apply, the RP relies on the ability of the Entity to identify a distinct instance of Entity Information.

For level 2 - The RP MUST use a minimum of 1 of the binding factor types or an existing Authenticator or Credential of equal or greater assurance level.

For level 3 - The RP MUST use a minimum of 2 of the binding factor types or an existing Authenticator or Credential of equal or greater assurance level.

For level 4 - The RP MUST use a biometric factor compliant with controls AA6.04, AA6.05 and AA7.01 with either of the knowledge or possession binding factor types; or an existing Authenticator or Credential of equal or greater assurance level.

Additional information – The Authentication Assurance Standard can be used as additional guidance on desirable features for each of the factor types and their levels. An existing registered Authenticator, potentially for another delivery channel, can be used to support binding, as can Credentials.

BA3.03 Control

The RP MUST bind the Entity to Entity information using the selected method.

BA3.04 Control

The RP MUST NOT assign a level of assurance to the binding, where an Authenticator or Credential is used, if the level has not been declared.

BA3.05 Control

The RP MUST limit the number of unsuccessful attempts to bind, disallow further attempts and trigger further investigation.

BA3.06 Control

The RP applies counter-fraud techniques, where possible.

For level 1 and 2 – The control does not apply

For level 3 – The RP SHOULD apply counter-fraud techniques.

For level 4 – The RP MUST apply counter-fraud techniques.

Additional information – More information is available in the guide Counter-fraud techniques (to be developed).

BA3.07 Control

The RP MUST store appropriate detail about the Entity binding process to enable queries or investigation in the future.

Objective 4 - Entity uniqueness in a context

Rationale

Having each instance of Entity Information distinguishable from another in a context and ensuring that each instance is claimed by 1 Entity still allows for 1 Entity to claim multiple instances of Entity Information.

In some contexts, there can be an additional need to ensure that an Entity has an association to 1 and only 1 instance of Entity Information. Otherwise known as Entity uniqueness. Examples can include contexts such as passports, justice or certain entitlements.

BA4.01 Control

The RP SHOULD ensure an Entity cannot claim more than 1 instance of Entity Information, where Entity uniqueness is required by the context.

Objective 5 - Entity Binding status is maintained

Rationale

The longer an Authenticator is used to represent the binding between an Entity and Entity Information, especially when challenged remotely, the more likely it can become compromised or the Entity can have lost control of it. In this case the Entity Binding has not being maintained.

Changes to the risk profile for the service or transaction, may necessitate increasing the binding which will retest it.

BA5.01 Control

The RP retests Entity Binding at least once every 5 years to ensure it remains consistent with the level of binding assurance (BA) required.

For level 1 and 2 - The RP SHOULD undertake this control.

For level 3 and 4 - The RP MUST carry out this control unless authentication events involve a biometric factor.

 

Requirements for Authenticator Binding

Whether an Authenticator becomes associated with an Entity and Entity Information through the creation process (e.g. creation of a password or printing of a membership card) or by another method if it already exists (e.g. a Passport or mobile phone), the objectives and controls remain the same.

Authenticator Binding assurance comes from the strength of the Authenticator and the ability for the Entity to successfully respond to authentication challenges.

All bound Authenticators will be recorded in Entity information.

Objective 6 - Entity is bound to the Entity Information

Rationale

Authenticator binding can occur during enrolment or later during a subsequent transaction. In either case it is essential to ensure that the Entity has been bound to the Entity Information at the required level of assurance before attempting to bind an Authenticator.

If there has been a disruption in the binding transaction this will necessitate repeating Entity Binding when the transaction is resumed.

BA6.01 Control

The RP MUST ensure that the Entity Binding is done in the same transaction session as Authenticator Binding occurs.

Additional information – An Authenticator is not always issued when Entity Information and Entity Binding occur. If the implementation has Authenticator Binding occurring in a separate transaction a temporary Authenticator can be used to represent the Entity Binding process having previously been undertaken, providing they have the same level of assurance and this is the same or higher than the Authenticator to be bound. If the Authenticator being bound is for a new delivery channel an existing Authenticator may be presented to confirm Entity Binding, provided it has an equal or greater level of assurance.

Objective 7 - Authenticator strength is consistent with Entity Binding

Rationale

Ensuring the same Entity remains associated to their Entity Information relies on the combination of the assurance levels of both the Entity Binding and the Authenticator. If 1 is weaker it reduces the overall assurance and increases the opportunity for takeover of Entity Information by another Entity.

There are instances where Authenticators of different levels of assurance are registered in Entity Information to reflect different transaction risks. For example, submitting a tax return has a different degree of risk from updating a bank account in the same context. 

BA7.01 Control

The RP MUST ensure the assurance level of the Authenticator is consistent with the level of Entity Binding and the level of binding assurance (BA) required.

Additional information – Any strength perceived to be gained by using an Authenticator of a higher level of assurance is negated when the corresponding Entity Binding assurance is lower.

Objective 8 - Entity can control Authenticator

Rationale

Associating an Authenticator with Entity Information without first ensuring that the Entity has control of it, can result in an inability for it to be used by the Entity in a future Authentication event or increases the risk of coercion and impersonation.

BA8.01 Control

The RP MUST ensure that the Entity can respond to all the Authenticator’s challenges before the Authenticator is recorded as active in Entity Information.

Additional information – Depending on the implementation there may be a need to record the existence of the Authenticator in Entity Information before the challenges can be tested. However, the Authenticator will not be available as a recognition mechanism until successful completion of the challenges.

BA8.02 Control

The RP establishes if the Authenticator has been previously compromised to the extent it makes it unusable.

For level 1 and 2 – The control does not apply

For level 3 – The RP SHOULD check for compromise with Authenticator issuers or equivalent service providers.

For level 4 – The RP MUST check for compromise with Authenticator issuers or equivalent service providers.

Objective 9 - Authenticator is registered

Rationale

For an Authenticator to be successfully used by the Entity returning in future, there needs to be enough information recorded in Entity Information (an aspect of Entity Information that relates to Access Management) to facilitate this.

BA9.01 Control

The RP MUST record enough information in Entity Information for an Authenticator to be recognised and its Authenticator Registration status to be managed.

BA9.02 Control

The RP MUST record appropriate detail about the Authenticator binding process to enable queries or investigation in the future.

Objective 10 - Authenticator registration status is maintained

Rationale

Authenticators have lifecycles distinct from the Entity and Entity Information. Authenticators can be reused in multiple contexts, therefore connected to different instances of Entity Information. The Authenticator Registration status provides information to the Authentication process as to whether an Authenticator should be accepted, even if the responses to challenges are successful. Typical statuses can include: active, suspended, expired and revoked.

In addition, there may be changes to the control of the Authenticator by the Entity, impacting Authenticator Binding and therefore the Authentication Registration status. For example, the Entity reports the Authenticator has been lost or stolen.

BA10.01 Control

The RP MUST be able to update the Authentication Registration status to prevent authentication occurring, even if the responses to challenges are successful.

BA10.02 Control

The RP SHOULD be able to set an expiry on an Authentication Registration where the implementation indicates this to be desirable.

What does compliance mean?

In order to comply with this standard ALL the controls will be met at the level required.

Voluntary compliance by any RP wishing to follow good practice for contributing to the prevention of identity theft and fraud, will be against the levels indicated by undertaking a risk assessment.

Compliance with this Standard given through means such as contractual requirements, cabinet mandate, legislation etc., will include mechanisms for assessment and certification. The RP will meet the levels determined by the risk assessment and any additional requirements specified.

Related advice

If the RP is providing binding assurance services to other parties, there will be additional controls to be applied in the Federation Assurance Standard.

For additional guidance on implementing the controls in this standard refer to Implementing the Binding Assurance Standard.

Contact

Department of Internal Affairs Te Tari Taiwhenua

identity@dia.govt.nz