data formats for identity records standard · data formats for identity records standard 0 foreword...

Dat

a Fo

rmat

s fo

r Ide

ntity

Rec

ords

Sta

ndar

d

Data Formats for Identity Records Standard

<?xml version=”1.0” encoding=”UTF-8” ?>  <n1:Party xmlns:n1=”urn:oasis:names:tc:ciq:xpil:3” xmlns:a=”urn:oasis:names:tc:ciq:xal:3” xmlns:n=”urn:oasis:names:tc:ciq:xnl:3” xmlns:xlink=”http://www.w3.org/1999/xlink” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”urn: oasis:names:tc:ciq:xpil:3 xPIL.xsd”><n:PartyName> <n:PersonName> <n:NameElement n:ElementType=”LastName”>Citizen</n: NameElement> <n:NameElement n:ElementType=”FirstName”>Fred</n:NameElement> <n:NameElement n:ElementType=”MiddleName”>Wiremu</n: NameElement> <n:NameElement n:ElementType=”MiddleName”>John</n: NameElement> </n:PersonName></n:PartyName> <n1:PersonInfo n1:Gender=”M” /> <n1:BirthInfo> <n1:BirthInfoElement n1:ElementType=”BirthYear”>1963</n1: BirthInfoElement> <n1:BirthInfoElement n1:ElementType=”BirthMonth”>11</n1: BirthInfoElement> <n1:BirthInfoElement n1:ElementType=”BirthDay”>01</n1: BirthInfoElement> <n1:BirthInfoElement n1:ElementType=”BirthTime” /> <n1:BirthInfoElement n1:ElementType=”MothersName”>Jane Public</n1: BirthInfoElement> <n1:BirthPlace> <a:Country> <a:Name a:Abbreviation=”true”>NZ</a:Name> </a:Country> <a:Locality> <a:Name a:NameType=”Type”>Town</a:Name> <a:Name a:NameType=”Name”>Taihape</a:Name> </a:Locality> </n1:BirthPlace> </n1:BirthInfo></n1:Party>

Vers

ion

1.1

- Jul

y 20

08

DATA FORMATS FOR IDENTITY RECORDS STANDARD

�

0 ForewordThe Networked State Services Development Goal (State Services Commission 2005a) is that, by June 2010, the operation of government will have been transformed through the use of the Internet. The challenge will be to transform government through enabling technology, so that individuals and businesses have a better and more consistent experience in their dealings with government, agencies work more closely with their customers and with each other, and the cost of delivering services, both online and through other channels, is reduced. This will require agencies to move beyond one-way provision of information to two-way transactions.

Moving to two-way transactions requires parties to be confident of the identity of those they are transacting with over the Internet. This is ‘authentication’.

The Government has recognised the importance and significance of authentication to the e-government programme. In 2004 the State Services Commission was directed to undertake a programme of work to develop all-of-government shared services for online authentication.

Integral to this programme of work was the development of a suite of authentication standards to be incorporated into the New Zealand E-government Interoperability Framework (NZ e-GIF). These standards give effect to the planning advice from the State Services Commission’s 2004 Authentication for e-government: Best Practice Framework for Authentication. They outline current accepted good practice for the design (or re-design) of the authentication component of online services that require confidence in the identity of transacting parties.

This Data Formats for Identity Records Standard contains a set of identity-related data elements presented in an agreed format, to provide a common approach for agencies to systemise their identity management processes for users of their services. The elements focus on ‘who you are’ (identity) rather than ‘what you own/your role’ (attributes of identity) or ‘what you can do’ (authorisation).

Version 1.1 of the Data Formats for Identity Records Standard clarifies the requirements and meaning of selected sections and incorporates the latest release of the OASIS Customer Information Quality (CIQ) Specifications.


�

Contents0 Foreword .......................................................................................................................... 3

1 Introduction ...................................................................................................................... 9

2 Application of Standard ................................................................................................. 11

2.1 Audience ............................................................................................................. 11

2.2 NZ e-GIF status ................................................................................................... 11

2.3 Accessing advice on this Standard ...................................................................... 11

2.4 Interpretation ....................................................................................................... 11

2.5 Definitions ........................................................................................................... 12

3 Scope .............................................................................................................................. 14

3.1 Elements specified in this Standard .................................................................... 14

3.2 Guidance on elements not specified .................................................................... 14

3.3 Legislative obligations remain ............................................................................ 15

3.4 Out of scope ........................................................................................................ 16

4 Background .................................................................................................................... 17

4.1 Authentication standards ..................................................................................... 17

4.2 All-of-government authentication services ......................................................... 18

4.3 Party information data-interchange standards .................................................... 20

5 Implementation: Overview ............................................................................................. 22

5.1 Usage scenarios ................................................................................................... 22

5.2 Relationship to other standards and resources .................................................... 22

5.2.1 Customer information ............................................................................. 22

5.2.2 Data sharing ............................................................................................ 22

5.2.3 Mapping to/from a database .................................................................... 22

5.2.4 Namespaces ............................................................................................. 22

5.3 Key concepts in the design of the CIQ Specifications v3.0 ................................ 23

5.3.1 XLink ...................................................................................................... 23

5.3.2 Enumeration lists ..................................................................................... 23

5.3.3 Extensibility ............................................................................................ 24

5.3.4 Namespaces ............................................................................................. 24


6 Implementation: Analysis ............................................................................................... 25

6.1 Definition of identity-related data elements ........................................................ 25

6.2 Identity-related data elements and their atomic (or granular) values ................. 26

6.3 Diagrammatic model of CIQ v3.0 ...................................................................... 27

6.4 Mapping the CIQ Specifications v3.0 to the five self-reported identity- related data elements ........................................................................................... 28

6.4.1 <PersonName> container ........................................................................ 28

6.4.2 Name ....................................................................................................... 28

6.4.3 <PersonInfo> container ........................................................................... 29

6.4.4 <BirthInfo> container ............................................................................. 29

7 Implementation: Outline Guidance ................................................................................ 32

7.1 Tools and applications to implement this Standard ............................................ 32

7.2 Implementation considerations ........................................................................... 32

7.3 Basic steps to implementing the Standard .......................................................... 33

7.3.1 Principles ................................................................................................. 33

7.3.2 Approach ................................................................................................. 33

7.3.3 Parsing and validating ............................................................................. 34

7.4 Sample files and navigation or interpretation tools ............................................. 34

Working group representation .................................................................................................. 35

Acknowledgement .................................................................................................................... 35

Copyright .................................................................................................................................. 35

Referenced documents .............................................................................................................. 36

Latest revisions ......................................................................................................................... 37

Review of standards ................................................................................................................. 37

�


�

Appendices

A – Summary of Identity-Related Data Elements ................................................................... 38

B – Gender Code ..................................................................................................................... 40

C – Country Code .................................................................................................................... 41

D – Differentiating Between Multiple Names ......................................................................... 45

E – Pseudonymous Identifiers ................................................................................................. 46

F – Interpreting the Diagrammatic Models of CIQ v3.0 ......................................................... 47

G – File Interpretation and Navigation .................................................................................... 49

H – Sample Validated Exchange File....................................................................................... 50

Tables

1 – Authentication standards and documents .......................................................................... 18

2 – Definition of identity-related data elements as reported by the person ............................ 25

3 – Summary mapping of identity-related data elements and CIQ v3.0 ................................. 38

Figures

1 – Outline of interactions with all-of-government authentication services ........................... 19

2 – CIQ Specifications v3.0 .................................................................................................... 21

3 – Identity-related data elements and their atomic (or granular) values ............................... 26

4 – <Party> container showing <PartyName>, <PersonInfo>, and <BirthInfo> containers (from CIQ v3.0 schema) .................................................................................. 27

5 – <PersonName> container with <NameElement> element ................................................ 28

6 – <BirthInfo> container with <BirthInfoElement> element and <BirthPlaceDetails> container ............................................................................................................................ 29


�

1 IntroductionThis Standard is one of the NZ e-GIF authentication standards. These standards outline current accepted good practice for the design (or redesign) of the authentication component of online services that require confidence in the identity of parties transacting with government agencies. Implementation of these standards by agencies will reduce the possibility of misuse and abuse of identity arising from services being delivered online.

