Skip to main content

Implementing the Federation Assurance Standard

Guidance on the Federation 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

Federation Assurance deals with all the aspects of creating, managing and presenting Credentials and Authenticators that can be used in multiple contexts.

The Federation Assurance Standard applies to any Credential Provider and any Facilitation Provider that facilitates the presentation of 1 or more Credentials.

The scope of the requirements in the Standard explicitly relates to the identification aspects of federated Credentials. It does not include considerations for security, other implementation matters or any contractual agreements. For more information, see Federation Assurance Standard.

For definitions of key terms used in this guidance, see Identification terminology.

This living guidance will evolve and expand over time to meet the needs of users.

Guidance for Credential Providers establishing Credentials

Credential Provider refers to the party accountable for the controls covered by this section, even if they’ve delegated or contracted delivery responsibility to other parties.

At a minimum, a Credential consists of an Authenticator and Integrity mechanisms. Most Credentials have additional information that determines their use for specific purposes — for example, to travel or to drive. This information has 3 aspects:

  • Credential subject information — this is information that the Holder of the Credential is overtly aware of making available to a Relying Party for their decision making.
  • Presentation information — this is information (including metadata) and associated processes that support the trust and operation of the Credential (for example, document security features, encryption, certificates).
  • Facilitation information — this is information (including metadata) that’s made available when the Credential Provider is involved in facilitating the presentation of the Credential to the Relying Party (for example, references, timestamps, transaction identifiers, logs).

The guidance for Credential Providers establishing Credentials applies to the relationship between an Entity, a Credential Provider and the Credential that they establish.

Objective 1: Credential risk is understood

Applying a risk-based approach to Credentials helps to identify the aspects that drive the level of risk. Understanding this enables the development of a wide range of mitigation strategies and determines the levels at which to apply the other identification standards in Control FA2.01.

FA1.01 Guidance — risk assessment

Any robust risk assessment process may be used to identify the risk of the Credential. The context for the Credential is the purpose it is to serve and the environment in which it will exist, including whether it’s a physical or digital Credential.

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.

It’s not the role of the Credential Provider to predict the risk of the services offered by any Relying Party who may accept the Credential. However, it will be useful to understand the levels of assurance required by the Relying Parties and Entities for whom the Credential may be designed.

FA1.02 Guidance — Credential information risk

Currently Credentials contain relatively small amounts of information. Digital Credentials can limit this further by only showing a subset of attributes from the information, depending on the Relying Party’s needs.

However, when a Holder is accessing their Credential, potentially for management purposes, they’ll have a view of all the information contained in the Credential. As Credentials will potentially get larger in the future, awareness of the risk that these larger amounts of information could expose the Holder to need to be understood and the appropriate additional authentication requirements implemented.

Objective 2: Credentials have recognised levels of assurance

A key element of trust is being able to recognise a Credential and understand the assurance that it provides.

FA2.01 Guidance — related standards compliance

During the Credential establishment process the Credential Provider is in the role of Relying Party and will need to apply the controls contained within the following Identification Standards:

The levels to which assurance has been gained against the above standards will be a contributing element to the levels to be declared in FA2.02 and FA10.01.

FA2.02 Guidance — recognised levels of assurance

Declaring the levels of assurance of Credential subject information is a key component to evaluating the strength and reliability of this information. Various methods may be used to make this declaration including posting the information on a website of other material about the Credential. Credentials that are offered digitally can include the levels in metadata.

Note: When a Credential Provider declares levels of information assurance (LoIA) for their Credential, the levels will be a step below that achieved for levels 3 and 4, unless a synchronised link is maintained with the evidence used in IA3.03.

Examples of reduced levels of assurance
  • An endorsement on a driver licence for driving forklifts was verified against the driver licence document and LoIA 3 is achieved — when the Credential is created, it’s a reference to a copy of the attribute value, therefore LoIA is level 2.
  • The endorsement is verified against the driver licence database, and LoIA 4 is achieved — the new Credential value is a copy of the authoritative source at a point in time, so becomes LoIA 3.
  • The endorsement is verified against the driver licence database, and LoIA 4 is achieved — the new Credential, which is digital, always accesses the driver licence database for the current value every time it’s presented, so this is deemed synchronous and therefore is LoIA 4.

Where a Credential Provider adds attributes to a Credential that it created, such as an expiry date or a reference number, they’re the authoritative source of these values. These attributes could have higher levels of assurance than information from other sources.

FA2.03 Guidance — recognisable Credential

Recognition of Credentials is related to recognising Credential Providers, both are integral to trusting the information and processes that they represent. They’re also needed for the ability to query an issue with either a Credential or transaction.

Examples of Credential recognition mechanisms

For physical Credentials: Features that require proprietary knowledge to be able to reproduce it, branding characteristics, fonts, watermarks or references that allow for independent contact with and/or verification with the Credential Provider.

