Other design considerations for assert

On the assertion service Share your information page, there are a number of elements where the display is customised by the online service during RealMe integration.

Information required

The introductory paragraph is configurable to describe the context. The information below is required to... is set text, followed by a phrase provided during integration - in this Elections example, "to complete your online enrolment application".

Verified attribute information

RealMe currently requires assertion service integrations to include verified identity in an assertion, but address (and future attributes) can be mandatory, optional or not required. Only the attributes requested during an assertion will be displayed.

For verified identity, the online service should only request the identity elements that are required to to complete the transaction. In this example, Elections only require full name and date of birth - place of birth and gender are not required. Although the Federated Identity Tag is always sent, this is not displayed to the user during an assertion.

Organisation name

The name of the organisation receiving the verified data is included in last sentence When you click the 'I agree' button... This variable is the organisation name element supplied during integration.

Identity sharing terms

When an online service customer has been redirected to the RealMe assertion service to share their information, they are no longer able to view information on the organisation's website without interrupting the transaction. The purpose of the pop-up sharing terms is to provide a summary of the terms under which the online service is requesting and retaining the person data. While many users will just trust the online service, this function provides the means for users that want the additional assurance. The questions that are posed are essentially aligned with the privacy principles that apply to any NZ online service complying with the Privacy Act.

Exception messages

While SAML exception messages returned by the RealMe assertion service (or login service during authentication) should follow the recommended approach, additional consideration is required by the online service as to when a retry of the identity assertion should be encouraged (perhaps the user just needs to reset their password or locate their second factor device) and when to suggest the use of an alternative non-online identity proofing method. The AuthnFailed exception is triggered both when a user chooses to leave the RealMe website which may be because they have not completed the verified identity application process, or perhaps they were simply distracted by something minor and should try again. An example AuthnFailed message is illustrated below.

The UnknownPrincipal message is returned when the customer has not even started the verified identity application process. In this case, the online service may want to only recommend the non-online alternative, but in some circumstances there may be value in encouraging the person to complete the verified identity process via RealMe and try again in a few days.