The authentication process consists of establishing and confirming the established identity over time. Establishing identity requires verified evidence of a person’s identity, so that they can be set up as an online service customer. The ongoing confirmation of identity requires the use of an ‘authentication key’, such as a username and password combination, to authenticate identity across the Internet.

The suite of authentication standards comprises:

• Guide to Authentication Standards for Online Services • Evidence of Identity Standard • Authentication Key Strengths Standard• Data Formats for Identity Records Standard• New Zealand Security Assertion Messaging Standard• Password Standard• Other authentication key standards (to be developed) • Guidance on Multi-factor Authentication• Security Assertion Messaging Framework.

The Guide to Authentication Standards for Online Services should be read before reading the Data Formats for Identity Records Standard, as it provides a high-level overview of the suite of authentication standards.

In the course of routine business and evidence of identity processes, agencies collect, record and, in some cases, exchange identity-related elements as part of a customer record. The Data Formats for Identity Records Standard specifies a set of data formats for a range of uses such as identity verification, authorised data matching, and information sharing.

A clear distinction between this Standard and the New Zealand Security Assertion Messaging Standard should be noted. There is no direct relationship between the standards. The Data Formats for Identity Records Standard supports the Evidence of Identity Standard’s processes of collecting, recording, and establishing the identity of individuals, ‘after the fact’ of a person self-reporting it. The New Zealand Security Assertion Messaging Standard is the format for conveying, in real-time, assertions and other security message types in a person’s online log-on session, in the course of ongoing authentication, authorisation, and identity verification.


Where agencies:

• use one or more elements specified in the Data Formats for Identity Records Standard, they SHOULD use the syntax specified in this Standard.

• exchange one or more elements specified in the Data Formats for Identity Records Standard, they MUST use the syntax specified in this Standard.

The data formats in this Standard are specified using an industry standard that is designed to represent party information (a ‘customer’ is a type of party) such as name and address, date and place of birth, and other identifying information.

Implementing this Standard will enable agencies to:

• improve interoperability between agencies under data matching agreements authorised by Parliament and monitored by the Office of the Privacy Commissioner

• reduce duplicated effort such as re-keying and mapping data• clarify agency requirements in Request for Proposal (RFP) documents, in turn helping

vendors propose consistent customer management system solutions.

As a technical standard, this document describes both policy and technical issues. Together with the Foreword, sections 1 to 4 provide information on the context, application, scope, and rationale for this Standard. These sections are of more interest to readers with policy responsibilities. Sections 5 to 7 provide the technical content of the Standard. These sections are of more interest to readers with technical responsibilities. In particular, section 6 defines each of the identity-related data elements, analyses the structure of these data elements, and maps each structure to specific components within the industry standard. Appendix A provides a two-page summary of the identity-related data elements defined in this Standard.

Agencies should note that they need to ensure there is adequate business continuity planning (BCP) for their online services.

10


11

2 ApplicationofStandard2.1 Audience

The intended audiences for this Standard are business and technical analysts, data architects, and developers. Readers are assumed to have in-depth knowledge of XML technologies, including schema, parsers, and programmatic navigation tools and libraries.

2.2 NZe-GIFstatusThis Standard is currently in the NZ e-GIF as Under development (U) and will graduate to Recommended (R) after a successful, documented implementation. This Standard is expected to graduate to Adopted (A) once there is a track record of proven successful implementations.

For guidance on agency responsibilities for compliance with NZ e-GIF standards at each status level, see the latest version of the NZ e-GIF (www.e.govt.nz).

2.3 AccessingadviceonthisStandardIn the first instance refer to the OASIS website, e-Commerce community section, Customer Information Quality (www.oasis-open.org/committees/ciq) for advice on this Standard. Further advice can be obtained from the agency initially responsible for this Standard:

e-GIF Operations

State Services Commission

Postal: PO Box 329, WELLINGTON

Phone: 04 495 6600

Fax: 04 495 6669

Email: [email protected]

Web: www.e.govt.nz

2.4 InterpretationThe following words, defined in Key Words for Use in RFCs to Indicate Requirement Levels (RFC 2119), are used in this Standard:

• ‘MUST’ – identifies a mandatory requirement for compliance with this Standard• ‘SHOULD’ – refers to practices that are advised or recommended• ‘MAY’ – refers to practices that are optional.

Agencies deviating from a ‘SHOULD’, MUST document:

• the reason for the deviation• an assessment of the residual risk resulting from the deviation• a date by which the decision will be reviewed• management’s approval of the above.

When cross-referencing sections of this Standard, the number only is quoted.


2.5 Definitions

Term Definition

Customer Information Quality Specifications v3.0 (CIQ v3.0)

The CIQ Specifications v3.0 are XML-based OASIS standards that define a vocabulary to represent party information (a ‘customer’ is a type of party) data, including identity-related data. CIQ v3.0 includes: eXtensible Name and Address Language (xNAL), eXtensible Party Information Language (xPIL) and eXtensible Party Relationship Language (xPRL). The xNAL Specification itself comprises eXtensible Name Language (xNL), and eXtensible Address Language (xAL).

eXtensible Markup Language (XML)

XML is a simple, very flexible text format derived from SGML. Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the World Wide Web and elsewhere.

eXtensible Stylesheet Language (XSL)

XSL is a language for expressing stylesheets ... Designers use an XSL stylesheet to express their intentions about how that structured content should be presented; that is, how the source content should be styled, laid out, and paginated onto some presentation medium.

[Edited from www.w3.org/TR/xsl/]

Government Logon Service (GLS) An all-of-government shared service that provides ongoing reconfirmation of online identity to participating agencies to the desired level of confidence.

Identity Verification Service (IVS) An all-of-government shared service that provides individuals with the option to verify their identity authoritatively, online, and in real-time with participating agencies to a passport level of confidence.

OASIS OASIS is a multi-organisation standards body that works to establish viable implementations of recommended interoperability formats and tools. The OASIS Customer Information Quality (CIQ) Technical Committee is responsible for delivering global, application-independent, open XML specifications for party/customer information and profile management.

Party Party means a person in this Standard. However, the CIQ Specifications v3.0 use the term party to mean a person or an organisation.

12


1�

XML Linking Language (XLink) XLink allows elements to be inserted into XML documents in order to create and describe links between resources.

XML Metadata Interchange (XMI) XML Metadata Interchange is an open information interchange model that allows developers who work with object technology to exchange programming data over the Internet in a standardised way.

XML Path Language (XPath) XPath is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer.

XSL Transformations (XSLT) XSLT is a language for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL (see eXtensible Stylesheet Language). XSL specifies the styling of an XML document by using XSLT to describe how the document is transformed into another XML document that uses the formatting vocabulary.

[Edited from www.w3.org/TR/xslt]


3 ScopeThe purpose of this Data Formats for Identity Records Standard is to specify data formats for a set of self-reported, identity-related data elements that government agencies may use in their customer records.

Where agencies:

• use one or more elements specified in the Data Formats for Identity Records Standard, they SHOULD use the syntax specified in this Standard

• exchange one or more elements specified in the Data Formats for Identity Records Standard, they MUST use the syntax specified in this Standard.

3.1 ElementsspecifiedinthisStandardThe following formats for a person’s self-reported identity-related data elements are specified in this Standard:

• name• gender • mother’s name• date of birth• place of birth.

These identity-related data elements are generally useful in most identity management systems and, in the Department of Internal Affairs’ experience in evidence-based processes, nearly always provide uniqueness. Each data element consists of more atomic elements, such as the component parts of a person’s name. Each of the data elements is defined in section 6.

This Standard also specifies the content, format, and structure of a validated exchange file that contains these identity-related data elements. Outline implementation guidance is given in section 7, although comprehensive implementation remains out of scope for this document. Additional implementation guidance will be provided once sufficient experience from initial implementations is gained.

Inclusion of all these identity-related data elements in the exchange file is not mandatory. For example, place of birth may not be available and so would be left blank in the exchange file. See section 7 for more guidance on implementing this Standard.

3.2 GuidanceonelementsnotspecifiedAgencies may need to use and exchange other authorisation-related data elements (such as role management, user entitlements, and access privileges), either in addition to or in place of the identity-related data elements listed in 3.1. Where this occurs, the exchange file SHOULD conform to the OASIS CIQ Specifications v3.0.

14