For digital Credentials: Digital certificates, cryptography and other tamper protections that can be systematically identified and/or access only enabled through a pre-established trusted communication channel.

FA2.04 Guidance — recognisable credential Provider

In conjunction with the recognisability of the Credential, recognition of the Credential Provider contributes to the integrity of a Credential. The Credential Provider is also the party that will hold any confirmation of conformance with this Standard.

Public branding plays a significant part in the recognition of a Credential Provider. Where reputation is concerned, measures outside the context of identification management will be being taken to protect the brand from misuse by unauthorised parties.

In the digital world, independently verifiable Credential Provider identifiers and digital certificates or asynchronous keys can be used to aid with recognising and confirming Credential Providers.

Objective 3: Credential is privacy-preserving

A Holder using the same Credential across multiple contexts (Federation) potentially enables the building of profiles and tracking of the Holder’s transactions across those contexts. Without taking steps to minimise or prevent this, Holders’ privacy could be at risk and they could be inhibited from adopting federated services.

FA3.01 Guidance — withholding Entity Information identifier

Entity Information identifiers include system-generated, assigned or collected identifiers that can uniquely identify a set of Entity Information in a given context, even if other attributes are identical.

The sharing of these across multiple contexts has the potential to allow the correlation of Entity information from multiple sources, without the subject’s permission or knowledge.

This control does not limit the sharing of an identifier that has a specific purpose (usually provided for in legislation), providing the sharing is for that purpose. Information on the limitation of the use of these identifiers and who they can be shared with will be made available to Holders and Facilitation Providers.

Examples of identifiers with prescribed purposes
  • Tax file number
  • National Student Index (NSI) number
  • National Health Index (NHI) number

Where an identifier is essential for administration and maintenance of a Credential, consider using a Credential identifier that’s only valid for the life of the Credential. Digital implementations can also support Credential presentation identifiers that are unique to each presentation of the Credential.

See also FA11.08 regarding persistent identifiers.

FA3.02 Guidance — partial credentials

Information minimisation is a key principle for preserving privacy.

For physical Credentials, limit the number of attributes to those essential for the Credential purpose.

Digital Credentials have much more scope for supporting use of partial sets of information contained in the Credential.

Objective 4: Participation is inclusive

When deciding to issue a Credential, Credential Providers need to identify who the Holders will be and ensure that those Holders are able to get the Credential.

FA4.01 Guidance — Credential Entities

Identifying the Entities who will require the Credential does not usually mean identifying the individual Entities. It’s about understanding the nature of the group and what may impact the application process:

  • Where are they located?
  • Will they have access to the application process?
  • Will they be able to understand any communication or messaging?
  • Is there anything preventing them from undertaking the process, such as the physical and mental ability to do so?

FA4.02 Guidance — Entities able to hold Credential

Using the information gathered in FA4.01, design the application process and any exception processes to enable the target group to be able to become a Credential Holder.

Examples of process considerations
  • Providing communications and messaging in multiple languages
  • Supporting in-person and remote application processes
  • Supporting cultural and religious aspects that may impact the application process
  • Having exception-handling processes in place to support those unable to meet the published requirements for establishing a Credential

Objective 5: Credential is maintained

A Credential is established at a point in time. As time goes by, elements of the Credential can become out of date. Maintenance is needed to ensure that its relevance and integrity continue.

These activities relate to managing the life cycle of the Credential and detecting fraud.

It can be common for Credential Providers to use specialised third parties as the Credential Holder’s contact point for these controls — for example, customer complaint services.

FA5.01 Guidance — updating a Credential

There are several ways for the information in a Credential to be updated.

The need to update can be triggered by:

  • a request from the Holder
  • a specified timeframe or expiry date
  • an external notification, usually from the authoritative source.

Physical Credentials will need to be reissued to be updated. Including an expiry date that’s reflective of the purpose of the Credential will reduce the risk of it becoming outdated.

Digital Credentials can provide more flexibility, depending on how they’re implemented, potentially providing the ability to replace a value in the Credential with a newer value, with or without reissuing the Credential.

Where a digital Credential offers the ability to link to a maintained source of information, the latest value(s) can be drawn for each presentation.

FA5.02 Guidance — cancelling a Credential

Providing the means for a Holder to cancel a Credential includes providing them with an automated self-service application or a point of contact to request the Credential Provider to do so on their behalf.

The ability to cancel the Credential can include options to do so permanently or temporarily.

Depending on the reason for cancellation and/or the type of implementation, the action may be applied to the Authenticator or the Credential as a whole.

Note: Physical destruction of a Credential is not enough to ensure that the status of the Credential is cancelled in all cases — for example, a Holder cutting up a membership card does not mean the Credential Provider is aware that the Holder no longer wants the card.

