Alec Campbell

Office of the CIO

Government of Alberta

Public Sector Case Studies:

Privacy Architectur

e

Why a Privacy Architecture?

Premise: Technology can help solve privacy problems, not just create them.

PIAs will identify privacy risks, but PIAs alone don’t mitigate risks. Policy and administration provide general direction

but unless they’re machine readable policies are of limited use in IT applications.

The complex privacy issues created by increasingly advanced information technology demand more technical privacy solutions.

“Privacy by Design” requires consistent design standards across the enterprise. Privacy architecture provides such standards.

Architecture Relationships

Busin

ess

Data

Appl

icatio

n

Tech

nolo

gy

Privacy

Security

Privacy Architecture Topics

Horizon 1 (fully addressed)

Terminology – a common language for discussing privacy requirements, issues and solutions

Identification Keys - how will data subjects be uniquely identified?

Data Classification - how should personal information or its uses be classified?

Data Sharing, Re-Use and Placement – to what extent can personal information be shared between departments and where should it be stored?

Privacy Architecture Topics

Horizon 2 (addressed in part)

User Interface - what privacy related features are required and what should they look like?

Data Transformation - guidance for rendering data anonymous (completed with Horizon 1)

Data Subject Access to Data – how should Data Subjects be provided with access to their own data?

Software Acquisition Criteria – privacy criteria for both privacy-enhancing and general software

Consent and Choice - rules for what consents and choices are to be offered

Access Control – expression of “need to know” in a privacy context

Privacy Architecture Topics

Horizon 3 (deferred)

Use of Technology to Enforce Privacy Rules - where should technology be used vs. processes and procedures

Use of Technology to Monitor Privacy Compliance - where should technology be used vs. processes and procedures

Terminology: Privacy Glossary

Defines terms and phrases relevant to PA development

Integrated with broader GAEA glossary Legal and policy definitions take precedence

The term ‘record’ has different meanings in the FOIP/HIA and ICT worlds. Both are recognized, but the FOIP meaning is adopted because it is defined in law.

GLOSSARY

Key Concepts: Identity Domains

Public Body

Program A

IID-1

Program B

IID-2

Identity Domains

FID

ID KEYS

Key Concepts: Data Architecture

Band 1

Band 2

Consistent

Band 3

Unique

Shared

Data Architecture Bands

Features:

Meaningful identifiers are separated from personal attributes Application databases contain only depersonalized

information Identifiers are stored separately under high security Repersonalization is subject to both policy and software

controls

“Federated identifiers” (FIDs) provide a control point for data sharing FIDs must be enabled to share any given data element between any

given pair of identity domains. Authorization is required. Thereafter, authorized data sharing by applications can occur

automatically, under the control of the ID Protection Component.

Identification Keys: ID Key SchemeID KEYS

Public Identifier (PID): used by individuals to identify themselves. E.g., user ID, driver’s license number, personal health

number Internal Identifier (IID): used by applications within a

domain to attach depersonalized individual information to an identity. (MBUN – Meaningless But Unique Number)

Federated Identifier (FID): used by applications in different domains to exchange or share information about an individual, if authorized to do so under FOIP or HIA. (MBUN)

ID KEYS ID Key Scheme

ID Key SchemeSeparation of identity and attributes

3$2K007 461 101Ralph Wiggum

2$97K837 234 003Sally Skinner

1$95K827 364 591Semour Skinner

2$250K987 654 321Joe Quimby

4$45K123 456 789Homer Simpson

RatingSalaryEmployee #Individual

3$2K007 461 101Ralph Wiggum

2$97K837 234 003Sally Skinner

1$95K827 364 591Semour Skinner

2$250K987 654 321Joe Quimby

4$45K123 456 789Homer Simpson

RatingSalaryEmployee #Individual

39608801007 461 101Ralph Wiggum

39570093837 234 003Sally Skinner

00836291827 364 591Semour Skinner

61036229987 654 321Joe Quimby

40598342123 456 789Homer Simpson

Internal IDEmployee #Individual

39608801007 461 101Ralph Wiggum

39570093837 234 003Sally Skinner

00836291827 364 591Semour Skinner

61036229987 654 321Joe Quimby

40598342123 456 789Homer Simpson

Internal IDEmployee #Individual

39608801

39570093

00836291

61036229

40598342

Internal ID

3

2

1

2

4

Rating

$2K

$97K

$95K

$250K

$45K

Salary

39608801

39570093

00836291

