Kantara sharing label and New Zealand ’s consent service

15 October 2012

Lionel Klee – Senior Business Analyst

igovt programme, Government Technology Services

Department of Internal Affairs

Purpose

The purpose of this paper is to describe how we would like to incorporate the Kantara sharing label and to provide some context about the overall solution. We have described three use cases, and the third use case illustrates our reliance on a consent service in order to implement user-centric information sharing where there are multiple parties and an intermediate broker service.

We have provided some commentary about the Kantara sharing label and our own components. We hope that these actual use cases will be informative and that this will lead to further discussion about the label and the overall initiatives of the InfoSharing work group.

Background

In New Zealand, the logon service has been in production since April 2007 and now provides citizens with federated pseudonymous authentication using SAML integration for about 40 different government service providers with about half a million users. The identity verification service provides complementary online assertion of identity based on authoritative government documentation. Recent legislation permits the identity verification service to progress from pilot to full implementation for use by both the government and private sectors.

Privacy legislation in New Zealand mandates against any unique identifier than can be shared across organisations to link a citizen’s record at one agency with their record. Furthermore, two agencies may only share information where legislation permits the specific exchange, unless the individual explicitly provides consent for the information to be shared. These privacy principles are fundamental to the design of the logon service which maintains a separate pseudonymous identifier - a federated logon tag (FLT) for each service provider – i.e. each privacy domain.

When an online business process needs to include more than one organisation, it becomes more challenging to extend the authentication while meeting the relevant privacy constraints. For more complex scenarios, reliance on browser redirects between service providers can become impractical as it relies on a continuous browser session.

This cross-agency online service objective has been achieved by a combination of browser and web services to maintain an extended authentication context management service (referred to as iCMS) that utilises a security token service based on WS-Trust messaging and SAML tokens.

Each transaction between one service provider and another needs to be based on a user-centric flow that obtains consent for sharing any personal identity attributes. When the circle of trust extends to more than two service providers or combines multiple identity attribute providers (IAPs), finding the means to obtain, store and access information sharing conditions and users’ consents becomes problematic. To address this need, we are implementing a centralised consent service. The consent service will provide three functions – a central repository of sharing terms (i.e. content of the sharing label), an archive of current and historical consents, and the ability to issue and validate consent tokens.

Commentary

The Kantara standard information sharing label

After applying draft version 0.4 of the label to a number of our anticipated sharing scenarios, the terms seem very fit for purpose and we don’t have any suggestions for significant modification. We look forward the initiatives to progress the sharing label design. We recognise that our use of the label would be very limited in terms of absolute numbers, although we are hoping that it is adopted by one or more major internet players that will bring the benefit of recognition by end users.

Kantara standard label content retrieval

As illustrated by our use cases, we anticipate that the service provider primarily responsible for displaying the label and collecting the user’s consent may not be the organisation responsible for the sharing conditions or providing the repository for the conditions. The user might be interacting with a broker that facilitates the sharing of identity attributes from one service provider to another.

It’s clearly beneficial to the person if they can view the conditions not only at the time of consent, but at any other time – particularly if the information sharing is for a duration that extends beyond the online session. In some circumstances the person may have read the sharing conditions and provided consent via a channel other than online – e.g. prior consent in a written contract. Even in a simple information sharing exchange between two service providers, it should be possible for the person to subsequently trigger display of the label from either service provider.

We would like to see Kantara’s current label content specification extended to include an XML messaging specification that describes how the label content should be transmitted between one party and another.

Kantara standard label rendering

While there is clearly significant benefit in a widely recognised visual format for the sharing label, it would seem somewhat restrictive to restrain the means by which it is displayed. In our context, we can make a choice as to how the label is displayed by the assertion service within the RealMe dashboard, but we are unlikely to always be able to influence the participating service providers or IAPs when they embed the display of the label within their online service.

Our current feeling is that the Amicus initiative to investigate browser plugins is likely to be problematic. It seems unlikely that all the major browser vendors would support such a plugin or that users would universally opt to download and install such a plugin. In any case, we anticipate that service providers or IdPs will want to have some control as to how the standard label is triggered and displayed within the context of the particular online service.

New Zealand ’s consent service