1�

3.3 LegislativeobligationsremainWhere agencies are undertaking data matching, they are required to fulfil their obligations under the Privacy Act 1993. In particular, agencies may need to have their proposed match authorised by Parliament through legislation. Once a match has received Parliamentary authorisation, the agencies must have an information matching agreement in place before the match can operate. In the interests of efficiency, as well as protection of personal privacy, agencies should ensure that the number of identity-related data elements included in their customer records is kept to the minimum required to fulfil service requirements.

All information collected and stored by a New Zealand government agency is deemed to be official information, and must be protected by strict adherence to promulgated policy statements such as Security in the Government Sector (SIGS) and the Protective Security Manual (PSM). This Data Formats for Identity Records Standard is to be used for services that deliver information classified as UNCLASSIFIED, IN CONFIDENCE, or SENSITIVE only, as specified in the Government’s Guidelines for Protection of Official Information.

Agencies MUST undertake a risk assessment for those risks associated with the delivery of their services through an interactive online channel. Agencies SHOULD follow the Australian and New Zealand Standard AS/NZS 4360:2004 on risk management for their authentication systems. Further advice on the application of AS/NZS 4360:2004 is set out in SAA/SNZ HB 436:2004 and SAA/SNZ HB 231:2004. Agencies also need to ensure there is adequate business continuity planning for their online services.

Many authentication risks may be addressed by ensuring that the authentication system is properly protected. The NZ e-GIF authentication standards do not give general advice for securing authentication systems. Agencies should comply with SIGS, NZSIT 400, ISO/IEC 17799:2005 and ISO/IEC 27001:2005.


3.4 OutofscopeThe following are outside the scope of this Standard:

• prescription of the minimum set of data elements to identify individuals uniquely• specification of business rules for interpretation, manipulation or use of the

elements• additional elements and schema for personal information that individual agencies

may wish to collect in order to enable or enhance their own specific internal processes and services

• Internet security and transport standards, policies and protocols associated with the storage and transport of identity records

• verification of the elements • information sharing, data matching and electronic data exchange policies and

processes• data modelling, database design, and data mapping tools such as eXtensible Stylesheet

Language (XSL)• comprehensive implementation guidance.

This Data Formats for Identity Records Standard is not a data storage standard. It does not define agency database fields, nor enforce database designs, although it may influence them. Rather, it defines data elements for the purposes of collecting and transferring data. Each agency decides whether it stores its data in the data formats specified in this Standard or whether it transforms its data when importing to and exporting from its databases. Where agencies store data elements as simple strings rather than as atomic or granular components, transformation will require splitting and mapping these simple strings into their correct atomic parts.

1�


1�

4 Background4.1 Authenticationstandards

The NZ e-GIF authentication standards provide detailed guidance for agencies to follow when designing their authentication solutions. In particular, the standards enable agencies to determine the level of identity-related risk for each of their services and to identify appropriate evidence of identity requirements and authentication key technologies (refer to 3.3 of the Evidence of Identity Standard).

Most online services delivered by government agencies are either anonymous (such as when someone downloads a brochure from an agency’s website) or have low levels of identity-related risk (such as when someone changes their address details). Services with low levels of identity-related risk are typically authenticated using minimal levels of evidence of identity requirements and username and passwords for ongoing confirmation of identity.

NOTE – Change of address is a generic example. For some services change of address may have a high level of identity-related risk.

To meet the Networked State Services Development Goal agencies will need to provide online services that have higher levels of identity-related risk. This will require the implementation of authentication solutions with more rigorous evidence of identity requirements and higher strength authentication keys.

Table 1 describes the purpose of each of the authentication standards and documents.


Table1–Authenticationstandardsanddocuments

Standard/document name Purpose

Guide to Authentication Standards for Online Services

Provides a high-level overview of the NZ e-GIF authentication standards.

Evidence of Identity Standard Specifies a business process for establishing the identity of government agency customers. Applies to offline as well as online services.

Authentication Key Strengths Standard

Specifies the authentication keys to be used for online authentication and protections necessary for the authentication exchange.


Specifies data formats for a set of customer information data elements that government agencies may use in customer identity records.

Password Standard Specifies requirements for passwords used for online authentication.

Other authentication key standards (to be developed)

Specify the requirements for two-factor authentication keys used for online authentication.

New Zealand Security Assertion Messaging Standard

Specifies messaging standards for communicating authentication assertions.

Guidance on Multi-factor Authentication

Provides an overview of multi-factor authentication. May be superseded once other authentication key standards are developed. Not a NZ e-GIF standard.

Security Assertion Messaging Framework

Provides a general introduction to security assertion messaging. Not a NZ e-GIF standard.

4.2 All-of-governmentauthenticationservicesAs well as supporting the implementation of individual agency authentication solutions, the authentication standards will also support the all-of-government authentication services – the Government Logon Service (GLS) and the Identity Verification Service (IVS). These shared services will allow agencies to devolve the management of the authentication component of online services.

The GLS is a service that allows people to access government online services more conveniently by using a common authentication mechanism appropriate to the service risk category established for the service. The IVS will allow people to establish their identity once so that they do not have to establish their identity separately with each agency that uses the IVS they transact with. See 2.5 for definitions of GLS and IVS.

18


1�

Agencies will interact with these shared services as follows:

• Registration – evidence of identity is established (IVS) and an authentication key is associated with the customer (GLS).

• First-time service – agencies verify identity for the customer’s first access (GLS and IVS) and link identity data and authentication key details. Agencies may also link a range of service-specific data.

• Repeat service – agencies confirm the identity of customers for ongoing access (GLS).

These interactions are shown in Figure 1 (State Services Commission 2005b).

Figure1–Outlineofinteractionswithall-of-governmentauthentication services

Where agencies adopt one or more of these shared services, they must adopt the standards relating to the functions of those services. Adopting the service relieves the agencies of some (but not all) obligations regarding standards adoption, since the service itself implements the standards applicable to its area of responsibility. However significant areas of the standards under the responsibility of the agency remain, such as risk assessments and agency website controls.

Agencies not using the shared services will have to comply with all of the authentication standards.

NOTE – The Data Formats for Identity Records Standard will be used by the proposed IVS to store

and exchange identity-related data.


4.3 Partyinformationdata-interchangestandardsStandards that represent identity-related data elements, such as customer names, are used to support data exchange or messaging. Such standards provide industry-developed schemas that uniformly represent customer information and structure transactions or messages into an XML file.

The feasibility of adopting an industry-developed party information standard to represent those identity-related data elements commonly used by New Zealand public sector agencies has been considered in developing this Standard.

The party information standard selected is the OASIS CIQ Specifications 3.0. CIQ v3.0 (OASIS 2008) defines a set of specifications and XML schema to represent several types of party-centric information, including name and address. After successful implementation, CIQ v3.0 is planned to replace the existing OASIS CIQ Specifications v2.0 later in 2008.

CIQ v3.0 comprises eXtensible Name and Address Language (xNAL), eXtensible Party Information Language (xPIL) and eXtensible Party Relationship Language (xPRL). The xNAL Specification itself comprises eXtensible Name Language (xNL), and eXtensible Address Language (xAL) (see Figure 2). The xPRL Specification is not used in the Data Formats for Identity Records Standard.

CIQ v3.0 has been designed and created following the experience gained from implementing earlier versions of OASIS CIQ standards, most notably xCIL v2.0. As a result, the overall XML schema structures are less hierarchical and include an enumeration strategy that allows complex elements to be represented by generic elements modified by ‘metadata tag’ values specific to each implementation. Consequently, CIQ v3.0 is cleaner and easier for developers to implement than its predecessors.

20


21

Figure2–CIQSpecificationsv3.0


5 Implementation:Overview5.1 Usagescenarios

This Data Formats for Identity Records Standard SHOULD be used by agencies when they prepare agreements for inter-agency data exchange. Agencies are most likely to use this Standard’s data elements and their formats when undertaking authorised information matching and data-sharing programmes. As shown in 4.2, this Standard will be used by the IVS to store and exchange identity-related data.

This Standard SHOULD be used by agencies as guidance when they redesign electronic and hard copy forms and systems, and prepare request for proposal (RFP) documentation. If agencies use any of the data elements specified in this Standard the elements MUST be formatted for electronic exchange as specified in this Standard. For example, agencies may continue to capture a person’s name elements as one element (a single string) as long as they exchange it in the atomised format shown in this Standard.