61036229

40598342

Internal ID

3

2

1

2

4

Rating

$2K

$97K

$95K

$250K

$45K

Salary

ID KEYS

ID Key Scheme

Program A

PI

Application

1. PIDProtected

Mapping

Service

2. PID

3. IID

4. IID

5. PI

PID = a Public ID (ex: a userid)

IID = an Internal ID (an MBUN)

Use of PID, IID and Protected Mapping Service unhooks direct connection of PI with the externally known ID

ID KEYS

ID Key Scheme OverviewID KEYS

Program A

Customer

PIDPIA

PID

Program B

Electronicdata

IID

FID/IID Identity Protection

PID/IID Identity Protection

PID/IID Identity Protection

PIDElectronic

dataIID

PIDS for Customer interface

FID

S f

or

Dom

ain (

Pro

gra

m)

Inte

rfac

e

IIDS for Depersonalization

YIELDPIA

Customer Service

Customer Service

PID

PID

iMac

PID

iMac

PID

PID

Highly SecureZone

Highly SecureZone

ID Key Scheme ID Protection Component:

Issues and controls Internal IDs, Federated IDs Enables/disables Federated IDs for sharing Controls linkages between Public IDs, Internal IDs and

Federated IDs Stores and maintains ID tables Is located in the restricted zone of the Security

Architecture (highest security) May be one or more ID protection components

One is better for control and administration Multiple (e.g., one per public body) may be better for

performance & scalability Multiple would require central service for federated ID

management across GoA

ID KEYS

Layered ProtectionExternal Destinations

ID Protection Component (GoA)

IdentityDomain

IdentityDomain

IdentityDomain

ID Protection Component- Depersonalization- De-Identification Services- Re-Identification Services- Privacy Linking Services- ID Linking Controls(Highly Secured Services)

ID / Data Linking

ID Key Scheme

Utility functions:IID creation FID enable/disable

IID linkage Administration functions

PID (e.g., Driver’s

License Number)

InternalID #1

InternalID #2

FederatedID

01234-010 234561789092 183927038109 982401765204

12345-123 978742090734 087439874298 774374387428

23456-001 198987437474 210943723987 906347864207

ID Protection Component Example: Public ID

Appl

icatio

n PID

IID

Subject to FOIP, HIA and policy controls

ID KEYS

Privacy Taxonomy (Personal Information Metadata Standard)

Name SIN Address Age Salary

Homer Simpson 123 456 789 12 My Street 47 $60K

Seymour Skinner 372 809 875 245 Elm Avenue 52 $92K

Ned Flanders 375 059 354 11 My Street 45 $85K

In English this might say

“this table contains names, social insurance numbers, addresses, ages and salaries obtained from the individual. . . ”

In the notation of the taxonomy it might be something like:

“SRC=IND”, “CAT=NAM,SIN,ADD,AGE,SAL”, . . .

To be implemented via metadata at the table and column levels.

TAXONOMY

Privacy Taxonomy

Source

Identity

Security

Category

Data Dimensions

Recipients

Purpose

Retention

Intent

Action Obligation

Consequences

Policy Dimensions

P3P Derived EPAL Derived

Conditions

Conditions

Created for the Privacy Architecture

TAXONOMY

Privacy TaxonomyCategory

Dimension

TAXONOMY

Current Location DataLOC

State management mechanismsSTA

Interactive dataINT

Navigation and click-stream dataNAV

Computer informationCOM

Health-related informationHEA

Affiliate informationPOL

Government-issued identifiersGOV

Preference dataPRE

Purchase informationPUR

ContentCNT

Demographic dataDEM

Financial informationFIN

Unique identifiersUNI

Online contact informationONL

Physical contact informationPHY

CategoryCode

Current Location DataLOC

State management mechanismsSTA

Interactive dataINT

Navigation and click-stream dataNAV

Computer informationCOM

Health-related informationHEA

Affiliate informationPOL

Government-issued identifiersGOV

Preference dataPRE

Purchase informationPUR

ContentCNT

Demographic dataDEM

Financial informationFIN

Unique identifiersUNI

Online contact informationONL

Physical contact informationPHY

CategoryCode

Health Services Provider Information HSP

Registration Information REG

Diagnostic Treatment and Care Information DTC

Sub-CategoryCode

Health Services Provider Information HSP

Registration Information REG

Diagnostic Treatment and Care Information DTC

Sub-CategoryCode

Alberta Driver’s License Number DLN

