Other design considerations for assert

On the assertion service Provide consent 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 RealMe service is all about ... is set text, followed by a phrase provided during integration - in this StudyLink example, "to be shared with StudyLink".

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, StudyLink requires all the elements - full name, date of birth, place of birth and gender. Although the Federated Identity Tag is always sent, this is not displayed to the user during an assertion.

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.