FA5.03 Guidance — loss of a Credential

Good Holder behaviour can be encouraged and the impact reduced by providing easy and effective means for the Holder to report loss or compromise of a Credential.

A dedicated email or phone number for accessing this service is desirable.

The processes that follow the loss or compromise need to be appropriate for the assurance level of the Credential.

FA5.04 Guidance — Credential establishment complaints

Enabling the Holders of Credentials to make complaints or to raise issues about Credential establishment and maintenance contribute to their integrity and trust in their use.

A dedicated email or phone number for accessing this service is desirable.

Implementing a case management approach will help to ensure that the complaint or issue is tracked through diagnosis to solution. It will help the Holder experience by reducing the likelihood that they’ll have to provide information multiple times, and it will provide consistency during the process if multiple staff are involved.

FA5.05 Guidance — Credential use complaints

Complaints about Credential presentations are highly likely to be the result of identity theft occurring or some other compromise of the Credential. This could be detected by either the Holder of the Credential or a Relying Party who has been presented with the Credential.

The means for making the complaint will be easy to find and use. As with FA5.04, dedicated access points for this purpose are desirable along with a case management approach.

The Credential Provider will assess the mechanisms for their efficacy in achieving resolution of complaints or problems.

If this avenue receives a complaint regarding a facilitated presentation and the Facilitation Provider is not the same as the Credential Provider, strong communication between the Providers is recommended to avoid the Holder or Relying Party feeling that Providers are shifting responsibility.

FA5.06 Guidance — Credential status

A Credential status change can be initiated by the Holder or as the result of another process, such as investigation into fraud.

The status change may be temporary or permanent depending on the case — for example, suspending a Credential could allow for it to be reactivated in the future, while other statuses could require a completely new Credential to be established.

Determining the reason for permanently disabling or deleting a Credential before doing so, saves time and effort for the Holder and Credential Provider.

Examples of Credential status changes
  • The Credential Provider is notified of fraudulent use of a Credential and immediately sets the status to ‘suspended’ — after investigation the case is found to be true and the status is changed to ‘revoked’.
  • The Holder advises the Credential Provider that they’ve mislaid their Credential while shifting house. They’re confident they’ll find it, so the Credential is ‘suspended’ and then ‘reactivated’ when later reported found.

Wherever possible, the status is to be available to Facilitation Providers and Relying Parties.

For digital Credentials, this will be straight forward as the Facilitation Provider will have access to the Credential status during each presentation and can either prevent presentation or provide the status to the Relying Party, depending on the implementation.

Where a Credential does not require a Facilitation Provider, such as Credentials that are physical documents, it’s recommended that the status is published in a register or source that can be independently checked by the Relying Party.

The policies under which the Credential operates will determine if there’s a requirement to notify Relying Parties of any status change after the Credential was used — for example, a Credential that’s found to be fraudulent or incorrect sometime after it was established. The ability to notify Relying Parties and the method for doing so will vary depending on the implementation.

FA5.07 Guidance — Credential expiry

Setting expiry dates on Credentials provides an opportunity to check that the information in the Credential is up to date and that it remains in the possession and control of the Holder.

It allows for the inclusion of or compatibility with new technology and to make changes to address new threats.

FA5.08 Guidance — activity logs

Logging activity within a system is a key enabler for investigations and fraud detection. While a list of the minimum items is in the control, additional information is expected to be recorded relative to the purpose and outcomes of the system.

Where the Credential is a physical document, the recording of activity is more likely to be about the reissuing of the Credential.

FA5.09 Guidance — preventative measures

It’s helpful to think of preventative measures in the same way as risk controls. They’re grouped into:

  • Preventative — those steps that stop a threat to the system altogether
  • Corrective or Reductive — steps that will not stop a threat but will minimise the impact when it does happen
  • Detective — steps to identify threat events so that corrective or preventative measures can be put in place
  • Directive or Disincentive — these measures are the least effective as they rely on education and perception rather than on any physical limitation.

For more information refer to guidance on Counter fraud techniques.

FA5.10 Guidance — Holder notifications

The ability to provide notifications to the Holder will be impacted by whether the Credential is facilitated during presentation or not.

In most cases, it’s not possible to notify a Holder of an unfacilitated use of a Credential. However, if a subsequent check against a source or register is undertaken as part of that use, this can be recorded and made available to the Holder on request.

Example of Holder notification

When a change to a Credential is made, the Holder receives a text to a pre-registered mobile phone. The message invites the Holder to contact the Credential Provider immediately if they did not make a change.

Note: When a change is made to any contact information, notifications need to be sent to the previous contact points. Otherwise, where the change was unauthorised the notification would not be seen by the subject.

Guidance for Facilitation Providers establishing facilitation mechanisms

