Subject: [Id-event] SET-Token: Privacy Protecting vs. Privacy Enhancing

From: Phil Hunt <[email-masked]>
Date: Thu, 20 Apr 2017 12:07:39 -0700

In reviewing a number of events being proposed based on SET (such as RISC, Logout, SCIM, etc), I notice a pattern that may be important for the privacy considerations and/or definitions section.

The observation is that for some events such as Backchannel Logout, it is clear that the SET should always (SHOULD always) be sent.  Why?

Why do other events, such as in RISC where account state change notices are being discussed require consent?  

How do we differentiate this?  Should we put guidance in the core SET Token spec?

The best answer is some text I will propose for the draft [square bracketed text is not for the draft]:

In Privacy Considerations:

SET Events fall into one of two privacy impact categories that determine how SETs should be handled:

Privacy Protecting
A SET that is used to clean-up or remove information about a subject that may have been previously shared (e.g. an OIDC Connect sign-on). By sending such a SET, the expectation is that the receiver will perform corresponding work to remove or mark invalid corresponding session information in its domain.  For example, any session cookies left in a user-agent are marked invalid and subsequently cleared.

Privacy Protecting SETs SHOULD always be shared and do not require consent for sharing.

[Impact:   OAuth token revocation and Backchannel Logout are two examples of privacy protecting]

Privacy Enhancing
A “privacy enhancing” SET improves the co-ordination of PII and account security that has been previously authorized for sharing by a subject (e.g. through OAuth authorization). The SET does not necessarily enhance or reduce the amount of PII but rather focuses more on protection and co-ordination.  For example, an Identity Provider that suspects that a subject account has been compromised, may choose to notify relying parties of the suspected compromise in an attempt to protect the subject in question. However, since the SET event may not be desired by all subjects, there is an assumption that subject consent be obtained in advance. Such consent can be obtained in many forms (e.g. terms of service, enterprise policy, explicit user consent). 

Privacy Enhancing events may require some process (e.g. as part of distribution) to check and/or manage subject enrolment for the sharing of SETs. In some cases, per Subject enrolment MAY additional negotiation methodologies between SET transmitters and receivers.

[Impact:  RISC seems to require consent for many events, and SCIM events are largely Privacy Enhancing but are often propagated by enterprise policy]

Any objections or text improvements? Maybe some of this belongs in the definition section?

Thanks,

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>