Agencies collecting and exchanging customer information-related elements that can be used to determine entitlement to services other than those specified in this Standard are encouraged to refer to the OASIS CIQ Specifications v3.0 for formatting guidance.

5.2 Relationshiptootherstandardsandresources5.2.1 CustomerinformationFor issues relating to customer information, refer to the relevant section of the New Zealand E-government Interoperability Framework (Business Services Layer).

5.2.2 DatasharingFor issues relating to inter-agency data exchange, refer to the relevant section of the New Zealand E-government Interoperability Framework (Information sharing and matching agreements).

5.2.3 Mappingto/fromadatabaseWhere target databases do not use the data elements specified in this Standard, either a mapping tool or the eXtensible Stylesheet Language (XSL) should be used for importing to or exporting from target databases. More information on XML mapping tools is available from: www.w3c.com.

5.2.4 NamespacesFor issues relating to namespaces, refer to the relevant section of the New Zealand E-government Interoperability Framework (Business Services Layer).

22


2�

5.3 KeyconceptsinthedesignoftheCIQSpecificationsv3.0

5.3.1 XLinkThe CIQ Specifications v3.0 make extensive use of the XML Linking Language (XLink). XLink allows “…elements to be inserted into XML files in order to create and describe links between resources. It uses XML syntax to create structures that can describe the simple unidirectional hyperlinks of…HTML, as well as more sophisticated links” (IDEAlliance 2005). For example, XLink helps programmers to link one person with another (Joe is the brother of Bill) and names with organisations (Samantha is the Director of Doe Limited).

NOTE – Within an XML file, links between resources can also be created and described using the

"Key" and "KeyRef" attributes (used as Primary and Foreign Keys) as defined in the CIQ Specifications v3.0. However, this implementation technique is now considered to have transitional conformance.

5.3.2 EnumerationlistsThe CIQ Specifications v3.0 make extensive use of enumeration lists. An enumeration list is an XML strategy to define and constrain element attributes. For example, to represent a person’s name in atomic or granular fashion, it is possible to prepare an enumeration list that defines and constrains the attributes of the <NameElement> element from CIQ v3.0.

An example of an enumeration list is given in the following extract from the sample validated exchange file. Values of the enumeration list are defined in quotes.

<NameElement n:ElementType="LastName" />

<NameElement n:ElementType="FirstName" />

<NameElement n:ElementType="MiddleName" />

<NameElement n:ElementType="MiddleName"

The CIQ Specifications v3.0 can also be used to constrain the values of XML element attributes using data from code value lists through the use of XML enumerations. For example, XML enumerations can be used to include agency-specific values in XML transfers to meet specific requirements.


5.3.3 ExtensibilityCIQ v3.0 is extensible. This allows agencies to add attributes under the prescribed element set of the schema to capture additional identity-related data elements. Take care in introducing additional elements in the XML-based file used to exchange data (validated exchange file), as the recipient may not be expecting them and this could lead to an inability to interoperate.

While the data elements specified in this Standard are useful in most identity management systems, CIQ v3.0 contains other data elements that agencies may wish to use. CIQ v3.0 is also fully extensible so that other, optional data elements, not included in the CIQ Specifications v3.0, can be added. More information on CIQ v3.0 is available from: www.oasis-open.org/committees/ciq. It is intended that the NZ e-GIF will ultimately adopt the full CIQ Specifications v3.0.

5.3.4 NamespacesCIQ v3.0 uses namespaces to separate elements that pertain to Name (n), Address (a), and Party (p). The schema specifies the rules of use of the namespaces, and the parser enforces the namespaces in the sense that elements from these three specific namespaces are ‘allowed’ in the resulting XML file. It is also possible to add other elements by defining additional namespaces, using the notation ‘x:’, as this is a valid namespace from the generic XML schema control file.

24


2�

6 Implementation:AnalysisThis section discusses how the self-reported identity-related data elements in this Standard map to the CIQ Specifications v3.0. Readers should appreciate the continually evolving nature of specifications and subsequent prescriptions of the specifications contained in this Standard. While the implementation analysis of CIQ v3.0 prescribed in this Standard (together with the XPath Statements, associated example XML files and IVS requirements) are valid at the time of publication, these core specifications may change over time. Exchanging parties implementing this Standard should refer to the latest specifications available and agree on any adjustment in their implementation as and when necessary.

6.1 Definitionofidentity-relateddataelementsTable 2 contains definitions and data types for the identity-related data elements in this Standard.

Table2–Definitionofidentity-relateddataelementsasreportedbytheperson

Data element Definition Data type

Name The full name, separated into logical atomic components: First Name, Middle Name/s and Last Name.

Text or Character

Gender The current sex of the person. Current sex aligns with the Department of Internal Affairs identity processes.

While not strictly accurate, the use of the term ‘Gender’ to describe current sex in a face-to-face, self-reported context is regarded as more socially and culturally acceptable by some sector agencies. Therefore a sex value is used to populate CIQ v3.0 Gender element.

The sex code will be chosen from a code list: F, M, or U, (see Appendix B).

Text or Character

Mother’s Name The full name of the person’s mother at the time of the mother’s birth is a string.

This structure is used to reflect the possibility that the person reporting their mother’s name at the time of the mother’s birth may not be able to separate it into logical atomic components.

Text or Character

Date of Birth The date of birth for the person, separated into logical atomic components: Birth Year, Birth Month, Birth Day and Birth Time.

The Birth Time structure is less rigid than the BirthDateTime structure in CIQ v3.0 to accommodate the likely variety of recording devices available ‘in situ’.

Numeric

Place of Birth The name of the Locality and Country where the person was born. Locality is a string and the Country code will be chosen from a code list (see Appendix C).

The Locality structure allows the optional use of enumeration or controlled value lists and implementation-related application logic.

Text or Character

See notes on page 26


NOTE –

(1) Data for each of the data elements defined in Table 2 is as reported by the person (self-reported) about their own identity. That is, the data need not be verified against source documentation. This is why some data elements are not separated into logical atomic components. The person reporting this data to an agency may have insufficient detailed knowledge of the elements, beyond their own name.

(2) Where agencies wish to exchange multiple instances of Name of Person, they should use multiple instances in the exchange record (see Appendix D).

(3) Where agencies wish to exchange data that requires a time-qualifier, they should use business processes to do this.

(4) Where agencies wish to incorporate a pseudonymous identifier in an exchange file, they should use

the "PartyID" and "PartyIDType" attributes for the <Party> container (see Appendix E).

6.2 Identity-relateddataelementsandtheiratomic(orgranular)valuesFigure 3 provides a schematic representation of the atomic or granular components of the five identity-related data elements defined in Table 2.

Figure3–Identity-relateddataelementsandtheiratomic(orgranular)values

Place of Birth

Date of Birth

Mother’s Name

Gender

Name

Last Name

First Name

Middle Name/s

Gender*

Name

Birth Year

Birth Day

Birth Month

Birth Time

Country*

Locality

* To be used with a code list. See Appendices B and C

Identity-related data elements Atomic (granular) values

2�


2�

6.3 DiagrammaticmodelofCIQv3.0Figures 4 to 6 have been derived using Altova’s XML editing tool, XMLSpy. A guide to the symbols used in the figures is set out in Appendix F. Note that not all CIQ v3.0 components are able to be represented in these figures.

The <Party> container from the CIQ xPIL Specification v3.0 contains all of the party information data elements. This container can be used to represent an individual or an organisation, or a combination of both. There is specific syntax to describe the relationship between members of a party if there is more than one.

The <Party> container includes the <PartyName>, <PersonInfo>, and <BirthInfo> containers. Each of the five identity-related data elements specified in this Standard maps to one of these three containers. The details of this mapping are reviewed in 6.4. Figure 4 shows the relationship of these three containers to the <Party> container.

Figure4–<Party>containershowing<PartyName>,<PersonInfo>,and <BirthInfo>containers(fromCIQv3.0schema)


6.4 Mapping theCIQSpecificationsv3.0 to the fiveself-reported identity-relateddataelements