A Facilitation Provider refers to the party accountable for the establishment and use of a facilitation mechanism. Credential Providers who are facilitating the presentation of their own Credentials are performing the role of Facilitation Provider.

Establishment of a facilitation mechanism includes confirming the relationship between the Entity and their Credentials and any new Authenticators associated with the mechanism.

A facilitation mechanism Holder refers to the individual Entity with whom the mechanism was first established — the rightful Holder.

The guidance in this section does not apply to Credentials used independently of facilitation mechanisms — for example, where an Entity presents a physical document to a Relying Party.

Note: Currently all known use cases for facilitation mechanisms are digital.

Objective 6: Facilitation mechanism risk is understood

Applying a risk-based approach to facilitation mechanisms helps to identify the aspects that drive the level of risk. As facilitation mechanisms have the potential to draw together large amounts of information from multiple sources, a full understanding of the impact of risks eventuating is important to maintain trust in their use.

FA6.01 Guidance — facilitation mechanism risk assessment

Any robust risk assessment process may be used to identify the risk of the facilitation mechanism. The context for the mechanism is the purpose it is to serve and the environment in which it will exist.

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.

It’s not the role of the Facilitation Provider to predict the risk of the services offered by any Relying Party who may accept presentations from the facilitation mechanism. However, it will be useful to understand the levels of assurance required by the Relying Parties and Entities for whom the mechanism may be designed.

FA6.02 Guidance — mechanism information risk assessment

Facilitation mechanisms can combine larger amounts of information than an individual Credential holds — for example, the content of 1 Credential compared to the contents of an entire wallet, purse or phone. While digital implementations can limit the exposure of information to Relying Parties, when a Holder accesses their facilitation mechanism for management purposes, they’ll potentially have a view of all the information contained in it.

As more information gets connected to a facilitation mechanism, awareness of the risk to the Holder of exposure of this information needs to be understood and the appropriate additional authentication requirements implemented.

Objective 7: Binding assurance is maintained

The Entity Binding levels of individual attributes are established by the Credential Provider.

The level of binding assurance (LoBA) does not change when a Credential is added to a facilitation mechanism.

If the Authenticators used to access the Credential and facilitation mechanism are of an equal or greater strength to that of the Entity Binding level, the Authenticators can support that binding level.

However, Authenticators at lower levels than the binding level increase the likelihood that an Entity other than the Holder is using the Credential or facilitation mechanism and not the original Holder bound to the Credential subject information.

Authenticators and their binding are the key to ensuring that a facilitation mechanism remains in the control of the Entity for whom it was established.

If implemented correctly, they also carry forward the strength of the binding of the Entity to the Entity information that's carried out during the enrolment process for the Credential. A break or reduction in the level of binding increases the risk of a different Entity claiming the information as their own.

FA7.01 Guidance — facilitation mechanism Authenticator

The number and type of Authenticators attached to the facilitation mechanism will be determined by the:

  • risk assessment undertaken for Objective 6
  • environments the mechanism is used in
  • authentication level of the Credentials being added.

A facilitation mechanism with lower authentication than the Credential(s) accessed by it increases the likelihood that it may be used by an Entity other than the Holder.

Consideration of the Entities and their capability to use certain Authenticator types are also a consideration for the type of Authenticator(s). For additional information refer to Authenticator types.

FA7.02 Guidance — authentication consistency

Credential Authenticators are used to maintain the Entity Binding of the information in the Credential — in other words, that the information being presented relates to the Entity holding the Credential.

The same applies to the facilitation mechanism Authenticator. The level of the Authenticator and the process for connecting it to the facilitation mechanism need to be consistent with the Credentials added to the facilitation mechanism to reduce the likelihood of another Entity becoming the Holder.

The level of Entity Binding will always reflect the original binding that occurred during the enrolment process for the Credential. The level of authentication assurance (LoAA) will reflect the lowest level of the connection and strength of the Authenticator used during the facilitation mechanism establishment process.

Examples of authentication consistency outcomes

An attribute in a Credential is declared by the Credential Provider as being {LoIA 4, LoBA 3, LoAA 3}. The following shows various outcomes for the declarable level of facilitation mechanism authentication assurance:

  • A Facilitation Provider establishes a facilitation mechanism with a level 3 Authenticator and tests the Entity has control of it at the same level; a Credential is then added to the facilitation mechanism without testing control of its Authenticator: Outcome LoAA 1.
  • A Facilitation Provider establishes a facilitation mechanism with a level 3 Authenticator, but only tests the Holder’s control of it at level 2; a Credential is then added to the facilitation mechanism after testing control of its level 3 Authenticator: Outcome LoAA 2.
  • A Facilitation Provider establishes a facilitation mechanism with a level 2 Authenticator and tests the Entity has control of it at the same level; a Credential is then added to the facilitation mechanism after testing control of its level 3 Authenticator: Outcome LoAA 2.
  • A Facilitation Provider establishes a facilitation mechanism with a level 3 Authenticator and tests the Entity has control of it at the same level; a Credential is then added to the facilitation mechanism after testing control of its level 3 Authenticator, however, when the Credential is presented via the facilitation mechanism, the Facilitation Provider allows this to be done with a level 2 Authenticator: Outcome LoAA 2.
  • A Facilitation Provider establishes a facilitation mechanism with a level 4 Authenticator and tests the Entity has control of it at the same level; a Credential is then added to the facilitation mechanism after testing control of its level 3 Authenticator: Outcome LoAA 3.