Social Insurance NumberSIN

Alberta Personal Health Number PHN

Sub-CategoryCode

Alberta Driver’s License Number DLN

Social Insurance NumberSIN

Alberta Personal Health Number PHN

Sub-CategoryCode

Root LevelGoA Level

Personal Address PDR

Business AddressBDR

Sub-CategoryCode

Personal Address PDR

Business AddressBDR

Sub-CategoryCode

Province PRV

City CTY

Street Address STR

Sub-CategoryCode

Province PRV

City CTY

Street Address STR

Sub-CategoryCode

Yes

Yes

No

Yes

No

Program

C

YesYesC5

YesNoC4

XYesNoC3

NoYesC2

XNoYesC1

Potentially Shareable Information

Program

B

Program

A

Personal Information Category

Yes

Yes

No

Yes

No

Program

C

YesYesC5

YesNoC4

XYesNoC3

NoYesC2

XNoYesC1

Potentially Shareable Information

Program

B

Program

A

Personal Information Category

1. Data Sharing Analysis

Initial data sharing analysis based on business requirements, to create a potential sharing status.

2. Privacy Impact Assessment

Because so many factors impinge on data sharing, potential sharing status must be confirmed by a PIA to ensure compliance with privacy law and policy.

Standard PIA template for ICT projects may require supplementary items to address band placement

DATA PLACEMENT

Data Sharing, Re-Use and Placement:Placement

Process

C1

C2

C3

C4 C5

Program A Program B Program C

FID FID FID

IIDIID

BAND 1

BAND 2

3. Data Placement Decision

If supported by a PIA, shareable data might be placed in Band 1** of the Data Architecture for use across government.

FIDs would be enabled to implement sharing, on a pair-by-pair basis.

**Band 1 = shared across GoA; Band 2 = ministry specific

DATA PLACEMENT

Applications for privacy transformation (all related to PI disclosure):

Researcher requests Data warehousing Routine disclosure & active

dissemination Reporting functions

Screen display Print functions

Role-specific access & display

Data Transformation:Privacy Transformation TechniquesPRIVACY

TRANSFORM

Privacy Transformation Techniques:Transformation Decision Process Summary

1. Don’t need individualized PI: Aggregation: Aggregate statistics are computed and published (e.g. average of

9 consecutive records). Recommend minimum cell size of 5 as a default.

2. Need individualized PI, but don’t need complete PI: Reduction: One or more fields are removed entirely (usually identifiers) Suppression: Parts of a field are removed (e.g., removing the last three digits of

a postal code or the day and month of a birthdate).

3. Need complete PI, but don’t need precise PI: Generalization: Specific fields or field values are replaced with generalized

fields or values (e.g. replacing an age with a range of ages or an assertion such as > 19 years old or even just a category description)

Perturbation: Field values are perturbed or blurred using a statistical technique (e.g., adding a random number between -10 and +10 to an age)

4. Need precise PI (no transformation): PIA: Do PIA with intent to release identifying information.

PRIVACY TRANSFORM

The Future: Horizon 3 Active Privacy

Application

Individuals

Privacy Data Handling

Act as gatekeeper for access to personal dataKnow where personal data is storedMake Real-time policy decisionsTransform data to less sensitive forms

Privacy User InteractionSend requests to data subjectsProvide access for data subjectsPresent and negotiate policies

DataUsers

Privacy Services

Manage policyRecord requests and decis ionsManage privacy obligations

Policy Consent

DataLog Data

Personal Information

Privacy specific communications

Request/Provide Privacy specific

information

Policy Management and Tracking

Privacy Directory and SecurityManage Identity ProtectionManage Pseudonyms and CredentialsManage Attribute Exchange

Privacy Support ToolsPolicy EditorsLog AnalyzersVulnerabil ity CheckersInventory Tools

• Rule based

• Metadata dependent

• Real time

• Transparent

Overview Report

Display copy at publications table.

Sign up to have a PDF copy sent to you after the conference.

Alec CampbellExecutive Director,

Privacy Policy & AssessmentOffice of the Chief Information Officer

Government of Alberta

9th floor, John E. Brownlee Building, 10365 – 97 StreetEdmonton, AB, Canada T5J 3W7

Tel: 780-427-3986 Fax: 780-422-0956

Email: alec.campbell@gov.ab.ca

Privacy Architecture on the Web: http://www.sharp.gov.ab.ca/itm_projects/gaea/

(Click on Completed Projects)

Questions?