TOC 
DraftN. Sakimura
 NRI
 J. Bradley
 Ping Identity
 February 3, 2013


OpenID Connect Privacy Consideration 1.0 - draft 00

Abstract

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

OpenID Connect handles various form of personal data and thus has privacy implications. At the same time, implemented correctly, OpenID Connect behaves as a Privacy Enhancing Technology (PET). This specification provides privacy consideration and guidelines for OpenID Connect.



Table of Contents

1.  Introduction
    1.1.  Requirements Notation and Conventions
2.  Terminology
    2.1.  personally identifiable information (PII)
    2.2.  PII controller
    2.3.  PII principal
    2.4.  PII processor
    2.5.  privacy controls
    2.6.  privacy enhancing technology (PET)
    2.7.  privacy stakeholder
    2.8.  processing of PII
3.  Privacy Principles of ISO/IEC 29100
    3.1.  Consent and choice
    3.2.  Purpose legitimacy and specification
        3.2.1.  Legitimate purpose
        3.2.2.  Communicating the purpose(s)
    3.3.  Collection limitation
    3.4.  Data minimization
        3.4.1.  Minimizing the amount of PII each entity processes
        3.4.2.  Enforcing "need-to-know" principle
        3.4.3.  Reduce obserbablity and linkability of PII collected
        3.4.4.  Data deletion
    3.5.  Use, retention and disclosure limitation
        3.5.1.  Limiting the use to the specified purpose
        3.5.2.  Limiting the retention
        3.5.3.  Cross-border Transfer
    3.6.  Accuracy and quality
        3.6.1.  Ensuring the PII is accurate, complete, and up-to-date
        3.6.2.  Verifying the self-claimed PII
    3.7.  Openness, transparency and notice
    3.8.  Individual participation and access
    3.9.  Accountability
    3.10.  Information security
    3.11.  Privacy compliance
4.  IANA Considerations
5.  References
    5.1.  Normative References
    5.2.  Informative References
Appendix A.  Acknowledgements
Appendix B.  Notices
Appendix C.  Document History
§  Authors' Addresses




 TOC 

1.  Introduction

OpenID Connect identifies a user and transfers various data and metadata about the identified user. As such, by definition, most data handled in OpenID Connect are personally identifiable information (PII). Thus, any party implementing this protocol SHOULD examin the privacy impact of the system.

This specification gives a high-level discussion of them based on several privacy frameworks.



 TOC 

1.1.  Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.



 TOC 

2.  Terminology

This specification uses the terms "Access Token", "Refresh Token", "Authorization Code", "Authorization Grant", "Authorization Server", "Authorization Endpoint", "Client", "Client Identifier", "Client Secret", "Protected Resource", "Resource Owner", "Resource Server", and "Token Endpoint" defined by OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749], and the terms defined by OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.) [OpenID.Messages].

This specification defines the following additional terms:



 TOC 

2.1.  personally identifiable information (PII)

any information that (a) can be used to identify the PII principal to whom such information relates, or (b) is or might be directly or indirectly linked to a PII principal

[ISO29100] (ISO/IEC, “ISO/IEC 29100 Information technology — Security techniques — Privacy framework,” November 2011.)



 TOC 

2.2.  PII controller

privacy stakeholder (or privacy stakeholders) that determines the purposes and means for processing personally identifiable information (PII) other than natural persons who use data for personal purposes

[ISO29100] (ISO/IEC, “ISO/IEC 29100 Information technology — Security techniques — Privacy framework,” November 2011.)



 TOC 

2.3.  PII principal

natural person to whom the personally identifiable information (PII) relates

[ISO29100] (ISO/IEC, “ISO/IEC 29100 Information technology — Security techniques — Privacy framework,” November 2011.)



 TOC 

2.4.  PII processor

privacy stakeholder that processes personally identifiable information (PII) on behalf of and in accordance with the instructions of a PII controller

[ISO29100] (ISO/IEC, “ISO/IEC 29100 Information technology — Security techniques — Privacy framework,” November 2011.)



 TOC 

2.5.  privacy controls

measures that treat privacy risks by reducing their likelihood or their consequences

[ISO29100] (ISO/IEC, “ISO/IEC 29100 Information technology — Security techniques — Privacy framework,” November 2011.)



 TOC 

2.6.  privacy enhancing technology (PET)

privacy control, consisting of information and communication technology (ICT) measures, products, or services that protect privacy by eliminating or reducing personally identifiable information (PII) or by preventing unnecessary and/or undesired processing of PII, all without losing the functionality of the ICT system

[ISO29100] (ISO/IEC, “ISO/IEC 29100 Information technology — Security techniques — Privacy framework,” November 2011.)



 TOC 

2.7.  privacy stakeholder

