Skip to main content
Skip to secondary navigation
Menu
Australian Government - Office of the Australian Information Commissioner - Home

Consultation on Australian Government Smartcard Framework (version 0.12), Standards and Model Specification Part C

Consultation on Australian Government Smartcard Framework (version 0.12 March 2007) Standards and Model Specification – Part C Submission to Australian Government Information Management Office April 2007

pdfConsultation on Australian Government Smartcard Framework (version 0.12), Standards and Model Specification (“Part c”); Submission to the Australian Government Information Management Office (April 2007)

(version 0.12 March 2007)

Standards and Model Specification – Part C

Submission to Australian Government Information Management Office

April 2007

Office of the Privacy Commissioner

The Office of the Privacy Commissioner (the Office) is an independent statutory body whose purpose is to promote and protect privacy in Australia. The Office, established under the Privacy Act 1988 (Cth) (the Privacy Act), has responsibilities for the protection of individuals' personal information that is handled by Australian and ACT government agencies, and personal information held by all large private sector organisations, health service providers and some small businesses. The Office also has responsibilities under the Privacy Act in relation to credit worthiness information held by credit reporting agencies and credit providers, and personal tax file numbers used by individuals and organisations.

Background

The Office of the Privacy Commissioner (“the Office”) welcomes the opportunity to provide comments on Part C of the Australian Government Smartcard Framework (“the Framework”), which deals with Standards and Model Specification (“Part C”).[1] The Office has previously made a submission on the Draft Smartcard Framework in March 2006[2], and welcomes the attention that has been paid to privacy issues by the Australian Government Information Management Office (AGIMO) during development of the Framework. The Office intends to make further comments on the recently released Version 2.0 of the Smartcard Implementation Guide (Part D of the Framework), and understands that comments are requested by 4 May 2007.

Preliminary matters

Part C states that many privacy issues are dealt with in Part D.[3] The Office suggests that privacy may be best addressed by affording it consideration at all possible stages throughout a project. In addition, appropriate technical constraints on information flows, when implemented strategically, can support agency business requirements by protecting privacy and contributing to an effective and trusted smartcard system. Accordingly, while noting that some of the measures that are intended to address privacy will be in Part D of the Framework, the Office offers the following comments on Part C.

The Office notes that the Framework is intended to provide guidance on the implementation of smartcard technology to all levels of government. These comments do not address issues raised by the application of the Framework in other jurisdictions, other than to note that in some jurisdictions, there is no privacy regulation, or regulation that may not afford equivalent protections to the Privacy Act 1988 (Privacy Act). In the Office’s view, this highlights the importance of privacy protections being built in to the Framework in the form of policy and technology solutions.

Interoperability

An underlying policy setting of Part C is the establishment and facilitation of interoperability. Related to this is the concept of “Communities of Interest” (COI), which is “a defined population of smartcard issuers and third parties that have a common requirement to interoperate”. The Office is of the view that unconstrained interoperability may heighten the risk of function creep – the incremental expansion in the purposes for which a system or object is used, resulting in the system or object being employed for purposes that were not initially agreed to or envisaged.[4]

Extensive interoperability may also create risks inconsistent with some of the aims of the Framework; in particular, increasing the security of government information and resources, and better protecting an individual’s personal information.[5] Further, circumstances where a smartcard can be compatibly used with other systems, including unrelated systems, could reduce the level of control an individual has over their information, and the security and protections applied to that information.

The Office recognises that AGIMO considers that achieving interoperability of smartcard systems is an important aspect of the Framework. The Office suggests that a more privacy enhancing way to approach this goal is to consider interoperability in light of the planned and intended uses of a particular smartcard implementation. Where smartcard initiatives are pursued with adequate planning and forethought, it should be possible to clearly define the COI and ensure that only an appropriate and necessary degree of interoperability is established within that COI. Determining the specific potential applications of a smartcard is also likely to advance an agency’s obligations under the Privacy Act 1988 (‘Privacy Act’) to identify the purpose for which it collects personal information.