6.4.1 <PersonName>containerThe <PartyName> container includes the <PersonName> container from the OASIS CIQ xNL Specification v3.0. The <PersonName> container has an element <NameElement> that defines person name (see Figure 5). The <NameElement> element contains the atomic parts of a person’s name which are distinguished by the default enumeration list values provided by the Specification.

Figure5–<PersonName>containerwith<NameElement>element

6.4.2 NameThe <NameElement> element has an enumeration list that provides flexibility in the metadata tags and, therefore, the context of the data contained in the element. As there is no mechanism to explicitly constrain the content of the <NameElement> element, the CIQ v3.0 requirement for a specific order must be satisfied with programmatic support and explicit business rules. The elements in the <PersonName> container shall appear in the order shown in the following extract from the sample validated exchange file:

<n:NameElement n:ElementType="LastName"></n:NameElement>

<n:NameElement n:ElementType="FirstName"></n:NameElement>

<n:NameElement n:ElementType="MiddleName"></n:NameElement>


Surname prefixes such as de, von, le and so on are included within the last name with a space between the prefix and the surname:

<n:NameElementn:ElementType="LastName">deJong</n:NameElement>

28


2�

NOTE – If it is necessary to differentiate between surname and surname prefixes, then the enumeration

"LastNamePrefix" can be added to the enumeration list for <NameElement> by modifying an

XML schema definition file (xPIL-types.xsd) by inserting the XML code:

<xs:enumeration value="LastNamePrefix"/>

The corresponding <NameElement> element will appear in the exchange file as:

<n:NameElementn:ElementType="LastNamePrefix"></n:NameElement>

6.4.3 <PersonInfo>containerThe <PersonInfo> container can be used to represent gender.

6.4.3.1 GenderIn order to accommodate the person’s current sex, the <PersonInfo> container has an element called gender that is an empty enumeration list. The enumeration list MUST be populated with code list values F, M, or U from the code list HISO 10006 (see Appendix B).

6.4.4 <BirthInfo>containerThe <BirthInfo> container includes the <BirthInfoElement> element and <BirthPlaceDetails> container. This element and container can be used to represent the three remaining identity-related data elements: mother’s name, date of birth, and place of birth (see Figure 6).

Figure6–<BirthInfo>containerwith<BirthInfoElement>elementand <BirthPlaceDetails>container


6.4.4.1 Mother’snameIn order to represent the birth name of the person’s mother in a CIQ v3.0 element, the enumeration list for the <BirthInfoElement> element within the <BirthInfo> container has to be changed to include the attribute value "MothersName". The attribute value "MothersName", as it appears in the sample validated exchange file, is shown in the following extract.

<p:BirthInfoElement p:Type="MothersName"></p:BirthInfoElement>

6.4.4.2 DateofbirthIn order to represent a granular date of birth, the enumeration list for the <BirthInfoElement> element within the <BirthInfo> container has to be changed to include the following attribute values: "BirthYear", "BirthMonth", "BirthDay", and "BirthTime". These attribute values, as they appear in the validated exchange file, are shown as:

<p:BirthInfoElement p:Type="BirthYear"></p:BirthInfoElement>

<p:BirthInfoElement p:Type="BirthMonth"></p:BirthInfoElement>

<p:BirthInfoElement p:Type="BirthDay"></p:BirthInfoElement>

<p:BirthInfoElement p:Type="BirthTime"></p:BirthInfoElement>

As there is no mechanism to explicitly constrain the content of the <BirthInfoElement> element, the requirement for a numeric data type must be satisfied with programmatic support and explicit business rules. The <BirthInfoElement> element’s attribute values are numeric, with specific value ranges as appropriate to the meaning of the element:

• "BirthYear" will have a format of YYYY. Values must be equal to or greater than 1890 and less than or equal to today’s date

• "BirthMonth" will have a format of MM. Values must be greater than 00 and less than 13

• "BirthDay" will have a format of DD. Values must be greater than 00 and less than 32

• "BirthTime" is likely to be left blank, but will have a format of HH:MM:SS. Values for ‘HH’ must be greater or equal to 00 and less than or equal to 24. Values for ‘MM’ and ‘SS’ must be greater or equal to 00 and less than or equal to 60.

NOTE – The "BirthDateTime" attribute from CIQ v3.0 has not been specified in this Standard. In

the view of the working group the highly constrained numeric value specified in "BirthDateTime" may inhibit wide adoption of this attribute. However, exchanging parties MAY agree to use

"BirthDateTime" in their data exchange agreements if it is practical to do so.

�0


�1

6.4.4.3 PlaceofbirthThe <BirthPlaceDetails> container includes the <Country> and <Locality> containers from the OASIS CIQ xAL v3.0 Specification. The <Country> and <Locality> containers can be used to represent the place of birth in a CIQ v3.0 element.

The country name can either be abbreviated, using ISO 3166 two letter codes, or entered as a complete word. If the exchanging parties are prescribing abbreviations, it MUST be indicated in the Country Name node (abbreviation values are "true" or "false").

The locality name is described with two nodes, one for the type of locality, for example city, suburb, town, village, and one for its actual name.

An extract from the sample validated exchange file for place of birth is as follows:

<a:Country>

<a:NameElement ct:Abbreviation="true"

a:NameType="Name"></a:NameElement></a:Country>

<a:Locality>

<a:NameElement a:NameType="Type"></a:NameElement>

<a:NameElement a:NameType="Name"></a:NameElement>

</a:Locality>

NOTE –

(1) If a controlled value list for type of locality is desired, it must be agreed between the parties in the

data-exchange agreement. Specific values should not be added to the schema to enforce rules of

conformity for the locality types.

(2) Due to the changing nature of the ISO 3166 Code Lists in response to new nation names emerging

and others ceasing use, a person may self-report a country that does not appear in the list. For

example, Yugoslavia no longer appears on the latest ISO 3166 Code List. The treatment for this is

to allow a string value as the following sample file extract shows:

<a:Country>

<a:NameElement ct:Abbreviation="false"

a:NameType="Name">Yugoslavia</a:NameElement>

</a:Country>


7 Implementation:OutlineGuidance7.1 ToolsandapplicationstoimplementthisStandard

Where possible, this Standard uses XML-based open standards and industry specifications such as XLink, XMI, and XSLT. More information on these standards and tools is available from the World Wide Web Consortium (W3C): www.w3c.com.

A range of technical skills is necessary to create valid XML files. These skills include an understanding of the XML file creation, validation and interpretation processes (and likely sources of error or failure), and an understanding of the logic and semantic meaning of the data elements to be included in validated exchange files.

The particular tools and applications required to use this Standard are:

• the data dictionary for the local database, available from the database administrator• XML parser software, either open source or provided by the commercial vendor• OASIS CIQ Specifications v3.0, available from www.oasis-open.org/committees/

ciq• Schema files for the CIQ Specifications v3.0, available from www.oasis-open.org/

committees/ciq:– xNL.xsd Name Elements– xNL-types.xsd Name Elements Enumeration Lists– xAL.xsd Address Elements– xAL-types.xsd Address Elements Enumeration Lists– xPIL.xsd Party Elements– xPIL-types.xsd Party Elements Enumeration Lists – xNAL.xsd Name and Address Elements (Record)– xNAL-types.xsd Name and Address Elements Enumeration List– xLink.xsd Types of linkage connectors.

7.2 ImplementationconsiderationsA range of considerations and decisions needs to be made when preparing validated exchange files to represent the identity-related data elements in this Standard. Once these decisions are made, the developer can proceed to write the code to prepare the validated exchange file in XML format.

The first consideration is how to map this Standard’s identity-related data elements to the fields that are stored and managed in agency databases. Database administrators should be able to assist with this mapping. The question to answer is: ‘Which fields in our agency database correspond to the identity-related data elements in the Standard?’

�2


��

Second, it is important to remember that different sets of identity-related data elements may be required for different services. The question to answer is: ‘What data elements do I need for my services?’

Finally, the implementation ‘rules’ laid out in this Standard will need to be interpreted by the developer, to ensure that the data elements are constructed correctly and put in the correct order. Additionally, it is the developer’s responsibility to ensure the resulting XML file is parsed without error so it conforms to the CIQ Specifications v3.0.

7.3 BasicstepstoimplementingtheStandard

7.3.1 PrinciplesThe following principles SHOULD be followed in implementing this Standard:

• Exchanging parties SHOULD engage, agree, and confirm:– their interpretation of this Standard and implementation considerations– reference to the latest CIQ Specifications v3.0 available (in order to avoid the

generation of a separate schema requiring future maintenance and synchronisation with CIQ v3.0)

– any additional exchange rules specific to the exchange (a draft data exchange checklist is available from the State Services Commission)

– any adjustment in the parties’ file exchange implementation as and when necessary.

• Inclusion of all these identity-related data elements in the exchange file is not mandatory. For example, place of birth may not be available and so would be left blank in the exchange file.

7.3.2 ApproachRegardless of the extent to which implementation of this Standard is automated by agencies, an appropriate data-sharing agreement and adequate software programming logic will be required. There are three phases to implementing the Standard:

• Creating a valid XML file for transmission to another agency by building an application that follows the rules of CIQ Specifications v3.0.

• Checking the XML file for validity against the latest CIQ Specifications v3.0 using a fit-for-purpose XML editing and parsing tool. Processing-logic applications SHOULD be programmed to ignore empty elements.

• Interpreting an XML file that came from an outside agency by using XPath to navigate the structure of the validated exchange file.


7.3.3 ParsingandvalidatingThe parsing process helps ensure that the structure of the XML file is well-formed and validated (that is, that any elements required by the IVS to be present are, in fact, present and in the correct order) and that the file conforms to the agreed (ideally latest) CIQ Specifications v3.0 and XPath statements. The current applicable XPath statements at the time of writing are shown in Appendix G. Therefore, the following principle applies: Before exchange, XML files SHOULD be parsed by the sending party without error using a parser agreed by the receiving party, however, on each exchange the XML files SHOULD be parsed by the receiving party because it is in their best interests to validate the incoming XML files before transferring them to a processing system

7.4 SamplefilesandnavigationorinterpretationtoolsThe sample validated exchange file in Appendix H illustrates appropriate places to accommodate the identity-related data elements defined in this Standard. The CIQ Specifications v3.0 (current at the time of publication) were used to create the sample validated exchange file. For the first stage of creating a valid XML file, a fit-for-purpose editing and parsing tool is used to edit and validate the contents. For the CIQ Specifications v3.0 particulars, including the valid metadata tag names and the order of the elements, the CIQ Specifications v3.0 serve as the filter to create a structurally-valid XML file.

From the experience in creating the sample validated exchange file, it is possible to create the following summary of rules for the hierarchy and order of elements, from the CIQ Specifications v3.0:

<Party> is a container element and the outermost element<PartyName> is the first element container

<PersonName> is a member of <PartyName><PersonInfo> is the second element container<BirthInfo> is the third element container

<BirthInfoElement> is a member of <BirthInfo><BirthPlaceDetails> is a member of <BirthInfo>

</Party> is the closing element for the file and matches the outermost element.

Appendix H contains a sample validated exchange file. Appendix G sets out sample programmatic navigation paths for the sample validated exchange file in Appendix H.

�4


��

WorkinggrouprepresentationThe following organisations contributed representatives to the working group that developed this Standard:

Accident Compensation CorporationDepartment of Internal Affairs Digeridoo Pty LtdInland Revenue DepartmentLand Transport New ZealandManukau City CouncilMinistry of EducationMinistry of HealthMinistry of JusticeNew Zealand Customs ServiceNew Zealand PoliceState Services CommissionStatistics New Zealand

AcknowledgementThe State Services Commission gratefully acknowledges the contribution of time and expertise from all those involved in developing this Standard.

CopyrightThis Standard is subject to Crown copyright. Those wishing to use, copy or adapt the Standard can find licensing information on the e-government website at:

www.e.govt.nz/standards/e-gif/authentication.


ReferenceddocumentsInternationalandJointAustralian/NewZealandStandardsandHandbooksISO 3166-1:2006 Codes for the representation of names of countries and their

subdivisions – Part 1: country codes. www.iso.org

AS/NZS 4360:2004 Risk management (Australian/New Zealand Standard). www.standards.co.nz

SAA/SNZ HB 231:2004 Information security risk management guidelines (Australian/New Zealand handbook). www.standards.co.nz

SAA/SNZ HB 436:2004 Risk management guidelines (Australian/New Zealand handbook). www.standards.co.nz

OtherBradner, S. March 1997. Key words for use in RFCs to indicate requirement levels (RFC 2119). www.ietf.org

Department of Internal Affairs. 2006. Evidence of identity standard. Version 1.0. www.dia.govt.nz

Department of the Prime Minister and Cabinet. 2002. Security in the government sector. www.security.govt.nz

Department of the Prime Minister and Cabinet. 2001. Guidelines for protection of official information. www.security.govt.nz

IDEAlliance. 2005. XLink. www.idealliance.org

Ministry of Health. 2005. Health practitioner index (HPI) – code set HISO 10006. www.hiso.govt.nz

New Zealand Security Intelligence Service. 2002. Protective security manual. www.nzsis.govt.nz

OASIS. 2008. CIQ version 3.0 Committee Specifications www.oasis-open.org/committes/ciq

State Services Commission. 2008. New Zealand e-government interoperability framework (NZ e-gif) Version 3.3. www.e.govt.nz

State Services Commission. 2008. New Zealand security assertion messaging standard. Version 1.0. www.e.govt.nz

��


��

State Services Commission. 2006. Authentication key strengths standard. Version 1.0. www.e.govt.nz

State Services Commission. 2006. Guidance on multi-factor authentication. Version 1.0. www.e.govt.nz

State Services Commission. 2006. Guide to authentication standards for online services. Version 1.0. www.e.govt.nz

State Services Commission. 2006. Password standard. Version 1.0. www.e.govt.nz

State Services Commission. 2006. Security assertion messaging framework. www.e.govt.nz

State Services Commission. 2005a. Development goals for the State Services. www.e.govt.nz

State Services Commission. 2005b. Authentication for e-government: Government Logon Service design overview. www.e.govt.nz

State Services Commission. 2004. Authentication for e-government: Best practice framework for authentication. www.e.govt.nz

NewZealandLegislationPrivacy Act 1993

LatestrevisionsThis Standard is to be reviewed from time to time by the working group so that it keeps up to date with changes in technology and business requirements in the sector.

Users should ensure they access the latest revisions of the NZ e-GIF authentication standards including amendments (if any). These can be found at www.e.govt.nz. Users should also access the latest revisions of the documents included in the list of referenced documents set out in this Standard.

ReviewofstandardsSuggestions for improvement of this Standard are welcomed. They should be sent to the Manager, e-GIF Operations, State Services Commission, PO Box 329, Wellington. Alternatively, suggestions can be sent by email to [email protected].


App

endi

xA

–Su

mm

ary

ofId

entit

y-R

elat

edD

ata

Elem

ents

This

app

endi

x su

mm

aris

es th

is S

tand

ard

by ta

bula

ting

the

defin

ition

, dat

a ty

pe, a

nd a

n ex

tract

from

the

va

lidat

ed e

xcha

nge

file

for e

ach

of th

e fiv

e id

entit

y-re

late

d da

ta e

lem

ents

.

Tabl

e3

–Su

mm

ary

map

ping

ofi

dent

ity-r

elat

edd

ata

elem

ents

and

CIQ

v3.

0

Dat

a el

emen

tD

efini

tion

Dat

a ty

peE

xtra

ct fr

om v

alid

ated

exc

hang

e fil

e

Nam

e Th

e fu

ll na

me,

sepa

rate

d in

to lo

gica

l at

omic

com

pone

nts:

Firs

t Nam

e, M

iddl

e N

ame/

s and

Las

t Nam

e.

Text

or

Cha

ract

er<n:NameElement n:ElementType="LastName"></n:NameElement>

<n:NameElement n:ElementType="FirstName"></n:NameElement>



Gen

der

The

curr

ent s

ex o

f the

per

son.

Cur

rent

se

x al

igns

with

the

Dep

artm

ent o

f In

tern

al A

ffairs

iden

tity

proc

esse

s.

Whi

le n

ot st

rictly

acc

urat

e, th

e us

e of

th

e te

rm ‘G

ende

r’ to

des

crib

e cu

rren

t sex

in

face

-to-f

ace

self-

repo

rted