It’s envisaged that over time the declaration of levels will mature and that it will become desirable for Facilitation Providers to declare both the Credential LoAA and the facilitation mechanism LoAA as 2 separate values.

Note: Use of stronger Authenticators does not increase the Entity Binding level. If a weaker Authenticator is used at any point, it does not alter the original Entity Binding level but it increases the likelihood that the Credential and the information it contains are now controlled by another Entity.

FA7.03 Guidance — control of Authenticator

Credentials are not to be added to facilitation mechanisms without first checking that they’re in the control of the Holder. To do so enables identity theft and exposes every Relying Party to the impacts of this when they receive a presentation from the facilitation mechanism.

Requiring the Entity to respond correctly to the authentication challenge component of the Credential before adding it to the facilitation mechanism reduces the likelihood consistent with the level of the Authenticator(s) used.

Objective 8: Facilitation mechanism is privacy preserving

Facilitation mechanisms that combine several Credentials, enabling the Holder to use them across multiple contexts (Federation), potentially enable the building of profiles and tracking of the Holder’s transactions across those contexts.

Without taking steps to manage this, Holders’ privacy could be at risk and they could be inhibited from adopting federated services.

FA8.01 Guidance — permission to add a Credential

Credentials cannot be added to a facilitation mechanism without the permission of the Holder. Where the Credential Provider is facilitating the presentation of their own Credential, this permission can be part of agreeing to the terms and conditions of the Credential.

Records will be kept of the permission being given, in an appropriate form.

The Holder is equally able to withdraw the permission and have the Credential removed from the facilitation mechanism.

FA8.02 Guidance — selective information

There are several reasons why a Credential Holder may not want all the attributes in a Credential added to the facilitation mechanism. The main one is to reduce the number of duplicated attributes that are caused by the narrow range of attributes available in current Credentials.

There can be usability issues if Holders need to select between multiple versions of attributes during presentation.

The purpose for which the Holder wishes to use their facilitation mechanism will also impact the attributes needed. Holding additional attributes increases the risk.

The Holder is equally able to remove availability of attributes that they’ve previously selected to include from the facilitation mechanism.

FA8.03 Guidance — notification of fraud detection

The primary reason a Holder adds Credentials, including the Entity Information they contain, to a federation mechanism is to be able to present various attributes to other parties.

In doing so, there’s an expectation that the Facilitation Provider will take steps to protect the subject of the Entity Information from the fraudulent use of their Credentials and facilitation mechanisms. Therefore, the Entity Information and additional information gained from activity will have an additional purpose for the Facilitation Provider. It’s important that the Holder is made aware of the nature and extent of this use.

Agreement to these purposes can be through the acceptance of terms and conditions for the service, where opting out means opting out of the service.

For additional optional service, see FA8.04.

It’s expected that Facilitation Providers will use pairwise identifiers where possible, to reduce unintended or unauthorised correlation or analysis. For more information on persistent identifiers, see FA11.08.

FA8.04 Guidance — permission to correlate or analyse information

It’s expected that some Facilitation Providers will develop services around specific needs that may include additional add-on services. Where this uses Entity Information and any additional information gained from activity, explicit permission is to be sought from the Holder. Opting out of these add-on services will not result in being unable to use the facilitation mechanism.

Objective 9: Facilitation mechanism is maintained

While a facilitation mechanism has an initial establishment point, the Credentials and attributes attached to it will change overtime. New Credentials will become available and the needs of the Holder can also change. Maintenance is needed to ensure that its relevance and integrity continue.

These activities relate to managing the life cycle of the facilitation mechanism and detecting fraud.

It can be common for Facilitation Providers to use specialised third parties as the facilitation mechanism Holder’s contact point for these controls — for example, customer complaint services.

FA9.01 Guidance — maintain Credentials in mechanism

As well as being able to choose which attributes from a Credential can be added to a facilitation mechanism, the Holder is to be able to remove unwanted attributes or Credentials later.

Consideration will need to be made as to what will happen to the facilitation mechanism if no attributes or Credentials remain attached.

FA9.02 Guidance — cancel mechanism