The following statements appear to support the proposal that interoperability may be appropriately limited by the scope and intended use of the smartcard:

  • at page 10, there is recognition that the interoperability requirements will vary with each project, including where there may be no such requirements;
  • at page 12, there is reference to a need for detailed analysis of particular business requirements, and the anticipated usage of smartcards;
  • at page 17, when addressing cardholder infrastructure requirements, the subheading “Comprehensiveness” states the objective that the infrastructure covers all likely cardholder use cases, which presupposes a thorough assessment of the likely uses;
  • at page 18, as part of the agency infrastructure requirements, the subheading “Specificity” states that “the infrastructure should be configurable to only deliver the defined scope of a specific agency requirement, with no capability to interoperate with others without specific agency permission”; and
  • at page 21, it is acknowledged that the business requirements will vary, and states that a detailed analysis of specific requirements should be undertaken.

These statements indicate a conceptual compatibility with limiting interoperability according to project specifications. However, at times, there appears to be an indication that the intention is unconstrained interoperability. For example, at page 31, reference is made to strategies to “obtain interoperability between all possible devices”.

The Office suggests that AGIMO could resolve this potential inconsistency by expressly stating that efforts towards interoperability should take into account the scope and intended use of the proposed smartcard, and be limited to serving that purpose. If there are demonstrated efficiencies in ensuring that hardware infrastructure maintains maximum interoperability, it may be useful for further consideration to be given to whether interoperability could be restricted to identified COIs through application or software measures, such as the Framework Application Modules.

Planned and managed interoperability also has the advantage of being clear and transparent to smartcard holders about the scope of the project and the use of information related to the smartcard. This measure, in addition to the ability to audit the use of the smartcard, technical measures such as authentication of a reader by a smartcard, and the ability for an individual to access logs of use are likely to reinforce user trust in the smartcard application.[6]

Binding of cardholders to cards

The government infrastructure requirements, from page 17, discusses adequate methods to bind the card to the cardholder, and indicate that this could be done through use of a PIN or appropriate biometric. While there is no statement that identification is always necessary, the Office considers that, for the purpose of clarity, a statement could be included at this point that in some instances binding may not be needed. This would ensure that users of the Framework consider whether, in relation to their business requirements, such a linkage is required.

Discussion of the linkage between the card and the cardholder, from page 20, indicates that the use of common credentialing methods may achieve certain benefits such as economies of scale. The Office reiterates the point made above that AGIMO should give further consideration to whether interoperability at application level, including with regard to authentication measures, could be limited to the particular COI rather than across all smartcard implementations. Consistent with this, on page 26, there is a statement that agencies should undertake an evaluation of the appropriate level of binding for the business purpose. The Office welcomes this recognition that different levels of identification and authentication will be appropriate for different smartcard projects.

There are minimum requirements set out for circumstances where a PIN, password or biometric is utilised to bind an individual to a particular smartcard (or to a logical chip etc). While the security standards that are outlined provide a basis for preventing unauthorised disclosure of the PIN or password this section may also benefit from including a statement which highlights that in some circumstances there will be no need, or limited need, to establish the link between the individual and the smartcard.

Finally, the Office welcomes the indication that biometrics may be used in place of or in addition to a PIN or password “where required”. The use of biometrics as identifiers raises particular issues and while the additional risks can be managed, and can result in a privacy enhancing outcome, they should generally be used after due consideration of whether that level of authentication is required. A Privacy Impact Assessment may also be valuable in such circumstances.[7]

Compliance with the Privacy Act

The Office welcomes the inclusion, on page 18, as part of the agency infrastructure requirements, that implementation should meet the requirements of the Privacy Act. The Office notes, however, that this is a minimum requirement, and that smartcards potentially raise particular risks which may not be adequately addressed through the principle based regulation contained in the Privacy Act. The Office suggests the inclusion of a statement encouraging agencies to consider whether additional legislative protections are warranted.

Security of the System

Finally, the Office notes that on page 22, Part C deals with the chain of trust. The Office suggests that trust in the security of the back end system, where applicable, be included in this section, as this could impact on the integrity of other parts of the system.


[3] Page 29 of Part C

[4] Further information on function creep can be found in the Office’s submission to the Consumer and Privacy Taskforce on the Health and Social Services Access Card – http://www.privacy.gov.au/publications/accesscard_sub_082006.html

[5] Page 3.

[6] As set out in “Transparent, clear and obvious in use” on page 20, and Access controls, on page 29 and 30

[7] The Office has prepared a Privacy Impact Assessment Guide, available at http://www.privacy.gov.au/publications/pia06/index.html.