cont

ext i

s re

gard

ed a

s mor

e so

cial

ly a

nd c

ultu

rally

ac

cept

able

by

som

e se

ctor

age

ncie

s.

Ther

efor

e a

sex

valu

e is

use

d to

pop

ulat

e C

IQ v

3.0

Gen

der e

lem

ent.

The

sex

code

will

be

chos

en fr

om a

cod

e lis

t: F,

M, o

r U (s

ee A

ppen

dix

B).

Text

or

Cha

ract

er<p:PersonInfo p:Gender="M" />

Mot

her’s

N

ame

The

full

nam

e of

the

pers

on’s

mot

her a

t th

e tim

e of

the

mot

her’s

birt

h is

a st

ring.

This

stru

ctur

e is

use

d to

refle

ct th

e po

ssib

ility

that

the

pers

on re

porti

ng

thei

r mot

her’s

nam

e at

the

time

of

the

mot

her’s

birt

h m

ay n

ot b

e ab

le

to se

para

te it

into

logi

cal a

tom

ic

com

pone

nts.

Text

or

Cha

ract

er<p:BirthInfoElement p:Type="MothersName"></p:BirthInfoElement>

�8


��

Dat

e of

Birt

hTh

e da

te o

f birt

h fo

r the

per

son,

se

para

ted

into

logi

cal a

tom

ic

com

pone

nts:

Birt

h Ye

ar, B

irth

Mon

th,

Birt

h D

ay, a

nd B

irth

Tim

e.

The

Birt

h Ti

me

stru

ctur

e is

less

rigi

d th

an th

e B

irthD

ateT

ime

stru

ctur

e in

CIQ

v3

.0 to

acc

omm

odat

e th

e lik

ely

varie

ty

of re

cord

ing

devi

ces a

vaila

ble

‘in si

tu’.

Num

eric

<p:BirthInfoElement p:Type="BirthYear"></p:BirthInfoElement>

<p:BirthInfoElement p:Type="BirthMonth"></p:BirthInfoElement>

<p:BirthInfoElement p:Type="BirthDay"></p:BirthInfoElement>

<p:BirthInfoElement p:Type="BirthTime"></p:BirthInfoElement>

Plac

e of

B

irth

The

nam

e of

the

Loca

lity

and

Cou

ntry

w

here

the

pers

on w

as b

orn.

Loc

ality

is

a st

ring

and

the

Cou

ntry

cod

e w

ill b

e ch

osen

from

a c

ode

list (

see A

ppen

dix

C).

The

Loca

lity

stru

ctur

e al

low

s the

op

tiona

l use

of e

num

erat

ion

or c

ontro

lled

valu

e lis

ts a

nd im

plem

enta

tion-

rela

ted

appl

icat

ion

logi

c.

Text

or

Cha

ract

er<a:Country>


a:NameType="Name"></a:NameElement>

</a:Country>

<a:Locality>

<a:NameElement a:NameType="Type"></a:NameElement>

<a:NameElement a:NameType="Name"></a:NameElement>

</a:Locality>


AppendixB–GenderCodeThis appendix contains the current sex Code List for the Gender element referred to in 6.1, 6.2 and 6.4.3.1. This Code List comes from section 2.4.1 of the Ministry of Health’s Health Practitioner Index (HPI) – Code Set HISO 10006. Exchanging parties should use the latest list available, agreed by the parties.

Value Description Note

F Female –

M Male –

U Unknown Not stated, or inadequately described.

40


41

AppendixC–CountryCodeThis appendix contains the current Code List for the <Country> container referred to in 6.1, 6.2 and 6.4.4.3. The Code List comes from ISO 3166-1:2006 Codes for the representation of names of countries and their subdivisions – Part 1: country codes. Exchanging parties should use the latest list available, agreed by the parties.

Value Description Value Description

AD Andorra BR Brazil

AE United Arab Emirates BS Bahamas

AF Afghanistan BT Bhutan

AG Antigua and Barbuda BV Bouvet Island

AI Anguilla BW Botswana

AL Albania BY Belarus

AM Armenia BZ Belize

AN Netherlands Antilles CA Canada

AO Angola CC Cocos (Keeling) Islands

AQ Antarctica CD Congo, The Democratic Republic of the

AR Argentina CF Central African Republic

AS American Samoa CG Congo

AT Austria CH Switzerland

AU Australia CI Côte d’Ivoire

AW Aruba CK Cook Islands

AX Åland Islands CL Chile

AZ Azerbaijan CM Cameroon

BA Bosnia and Herzegovina CN China

BB Barbados CO Colombia

BD Bangladesh CR Costa Rica

BE Belgium CU Cuba

BF Burkina Faso CV Cape Verde

BG Bulgaria CX Christmas Island

BH Bahrain CY Cyprus

BI Burundi CZ Czech Republic

BJ Benin DE Germany

BL Saint Barthélemy DJ Djibouti

BM Bermuda DK Denmark

BN Brunei Darussalam DM Dominica

BO Bolivia DO Dominican Republic

DZ Algeria HK Hong Kong


EC Ecuador HM Heard Island and Mcdonald Islands

EE Estonia HN Honduras

EG Egypt HR Croatia

EH Western Sahara HT Haiti

ER Eritrea HU Hungary

ES Spain ID Indonesia

ET Ethiopia IE Ireland

FI Finland IL Israel

FJ Fiji IM Isle of Man

FK Falkland Islands (Malvinas) IN India

FM Micronesia, Federated States of IO British Indian Ocean Territory

FO Faroe Islands IQ Iraq

FR France IR Iran, Islamic Republic of

GA Gabon IS Iceland

GB United Kingdom IT Italy

GD Grenada JE Jersey

GE Georgia JM Jamaica

GF French Guiana JO Jordan

GG Guernsey JP Japan

GH Ghana KE Kenya

GI Gibraltar KY Kyrgyzstan

GL Greenland KH Cambodia

GM Gambia KI Kiribati

GN Guinea KM Comoros

GP Guadeloupe KN Saint Kitts and Nevis

GQ Equatorial Guinea KR Korea, Democratic Peoples’ Republic of

GR Greece KW Kuwait

GS South Georgia and the South Sandwich Islands

Ky Cayman Islands

GT Guatemala KZ Kazakhstan

GU Guam LA Lao Peoples’ Democratic Republic

GW Guinea-Bissau LB Lebanon

GY Guyana LC Saint Lucia

42


4�

LI Liechtenstein NL Netherlands

LK Sri Lanka NO Norway

LR Liberia NP Nepal

LS Lesotho NR Nauru

LT Lithuania NU Niue

LU Luxembourg NZ New Zealand

LV Latvia OM Oman

LY Libyan Arab Jamahiriya PA Panama

MA Morocco PE Peru

MC Monaco PF French Polynesia

MD Moldova, Republic of PG Papua New Guinea

ME Montenegro PH Philippines

MF Saint Martin PK Pakistan

MG Madagascar PL Poland

MH Marshall Islands PM Saint Pierre and Miquelon

MK Macedonia, The Former Yugoslav Republic of PN Pitcairn

ML Mali PR Puerto Rico

MM Myanmar PS Palestinian Territory, Occupied

MN Mongolia PT Portugal

MO Macao PW Palau

MP Northern Mariana Islands PY Paraguay

MQ Martinique QA Qatar

MR Mauritania RE Reunion

MS Montserrat RO Romania

MT Malta RS Serbia

MU Mauritius RU Russian Federation

MV Maldives RW Rwanda

MW Malawi SA Saudi Arabia

MX Mexico SB Solomon Islands

MY Malaysia SC Seychelles

MZ Mozambique SD Sudan

NA Namibia SE Sweden

NC New Caledonia SG Singapore

NE Niger SH Saint Helena

NF Norfolk Island SI Slovenia

NG Nigeria SJ Svalbard and Jan Mayen

NI Nicaragua SK Slovakia


SL Sierra Leone TV Tuvalu

SM San Marino TW Taiwan, Province of China

SN Senegal TZ Tanzania, United Republic of

SO Somalia UA Ukraine

SR Suriname UG Uganda

ST Sao Tome and Principe UM United States Minor Outlying Islands

SV El Salvador US United States

SY Syrian Arab Republic UY Uruguay

SZ Swaziland UZ Uzbekistan