Providing the means for a Holder to cancel a facilitation mechanism includes providing them with an automated self-service application or a point of contact to request the Facilitation Provider to do so on their behalf.

The ability to cancel the facilitation mechanism can include options to do so permanently or temporarily.

Depending on the reason for cancellation and/or the type of implementation, the action may be applied to the Authenticator or the mechanism.

FA9.03 Guidance — loss or compromise of mechanism

Good Holder behaviour can be encouraged and the impact reduced by providing easy and effective means for the Holder to report loss or compromise of a facilitation mechanism.

A dedicated email or phone number for accessing this service is desirable.

The processes that follow the loss or compromise need to be appropriate for the assurance level of the facilitation mechanism.

FA9.04 Guidance — mechanism complaints

Complaints about the facilitation mechanism are likely to be the result of identity theft occurring or some other compromise of the mechanism or a Credential attached to it. This could be detected by either the Holder or a Relying Party who has received a presentation from the mechanism.

The means for making the complaint will be easy to find and use. As with FA9.03, dedicated access points for this purpose are desirable along with a case management approach.

The Facilitation Provider will assess the mechanisms for their efficacy in achieving resolution of complaints or problems.

If this avenue receives a complaint regarding a facilitated presentation and the Facilitation Provider is not the same as the Credential Provider, strong communication between the Providers is recommended to avoid the Holder or Relying Party feeling that Providers are shifting responsibility.

FA9.05 Guidance — mechanism activity logs

Logging activity within a system is a key enabler for investigations and fraud detection. While a list of the minimum items is in the control, additional information is expected to be recorded relative to the purpose and outcomes of the system.

FA9.06 Guidance — preventative measures

It’s helpful to think of preventative measures in the same way as risk controls. They’re grouped into:

  • Preventative — those steps that stop a threat to the system altogether
  • Corrective or Reductive — those steps that will not stop a threat but will minimise the impact when it does happen
  • Detective — those steps that identify threat events so that corrective or preventative measures can be put in place
  • Directive or Disincentive — these measures are the least effective as they rely on education and perception rather than on any physical limitation.

For more information refer to guidance on Counter fraud techniques.

FA9.07 Guidance — notifications to mechanism Holder

The nature and amount of information able to be provided to a Holder will depend on the implementation. Where the destination of the notification has been part of the change, the notification will be sent to an alternative or previously recorded destination.

Examples of Holder notification
  • The Holder logs into their digital wallet and is provided with a note that they last logged on 3 days ago and that it was for presentation of part of a Credential. The information describes the attribute types sent and the Relying Party that received them.
  • The Holder makes a change to their facilitation mechanism and receives a text to a pre-registered mobile phone. The message invites the Holder to contact the Facilitation Provider immediately if they did not make a change.

Guidance for the presentation of Credentials by Facilitation Providers

For the purposes of this section, Credential presentation refers only to cases where the presentation is facilitated by a Facilitation Provider. This includes where the Credential Provider is presenting their own Credential.

Providing and facilitating the presentation of a Credential can involve 1 or more parties working together. Other standards and jurisdictions segment these using terms such as Information Provider, Attribute Provider, Credential Service Provider, and Verifier. Regardless of the number of parties that are working together, the Facilitation Provider is the accountable party for the purposes of assurance.

Objective 10: Presentations are consistent and recognised

A system that requires a Relying Party to make judgements about the assurance of a Credential based on its type enables assumptions about their strength — for example, the processes for issuing a Driver Licence vary from country to country, yet many assume they’re the same.

Additionally, the processes behind each attribute in a Credential also differ.

The key to interoperability is to have a recognisable and consistent set of values representing the levels of assurance for each process undertaken, on each attribute.

FA10.01 Guidance — levels of assurance known

For each attribute being presented, the metadata will provide the 3 levels of assurance achieved by the identification processes applied to the attribute.

The 3 levels are:

  • LoIAn — the level of assurance in the value or derived value of the attribute
  • LoBAn — the level of assurance in the binding of the Entity, the attribute and the Credential Authenticator
  • LoAAn — the level of assurance of the Authenticator and its presentation.

It’s recommended that where the Authenticator for the Credential differs in level from the facilitation mechanism, that both are declared.

Where it’s not yet possible to declare the levels of assurance within the presentation, they can be published or made available through other means.

FA10.02 Guidance — declaring lowest level

Where the Facilitation Provider is unable to declare separate levels of assurance for attributes and/or processes, declaring any levels higher than the lowest will result in loss of trust and integrity in the system. Overstating levels will expose Relying Parties to higher risk and will impact the decisions that they make based on the level declared.

FA10.03 Guidance — metadata for Relying Party

Additional Presentation information is essential for the Relying Party to make an informed decision regarding the Subject information being received and to maintain the integrity of the system.

