Minimal disclosure tokens: the case of SSO
As mentioned in my previous post, minimal disclosure tokens are about ensuring that identity claims convey no identity-related information whatsoever beyond any attribute statements they may contain. (”Selective disclosure” adds privacy functionality on top of this, by enabling users to disclose properties of that attribute data without revealing more; see here for details.) Anonymity and pseudonymity are just two possible requirements that can be met. If an identity claim is required to contain a unique identifier that is known to both the identity provider and the relying party, the identity provider can simply encode an identifier into the minimal disclosure token in the form of an attribute statement. In other words, minimal disclosure tokens are all about technologically complying with the principle of least privilege (aka the principle of least authority).
To illustrate that minimal disclosure technology is not all about anonymity, the figure below illustrates the benefits of using minimal disclosure tokens for giving users an SSO experience.
In this scenario, users log into personalized services (or accounts) at different Service Providers (SPs) by using different minimal disclosure tokens that are issued to them by an Identity Provider (IdP, called Authority in the figure). Service Providers (SPs) may, and often will, “know” users under their “real name” or other identifiers, whether universally unique identifiers or identifiers that are unique only within their own context. The association between a user’s “name” at an SP and a presented token can take place at presentation time; it must be established once in a “roll-over” phase, whereupon the user can revisit the SP by simply proving knowledge of the private key of the associated token.
The Identity Provider may, and typically will, also know the user in some manner — for example to facilitate a payment-for-tokens relation, or to verify that the user meets prerequisite requirements before issuing login tokens to that user.
However, and this is the important thing to notice, owing to the unlinkability features of the tokens themselves, SPs cannot link their identifiers for the user even when they collude with the IdP — unless, of course, such linking capabilities were enabled by explicitly encoding common identifiers into the tokens at issuing time.
Isn’t it a bit paranoid, you might ask, to worry about the IdP and SPs colluding? (See also Kim’s post titled “Collusion takes effort; how much?“) Well, keep in mind that in many cases the SPs and the IdP are part of the same entity. Even if they are not, legal requirements may impose the central collection of (user-authenticated) audit transcripts of login sessions, in which case the central audit log repository contains all the data needed to do cross-domain linking (which might be undesirable for SPs themselves!). Last, but not least, in many environments there are strong incentives for collusions, whether for profit motives or for security-related reasons.
But ultimately this is the wrong question to ask. Instead, you should ask yourself: what is the justification for adopting an SSO solution that has the unintended inescapable side effect of hardwiring cross-domain linking powers, when such can easily be prevented? By adopting an SSO solution based on minimal disclosure tokens, one can support all possible use cases rather than merely those where cross-domain linking capabilities are not problematic.
