The Facilitation Service Standard deals with all the aspects of creating and managing facilitation mechanisms.

It applies to any Facilitation Provider that facilitates the presentation of one or more Credentials. This could be as a provider of an exchange, hub (for example, RealMe) or a digital wallet.

The scope of the requirements in the Standard explicitly relate to the identification aspects of facilitation mechanisms. It does not include considerations for security, other implementation matters or any contractual agreements. For more information, see Facilitation Service Standard.

Information relevant to facilitation has 3 aspects:

• Credential subject information — this is information that the Holder of the facilitation mechanism is overtly aware of making available to a Relying Party for their decision making. This information is usually about the Holder but can include another Entity’s information that the Holder has the authority to use (for example, organisation information).
• Presentation information — this is information (including metadata) and associated processes that support the trust integrity and operation of the Credential (for example, security features, encryption, digital certificates).
• Facilitation information — this is information (including metadata) that’s used when a Credential is connected to and presented by a facilitation mechanism (for example, references, timestamps, transaction identifiers, logs).

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.

Part 1 — 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.

Accountability for an action in a control does not mean that the Facilitation Provider undertakes the task directly themselves. It could be delivered by the facilitation mechanism (for example, programmed into a digital wallet) or by another contracted party.

Establishment of a facilitation mechanism includes confirming the relationship between the Entity, their Credentials and any new Authenticators associated with the facilitation 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).

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 idmstandards@gdda.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 established or added to a facilitation mechanism.

The Credential Authenticator and facilitation mechanism Authenticator support the Entity Binding by ensuring that the information is still controlled by the correct Entity.

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

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

In the case of digital Credentials, this also includes the transfer of the Credential to the facilitation mechanism.

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

The level of the Authenticator and the process for connecting it to the facilitation mechanism are established by applying the Authentication Assurance Standard controls.

Authentication Assurance Standard

While 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) is impacted by the lowest level of process when adding Credentials.

For Control FA7.02, a Credential is not to be added to the facilitation mechanism if the outcome will result in a lower level of authentication (LoAA) than the Credential.

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.

In the case of many digital Credentials, the Credential Authenticator could be a one-time Authenticator used solely to add it to a facilitation mechanism.

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 ensure their service protects the subject of the Entity Information from the fraudulent use of their Credentials and the facilitation mechanism. Therefore, information gained from activity will have an additional purpose for the Facilitation Provider.

If the Facilitation Provider has access to this information, for example through a hub or exchange, it’s important that the Holder is made aware of the nature and extent of its 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 services, 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

Some Facilitation Providers have indicated they may develop add-on services based on information accessible through the facilitation mechanism. The type of facilitation mechanism will determine the degree to which information is available to the Facilitation Provider. For example, a digital wallet may operate solely on a Holder’s device and not transmit any information to the provider of the wallet.

Where Entity Information or any additional information gained from activity is accessible, 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.

For digital wallets, where the Facilitation Provider has little or no direct control of the facilitation mechanism, support may be instructions to cancel the wallet.

FA9.04 Guidance — mechanism complaints

Facilitation Providers are obligated to ensure that their facilitation mechanism does not have faults or operate in a way that leaves it open to compromise or misuse. Monitoring complaints and problems is one way to do this.

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.

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 this control, additional information is expected to be recorded relative to the purpose and outcomes of the system.

For a digital wallet, where this information is only stored in the wallet and not transmitted to the Facilitation Provider, the Holder will need to be able to access it.

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/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/Disincentive — these measures are the least effective as they rely on education and perception rather than on any real limitation.

These steps can be taken directly by the Facilitation Provider or built into the operations of the facilitation mechanism.

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 type of facilitation mechanism and its 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.

Part 2 — 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 trust and interoperability is to have a recognisable and consistent set of values representing the levels of assurance for each process undertaken for 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, to the attribute
• LoAAn — the level of assurance that the Credential/s from which the presentation is built, are in control of the rightful Holder.

Where the Credential Authenticator differs in level from the facilitation mechanism Authenticator, the lower is declared. Noting that control FA7.02 requires that a Credential is not added to a facilitation mechanism, unless it can equal the strength of the Credential Authenticator.

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, such as websites.

FA10.02 Guidance — declaring lowest level

Where the Facilitation Provider’s mechanism 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.

As a Holder adds Credentials to a facilitation mechanism, they could 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.

This can include:

• blocking requests from Relying Parties who are known to over-collect, much like a deny list for spam prevention
• not allowing a Relying Party to integrate with a hub or exchange where this is able to be controlled
• configuring facilitation mechanisms to provide warnings to Holders when requests indicate the possibility that over-collection is occurring. As digital interactions mature, patterns for over-collection will begin to emerge.

These steps 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.

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.

For additional information on this topic, the following ISO Standard may be useful.

ISO/IEC 27551-Requirements for attribute-based unlinkable entity authentication

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 masking 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.

Contact

Government Digital Delivery Agency
Email: idmstandards@gdda.govt.nz