natural or legal person, public authority, agency or any other body that can affect, be affected by, or perceive themselves to be affected by a decision or activity related to personally identifiable information (PII) processing

[ISO29100] (ISO/IEC, “ISO/IEC 29100 Information technology — Security techniques — Privacy framework,” November 2011.)



 TOC 

2.8.  processing of PII

operation or set of operations performed upon personally identifiable information (PII)

[ISO29100] (ISO/IEC, “ISO/IEC 29100 Information technology — Security techniques — Privacy framework,” November 2011.)



 TOC 

3.  Privacy Principles of ISO/IEC 29100

[ISO29100] (ISO/IEC, “ISO/IEC 29100 Information technology — Security techniques — Privacy framework,” November 2011.) lists the following as the privacy principles.

  1. Consent and choice
  2. purpose legitimacy and specification
  3. Collection limitation
  4. Data minimization
  5. Use, retention and disclosure limitation
  6. Accuracy and quality
  7. Openness, transparency and notice
  8. Individual participation and access
  9. Accountability
  10. Information security
  11. Privacy compliance

In this section, the relationship between the above principles and the OpenID Connect protocols are examined.



 TOC 

3.1.  Consent and choice

To adhear to this principle, the Authorization Server needs to obtain a consent from the PII principal except in the cases where applicable law specifically allows the processing without the consent. The consent can be either explicit or implicit, but has to be given freely, specific and on a knowledgeable basis.

Typically, this would be achieved in OpenID Connect through the authorization screen. However, it should be noted that people are unlikely to read the lengthy terms and mearly displaying the consent screen would result in "consent without knowledge", which is invalid in many cases.

Typical threats to this principles are as follows:

[[to be continued]]



 TOC 

3.2.  Purpose legitimacy and specification



 TOC 

3.2.1.  Legitimate purpose

To examine whether the purpose is legitimate or not is out of the scope of the protocol. However, the client MUST make sure that the purpose is legitimate. Also, the authorization server SHOULD reject the request with apparently illegitimate purpose.

When utilizing some form of trust framework, the trust framework provider may offer the service to examine the legitimacy of the purpose.



 TOC 

3.2.2.  Communicating the purpose(s)

The OP, before obtaining the user authorization, SHOULD communicate the purpose to the user. This is typically achieved through displaying the purpose(s) to the authorization screen. It is well known that lengthy terms of service and privacy policies will not be read by most users. Therefore, a concise and standardized way of showing the purpose similar to Kantara Initiative's Standard Information Sharing Label or ToS-DR SHOULD be considered.

It should be noted that it may not be desirable to always show the authorization screen to the user as it will just train the user to click without reading. Sometimes, the purpose is obvious from the context. In such cases, it probably is desirable not to show the screen. This way, the screen will appear only at the time where the purpose and PII collected is not obvious from the context, giving sufficient warning to the user.



 TOC 

3.3.  Collection limitation

Collection limitation requires the colleciton of PII to strictly necessary for the specified purpose(s). This requires the organization to

Once the set of PII to be collected is determined, the client SHOULD only ask for those PII. This will likely to require the client to use a granular claim request through the request object.



 TOC 

3.4.  Data minimization

Data minization principle requires that the processing of the PII collected to be minimized. Adhering to this principle in the context of OpenID Connect would mean the followings:



 TOC 

3.4.1.  Minimizing the amount of PII each entity processes

Collecting all the PII to the OP results in unnecessary concentration of data and violates this principle. There are at least two possible ways to mitigate this problem.

The first one is to use distributed claims model. This would minimizes the data concentration.

Note that this will let the claims source to know where the data is being sent, creating yet another PII exposure. In many cases, this is not an issue because the destination is known a-priori but in the cases it is not, it has a privacy impact. If this is a real issue, then using the second method described below or something similar to onion routing shoudl be considered.

The second one is to encrypt the claims using the recipient's ephemeral key and provide it through the OP. In this case, OP will not be able to read the claims and thus reduces its PII handling.

Note that the care needs to be taken that the ephemeral key in fact is not the one fabricated by the OP. To avoid this attack, the key may be signed by a trusted third party.



 TOC 

3.4.2.  Enforcing "need-to-know" principle

How the PII is being handled within OP, RP, and the claims sources are out of scope of the OpenID Connect. However, care should be taken to put the access control system in place within each organization, that implements the "need-to-know" principle. Simply implementing a user based access control would not be adequate. The access control system should also record the reason for the access and provide some sort of dynamic access control mechanism based on it.



 TOC 

3.4.3.  Reduce obserbablity and linkability of PII collected

Whenever possible, the systems SHOULD consider using PPID or ephemeral user identifier as sub to reduce the obserbability of the user interactions and linkability of the collected data.



 TOC 

3.4.4.  Data deletion