Transaction identifiers — these enable an individual transaction to be investigated later and to prevent attackers from replaying prior presentation transactions. While ideally these should be unique references, they can be composites of references such as the Credential identifier and a timestamp.

Credential issuance — this is a timestamp indicating how long ago the Credential was created. Where the attributes have an LoIA of 3 or below, this could be used as an indication of an increased likelihood that the values have changed.

Expiration date — this refers to the date the Credential is no longer valid for the purposes it was created. In most cases this does not mean the attributes within the Credential are not still correct. Care needs to be taken not to misinterpret what the expiration date indicates.

Credential validity — this refers to mechanisms such as security features, digital certificate and signatures that can be independently assessed to determine if the Credential is genuine, along with checks that the Credential has not been cancelled or revoked by the Credential Provider.

Audience identifier — like a Transaction identifier, this can be used to aid in investigations. An Audience identifier also enables a Relying Party to self-detect if they’re receiving information intended for themselves. Ideally, they’ll use restricting techniques such as being limited to use by a single Relying party (and only once), and being time limited.

Some Presentation information need only be stated once, as it applies to the whole presentation, such as the Transaction and Audience identifiers. However, some will be different for each Credential and/or attribute within the presentation.

The Federation Standard provides a list of the minimum items of metadata to be included but other metadata may also be relevant — for example, the Relying Party may also wish to know if the Facilitation Provider and Credential Provider have complied with the Federation Standard.

Objective 11: Presentations are privacy preserving

The presentation of Credential(s) should not expose any Holder to a reduction in privacy. Active application of privacy principles, such as data minimisation and providing permission, contribute to good identification management practice and reduce identity theft and its impacts.

Without taking steps to manage this, Holders’ privacy could be at risk and they could be inhibited from adopting federated services.

FA11.01 Guidance — permission to pass information

Permission to pass Credential subject information is to be explicit. The Holder will be able to see the attributes and values related to them, before providing permission for them to be made available to the Relying Party.

FA11.02 Guidance — allowing presentation edit

Despite there being privacy rules to prevent the over-collection of information, it’s still possible that a Relying Party will collect more information than they need for the service they’re delivering. Or that the Holder may not wish for certain information to be available to the Relying Party. In both cases, it will be the responsibility of the Relying Party to advise the Holder of the purpose for needing each attribute and the implications of not providing critical attributes.

By enabling the Holder to deselect attributes from the presentation, the Facilitation Provider allows the Holder control over their information.

FA11.03 Guidance — present as requested

When a Relying Party has identified itself and requested the Credential subject information that it needs, the presentation will be sent only to that Relying Party and contain only the information requested.

If the Facilitation Provider does not offer derived, inferred or estimated values and 1 or more have been requested, the attributes from which these are calculated will not be part of the presentation.

To provide more information than has been requested, even with the permission of the Holder, does not support the Relying Party’s compliance with privacy legislation.

Examples of calculated values
  • age or confirmation of being over a certain age, from a date of birth
  • a region, town, city or postal code, from a full address
  • confirmation of ability to drive, from the currency of a driver licence
  • estimation of age from an image.

As a Holder adds Credentials to a facilitation mechanism, could often end up with multiple sources for the same attributes. These can be at different levels of assurance. To improve usability, the Holder can choose to select the best source for the attribute and remove the other sources, as per FA8.02.

Where the Holder has chosen to retain multiple sources of attributes at different levels, the attribute equal to or higher than a requested level is presented before lower levels.

Where the attribute has multiple sources that meet a requested level, permission will need to be sought from the Holder as to which version is to be sent.

FA11.04 Guidance — questioning purpose

As facilitation mechanisms can access larger amounts of information, it could make them a target for malicious Relying Parties.

Where possible the Facilitation Provider needs to avoid knowingly contributing to the over-collection of information by Relying Parties by blocking them or advising Holders of the possibility that over-collection is occurring. This will contribute to the integrity of identification systems and increase trust in their use.

FA11.05 Guidance — relevant metadata

Generally, the Holder only provides permission for Credential subject information to be made available to the Relying Party. For the permitted Credential subject information to be made available, additional Presentation information and Facilitation information are also needed. This can be related to the Relying Party’s ability to interpret the information and for the technical aspects of the transaction to occur.

The Facilitation Provider is only permitted to make available Presentation information and Facilitation information that are directly related to the Credential subject information that the Holder gave permission to be made available.

FA11.06 Guidance — reduce persistent identifiers

There are several persistent identifiers that can be shared. These are described in FA3.01 and the Credential Provider is responsible for informing Facilitation Providers about any restrictions in their use.

For each link between a facilitation mechanism and a Credential, Authenticator or Relying Party, a different identifier will be used. This prevents an unauthorised party from using an identifier to correlate the activity of a Holder.

The Facilitation Provider will need to retain a mapping of these identifiers for the functioning of the facilitation mechanism, but it will not be disclosed to other parties.