TC Turks and Caicos Islands VA Holy See (Vatican City State)

TD Chad VC Saint Vincent and The Grenadines

TF French Southern Territories VE Venezuela

TG Togo VG Virgin Islands, British

TH Thailand VI Virgin Islands, U.S.

TJ Tajikistan VN Vietnam

TK Tokelau VU Vanuatu

TL Timor-Leste WF Wallis and Futuna

TM Turkmenistan WS Samoa

TN Tunisia YE Yemen

TO Tonga YT Mayotte

TR Turkey ZA South Africa

TT Trinidad and Tobago ZM Zambia

44


4�

AppendixD–DifferentiatingBetweenMultipleNamesThis appendix contains sample XML code to illustrate how exchanging parties can differentiate between a person’s multiple names by using the enumerations for the <PersonName> container. This example uses two enumerations from the range of available enumerations for the <PersonName> container. Exchanging parties will need to agree on which particular enumerations they will use.

<n:PersonName n:Type="CommonUse">

<n:NameElement n:ElementType="LastName">Citizen</n:NameElement>

<n:NameElement n:ElementType="FirstName">Fred</n:NameElement>

<n:NameElement n:ElementType="MiddleName">Wiremu</n:NameElement>

<n:NameElement n:ElementType="MiddleName">John</n:NameElement>

</n:PersonName>

<n:PersonName n:Type="KnownAs">

<n:NameElement n:ElementType="LastName">Tones</n:NameElement>

<n:NameElement n:ElementType="FirstName">Pleasant</n:NameElement>

</n:PersonName>


AppendixE–PseudonymousIdentifiersThis appendix contains sample XML code to illustrate how exchanging parties can incorporate a pseudonymous identifier in an exchange file by using the "PartyID" and "PartyIDType" attributes for the <Party> container. The IVS is expected to incorporate such an identifier when it exchanges identity-related data.

<p:Party p:PartyID="1234567" p:PartyIDType=”IVS”>

<p:PartyName>

<n:PersonName>





</n:PersonName>

</p:PartyName>

</p:Party>

4�


4�

AppendixF–InterpretingtheDiagrammaticModelsofCIQv3.0The schema diagrams in this Standard are generated by Altova’s XML editing tool, XMLSpy. They are designed to help understand the schema, rather than study the schema files directly.

XMLSpy diagrams use the following symbols:

Element Symbolexample Details

Mandatory Container Element (expanded).

Mandatory Container Element (expanded). Element that has been selected.

Means exactly the same as the example above

Mandatory Single Element. MinOcc=1, MaxOcc=1

Mandatory Single Element, containing parsed Character Data (#PC-Data). The content may be simple content or mixed complex content.

MinOcc=1, MaxOcc=1, type=xsd:string, content=simple

Mandatory Container Element (collapsed), Pointer.

MinOcc=1, MaxOcc=1

Optional Single Element. MinOcc=0, MaxOcc=1

Mandatory Multiple Element. Can occur 1 g 5 times.

MinOcc=1, MaxOcc=5

Mandatory Multiple Element containing unparsed character data. Can occur 1 g infinite times.

MinOcc=1, MaxOcc=1, free format text

Mandatory Multiple Element containing child elements. Can occur 1 g infinite times.

MinOcc=1, MaxOcc=unbounded, type=DivisionType, content=complex

Mandatory Multiple Element, Container (collapsed), pointer. Can occur 1 g infinite times.

MinOcc=1, MaxOcc=unbounded

Optional Multiple Element, containing parsed character data. Can occur 0 g infinite times.



Element Symbolexample Details

Optional Multiple Element, Container (collapsed). Can occur 0 g infinite times.


Mandatory Group element (a named collection of elements to allow reuse in the construction of different complex types).

name=Subsidiaries

‘Any’ can be a placeholder for any element from a certain namespace.

See www.w3.org/TR/xmlschema-0/ - any for details

Optional Multiple Group Element. Can take any name, can occur 0 g infinite times.


Connector, 1 to 1 relationship.

MinOcc=1, MaxOcc=1

Optional Choice Container (expanded).

MinOcc=1, MaxOcc=1

Mandatory Choice Container (expanded).


48


4�

AppendixG–FileInterpretationandNavigationThis appendix contains XML Path Language (XPath) statements that can be used to locate the person’s identity-related data elements in the sample validated exchange file shown in Appendix H. Exchanging parties should use the latest XPath statements available, agreed by the parties.

xPIL v3.0 Data element XPath statement

First Name //Party/PartyName/PersonName/NameElement

where ElementType = “FirstName”

Last Name //Party/PartyName/PersonName/NameElement

where ElementType = “LastName”

Middle Name //Party/PartyName/PersonName/NameElement

where ElementType = “MiddleName”

Gender //Party/PersonInfo(Gender) = “enumeration list value for gender”

Mother’s Name //Party/BirthInfo/BirthInfoElement

where BirthInfoElement(Type) = “MothersName”

Birth Year //Party/BirthInfo/BirthInfoElement

where BirthInfoElement(Type) = “BirthYear”

Birth Month //Party/BirthInfo/BirthInfoElement

where BirthInfoElement(Type) = “BirthMonth”

Birth Day //Party/BirthInfo/BirthInfoElement

where BirthInfoElement(Type) = “BirthDay”

Birth Time //Party/BirthInfo/BirthInfoElement

where BirthInfoElement(Type) = “BirthTime”

Place of Birth (Country) //Party/BirthInfo/BirthPlaceDetails/Country/NameElement

where NameElement(Abbreviation)= “true”

Place of Birth (Locality) //Party/BirthInfo/BirthPlaceDetails/Locality/NameElement

where NameElement(NameType)= “Type”

AppendixH–SampleValidatedExchangeFileThis appendix contains a sample validated exchange file. The record in the sample file is for illustrative purposes only.

<?xml version="1.0" encoding="UTF-8" ?>



<c:Customers

xmlns:c="urn:acme.org:corporate:customers" xmlns:a="urn:oasis:names:tc:ciq:xal:3"

xmlns:n="urn:oasis:names:tc:ciq:xnl:3" xmlns:p="urn:oasis:names:tc:ciq:xpil:3"

xmlns:ct="urn:oasis:names:tc:ciq:ct:3" xmlns:xlink="http://www.w3.org/1999/xlink"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:acme.org:corporate:customers sample-xPIL-wrapper.xsd">

<p:Party>

<p:PartyName>

<n:PersonName>





</n:PersonName>

</p:PartyName>

<p:PersonInfo p:Gender="M" />

<p:BirthInfo>

<p:BirthInfoElement p:Type="MothersName">Jane Public</p:BirthInfoElement>

<p:BirthInfoElement p:Type="BirthYear">1963</p:BirthInfoElement>

<p:BirthInfoElement p:Type="BirthMonth">11</p:BirthInfoElement>

<p:BirthInfoElement p:Type="BirthDay">01</p:BirthInfoElement>

<p:BirthInfoElement p:Type="BirthTime" />

<p:BirthPlaceDetails>

<a:Country>


a:NameType="Name">NZ</a:NameElement>

</a:Country>

<a:Locality>

<a:NameElement a:NameType="Type">Town</a:NameElement>

<a:NameElement a:NameType="Name">Taihape</a:NameElement>

</a:Locality>

</p:BirthPlaceDetails>

</p:BirthInfo>

</p:Party>

</c:Customers>

�0


�1

NOTE – The exchange file has been validated against the CIQ Specifications v3.0 and a

modified XML schema definition file (xPIL-types.xsd) that reflects the customisations

introduced by this Standard to allow the mother’s name and date of birth to be represented

(see 6.4.4.1 and 6.4.4.2). The State Services Commission expects to implement an object

repository as an authoritative source of modified XML schema definition files. Until such

time as an object registry is available to host (among other objects) modified XML schema

definition files, exchanging parties will have to agree among themselves on modifications to

this XML schema definition file. The schema definition file should be modified by inserting

the following XML code:

<xs:enumeration value="MothersName"/>

<xs:enumeration value="BirthYear"/>

<xs:enumeration value="BirthMonth"/>

<xs:enumeration value="BirthDay"/>

<xs:enumeration value="BirthTime"/>

data formats for identity records standard · data formats for identity records standard 0 foreword...

Documents