Relying Parties MUST delete the data once the purpose for PII processing has expired, unless the retention is legally required. In general, it is a good practice to treat the locally stored data only as a cache for the performance sake and delete within a short time period, provided that the re-fetch is possible.



 TOC 

3.5.  Use, retention and disclosure limitation

OP MUST acess control the user's PII so that only the authorized entity can access.

RP SHOULD dispose the collected data once it becomes unnecessary.



 TOC 

3.5.1.  Limiting the use to the specified purpose

RP and OP SHOULD strive to make the purpose clear from the context of the transaction. If it is not, RP and OP together MUST show the consent screen to the user and obtain the explicit consent from the PII principal. OP and SHOULD record the purpose. The RP MUST record the purpose linked to the data and implement the management process that ensures the use outside the purpose would not be performed.



 TOC 

3.5.2.  Limiting the retention

When it becomes unnecessary to retain the data to fulfill the stated purpose, the RP MUST either destroy or anonymize the data.

If there is a legal requirement to retain the data even after the purpose expiration, then the RP MUST archive the data so that the PII is secured and exempted from further processing.



 TOC 

3.5.3.  Cross-border Transfer

When PII is transferred across the border, the PII controller should check if there is any additional national or local requirements specific to cross-border transfers. If there are restrictions, OPs and RPs MUST make sure to comply to it. For example, if PII was being moved from an OP in EU to an RP in a country which was specified as having inadequate privacy protection, the OP SHOULD make sure that the transaction complies to the respective law before proceeding with the transaction.



 TOC 

3.6.  Accuracy and quality

PII processing generally results in yet another PII. If the input PII is inaccurate or incomplete, the resulting PII may become incorrect and sometimes results in denying some rights etc. of the PII principal. Thus, the PII processors SHOULD make sure that the PII processed is accurate, complete, up-to-date, adequate and relevant for the purpose of the use.



 TOC 

3.6.1.  Ensuring the PII is accurate, complete, and up-to-date

Obtaining the data from the original source through distributed claims is one way to achieve it. When obtaining the data from a secondary soruce, such as the OP, care should be taken to see when the data was last updated etc.



 TOC 

3.6.2.  Verifying the self-claimed PII

There are claims that the self-claimed ones are in fact authoritative. However, there are other types of claims that are not. OPs and RPs should put in place the process to verify those self-claimed claims to a desired level of accuracy. Typical example of such process includes the reacheability check of a email and a mobile phone number through SMS.



 TOC 

3.7.  Openness, transparency and notice

This principle requires PII controllers to provide PII principals with clear and easily accessible information about PII controller's poicies, procedures and practices with respec to the processing of PII. For RPs, this is typically done in OpenID Connect by registering respective policies and procedure at the client registration time.

OP MUST make ithem avialabe to the PII principals (uers). Also, OP MUST make the list of the RPs that the data was provided available to the PII principals and SHOULD make the access history available as well. If the PII principal so desires, the OP SHOULD provide the way to notify him via suitable means.



 TOC 

3.8.  Individual participation and access

All of OP, RP, and Attribute Providers SHOULD provide the followings:



 TOC 

3.9.  Accountability

OPs, RPs, and Attribute providers should put in place the management system that achieves accountability on the PII handling.



 TOC 

3.10.  Information security

OPs, RPs, and Attribute providers should put in place the appropriate security controls to safeguard the PII. Adhearing to a management system such as ISO 27001 is recommended.

To facilityate as such, OpenID Connect provides the follwoing capabilities.

For more details, refer to the Security Consideration section of the OpenID Connect Messages and Standard, as well as the OAuth threat model specification.



 TOC 

3.11.  Privacy compliance

To adhear to this principle, each PII Processors has to demonstrate that the level of their PII handling is above the level of what the relevant laws require, and put in place the management system to sustain that level.



 TOC 

4.  IANA Considerations

This document makes no requests of IANA.



 TOC 

5.  References



 TOC 

5.1. Normative References

[ISO29100] ISO/IEC, “ISO/IEC 29100 Information technology — Security techniques — Privacy framework,” International Standard 29100, November 2011.
[OpenID.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2246] Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, January 1999 (TXT).
[RFC3339] Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML).
[RFC4627] Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).
[RFC6125] Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” RFC 6125, March 2011 (TXT).
[RFC6749] Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT).
[RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012 (TXT).


 TOC 

5.2. Informative References



 TOC 

Appendix A.  Acknowledgements



 TOC 

Appendix B.  Notices

Copyright (c) 2013 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.



 TOC 

Appendix C.  Document History

[[ To be removed from the final specification ]]

-00



 TOC 

Authors' Addresses

  Nat Sakimura
  Nomura Research Institute, Ltd.
Email:  n-sakimura@nri.co.jp
  
  John Bradley
  Ping Identity
Email:  ve7jtb@ve7jtb.com