Technologies that support this include:

  • pairwise pseudonymous identifiers — these are usually randomly generated pairs of identifiers known only by one pair of endpoints (for example, the facilitation mechanism and the Relying Party), and are created in an unguessable manner
  • decentralised identifiers (DIDs) — these are globally unique identifiers that do not require a centralised registration authority as they’re registered with distributed ledger technology (DLT) or other form of decentralised network — for more information, refer to the W3C standard on Decentralized Identifiers (DIDs) v1.0 — W3C
  • decentralised public key infrastructure (DPKI) — this is a public key infrastructure based on decentralised identifiers and records (for example, DID documents) containing verifiable public key descriptions.

Note: Extreme care should be taken with combinations of attributes that form a unique identifier within a context, especially if that context is large. If these are made available to multiple Relying Parties, they effectively over-ride any protection provided by employing non-persistent identifiers.

FA11.07 Guidance — providing for anonymity

Where an anonymous presentation has been requested, no information from any of the Credential subject information, Presentation information or Facilitation information that includes attributes which could be used as persistent identifiers will be made available to the Relying Party. This will include combinations of attributes that could be used to identify the activity as unique to 1 Holder, even if the Holder is not otherwise identified.

In other words, it’s not enough for the activity to be pseudonymous. Each presentation needs to appear to be from an independent Holder.

FA11.08 Guidance — securing transmission

Protecting information from unauthorised observation during transit from source through the facilitation mechanism to the Relying Party can be done using several technical security measures. Some of these include, but are not limited to:

  • ensuring that the Relying Party receiving the information is the same as the one requesting the information
  • encrypting the information in a way that only the authorised Relying Party can decrypt it
  • sending the presentation over an authenticated protected channel.

Objective 12: Presentation content is unaltered

Ensuring that Credential subject information remains the same during its presentation, from the source through to the point that the Holder has permitted the presentation to the Relying Party, is key to trust in services by Holders and Relying Parties.

FA12.01 Guidance — presentation is unaltered

To protect the information during transit from source through the facilitation mechanism to the Relying Party can be done using several technical security measures. Some of these include, but are not limited to:

  • sending the presentation over an authenticated protected channel
  • cryptographically signing the presentation and verifying it with the Relying Party.

FA12.02 Guidance — secure multi-party channels

Where the facilitation mechanism requires multiple parties to create the content of a presentation, secure communication channels are needed between all these parties. The methods for doing this include those mentioned in FA12.01.

Objective 13: Presentation can be investigated

An important element of trust in any identification process is the ability for a Holder or Relying Party to question a process or presentation. While various controls allow for anonymity, pseudonymity and blinding of various parties in the facilitated presentation process, none of these should prevent the investigation of a suspicious transaction.

It can be common for Facilitation Providers to use specialised third parties as the facilitation mechanism Holder’s contact point for these controls — for example, customer complaint services.

FA13.01 Guidance — facilitation provider contactable

Enabling the Holders and Relying Parties to make complaints or raise issues about a presentation, contributes to the integrity of and trust in facilitation mechanisms.

A dedicated email or phone number for accessing this service is desirable.

Implementing a case management approach will help to ensure that the complaint or issue is tracked through diagnosis to solution. It will help the Holder experience by reducing the likelihood they’ll have to provide information multiple times, and it will provide consistency during the process if multiple staff are involved.

Complaints about presentations are highly likely to be the result of identity theft occurring, or some other compromise of either the facilitation mechanism or the Credentials available to it. This could be detected by either the Holder of the facilitation mechanism or a Relying Party who has received a presentation from it.

The means for making the complaint will be easy to find and use.

The Facilitation Provider will assess the complaints mechanisms for their efficacy in achieving resolution of complaints or problems.

If this avenue receives a complaint regarding a facilitated presentation and the Facilitation Provider is not the same as the Credential Provider, strong communication between the Providers is recommended to avoid the Holder or Relying Party feeling that Providers are shifting responsibility.

FA13.02 Guidance — presentation metadata

Recording information about each presentation allows for auditing and investigation processes to occur. These are needed to maintain the integrity of the system and the trust of users.

The information along with security controls are also designed to manage the following threats:

  • Presentation repudiation — any party in the presentation transaction denying that an aspect has occurred
  • Presentation reuse — the presentation is made again to another Relying Party and/or on behalf of another subject
  • Presentation substitution — the presentation is hijacked during transmission and information altered.

Related advice

When enrolling Entities for the purposes of issuing a Credential or establishing a facilitation mechanism, the Information, Binding and Authentication Assurance standards will also be applicable. These should be read in context starting with About identification management.

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

Was this page helpful?
Thanks, do you want to tell us more?

Do not enter personal information. All fields are optional.

Last updated