This guidance describes how values for information are derived, inferred or estimated from other information. It also explains the levels of assurance of these values.
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
Within Identification Management, pieces of information (or attributes) have values. For example, ‘’ is a date value and ‘blue’ is a colour value.
Most of the time these values are authoritative values or copies of authoritative values. This is the most common method of establishing values, but there are other methods.
This guidance describes:
the methods used to establish values and where these values fit within the levels of information assurance
the concepts of low and zero-knowledge proofs when information is presented.
There are 4 main ways to establish values. Each is described here.
Establishing an authoritative value
An authoritative value is established or created by the authority for the information.
The value is deemed to be accurate regardless of the method or process the authority uses to establish the value.
Examples of authoritative values
An Entity saying their favourite colour is ‘blue’.
Date of birth established by the registrar of births.
Establishing a derived value
A value is derived when it is directly calculated from one or more values.
Examples of derived values
The initials JPG are derived from the name John Paul Getty.
An Entity’s age is derived from its date of creation or birth and another point in time, such as today.
A suburb is derived from its postal code.
An Entity saying their age is ‘32’.
Establishing an inferred value
An inferred (or deduced) value takes 1 or more pieces of information and makes an assumption. As many other things could influence the assumption, these values are more subjective and less certain.
Often inferred values are not directly related to the value (or values), that’s being used for the assumption.
While using more points of reference can increase the likelihood of the value being accurate, it cannot be assumed that it is accurate. This impacts the Level of Information Assurance (LoIA).
Examples of inferred values
A person wears lots of blue clothing so blue is their favourite colour.
A person has a credit card so they’re over 18 years old.
A person needs to be 18 years old to be enrolled to vote, so people on the electoral role are at least 18 years old.
A person works and shops in a place, so this is where they live.
Aggregating an Entity’s social media posts and then making assumptions about their political views, their age, or their preference for cats over dogs.
Establishing an estimated value
A value is deemed to be estimated if it is established using statistical analysis.
An estimated value may come from large sets of information such as financial, biometric (physical or behavioural) or locational.
Estimations using biometric information have the benefit of also being bound to the Entity that’s the subject of the estimation.
Examples of estimated values
By analysing a facial image against known parameters, it’s estimated that this person is aged 40 or between 35 and 45 years old.
After analysing voice recordings against known parameters, it’s estimated that this person is in a bad mood or comes from a particular region.
By analysing financial transactions on spending, it’s estimated an Entity’s salary is $50,000 per year.
Information Privacy Principles are to be applied to all information collected or generated.
How values are expressed
A large portion of the information used in identification management uses formatting standards, such as for dates, account numbers and addresses.
Most values are expressed as ordinary alpha or numeric values. However, some are both alpha and numeric.
Values can also be expressed in the following ways.
Ranges
Values can be expressed as a range such as between x and y or greater than x and less than y. This can include statements like under or over. For example, the Entity is under 65 years of age or over 18 years of age.
Binary response
If a request for information comes as a closed question about the value of a piece of information or attribute, then the value of the response can be expressed in binary forms such as:
1 or 0
Yes or No
green tick or red cross.
Some responses might allow for the addition of values (such as other, exception or maybe), which can invite the Relying Party to take other actions that are specific to the context.
Codes
A value can be replaced by a code to:
save system storage space
reduce the size of information sharing files
obscure a value from being read by unauthorised parties.
Examples of where codes are commonly used
the names of countries expressed as 2 or 3 letter country codes for which there are international standards.
codes for airports in the aviation industry.
codes to represent gender.
Whenever codes are used to reduce information, the Relying Party will need to have access to data which decodes the values. This data could be public or private.
Applying levels of information assurance
The method used to establish a value impacts the level of assurance that can be achieved by the value.
The level of information assurance is only an indicator of the accuracy of a value. Entity binding is still needed to ensure the value relates to the Entity that’s claiming it.
Authoritative and derived values
The level of information assurance for these reflect the:
value’s distance from the authoritative source
quality of the evidence used to verify the value.
The controls for levels of information assurance are contained in the Information Assurance Standard.
A derived value calculated from an authoritative value inherits the assurance level of the authoritative value. However, when the Relying Party stores a value, it becomes a copy and drops down a level of assurance.
Examples of derived value assurance levels
If a date of birth is known to be LoIA3, then an age derived from this date of birth is also LoIA3.
If total income of ‘$31,576.23’ is known to be LoIA2, then an income range of between $30k and $35k derived from that, will also be LoIA2.
Inferred values
Inferred values, like derived values, inherit the LoIA of the information that’s used for the inference. But this is only if there are no exceptions or conditions associated with the information from which it was inferred.
When there are exceptions or conditions that could impact the assumption, the lowest level of information assurance (LoIA1) is used.
Examples of inferred value assurance levels
Where marriage is only permitted between individuals over the age of 16, a valid government-issued marriage certificate containing name information at LoIA3, would infer that the named individuals are over 16 to LoIA3.
Regardless of the LoIA of the information about where a person works and shops, they could live at a different location. So, the inference that they live at the same location as where they work and shop will be at LoIA1.
A person’s decision to wear blue maybe influenced by an employment policy rather than their personal choice, so inferring blue is their favourite colour will be at LoIA1.
Estimated values
In general, estimated values should be considered as LoIA1 for accuracy. This is because even those using authoritative information or attributes, are based on probabilistic prediction.
Estimated value results will always include false positives and false negatives.
There are some situations where a Relying Party can have more trust in an estimated value and accept it as LoIA2.
However, the added situations will not be sufficient for an estimated value to be considered as equal to an authoritative source or to a direct copy it.
A Relying Party will need to implement additional risk mitigations where the risk indicates that a higher level of assurance is needed.
Situations that may increase trust in an estimated value:
the information source on which the estimate is based
the method of estimation used
whether the estimation is expressed precisely or as a range, thereby allowing for margins of error
if the information used for the estimation has no uncounted or uncontrollable factors that could impact the result. For instance, if a facial expression in an image cannot be controlled it could impact the result, such as smiling reducing an age estimate
whether the method of estimation has empirical evidence of its efficacy.
Examples of estimated value assurance levels
Estimation of a facial image using an unknown method and source to be 40 years old, LoIA1.
Estimation of a facial image of the live Entity using a reliable verified method to be between 35 and 45 years old, LoIA2.
Analysing voice recordings to estimate mood and region would likely have too many uncounted and uncontrollable factors to be more than LoIA1.
An analysis of spending does not account for whether the person spends all their money or saves some, so an estimated salary of $50,000 per year is LoIA1.
An analysis of spending does not account for the source of income, so an estimated salary of more than $50,000 per year would still need to be taken as LoIA1.
Presentation of information
The following guidance is for Credential and Facilitation Providers who provide values on which others rely, that are derived, inferred or estimated.
Meta data about how the value was created
A Credential or Facilitation Provider must advise the Relying Party when the information given has been derived, inferred or estimated.
Additional information about the value that can be made available to the Relying Party includes:
the method used to establish the value — derived, inferred or estimated
the LoIA or source of information used to arrive at the value
how this information was used to create the value, especially if it’s an estimate
for inferred and estimated values — a description of the level and nature of the testing done to ensure the efficacy of the results generated by the method.
Low and zero-knowledge proofs
Low and zero-knowledge proofs describe situations where the Facilitation Provider can make available information without disclosing the original value.
The Relying Party requests information about the value rather than requesting the value itself.
Low-knowledge proofs
Low-knowledge proofs obscure the precise value by either placing it within a larger number of values or expressing it in a more general way.
Examples of low-knowledge proofs
Making available an age instead of the date of birth.
Expressing a date of birth as within a range of dates.
Providing a maximum or minimum date, that’s not the date itself.
Expressing salary as within a range — the bigger the range the lower the knowledge.
Zero-knowledge proofs
Zero-knowledge proofs make use of binary responses. Rather than asking for an attribute, the Relying Party provides the Facilitation Provider with a distinct set of parameters that the value of the attribute needs to meet.
The Facilitation Provider applies the parameters to what they know and provides a binary response — which could include indicating they’re unable to respond.
Examples of zero-knowledge proof questions and responses
Is this Entity over 18 years of age? Yes.
Is this Entity living in New Zealand? Yes.
Is this Entity a permanent resident? Green tick.
Does this Entity meet the criteria (this would be defined) for this service? Red cross.
Related advice
The following resources are related to this topic:
