Implementing the Binding Assurance Standard
Guidance on the Binding Assurance Standard and how to comply with the controls.
Help us create the best guidance possible
If you would like anything added to or clarified in this guidance, email the Identification Management team at identity@dia.govt.nz.
Introduction
Binding Assurance is about the degree to which an entity claiming information is the actual subject of that information (does the information belong to or relate to someone or something else) and, if an Authenticator is to be used, is this also bound to the same degree.
If binding is not done or insufficiently done, it increases the likelihood of identity theft and service takeover. This is covered in the Binding Assurance Standard.
Binding Assurance does not make any judgement as to whether the Entity Information is accurate or not, this is covered as part of the Information Assurance Standard.
Definitions for key terms used in this guidance can be found in Identification terminology.
This is living guidance and will be evolved and expanded over time to meet the needs of users.
Guidance 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.
Objective 1: Binding risk is understood
Applying a risk-based approach to binding assurance helps to identify the aspects of binding that drive the level of risk. Understanding this enables the development of a wide range of mitigation strategies.
BA1.01 Guidance — risk assessment
Any robust risk assessment process may be used to identify the binding risk posed. The guidance provided in Assessing identification risk has been developed to improve the quality of this assessment.
A workbook has also been developed to help with undertaking an identification risk assessment and to provide the optimum level of assurance as an output.
For a copy, email identity@dia.govt.nz.
Objective 2: Entity can claim an instance of Entity Information
During an enrolment process, the Entity remains linked to the Entity Information they have provided, if it is carried out in a single session.
If there is a break in the enrolment process or when the Entity returns to the service in the future, without an Authenticator, they need to be able to claim (connect) to their instance of Entity Information. Instances of Entity Information that are not currently bound to an Entity or Authenticator are deemed to be orphaned.
There are some contexts where Entity Information may be received by a Relying Party outside an enrolment process. This is unclaimed Entity Information in the context of that Relying Party. For example, a hospital provides the Registrar of Births, Deaths and Marriages, information about the birth of a child. Or the Electoral Commission provides a Local Body, information about eligible voters for an upcoming election.
Both the Registrar and the Local Body now hold Entity Information that an Entity has yet to claim.
An instance of Entity Information is often referred to as an ‘account’ or a ‘record’. When stored in a system, Entity Information may not be in one place. How and where Entity Information is stored is outside the scope of Identification Management.
BA2.01 Guidance — identify instance of Entity Information
Depending on the context, individual attributes within Entity Information can be similar or the same.
If the Relying Party does not collect enough information to identify the right instance, multiple instances of Entity Information can be found and there is an increased likelihood the incorrect instance might be used.
Additional information should be requested until it is certain the correct instance has been identified, before beginning any binding processes.
BA2.02 Guidance — instances are known to be claimed
Not recording any information about an attempt to claim an instance of Entity Information, successful or not, can increase the likelihood that the Entity Information becomes vulnerable to being taken over by an Entity who is not the rightful claimant.
The recording or registering of Authenticators is the easiest way in which to do this.
If a subsequent claim occurs to Entity Information that has already been recorded as having been bound, this should raise concern.
An investigation should occur to determine the rightful claimant. Where the Entity Information has either been orphaned or unclaimed for any period, it should never be assumed that the first Entity to claim the instance is the correct one.
Objective 3: Entity is the subject of Entity Information
Failure to identify the correct Entity Information is an avenue for identity theft. Failure to carry out sufficient binding of an Entity to Entity Information is another. These controls cannot be replaced by relying on or increasing the level of information assurance.
BA3.01 Guidance — establish binding level
The Identification risk assessment process can be used to determine the level of binding assurance (BA) required, for linking or binding the Entity to their information.
Alternatively, use an analytical assessment considering the following:
- the key business drivers and outcomes
- risk of financial loss or liability
- risk to the privacy, standing, reputation or safety of people
- harm to agency programmes or the public interest
- any direct downstream effects, this could include other parties that will rely on the outcome (for example, a credential).
- Level 1 — Binding is very light, possibly aligned to self-asserted information, nil or negligible impact if another Entity uses the information.
- Level 2 — A distinct link is needed between the Entity and their information for some business decisions. There is some expectation by the Entity that their information is not being misused.
- Level 3 — The Entity and Entity Information need to be solidly bound to ensure that decisions made, and services provided are to the entitled Entity. Impacts from incorrect binding are moderate. There is a strong expectation by the Entity that their information is not being misused.
- Level 4 — It is critical that the Entity and Entity Information are firmly bound, decisions made, and services provided to a non-entitled Entity have severe impacts. There is a very high expectation by an Entity that their information is not being used by any other party.
BA3.02 Guidance — design binding process
Binding is most often done using a Credential established in another context.
All binding relies on the ability of the Entity to respond to challenges using 1 or more of the following 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.
For more information on the factor types and the forms they can take, refer to Authenticator types.
The more critical the risk associated with incorrect binding, the higher the level needed and therefore the number of factors that need to be successfully responded to.
It’s difficult to use knowledge factors for binding, when they are not part of an existing Credential or Authenticator.
It requires access to enough Entity Information that the responses to challenges are unlikely to be known by others, including family, close friends and social media contacts.
Note: Responses to knowledge factor challenges do not include any questions asked for the purposes of identifying which instance of Entity Information the Entity is to be bound to.
Possession factors used on their own are the weakest form of binding because they can be transferred to another Entity, either with or without the Entity’s knowledge.
Usually a possession factor will be a Credential produced from another context and will often be combined with another factor. For example, it may have an image of the Entity embedded in it.
Single-factor:
- Physical presentation of a birth certificate, certificate of a qualification, membership card or credit card.
- An online transaction that requires entry of credit card details including the CSV code off the back of the card.
- A virtual credential accessed by a mobile phone.
Multi-factor:
- A physical membership, access or employment card that contains a photo.
- A virtual credential accessed by a password and mobile phone.
Biometric factors used for binding can be implemented using manual or automated comparison processes.
Biometric characteristics will be non-existent or difficult to establish for non-human Entities, so are unlikely to be used for these entity types.
- Manual comparisons of an Entity to an image on a document, for example, a passport.
- Automated comparison of an iris scan with a database of pre-registered Entities.
- A statement by a trusted party that an image is a true likeness of the Entity.
When using a Credential of equal or greater assurance level, the Credential will need to contain some information matching the Entity Information to be bound.
The number of binding factors in the Credential’s authentication mechanism will need to be equal to or greater than those of the level being met.
Using a passport:
A passport could be used to bind at levels 1, 2 and 3 if it is physically presented, information in the passport is consistent with the Entity Information, it has a declared level of Binding Assurance of at least 3 and the photograph is compared manually with the Entity.
To be able to be used for level 4, it will require the declared levels of Binding Assurance to be 4, the chip to be accessed and a biometric recognition system meeting controls AA6.04, AA6.05 and AA7.01 to be used for the facial comparison.
Using RealMe:
A RealMe Verified Account could be used to bind up to level 3 as the Authenticator attached to it is level 3, provided it also declares Binding Assurance at level 3.
Note: An instance of a Credential where the Binding Assurance level is higher than the Information Assurance level has not been identified. Therefore, it is not currently known if there are any related requirements needed for the level of Information Assurance, when binding.
Using an Authenticator of equal or greater strength only applies when the context has an existing Authenticator in place, for another delivery channel. For example, using an Authenticator for the phone channel to confirm the Entity Binding for an interaction online or in-person.
BA3.03 Guidance — carry out binding
It is ineffective to have a binding process and not undertake the process when initially enrolling an Entity or subsequently associating an Entity to an already held instance of Entity Information. Or to carry out an alternative process that is weaker.
This increases the likelihood that Entity Information will be stolen and therefore being used to commit fraud. Examples of binding processes are in the guidance on BA3.02.
BA3.04 Guidance — level assumptions
If the Credential Provider has not indicated the level(s) of assurance of their credential, it can be dangerous to assume what these might be. Ideally, the Credentials should be treated as level 1. However, until declaration of levels of assurance becomes embedded, a pragmatic approach to accepting Credentials as having higher levels will need to be taken.
Estimation of levels of assurance, when not declared, will need to be done in conjunction with the Credential Provider and expertise in the application of the Identification standards.
BA3.05 Guidance — limit unsuccessful attempts
Allowing an Entity to continue to attempt to bind to a record can indicate an attempt to associate with another Entity’s information. This can be for the intention of undertaking fraud or just to cause nuisance.
Letting this continue unchecked increases the likelihood that an unauthorised Entity will eventually be successful.
The number of allowable attempts will be proportional to the risk of incorrect binding, which has been established and the other mitigation which are in place.
BA3.06 Guidance — counter-fraud
Counter-fraud techniques are activities that contribute to binding assurance after the decision to bind and to complete the enrolment of the Entity.
For more information refer to guidance on Counter fraud techniques.
BA3.07 Guidance — investigation
It is important to keep good records, regardless of the way in which binding assurance is carried out. The ability to investigate the processes, is a contributing element to building trust in those processes.
What and how much information is recorded about the processes undertaken will depend on the risk behind the need for enrolling the Entity plus any requirements under legislation, such as the Public Records Act 2005.
Objective 4: Entity uniqueness in a context
There is a substantial difference between ensuring that each instance of Entity Information in a context is unique and ensuring that each Entity participating in a context has only 1 instance of Entity Information.
A single Entity associating themselves with multiple instances of Entity Information can have negative outcomes in certain contexts. For example, passports, justice or certain entitlements.
BA4.01 Guidance — 1 and only 1
Currently the most effective way to ensure an Entity is only enrolled once in a context is to use a biometric characteristic in which any new Entity entering the context is compared to all existing Entities in the context to reduce duplication.
As this is a costly exercise to do, the risk being mitigated and the benefits of doing so need to be considered.
Objective 5: Entity Binding status is maintained
Once an Entity has been bound to Entity Information, it will only last for the length of that interaction. When the Entity leaves it is broken. The essence of the binding can be held through the registering of an Authenticator at the equivalent level. However, if this Authenticator does not have a biometric component, there is a risk that over time it may come into the possession of another Entity. Possession by another Entity means that the binding between the Entity and Entity Information is also compromised.
To mitigate against misappropriated and misused Authenticators, retest at Entity Binding at regular intervals. Retesting also ensures that Entity Information not used on a regular basis is appropriately managed if the Entity it relates to is deceased or otherwise inactive.
This also provides an opportunity to increase the binding level if additional risk is present.
Changes to the risk profile for the service or transaction and increases in binding level, are also opportunities to proactively retest Entity Binding.
BA5.01 Guidance — retest binding
Retesting Entity Binding involves carrying out an event that does not rely solely on the Authenticator, unless it contains a biometric factor as part of the authentication process.
These events should involve direct contact with the Entity but do not necessarily have to take place face-to-face. For example, it could be by phone.
If the Entity has an Authenticator with a biometric element but it is not the primary method of authentication this could be used to facilitate the process of retesting the Entity Binding.
- Every time a passport is physically presented, and the image is compared with the holder, the binding is being tested.
- An Entity Binding process done when a Credential (especially one without a biometric) is being reissued or renewed after expiry.
- Requiring an Entity to attend in-person every so often, where a binding process occurs, in order to continue to receive the benefit of a service.
Guidance 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.
Objective 6: Entity is bound to the Entity Information
It is important to ensure the Entity is the rightful claimant of the Entity Information before binding an Authenticator to an Entity and registering it in Entity Information. This is an avenue for the takeover of Entity Information. It can also increase the likelihood of the wrong Entity Information being used.
BA6.01 Guidance — confirm Entity Binding
Ensure the Entity Binding and Authentication Binding occur within the same transaction session. For example, information collection, binding and establishment of an Authenticator are all part of one continuous process.
If this is not possible, either a temporary binding mechanism can be used to bridge the gap or the Entity Binding process needs to be repeated.
- At levels 1 and 2, a unique reference number can be provided to use when returning to complete the Authenticator Binding process. For example, an application number.
- At level 3, a receipt is issued to acknowledge completion of the information collection and Entity Binding steps. On returning, the receipt is required to be produced and some challenge questions also need to have the correct responses before the Authenticator Binding process begins.
Where there have been other Authenticators registered, these can be used to add new Authenticators at the same or lower levels.
Objective 7: Authenticator strength is consistent with Entity Binding
As the role of the Authenticator is to reconfirm the Entity’s connection to their Entity Information each time Entity Information is used, it needs to be consistent with the level of Entity Binding that was done.
BA7.01 Guidance — levels are consistent
If the Entity Binding and Authenticator (through the test of its control) are at different levels, then the level of Binding Assurance reflects the lower.
In some contexts, multiple Authenticators of differing levels can be added to reflect usability when accessing transactions of differing risk levels. In this case at least one Authenticator should reflect the level of Entity Binding.
Note: The level of Binding is not increased by the addition of a stronger Authenticator without also increasing the Entity Binding to the same level.
Objective 8: Entity can control Authenticator
If an Entity has not been challenged to respond to an Authenticator during its registration, it can provide a poor customer experience if they are then unable to respond at the first authentication event.
Failing to check that the Entity is in control of an Authenticator also removes an opportunity to detect if the Entity is being coerced to add an Authenticator controlled by someone else.
BA8.01 Guidance — control of Authenticator
The type of Authenticator will determine when the testing of control of an Authenticator occurs in the overall process of adding an Authenticator. The important thing is that the ability to authenticate using the Authenticator does not become active until both the registration and test of control have been completed.
- A mobile phone number is recorded for use as part of an Authenticator, a challenge is sent to the phone which must be correctly responded to, before the phone number becomes actively registered.
- An Entity establishes control by creating their own password during enrolment, that is registered instantaneously as part of adding an Authenticator.
Note: If an Authenticator has multiple factors, all the factors need to be challenged and successfully responded to.
BA8.02 Guidance — check for compromised Authenticators
A compromised Authenticator is one that has been recorded as being lost, stolen or misused. It can also include Authenticators that have been revoked, where this is not able to be detected as part of the Authentication process.
There are various registers and services available for undertaking these checks though many are only available to certain sectors.
- Waka Kotahi New Zealand Transport Agency provides a service to financial institutions to check the validity of information on a New Zealand driver licence, including if the version number is still current.
- There are several services that record privacy breaches involving passwords. For example, https://my.vericlouds.com/
- Watchlists can also include compromised credentials.
Objective 9: Authenticator is registered
Authenticator Registration is the recording of information about an Authenticator so it can be used as a mechanism for recognising the Entity when they return to the context. Information about the Authenticator forms part of Entity Information.
BA9.01 Guidance — record Authenticator
Information about an Authenticator can include reference numbers and identifiers for the Authenticator.
Where the information includes the answers to knowledge factors for example, passwords and PINS, appropriate measures should be taken to protect this information. Refer to Information Security specialists for more guidance on this.
Information to allow an Authenticator’s status to be maintained can include, status indicators, dates, and other flags that the Access Management system can use to determine if attempts to use the Authenticator should be accepted, even if the responses to the challenges are correct.
BA9.02 Guidance — investigation
It is important to keep good records regardless of the way an Authentication binding is carried out.
The ability to investigate the processes is a contributing element to building trust in those processes.
What and how much information is recorded about the processes undertaken will depend on the risk behind the need for registering the Authenticator plus any requirements under legislation, such as the Public Records Act 2005.
Objective 10: Authenticator registration status is maintained
The lifecycles of Authenticators, Entities and Entity Information are all independent. Authenticators can also be reused in multiple contexts, and are therefore connected to different instances of Entity Information.
The Authenticator Registration status provides information to the Authentication process and/or an access management system as to whether an Authenticator should be accepted, for the context. This is irrespective of whether the responses to challenges are successful or not.
BA10.01 Guidance — Authenticator status
Typical Authenticator statuses can include: active, suspended, expired and revoked. Changes to the status can be initiated by the organisation or the Entity. Examples include, business rules, detection of fraud, the reporting of a lost or stolen Authenticator, or other unauthorised access to Entity Information.
The information to allow an Authenticator’s registration status to be maintained can include, status indicators, dates, and other flags that the access management system can use to determine if attempts to use the Authenticator should be accepted.
BA10.02 Guidance — expiry
Setting an expiry date on Authentication Registration is an ideal way to initiate the rechecking of Authenticators, Authenticator Binding and Entity Binding processes.
- Debit and credit cards do not work indefinitely — they cease to work after the month printed on the card.
- Automated Password resets. Note that where a password has been used in multiple contexts it does not impact all of them. This is because it is the Authenticator Registration aspect that is being expired, not the password itself.
Related advice
If there is an intention to provide binding assurance or other identification services to other parties, the requirements and guidance for Federation Assurance should also be applied.
The following resources are also related to this topic:
Contact
Te Tari Taiwhenua Department of Internal Affairs
Email: identity@dia.govt.nz
Utility links and page information
Last updated