In the short term, our adoption of a separate consent service is as much a pragmatic solution to implementing the intermediate broker design for the assertion service and RealMe dashboard as it is a desire to follow the relevant privacy principles and demonstrate to the user the level of participation and openness in their information sharing transactions. (see http://kantarainitiative.org/confluence/download/attachments/45059378/NZ+RealMe+Solution+Overview+v1.pdf for an overview of the RealMe solution)

In the medium term, however, we anticipate that the consent service could effectively become a user-centric control mechanism – ideally under the purview of an independent authority, which would actively audit information sharing between service providers. This would require some of the data items contained in the sharing label to become fully machine readable and unambiguously interpretable – such as availability, for how long and output to.

In our context, we are considering a future solution evolution where the enabling security token service framework – iCMS would only issue or redeem tokens to support the information sharing exchange if the consent parameters are satisfied. The recent privacy impact assessment of iCMS and the RealMe assertion service recommended that the solution should provide system controls on the user’s behalf to ensure that any information sharing transactions complied with the specific sharing conditions for which consent was provided.

Consent tokens

The use case descriptions below refer to consent tokens that are issued by the consent service to service providers and IAPs. At this stage, we are still working on the definition and design of the consent token concept.

For the first iteration of the consent service, the consent token may be no more than a means to refer to a consent event recorded by the consent service. To comply with the New Zealand privacy principles we need to ensure that this reference cannot be used as a unique identifier to subsequently link a person across the privacy domains of two different service providers.

In subsequent iterations, we anticipate that a consent token issued by the consent service will be something like a SAML authentication token or attribute assertion. It will provide sufficient information to the service providers or identity attribute providers in an information sharing exchange that allows them to determine not only if the user has provided consent, but that the key agreed sharing conditions for the exchange have been satisfied.

While the label directly addresses the ability of the user to provide informed consent, we would like to see the approach cater for the transformation of the key sharing terms so that these can be subsequently accessible by any of the downstream systems or organisations involved in multi-party business transactions.

Context

Solution view

The diagram illustrates the New Zealand solution context and in particular the process flow described in use case 3 at the end of this document.

A New Zealand citizen (‘Customer’) is authenticated to a service provider (‘Client organisation) by the federated authentication IdP (logon service). When the service provider’s online service requires verified information such as identity and address, the citizen choose to share this information online by providing explicit consent through the identity dashboard application (‘Account’). The attribute assertion IdP (assertion service) acts an intermediary on behalf of the client between the service provider and the authoritative data sources (‘identify attribute providers’).

“RealMe” has been as an overarching brand name that seeks to extend the current use of the logon service and the igovt identity service only in the government sector to selected private sector clients such as financial institutions.

Logical View

The solution design encompasses three logical tiers that separate the functional domains. This separation is key to addressing the requirements for of privacy and information security.

Privacy Framework View

The solution is underpinned by the concept of privacy domain . No unique common identifiers are shared between the domains. This means the citizen’s personal information in one privacy domain cannot be used to understand or correlate personal information residing in another privacy domain.

The privacy domain model is enabled by the ability of the logon service to provide a mutually exclusive set of identifiers, or federated logon tags (FLTs), to these privacy domains. 

The context mapping service is shown as a common service available to each of the privacy domains. This allows browser or web services within each privacy domain to communicate with services in other privacy domains, but only with intermediation by the iCMS.

Conceptually the iCMS acts as a “privacy domain bus”. The operation of the content mapping service utilises security token service messaging.

Description of use cases

The following use cases represent the anticipated use of the consent service and are listed in order from one to many service providers/identity attribute providers.

Use case 1: Consent for single service provider – this use case could cater for citizen provided (self-asserted) information collected by the service where the service provider perceives value in utilising the third-party consent service. Under most conditions, the service provider would typically store the consent within the online service, but this use case is useful for demonstrating the simplest consent service scenario.

Use case 2: Consent for two service providers – this use case caters for the situation where the initial service provider’s online service needs to get or send personal identity data to or from a second service provider – probably during the user’s browser session at the initial online service. In this scenario the user’s consent might be checked by the second service provider before exchanging the personal information. This use case has been implemented using the iCMS and allows one government agency to exchange personal information with another in a privacy protective manner.

Use case 3: Consent for assertion service and multiple identity access providers – this use case caters for the scenario where a service provider can request a broker (assertion service IdP) to obtain personal information from multiple identity attribute providers. In this scenario, the user provides consent in turn via an identity dashboard to retrieve each credential. This use case is being implemented as the “RealMe dashboard” and assertion service. The initial IAPs are the identity verification service and the address verification service. Future identity attributes could include tax number, bank account number, car registration, etc. In most instances, the IAP will be the authoritative source of the attribute type, although data could also be sourced from non-verified or self-asserted sources.

Use cases

Use Case 1 - Consent for single service provider

The steps in this use case are as follows:

  • The Service User navigates to a protected resource at the service provider’s online service (SP1).
  • SP1 creates a SAML authentication request and redirects the user’s browser to the logon service where they enter their username and password (and second factor if required). The logon service redirects the user back to SP1 and completes an SAML artifact exchange to provide the user’s pseudonymous identifier – i.e. the federated logon tag (FLT SP1 ). The authentication response also includes a logon attributes token which can be used to bootstrap a subsequent token request.
  • The Service User triggers a business process that requires information consent to share. SP1 displays a page that requires the user to provide consent and includes the link for the standard label.
  • The Service User selects the sharing label link. Assuming that SP1 has chosen to store the sharing conditions with the consent service rather than within their online service, SP1 makes a call to the consent service to retrieve the applicable sharing conditions set and this is returned by the consent service.
  • SP1 displays the applicable information sharing label.
  • The Service User reads and accepts the sharing conditions and provides consent. The Service User’s consent should be stored at the consent service to provide the ability for easy reference.
  • SP1 retrieves the logon attributes token and sends this in a security token issue request to the iCMS to be used at the consent service.
  • The iCMS processes the request and returns an opaque token containing FLT SP1 and a copy of the original logon attributes (strength, authentication time, and expiry).
  • SP1 sends the opaque token and the consent details via a web service request to the consent service.
  • The consent service cannot read the opaque token and consequently makes an STS validate request to iCMS. This allows the consent service to redeem a logon token for its own privacy domain FLT CS which it can now use to pseudonymously record the consent event for future reference by the user or the service provider on the user’s behalf.
  • The consent service returns a consent token to SP1. This provides the Service Provider with ability to recall the consent details in the future.

Use case 2 - Consent for two service providers

Many of the steps in this use case are similar to those for the single service provider use case. The key difference is that the second service provider, which only participates via a web service, has the ability to check with the consent service that the Service User has provided an applicable consent. Following this check, the data exchange can be completed.

A summary of steps and highlights are as follows:

  • The Service User navigates to SP1 and is authenticated at the requisite step by the logon service. During the business process, the user triggers a condition that requires an identity attributes to be exchanged with SP2.
  • Before the exchange can take place, the Service User needs to provide consent. In this scenario, the sharing conditions have been agreed between SP1 and SP2 and the relevant details recorded with the consent service. When the user selects the standard label, SP1 requests the data from the consent service and displays the label.

  • After the Service User has read the sharing conditions and provided consent, SP1 needs to request iCMS to provide an opaque token to be used for storing the consent at consent service.
  • SP1 retrieves the logon attributes token and sends this in a security token issue request to the iCMS to be used at the consent service.
  • The iCMS processes the request and returns an opaque token containing FLT SP1 and a copy of the original logon attributes (strength, authentication time, and expiry).
  • SP1 sends the opaque token and the consent details via a web service request to the consent service.
  • The consent service cannot read the opaque token and consequently makes an STS validate request to iCMS. This allows the consent service to redeem a logon token for its own privacy domain FLT CS which it can now use to pseudonymously record the consent event for future reference by the user or the service provider on the user’s behalf.
  • The consent service returns a consent token to SP1. This provides the Service Provider with ability to audit and recall the consent details in the future.
  • To complete the personal information exchange with SP2, SP1 needs to obtain another opaque token for use with SP2. SP1 again uses the logon attributes token and sends an STS issue request to iCMS which returns the applicable opaque token.
  • SP1 sends the opaque token to SP2 via a web service call along with the request to exchange personal data.
  • SP2 makes an STS validate request to iCMS which returns the local logon token FLT SP2 . Typically the Service User would already have been authenticated at SP2, but under certain conditions SP2 might accept some identity information from SP1 and “auto-federate” the user.
  • If SP2 has sufficient trust that SP1 collected the required consent, then the data could be exchanged with SP1 at this point. If SP2 needs to check the consent, then it must opt to contact the consent service.
  • SP2 makes a STS issue request to the iCMS using the redeem token earlier received from iCMS and receives an opaque token for use at the consent service. SP2 makes a consent check request to the consent service using the opaque token. Consent service makes a validate request to iCMS and redeems the applicable FLT CS . The consent service returns the consent token to SP2. SP2 checks the consent and exchanges the personal data with SP1.

Use case 3 - Consents with assertion service

While the component flows in this use case are similar to the one and two service provider use cases, the key difference is the brokering role of the assertion service and the associated RealMe dashboard. In this information sharing scenario, the Service User is primarily interacting with the broker and not with the requesting service provider or the one or more identity attribute providers.

In this context, the central role of the consent service is a necessary ingredient to the implementation of the privacy protective and user-centric information sharing model. It’s difficult for SP1 to collect the relevant consents as the service provider does not have a direct relationship with the IAPs. It’s not possible for the Service User to supply consent at each of the IAPs as the credentials are only asserted via web services rather than browser redirect.

The steps in this use case are as follows:

  • The Service User navigates to a service provider’s online service (SP1).
  • The Service User triggers a step in the business process that allows for online assertion of identity attributes. Depending on the particular online service, the service provider may or may not have required the Service User to be authenticated.

  • The Service User chooses to use the “RealMe dashboard” method to verify their details online.
  • SP1 creates a SAML assertion request specifying that identity and address are required and redirects the user’s browser to the assertion service.
  • The assertion service needs the user to be authenticated to display the RealMe dashboard and process the request. The assertion service creates a SAML authentication request and redirects the user’s browser to the logon service.
  • The Service User enters their username and password and second factor.

 

  • The logon service redirects the user back to the assertion service and completes an artifact exchange to provide the user’s pseudonymous identifier – i.e. the federated logon tag (FLT RM ). The authentication response also includes a logon attributes token which can be used to bootstrap a subsequent token request.
  • Before displaying the identity dashboard, the assertion service needs to determine whether the Service User has previously provided consent for the assertion service to access the relevant IAPs – in this case the identity verification service and the address verification service. The assertion service retrieves the logon attributes token and sends this in a security token issue request to the iCMS to be used at the consent service.
  • The iCMS processes the request and returns an opaque token containing FLT RM and a copy of the original logon attributes (strength, authentication time, and expiry).
  • The assertion service sends the opaque token via a web service request to the consent service with a query to return the Service User’s consents for the RealMe dashboard to access the relevant IAPs.
  • The consent service cannot read the opaque token and consequently makes an STS validate request to iCMS. This allows the consent service to redeem a logon token for its own privacy domain FLT CS which it can now use to locate the applicable sharing consents for IAPs and the RealMe dashboard.
  • The consent service returns the relevant IAP consent tokens to the assertion service.
  • The assertion service again retrieves the logon attributes token and sends this in security token issue requests to the iCMS to be used at IAP1 and IAP2.
  • The iCMS processes the request and returns opaque tokens containing FLT RM .
  • The assertion service sends the respective opaque token via a web service request to IAP1 – the identity verification service with a query to return the status and details for the Service User’s identity credential (full name, date of birth, place of birth and gender).
  • IAP1 cannot read the opaque token and consequently makes an STS validate request to iCMS. This allows IAP1 to redeem a logon token for its own privacy domain FLT IVS which it can now use to retrieve the identity credential.
  • IAP1 returns the identity details via a web service response to the assertion service.
  • The assertion service also sends the respective opaque token via a web service request to IAP2 – the address verification service with a query to return the status and details for the Service User’s address credential.
  • IAP2 makes an STS validate request to iCMS. This allows IAP2 to redeem a logon token for its own privacy domain FLT AVS which it can now use to retrieve the address credential.
  • IAP2 returns the address details via a web service response to the assertion service.
  • The assertion service now has all the relevant data for the Service User and can display the RealMe identity dashboard page showing the IAP credentials, consent options and a standard label link for each IAP.

  • The Service User selects the sharing label link for the identity credential. The assertion service makes a call to the consent service to retrieve the applicable sharing conditions set and this is returned by the consent service.
  • The RealMe dashboard displays the applicable information sharing label.

 

  • The Service User reads and accepts the sharing conditions and provides consent for sharing identity.
  • The Service User selects the sharing label link for the address credential. The assertion service makes a call to the consent service to retrieve the applicable sharing conditions set and this is returned by the consent service.
  • The RealMe dashboard displays the applicable information sharing label.
  • The Service User reads and accepts the sharing conditions and provides consent for sharing address.
  • The Service User chooses to submit – i.e. to share the identity and address credentials with SP1.
  • The assertion service retrieves the opaque token previously used with the consent service and forwards the Service User’s consent events for IAP1 and IAP2 to the consent service.
  • The consent service again needs to make an STS validate request to iCMS to redeem the Service User’s FLT CS .
  • The consent service records the consent events for IAP1 and IAP2.
  • The consent service returns consent tokens to the assertion service for recording in the user’s transaction history record.
  • The assertion service creates a SAML assertion response and includes the identity and address assertions for IAP1 and IAP2 and redirects the user’s browser to SP1.
  • SP1 displays a page that shows the identity and address information that has been shared by the IAPs at the Service User’s request.